Write tasks a reviewer can follow on their own

A reviewer shouldn't need the original chat session to work out why a change exists. Before implementation starts, the task needs a bounded objective, the current behaviour, the expected behaviour, any constraints and the checks that decide whether it's accepted.

For a coding agent, I'd want the task to include:

1. The problem you can observe, or the outcome being asked for.
2. The users, roles or system boundary involved.
3. Evidence of how it behaves right now.
4. Which repository and files the agent is allowed to touch.
5. What's explicitly out of scope.
6. The tests and verification commands it has to run.
7. Any security, privacy, compatibility or migration constraints.
8. What the agent has to hand back for review.

Write acceptance criteria as things you can observe. "Improve error handling" leaves the reviewer guessing. A better criterion names the failing input, the response or state you expect, the record that should get written and what a retry should do. You can test that without buying into the agent's implementation.

If the task implements a specification, include the relevant section and its version. If it fixes a defect, keep the reproduction steps. Private messages can explain the request early on, but the approved requirement should live somewhere reviewable in the project before code gets merged.

Be honest about what you don't know yet. An agent can go and find out which component owns a particular state transition and come back with evidence, without editing any code. If you mix that discovery work into one broad implementation instruction, the first plausible answer it finds tends to become the architecture.

Review the task itself for scope, too. If two engineers could read it two different ways, several parallel agents will give you several answers that don't fit together. Settle the decision or split the work before you've paid for the review.