Prompt · Code
Code review prompt
Getting a second pair of eyes on a diff before a human reviewer spends theirs, where a list of style nitpicks is worse than no review at all.
Review the code below for defects.
<code language="{{language}}">
{{code}}
</code>
Report only problems that would cause incorrect behaviour, data loss, a security issue or a crash. Do not report formatting, naming or stylistic preferences.
For each finding give:
- Severity: critical, high or medium.
- Location: the function or line.
- The defect, in one sentence.
- A concrete failure scenario: specific inputs or state, and the wrong result they produce.
If you cannot describe a concrete failure scenario, do not report the finding. A suspicion without a triggering case is noise.
Order findings by severity. If the code has no defects of this kind, say "No correctness issues found" and stop — do not manufacture findings to appear useful.
Consider especially: off-by-one and boundary conditions, null and empty inputs, error paths that swallow failures, concurrent access to shared state, unvalidated input reaching a query or a shell, and resources that are not released on the error path.What to fill in
{{language}}- Helps with idiom-specific issues — Python mutable defaults, JavaScript equality coercion, Go nil maps.
{{code}}- A diff works better than a whole file: it focuses the review on what changed. Include enough surrounding context that called functions are visible.
Why it is written this way
Every rule in the prompt is there because of a specific failure it prevents. Knowing which is which is what lets you adapt it instead of only pasting it.
The scope is narrowed to correctness
Unscoped review prompts return style opinions, because style issues are abundant and easy to spot. Excluding them explicitly is what makes the remaining findings worth reading.
A failure scenario is required
This single rule removes most false positives. A model that must produce specific triggering inputs cannot report a vague "this could be a problem" — either the case exists or the finding gets dropped.
Silence is permitted
Without explicit permission to find nothing, a review of clean code produces findings anyway, because the prompt implied findings were expected. After two rounds of that, developers stop reading the output.
The checklist is at the end
The categories listed last are the ones models miss without prompting — resource leaks on error paths and concurrent access especially. They sit at the end because that position is attended to most strongly.
Severity is a fixed set
Three levels, named. An open-ended severity produces a different scale every run and cannot be sorted or filtered downstream.
The version most people write, and what it costs
Review this code and suggest improvements:
{{code}}It returns eight suggestions, six of which are naming and formatting, one is a real bug buried at position four, and one is a confident claim about a race condition that cannot occur. The developer reads the first two, sees nitpicks, and stops — so the real bug ships.
What it still gets wrong
- It sees only the code you paste. Bugs that depend on a caller, a schema or a config file elsewhere are invisible.
- Race conditions and memory issues are reported with low precision. Treat those findings as prompts to look, not as conclusions.
- It does not replace tests. A review says code looks correct; a test says it behaved correctly.
Check it before you ship it
- AI Skill GeneratorThree skill shapes — review, generate, diagnose — each producing a complete file.
- Prompt LinterStructural review of a prompt: what is costing you money and what will fail.
- LLM Token CounterReal BPE tokenization, not characters ÷ 4. Shows which counts are exact and which are estimates.
To build one of these from scratch for a task not covered here, the prompt generator assembles the same structure — delimiters, output contract, edge cases — from an expert-authored blueprint, and the prompt review checklist is what to run over the result.