Review a code change
A reviewer prompt that ranks findings by severity, separates bugs from taste, and must say "nothing blocking" when that's the truth.
Last updated
Fill in the blanks
Assembled in your browser — nothing you type is stored or sent anywhere.
Your prompt
Model-agnostic — works in Claude, ChatGPT, Gemini or any AI chat.
Why this prompt works
- →Severity ordering with a bugs/risks/style split stops the classic AI-review failure — ten equal-weight comments where the one real bug hides between two naming nitpicks.
- →Requiring a triggering scenario per bug filters confident-sounding false positives: a "bug" that can't name its failing input usually isn't one.
- →Licensing "nothing blocking" matters — without it, models manufacture findings to look thorough.
Part by part
- Report findings in severity order
- Ordering by severity rather than by position in the diff. An unordered review gives a naming nit the same weight as a data-loss bug.
- with the concrete scenario that triggers it
- Forces each bug claim to be demonstrable. A finding you can reproduce is a bug report; one described abstractly usually turns out not to apply.
- clearly labelled as optional
- Separates taste from correctness, so an author can act on the blocking items and decide about the rest.
- nothing blocking
- Explicit permission to find nothing. Models pad reviews to appear useful, and padding is what teaches people to skim them.
- Do not invent requirements the change was never trying to meet
- The guard against scope drift, where a review of a bug fix becomes a critique of the architecture around it.
Common mistakes
Review this code.Returns a flat list mixing a possible null dereference with a preference about variable names. The author has to triage the review before acting on it, which is work the review should have done.
Find all the problems with this code.All invites padding, so genuine findings are diluted by invented ones. A review that always finds ten things is one nobody reads carefully.
Review this diff without providing context.Without knowing what the change is for, the review grades it against generic expectations — flagging missing features it was never meant to include.
Questions
Does this replace human review?
No. It is reliably good at spotting unhandled cases and inconsistencies in the diff, and it cannot know your conventions, your roadmap, or why the surrounding code is the way it is. Use it before review, not instead.
Why insist on a triggering scenario?
Because it separates real findings from plausible ones. A model asked for bugs will produce some; asked for the input that causes each, several turn out to be unreachable and drop out.
What context is worth supplying?
What the change is for, and anything unusual about the surrounding code. Both prevent findings that are correct in general and wrong here, which are the ones that waste the most time.
Should I paste the whole diff?
As much as fits, with the surrounding function for anything modified. A diff without context produces guesses about the code above and below it, stated as confidently as the rest.