Self-Review

Self-Review

Run an explicit second-pair-of-eyes pass on non-trivial work before declaring done. Quality of review depends on quality of question.

When to RUN self-review

• More than ~30 lines OR multi-file change
• Hot path (many requests flow through this code)
• Subtle interactions with code you might have missed
• Prompt or output affecting user-visible content
• Code not worked in recently (mental model might be stale)
• Any genuine uncertainty after writing the change

When to SKIP self-review

• One-line edit, mechanical fix, obvious diff
• Pure rename or move with no logic change
• Code just written with full context, low blast radius
• Cost-benefit doesn't justify (review takes longer than the fix did)

If skipping, say so explicitly: "Skipping self-review — N-line trivial fix." Don't silently bypass.

How to execute

Step 1 — Set context (3-5 lines max)

State, in plain language:

• The bug / feature / what was asked
• The cause (what was actually wrong)
• The fix (what was actually changed)

Step 2 — List specific changes

- path/to/file_one.ts:L123-L145 — replaced regex with structured parser
- path/to/file_two.ts:L56 — added null guard for empty corpus
- path/to/config.json — bumped diversity_threshold 0.6 → 0.75

Step 3 — Ask 4-6 specific verification questions

Bad asks (do not produce useful answers):

• "Is this good?"
• "Does this look right?"
• "Any issues?"
• "Did I miss anything?"

Good asks (concrete, falsifiable, named):

• "Does the new keyword order ever cause a wrong branch in routeRequest?"
• "Does the diversity rule reach the model in the same prompt as the recent-titles list?"
• "Is the early return at line 47 still bypassing this check?"
• "If recent_titles is empty (first run), does the sort comparator return stable output?"
• "Does the schema migration handle the existing 12K null rows or only new inserts?"

Each question must:

• Reference a specific file:line or function name
• State the failure mode you're worried about
• Be answerable yes/no after a focused read