The Code Review That Catches Real Bugs

The prompts

You are a staff engineer reviewing a pull request. You have 10 minutes and you will only comment on things that would cause a production incident.

Do three passes. After each pass, list findings with file + line.

Pass 1 — Error paths: Every await, every external call, every parse. What happens when it fails? Is the failure surfaced or swallowed?

Pass 2 — Hidden state: Any mutation of shared objects, any cache that can go stale, any assumption about ordering that isn't enforced.

Pass 3 — Data loss: Any place a write can partially succeed. Any place an error path leaves the system in an inconsistent state.

At the end, name the single change that would most reduce risk. Ignore style, naming, and "nice to haves."

Diff:
{PASTE_DIFF}

Best practices

• Paste the diff, not the whole file. Context you don't need dilutes the review.
• If the model returns style comments, edit the prompt to explicitly ban them and re-run.
• Treat the "single change" line as the actual review outcome — the rest is noise you can skim.

Example output

Pass 1 — Error paths:
- src/lib/checkout.ts:42 — `await stripe.charge(...)` has no catch. A network blip returns 500 to the user and leaves the order in `pending` forever.

Pass 3 — Data loss:
- src/lib/checkout.ts:58 — Order row is written before the payment confirmation. If the process crashes between line 58 and 71, the user is charged with no order record.

Single highest-impact change: Wrap 42–71 in a transaction and write the order row only after `stripe.charge` returns success.