Code Review

How it works

When a pull request opens (or a push lands, depending on your settings), specialised agents analyse the diff in the context of your full codebase — not just the changed lines. Each agent looks for a different class of problem: logic errors, security gaps, broken edge cases, subtle regressions. A verification step cross-checks each candidate finding against the actual code to filter out false positives before anything is posted.

Results land as inline PR comments on the exact diff lines where the issue was found, plus a summary in the review body. If no issues are found, Claude leaves a brief confirmation comment instead of staying silent.

Severity levels

Every finding is tagged with one of three severity levels so you can triage quickly.

Each inline comment also includes a collapsible Extended reasoning section. Expand it to see exactly how Claude verified the issue — which file and line it traced, what code path it followed.

What it looks like on a real PR

Below is an example review on a pull request that adds payment retry logic. Claude found one Important bug (potential double-charge on network timeout) and one Nit (unused parameter).

Use thumbs up on comments that are useful and thumbs down on ones that are wrong or noisy. Anthropic uses these reactions to tune the reviewer after the PR merges.

Set up Code Review

An admin enables Code Review once for the whole organisation, then picks which repositories to include and how each one triggers.

Trigger a review by comment

Two comment commands let anyone request a review on demand, regardless of the repository's configured trigger. Post them as top-level PR comments — not as replies to inline diff threads.

Customise with REVIEW.md

Add a REVIEW.md file to your repository root to tune how Code Review behaves on that repo. Its contents are injected as the highest-priority instruction for every agent in the review pipeline — overriding the default guidance.

Here is an original example for a backend API service:

# REVIEW.md — Backend API Service

## What counts as Important here
Only flag findings that would break production behaviour, expose PII, or block
a rollback: incorrect logic, unscoped DB queries, passwords or user IDs in logs,
and migrations that are not backward-compatible.
Style and naming suggestions are Nit at most.

## Cap the nits
Report at most four Nit comments per review. If you found more, summarise the
extras as "plus N similar items" in the review body. If every finding is a Nit,
open the summary with "No blocking issues found."

## Skip these paths
- src/generated/           (auto-generated from schema)
- **/*.lock                (dependency lockfiles)
- migrations/              (reviewed separately by the DBA team)
- Anything that only changes comments or whitespace

## Always check
- New /api routes have an integration test in tests/integration/
- Log statements do not include req.body, user.email, or user.id
- Database queries filter by tenant_id when tenant data is involved

Pricing

Code Review is billed by token usage, separately from your plan's included usage. Cost scales with PR size and codebase complexity. Check the admin usage page for current pricing in your organisation.

Troubleshooting

Quick reference

Before you continue

• Code Review posts inline PR comments tagged Important, Nit, or Pre-existing.
• Admins enable it once, then choose repos and trigger modes per repository.
• Use @claude review or @claude review once for on-demand reviews.
• Tune behaviour per repo with REVIEW.md; use CLAUDE.md for general project context.
• Next lesson: techniques for getting consistently better results from Claude Code.

What's Next

Code review is part of your workflow. Next: techniques for getting consistently better results from Claude Code on any task.