Prompt Engineering

Code Review Prompt — the Review Contract

"Review this code" gets shallow comments. The review contract gets findings with severities, a checklist, and a verdict.

Overview

The difference between a useless AI review and a useful one is the contract: what to look for, how to report it, and what verdict to end with. This setup loads the baseline contract — a correctness review of a complete file with the twelve-check correctness checklist, the four-level severity standard ([CRITICAL] through [NIT], severity reflecting impact not effort), findings-only output with exact locations, and a verdict rule. It's the template every other review on this site specializes from.

Workflow

Generate once, reuse per review
The contract is the standard; paste each file or diff into the code slot and every review comes back in the same shape.
Read findings by severity
CRITICAL first — the grouping rule means the things that block merge are always at the top.
Hold the AI to the verdict rule
"Base the verdict only on the findings listed" — no vibes-based approvals.

Why This Works

A checklist the AI must work through beats an open-ended "look for problems"
Severity tagging turns prose into a triageable review
Findings-only output cuts the praise padding that hides real issues

Best for

Developers using chat AIs as a second reviewer
Teams that want review consistency across members and models
Anyone tired of "looks good, consider adding comments" reviews

Not for

Making the AI rewrite the code — that's the Refactor Prompt Builder (review judges, refactor changes)
A persistent reviewer persona — that's a System Prompt (SPG); this is a per-review task contract

Use cases

Getting findings with severities instead of vague observations
Standardizing what every AI review must check and report
Ending every review with a defensible verdict

Customize This Resource

Opens this setup in Code Review Prompt Generator. Generate to get the full review contract — then adjust the focus, scope, language, and style.

Open in Code Review Prompt Generator

Prompt Template

REVIEW OBJECTIVE
Review this module against the team's review standard before merge.
Primary focus: correctness — find the ways this code produces wrong results or fails.
Review only — report findings; do not rewrite the code.

REVIEW SCOPE
You are reviewing a complete file — judge both the code and the file's structure: imports, ordering, and what this file owns.

REVIEW CRITERIA
- Logic errors and inverted conditions
- Edge cases: empty, zero, negative, maximum, duplicate inputs
- Null/undefined/None handling before dereference
- Error paths: propagation, swallowed exceptions, partial failure states
- Concurrency: race conditions, unawaited async results, shared mutable state

SEVERITY RULES
- Tag every finding with exactly one severity: [CRITICAL], [MAJOR], [MINOR], or [NIT].
- CRITICAL: must be fixed before merge — bugs, vulnerabilities, data loss.
- MAJOR: should be fixed — real risk or real debt.
- MINOR: worth fixing — small risk or friction.
- NIT: style preference; fixing is optional.
- Severity reflects impact, not effort to fix.

REVIEW CHECKLIST
Work through every item; report only the items that fail:
1. Are inputs validated at the boundaries where they enter?
2. Are edge cases handled: empty, zero, negative, maximum-size inputs?
3. Any off-by-one errors in loops, slices, or range checks?
4. Is null/undefined handled before every dereference?
5. Do error paths return or propagate correctly — nothing swallowed silently?
6. Are async operations actually awaited and their failures handled?
7. Any race conditions on shared state or check-then-act sequences?
8. Are return values of fallible calls checked?
9. Are type coercions and implicit conversions intentional?
10. Are comparison boundaries correct (< vs <=, exclusive vs inclusive)?
11. Is there dead or unreachable code hiding an intent mismatch?
12. Does the code do what its name and comments claim it does?

REQUIRED OUTPUT FORMAT
- One finding per bullet: [SEVERITY] location — what is wrong and why it matters.
- Group findings by severity, CRITICAL first.
- Cite the exact line, function, or symbol for every finding.
- Do not mention checklist items that pass — findings only.
- Prioritize findings that matter; skip pure style nits unless they hurt readability.
- If something is done notably well, say so once — briefly.

FINAL VERDICT
- End with a verdict: APPROVED, APPROVED WITH COMMENTS, or CHANGES REQUIRED.
- Base the verdict only on the findings listed above.

CODE TO REVIEW
[Paste the file here]

Related Resources

Explore more resources that work well with this one.

Used in Playbooks

Complete workflows that include this resource as a step.

AI Code Review Workflow Workflow · 5 steps AI Code Refactoring Workflow Workflow · 4 steps AI Test Generation Workflow Workflow · 5 steps

Tip: Save time by exploring related resources and tools that integrate with this workflow.

Explore all resources