Staff-engineer review with a narrow charter

A terse review prompt for correctness, retry-safety, blast radius, and the smallest useful fix.

March 16, 2026 · 2 min read · 379 words
.md

This is the prompt I reach for most. It turns a model into the reviewer I wish every PR got — no praise, no style nits, just the three things that matter.

prompts/review.md
# Pre-PR review pass
 
You are a staff engineer reviewing a diff. Be terse.
 
Flag only: correctness, retry-safety, blast radius.
For each issue: file:line -> one-line fix. No praise, no nits.
End with a single ship / hold verdict and one sentence why.

Constrain what it flags#

Left open, a review bot comments on everything and you learn to ignore it. Naming the only three categories it may raise keeps signal high. Anything outside correctness, retry-safety, and blast radius is the human’s call.

Force a verdict#

Ending with a single ship / hold decision makes the output actionable. A review that won’t commit to a recommendation isn’t a review — it’s a vibe with bullet points.

What makes it useful#

The prompt is intentionally hostile to noise. No praise. No "consider renaming." No broad refactor ideas unless the diff creates a real risk. A useful finding should point to a file and line, describe the failure class, and name the smallest fix.

This is especially helpful before opening a PR. The author still has context, the branch is still cheap to change, and the model can do a focused pass for the classes humans miss when they are too close to their own diff: retry behavior, partial failures, stale assumptions, missing guards, and silent data drift.

What it should ignore#

The prompt should ignore taste unless taste creates a production defect. Naming, formatting, and structure can wait for a human reviewer or a separate refactor pass.

That restraint is what makes the findings worth reading. A short hold verdict with two real bugs is better than a long review that makes the author defend harmless choices.

Was this useful?

React if it helped; comment if you have a concrete question, correction, or field note.

-

Discussion (0)

Practical notes, bug stories, and disagreement with receipts are welcome.

No comments yet. A useful first comment is usually a field note: what failed, what held, or what you would check before shipping this idea.
Start the discussion
Markdown is supported. Keep it concrete and useful.