CodeRigor

LESSON

Write a task another engineer can execute

Specify outcome, writable files, acceptance and exact checks before asking for a patch.

A useful task is a compact engineering contract: outcome, scope, accepted behavior and verification. “Fix money parsing” leaves almost every important decision unresolved. The owner should specify the existing function signature, the decimal grammar, writable files and evidence before a proposal is evaluated.

Our final bug-fix task allows changes only to money.py. The sealed acceptance suite stays outside that write scope. In the first lesson you practiced writing acceptance; in the final replay the owner supplies those tests independently. The distinction matters: an agent should not silently weaken the oracle while claiming a correction.

A bounded engineering task
start / 3
State the outcome, scope, API and checks before evaluating implementation.
A bounded engineering task
State the outcome, scope, API and checks before evaluating implementation.

Make the goal concrete and keep the patch boundary narrow. The task also lists the required checks in an intentional order. Unknown commands and duplicate entries are invalid declarations, rather than opportunities for the worker to invent a different verification process.

The frozen TaskSpec stores tuples so later code cannot mutate its scope by editing the original list. Canonical relative paths avoid ambiguous spellings in this fixture. This validation concerns a declared snapshot; a real filesystem still needs symlink, permission and process isolation controls.

Python
task = {"goal":"Return canonical integer cents", "writes":["money.py"],
        "acceptance":["0.29 -> 29", "1e2 -> ValueError"],
        "checks":["unit", "syntax"]}
print(task["goal"])
print("writes", ", ".join(task["writes"]))
print("checks", " then ".join(task["checks"]))

Separate acceptance statements from commands. “Return29 for canonical0.29” describes behavior; “run the unit suite” describes evidence collection. Both belong in the task. A required tool that cannot run is an unresolved check, not permission to mark the task complete.

Useful prompts also ask the worker to explain the cause, keep unrelated files unchanged and report uncertainty. They should not demand fabricated test results or hide a failed check. The local prompt template gives a concrete example you can reuse with your chosen tool.

Inspect the boundary
start / 3
State the outcome, scope, API and checks before evaluating implementation.
Inspect the boundary
State the outcome, scope, API and checks before evaluating implementation.
Python
from dataclasses import dataclass
@dataclass(frozen=True)
class Scope:
    paths: tuple[str, ...]
paths = ["money.py"]
scope = Scope(tuple(paths))
paths.append("tests.py")
print(scope.paths)
print("tests.py" in scope.paths)

Implement declaration validation and check both ordinary and malformed tasks. Then draft the real bug-fix task in task.json. Keep the API and acceptance grammar explicit enough that another engineer can challenge a proposal without guessing your intention.

Watch & read

Free lectures, talks and readings that cover this skill from another angle. All resources →