Write tasks that carry their own review context

A reviewer should not need the original chat session to understand why a change exists. The task needs a bounded objective, current behaviour, expected behaviour, constraints and acceptance checks before implementation begins.

A useful coding-agent task contains:

1. The observable problem or requested outcome.
2. The relevant users, roles or system boundary.
3. Evidence showing the current behaviour.
4. The permitted repository and file scope.
5. Explicit exclusions.
6. Required tests and verification commands.
7. Security, privacy, compatibility or migration constraints.
8. The artefacts the agent must return for review.

Write acceptance criteria as observations. "Improve error handling" leaves the reviewer guessing. A stronger criterion identifies the failing input, the response or state expected, the record that should be written, and the behaviour of a retry. It can be tested without adopting the implementation proposed by the agent.

Link decisions to their source. If a task implements a specification, include the relevant section and version. If it fixes a defect, preserve the reproduction steps. Private messages may explain the request during discovery, but the approved requirement should live in a reviewable project artefact before code is merged.

State unknowns honestly. An agent can investigate which component owns a state transition, then return evidence without editing code. Mixing discovery and implementation in one broad instruction encourages the first plausible answer to become architecture.

Review the task itself for scope. If two engineers would reasonably interpret it in different ways, several parallel agents will produce several incompatible answers. Resolve the decision or split the work before paying the review cost.