Self Review
Review your own diff as if a stranger wrote it and your name goes on the approval. Your context is biased toward what you meant to write, so this pass works from artifacts only: the actual diff and files, not your memory of editing them.
1. The full diff, top to bottom
Run git diff (and git status for untracked files). Read every hunk. You are hunting, in order of frequency:
- Debug leftovers:
console.log/print/ dump statements added while working; temporary sleeps; verbose flags. - Scratch artifacts: test scripts, fixtures, output files you created to iterate and forgot. Untracked files you can't name a reason for: delete.
- Commented-out code and TODOs you could resolve right now.
- Hardcoded temporaries: paths, ports, ids, credentials, dates that were placeholders.
- Orphans: imports/variables/functions your later edits made unused.
- Accidents: deleted lines you don't remember deleting, files changed that the task had no business touching, formatting churn on untouched lines.
2. The AI-accent sweep
Would a reviewer smell generated code? Remove the accent:
- Comments that narrate ("// fetch the user"), explain the change ("// updated to new API"), or tutor. Keep only constraint comments the code can't express.
- Defensive bloat: null checks and try/catch on paths that cannot fail, validation of internal calls. Boundaries validate; internals trust.
- Speculative generality: parameters nothing passes, options nothing sets, abstractions with one caller.
- Convention mismatch: naming style, error idiom, file layout diverging from the neighboring code. The codebase's way wins over yours.
3. The requirements cross-check
Re-read the original request word by word. For each explicit and implicit requirement, point at the diff hunk that satisfies it. No hunk → it's not done, no matter how done it feels. This is where multi-part requests silently lose part 3 of 4.
Also the inverse: for each diff hunk, name the requirement it serves. Hunks serving no requirement are scope creep: revert them or justify them explicitly in the report.
4. The adversarial minute
Assume this diff contains exactly one bug and you must find it before the reviewer does. Best places to look: boundaries between changed and unchanged code, error paths you never exercised, the caller you updated from memory instead of grep, off-by-one at edges (empty list, first/last item, missing key).
For changes above ~150 lines or touching shared interfaces, don't trust your own adversarial minute: spawn the fresh-context verifier (agents/verifier.md pattern) and give it the requirements + diff, not your reasoning.
5. Close
Fix what you found (each fix re-enters this review), then proceed to verification (/verify-done) if you haven't run it. In the report, mention anything you noticed but deliberately left alone.
