Bring the evidence into view.
Review starts with the original acceptance condition. Read the diff as an explanation of how the behavior changes, then inspect the evidence behind that explanation. A successful command only proves what that command actually exercised.
Inspect the behavior boundary
Look for altered public inputs, defaults, error paths, and side effects. Check that the change handles the reported failure without breaking the nearby valid case. Review dependency and lockfile changes deliberately. Unexpected files in a small task are a reason to ask how they contribute.
Read the verification record
Ask for the commands run, their outcomes, and any checks that were unavailable. Distinguish a targeted test from a full suite and a static check from runtime behavior. For UI work, inspect the affected screen and relevant small viewport rather than relying only on compilation.
Checkpoint
- Diff answers the original brief
- Relevant failure and valid case checked
- Unrun checks and remaining risks stated
Read-only transmission
Review this diff against [acceptance condition]. Prioritize bugs and behavioral regressions. Cite file locations for findings. Explain what the available test evidence proves and what remains unverified. Do not modify the implementation during this review.
Close the task with an explicit result: accepted, needs a specific correction, or blocked on named evidence. Avoid a vague "looks good".
Next: Context handoff