The strict reviewer: a prompt that finds real issues

Ask an agent to review a diff and you usually get a paragraph of hedged observations and at least one compliment. Ask it for severity, a concrete failing input, and a fix, and you get something you can act on in the time it takes to read it. The difference is entirely in what the output format requires the reviewer to produce.

Why "review this" underperforms

An open-ended review prompt gives the model no reason to commit to a position. It can note something "might be worth considering" and move on, and that hedge costs it nothing because nothing in the prompt asked for a ranked, falsifiable claim. A strict reviewer prompt closes that gap by making every field in the output do specific work, as shown in the figure. Severity forces ranking instead of a flat list. Issue forces one specific problem instead of a general description. Why it matters forces the reviewer to reason about impact rather than just flag something as unusual. Fix forces a concrete next step instead of a complaint with no resolution.

Failing input is the field that catches shortcuts

The field most reviewer prompts skip, and the one worth adding even if you add nothing else, is a concrete input that demonstrates the bug. It's easy for a model — or a person — to flag "this looks like it could be an injection risk" without ever constructing the string that proves it. Requiring a specific failing input turns a vague suspicion into a verifiable claim: either id="1 OR 1=1" actually breaks getUser() or it doesn't, and that's checkable in seconds. This is the same discipline this series covered for tests an agent can't game — a claim that specifies exactly what would prove it wrong is worth more than one that doesn't.

A prompt shape that produces this

You are reviewing this diff for correctness bugs only, not style.
For each issue found, output exactly these fields:
SEVERITY: critical | major | minor
ISSUE: one sentence, one specific problem
WHY: the concrete impact if this ships
FAILING INPUT: a specific input or scenario that triggers it
FIX: the smallest change that resolves it
Do not include compliments or general observations.
If you find no issues, say so directly — do not invent minor ones.

The last two lines matter as much as the format. Banning compliments removes the easiest way to pad a response with nothing. Explicitly permitting "no issues" removes the incentive to manufacture a minor one just to have something to say — a reviewer that always finds something is as useless as one that never does.

Severity ranking makes triage possible

Without severity, every finding reads with equal weight, and a reviewer that surfaces one critical bug and four style nits looks the same as one that found nothing serious. Ranking lets the person reading the output triage in seconds: address every critical before merge, batch the minors for later, and treat a review with zero critical findings differently from one with three.

Try it today

1. Take your current review prompt and add the five required fields from the figure, in that exact order.
2. Add the line banning compliments and general observations — rerun it on a diff you've already reviewed and compare.
3. For the next critical finding, check whether the failing input actually reproduces the issue before acting on it.
4. Have the reviewer run on its own past output once, checking whether an earlier "fix" actually addressed the failing input it named.
5. Keep the prompt in a skill or shared file, not a one-off message, so the format stays consistent across reviewers and repos.

Where this breaks

A strict format doesn't guarantee correct findings — a confidently wrong severity or a fabricated failing input is still possible, so treat findings as claims to verify, not conclusions to trust. The format also discourages nuance; some real issues are genuinely ambiguous and don't fit a clean severity label. And a reviewer prompt run by the same agent that wrote the code inherits its blind spots — the "one does, one checks" separation this series covered earlier still matters more than the prompt wording.

Next: bounded autonomy — what stops a review-and-fix loop from running forever.