Claude Code Code Review Prompt — Severity-Tiered Review Template
A Claude Code code review prompt with critical / minor / suggestion severity tiers. Covers correctness, security, performance, accessibility, TypeScript types.
On this page
What severity tiers buy you
A code review without severity tiers is noise. When every observation reads at the same
volume, reviewers triage by length instead of by importance, and the genuine showstoppers
get buried under nits about variable casing. This prompt structures Claude Code’s review
output into three tiers — Critical, Minor, Suggestion — and constrains what each tier may
contain. Tier discipline is what turns a 40-bullet review into a 6-bullet “fix these now”
plus a 30-bullet “address before merge” plus a 4-bullet “consider in the next refactor”.
The parameterised version lives at
/tools/ai-code-review-prompt-generator.
The prompt
# Review request
Review the diff or file referenced below. If anything is unclear, ask before
editing. Do not propose code changes inside the review — only describe issues
and the smallest correct fix per issue.
# Severity tiers (use exactly these three)
- Critical: bug, regression, security flaw, type unsoundness, accessibility
blocker, or violation of a locked decision in CLAUDE.md.
- Minor: maintainability friction, missing edge-case handling that is unlikely
to fire, performance smell with measurable but small impact, naming
inconsistency that affects a public surface.
- Suggestion: stylistic preference, a clearer rewrite that is not strictly
better, an architectural pivot the team would have to discuss first.
# Focus areas (assess each — silence is a positive finding)
- Correctness (does the code do what its name claims?)
- Edge cases (empty input, null, large input, unicode, concurrent calls)
- Security (injection, XSS, auth boundary, secret handling)
- Performance (allocation in hot path, accidental quadratic loop, N+1)
- Accessibility (semantic HTML, keyboard navigation, focus management,
aria-label and aria-describedby where applicable)
- Maintainability (naming, function length, module boundaries)
- TypeScript types (`any` slips, unsafe casts, missing narrowing)
# Output format
1. One-paragraph summary: overall assessment + count per tier.
2. Critical findings — each one references file:line and a smallest fix.
3. Minor findings — same shape.
4. Suggestion findings — same shape.
5. One sentence noting any focus area you could not assess from the diff alone. Why each section earns its place
The “ask before editing” sentence is the most consequential line in the prompt. Without it Claude Code will helpfully patch the file under review, which inverts the purpose of a review. The tier definitions are deliberately narrow — Critical is reserved for things that must be fixed before merge; Suggestion is reserved for things that the team has not yet agreed on. The Focus areas list is structured so that silence on a focus area is itself a positive finding (“Performance: nothing to flag in this diff”); without that contract, a short review reads as the agent skipping the boring parts. The “smallest fix per issue” phrase is what stops Claude Code from rewriting half the file inside a review bullet — each finding has a fix scoped to that one line or block.
Variants by review focus
If you want a narrower review — say, before a security audit or an a11y pass — pin the focus and Claude Code will ignore the others. The seven rows below match the locked focus areas from the code-review generator’s UI.
| Focus area | What it surfaces | Tier most populated |
|---|---|---|
| Correctness | Logic errors, off-by-one, wrong branch | Critical |
| Edge cases | Empty input, null, large input, concurrent calls | Critical / Minor |
| Security | Injection, XSS, auth boundary leaks, secret-in-log | Critical |
| Performance | Allocation in hot path, N+1, accidental quadratic | Minor |
| Accessibility | Missing aria, focus traps absent, keyboard navigation broken | Critical / Minor |
| Maintainability | Naming drift, function length, module boundary leaks | Suggestion |
| TypeScript types | any slips, unsafe as casts, missing narrowing | Minor |
A correctness-only review on a feature PR keeps the reviewer focused on whether the code does what it claims; appending accessibility broadens the scope to user-visible quality. Pin one focus area at a time when you want the review to fit on one screen.
Common pitfalls when Claude Code reviews code
Three failure patterns recur. Review fatigue is the first: Claude Code marks every
observation Critical, which is the same as marking nothing Critical — counter by quoting
the exact tier definitions back at it. Missing security context is the second: a review
that does not know the threat model cannot tell whether a dangerouslySetInnerHTML is
acceptable — counter by including a paragraph in CLAUDE.md
naming the trust boundaries of the codebase. Review-bot drift is the third: the review
turns into “rename this variable” 30 times instead of evaluating the diff’s correctness —
counter by stating up front “Suggestions about naming are out of scope unless the name
appears in a public export.” For the upstream tasks the review evaluates, see the
Claude Code feature prompt, the
Claude Code bug fix prompt, and the
Cursor rules template for the IDE-side review companion.
Try the generator
Build this prompt interactively — pick options, copy the result.