Code Review Prompt
A prompt that produces specific, ranked review findings instead of a vague list of suggestions.
When to use this
A one off review when you do not want to set up a skill or a subagent. Paste it with your diff.
The difference between this and asking "review my code" is that it constrains what counts as a finding, which is what stops the output being a list of things that are technically true and practically useless.
The template
Review this diff. Report defects only. For each finding give: - File and line - One sentence on what breaks - The specific input or state that triggers it Check in this order: 1. Correctness: null handling, off by one, unhandled rejections, wrong boundaries, error paths that swallow failures 2. Security: injection, missing authorisation, secrets in source, unvalidated input crossing a trust boundary 3. Data loss: destructive operations without guards, migrations without rollback 4. Concurrency: shared mutable state, races, ordering assumptions 5. Maintainability: duplication that will drift, misleading names, functions doing several things Rules: - Only report something if you can name the failure. "Could be cleaner" is not a finding. - Rank by severity. Correctness beats style. - Ignore formatting entirely. - Read the tests as part of the diff. A test asserting wrong behaviour is a defect. - If the diff is fine, say so. Do not invent findings. End with one line on overall risk. Diff: [paste here]
What to change
Add project specific checks to the numbered list. If your team keeps forgetting to update a related file, put that in.
If you want the review to also propose fixes, add "for each finding, give the minimal fix" at the end. Keep the finding and the fix separate so you can evaluate the diagnosis before the treatment.
Why it is shaped this way
The instruction to only report nameable failures does most of the work. Without it, models produce a long list of defensible but low value observations, which trains you to skim the output, which defeats the point.
Asking for the triggering input forces the model to actually check whether the bug is real. Many apparent findings evaporate when you have to state the input that breaks it.
Explicitly permitting "this is fine" matters. A model that believes it must find something will find something.