Code review for correctness only
Findings with a triggering input, ranked by severity — and permission to find nothing. Written for Claude, free to copy, with every placeholder explained below.
The prompt
<role>
You are a senior engineer reviewing a change for correctness.
</role>
<context>
Language and version: {{language}}
What this code does: {{purpose}}
Environment it runs in: {{environment}}
</context>
<diff>
{{diff}}
</diff>
<task>
Review the diff for correctness bugs.
</task>
<constraints>
- Correctness only. Ignore style, naming and formatting entirely.
- For each finding give: the exact line, a concrete input that triggers the wrong
behaviour, and what happens instead of what should happen.
- If you cannot construct a triggering input, do not report the finding.
- Rank findings by severity: data loss, then incorrect output, then crash, then edge case.
- If there are no correctness bugs, say so. Do not pad the review.
- If you are unsure whether an API or method exists, say so rather than assuming.
</constraints>
Now review the diff above.Open this in the prompt builder to adapt it, score it, and re-render it for a different model.
What to replace
| Placeholder | What to put there |
|---|---|
| {{language}} | Language and version — behaviour differs between them. |
| {{purpose}} | What the code is meant to do, so "wrong" is definable. |
| {{environment}} | Runtime, concurrency model, deployment target. |
| {{diff}} | The change under review. |
Why this prompt works
- Triggering input required
- The single most effective filter against speculative findings. A bug you cannot trigger is a hypothesis, not a bug.
- Explicit permission to find nothing
- Asked to review, a model will always find something. Without this line, clean code produces invented nitpicks.
- Severity order defined
- Naming the ranking prevents a list where a typo sits above a data-loss bug.
- Style explicitly excluded
- Style feedback crowds out correctness feedback, and is the easier thing for a model to produce.
More prompts
- Debug from an error and stack trace — Ranked hypotheses with a test for each, instead of one confident guess.
- Unit tests written from the spec — Tests derived from requirements rather than from the implementation, so they can fail.
- Explain unfamiliar code — A walkthrough pitched at your actual level, with the non-obvious decisions called out.
- SQL query from a plain-English question — A query with its assumptions stated, so you can check them before running it.
- Blog post from an outline — Turn a rough outline into a full draft that keeps your structure and does not pad.
- Rewrite for clarity without changing meaning — Tighten prose while keeping the author's voice and every factual claim intact.
Browse the full prompt library, all coding & development prompts, or read the guides.