A coding agent needs enough context to make a correct change, but more text does not always make the task clearer. Useful context is selected for the decision at hand: the requested outcome, constraints, relevant code, and how the result will be checked. A small brief is easier to review and update than a transcript full of unrelated history.
A compact task brief could read: update the settings page so workspace owners can change the display name; preserve the existing membership check; show a useful error if saving fails; update the focused test; run the named settings test command. Link the relevant component and test. This gives the agent a goal, a boundary, and a check while leaving implementation choices open.
Include context that can change the answer
- Task and reason. Name the outcome and why the change is needed.
- Acceptance criteria. Describe success and important failure behavior.
- Project constraints. Include relevant architecture, authorization, tenant, or compatibility rules.
- Relevant code. Point to the component, function, tests, or data model that owns the behavior.
- Verification. Give the exact check and explain the expected result.
Keep instructions current and specific
Separate durable project rules from temporary task details. A rule that applies to every change belongs in project guidance; a one-off constraint belongs in the issue or prompt. State which source controls when instructions conflict. Remove stale setup steps and examples. Replace broad requests such as "make it robust" with the behavior, boundary, or failure case that needs attention.
Make uncertainty easy to report
Ask the agent to list assumptions before implementation when the task is ambiguous. Tell it to stop at a decision boundary that requires product, security, or data ownership judgment. At the end, request a summary of changed files, checks run, results, and unresolved questions. This summary is a claim about the work; inspect the files and check output before treating it as confirmation.
Write a handoff another session can use
Store decisions, current state, and remaining work in the issue or project notes. Include the exact command that failed and relevant output when debugging. Avoid copying secrets, customer data, or an entire chat into a shared record. A useful handoff lets the next person start from project facts and evidence rather than guess which parts of a conversation still apply.
Review context as part of code review. If the agent needed an undocumented decision or repeatedly touched unrelated files, improve the task record or project instructions. Better context should make work easier to explain and verify, not merely produce a longer prompt.