claude-code lastVerified: 2026-05-08

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
  1. What severity tiers buy you
  2. The prompt
  3. Why each section earns its place
  4. Variants by review focus
  5. Common pitfalls when Claude Code reviews code

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

code-review-prompt.md
# 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 areaWhat it surfacesTier most populated
CorrectnessLogic errors, off-by-one, wrong branchCritical
Edge casesEmpty input, null, large input, concurrent callsCritical / Minor
SecurityInjection, XSS, auth boundary leaks, secret-in-logCritical
PerformanceAllocation in hot path, N+1, accidental quadraticMinor
AccessibilityMissing aria, focus traps absent, keyboard navigation brokenCritical / Minor
MaintainabilityNaming drift, function length, module boundary leaksSuggestion
TypeScript typesany slips, unsafe as casts, missing narrowingMinor

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.