Read the change before the next request.
Momentum depends on noticing a wrong turn while the change is still small. Review the result against the original request before assigning another task. A concise diff and a concrete verification record make that decision easier.
- 01
Return to the acceptance condition
Restate the outcome the change was meant to deliver. Check the reported failure or requested state yourself when practical. Look for partial completion hidden behind a successful check, such as an empty state that works visually but is missing accessible text or correct data handling.
- 02
Inspect the actual diff
Read changed lines in context and notice unexpected files. Check defaults, error paths, and side effects. Preserve pre-existing user edits and distinguish them from this task's work. Ask for a concrete explanation when a small behavior change includes dependency churn or an unrelated refactor.
- 03
Make one clear decision
Accept the iteration, request a specific correction, or name the evidence still required. Keep corrections tied to the original outcome. If a new idea emerges during review, write it as the next task. That prevents a completed change from expanding indefinitely.
A useful finish
You have an explicit acceptance decision and no unexplained file changes within the iteration.
A focused review request
Review this change against [acceptance condition]. Identify bugs, regressions, and missing evidence with file references. Account for pre-existing edits. Summarize what the checks prove. Do not add features or alter the implementation during the review.