Give your coding agent a task contract it can finish

“Fix the app” is a mood, not a task. I understand the mood. But an agent needs a finish line that another person can recognize. A useful task contract is short enough to read and concrete enough to constrain the work. It is an engineering habit, not a claim that a new prompt format makes every model reliable.

Write the user-visible result first

Start with a trigger and an outcome: “When an empty CSV is uploaded, show an actionable message and preserve the current workspace.” That is more useful than “improve error handling.” Add a real failing example with private information removed. Name the repository and branch or worktree so the agent does not infer a target from whichever directory happens to be open.

Define what the agent may change. For a frontend validation fix, database migration and authentication redesign are probably outside scope. If those areas turn out to be relevant, the agent should bring evidence back instead of silently expanding the project. The contract should also state any already-authorized deployment or publication step; memory and comments in a file cannot grant that permission.

Ask for evidence that fits the change

A good acceptance statement has an observable result. “The supplied empty file produces the error, the previous dataset remains readable, and a valid import still succeeds” is testable. The particular checks should come from the failure risk, not from a ritual to run every tool in the repository.

Use a compact handoff structure:

Target: empty-CSV import behavior
Allowed area: importer and its error UI
Acceptance: no workspace loss; valid import still works
Evidence: reproduction, focused checks, changed files
Handoff: result, limits, next required action

This is an original example, not a configuration format for a particular harness. Keep credentials and customer files out of the task text. Link to authorized fixtures instead.

Make partial progress honest

An agent may discover that the failure occurs in a dependency it cannot safely change. A useful report says what it reproduced, what it changed, what remains, and which check supports each statement. A plan is not an implementation; a file edit is not a passing test; a passing local test is not a deployed fix.

Review the result against the original acceptance statement before asking for more work. If the goal changes, update the contract rather than layering contradictory messages on top. Clear boundaries save time because the worker can make routine choices independently while still knowing where its authority ends.