Start with the smallest useful picture of the work. In this local sample, that means naming the customer outcome, the files that own it, and the check that would make the change believable.
What changes in practice
Write the outcome, the boundary, and the proof in three lines. Everything else is supporting evidence.
$ codex exec "review the changed boundary"
→ reading the scoped files
✓ focused checks passedWrite the outcome, the boundary, and the proof in three lines. Everything else is supporting evidence.
The technique is less about making prompts short than making decisions reversible. A good brief gives an agent a place to stop exploring and a clear reason not to modify nearby systems.
For repeat work, keep a tiny handoff note beside the issue: what was observed, what is deliberately out of scope, and which command was last green. It makes the next session feel like continuity rather than archaeology.
Keep this close
- Outcome before implementation
- Exact file or service boundaries
- One focused verification command