Automated code reviews with Claude Code

Level 3 How-to Updated 2026-10-16

Automated code review in Claude Code puts independent readers on every change before a person does: /code-review in the session, a claude -p pre-push gate, managed Code Review on each pull request and claude ultrareview for risky branches. Anthropic’s Claude Code team reported on 2026-10-15 that it layers such review with security checks, CI and risk-scaled human approval.

This page is for developers who want Claude to catch their own mistakes before a teammate does, and for tech leads who own the review rules. Your sessions now open more pull requests than your reviewers can read. The human comments repeat: a missing error path, an unvalidated input, a test that covers only the happy path. Faros AI’s April 2026 AI Engineering Report measured median time in review up 441.5% across 22,000 developers. The mechanical part belongs to a machine, so people keep their attention for judgment calls. Product facts were checked on 2026-10-16 against code.claude.com, CLI flags against Claude Code 2.1.302.

What automated review in Claude Code gives you

A /code-review routine for every branch, with the effort level and target chosen on purpose.
A pre-push hook that blocks a push only on a critical defect it can name by file and line.
One set of review rules in CLAUDE.md that every reviewer reads, and a REVIEW.md for the managed review.
Managed Code Review with a level per repository and a merge gate that blocks on Important findings and on threads left unresolved.
A seeded-bug fixture that measures what your reviewer catches, and round caps that keep an agent author and an agent reviewer from looping.

Which Claude Code review tool fits which moment?

Use the cheapest private check first, so the public review stays worth reading.

Tool	When it runs	What it gives you	Limits (checked 2026-10-16)
`/code-review`	In the session, before commit	Correctness bugs, plus cleanup suggestions depending on model and effort; `--fix` applies them, `--comment` posts them to a GitHub pull request or a GitLab merge request	Any plan; reads `CLAUDE.md`, not `REVIEW.md`
`/security-review`	Before a pull request that touches auth, input handling or secrets	Security review of the branch diff	Diff only; for a whole-repository audit see security audits with Claude Code
Pre-push `claude -p` gate	On `git push`	A `pass` or `block` verdict your script reads from JSON	`git push --no-verify` skips it, so CI stays the real gate
`claude ultrareview`	Before merging a high-risk branch	A cloud fleet of reviewer agents; every finding is independently reproduced	Research preview; claude.ai login; three one-time free runs on Pro and Max, then typically $5 to $25 in usage credits; where it is unavailable
Managed Code Review	On pull requests, as each repository is set; runs on Anthropic infrastructure	Inline comments ranked Important, Nit or Pre-existing, a summary and a neutral check run	Team and Enterprise plans, GitHub only; no flat per-review price; availability and costs

Availability, limits and billing are Anthropic’s own statements from the Code Review, Code Review costs, local review and Ultrareview pages.

How does Anthropic’s Claude Code team layer code review?

Anthropic’s Claude Code team reported on 2026-10-15 in How the Claude Code team does code review (claude.dev Blog; figures are self-reported about its own repositories, not an industry benchmark) that it stacks seven layers around a change: a runnable check and a fresh-context subagent review before the pull request, Code Review on every pull request, a security review that can block, required CI, human approval scaled by risk, a merge queue with flags and a release that reaches latest before stable, and fast rollback. Its goal is that most pull requests merge with at most one human in the loop, who can be the author, with no increase in reverts or incidents; revert and incident rates are the guardrail. This page builds the first three layers. Reviewing an agent’s pull request without reading every line covers the layers and the evidence a person reads, and governance and autonomy covers the risk tiers.

Review your branch with /code-review

/code-review is a bundled skill that works on any plan; the review runs in your own session, so it counts toward your plan’s usage or API billing. /review is now its alias, not a separate command. With no argument it reviews your branch’s commits ahead of its upstream plus any uncommitted changes. It runs as a background subagent with its own context window, so you keep working while it reads.

Run the review at an explicit effort level. In the Claude Code prompt:
```
/code-review medium
```
At low the review reports the findings it is most confident in, so you see fewer false positives; from medium through max it broadens coverage. From v2.1.290, medium on models without tuned review settings, including Opus 5.5 and Sonnet 5.5, also reports cleanup and CLAUDE.md-convention findings. Type the level every time: a bare /code-review reuses the last level from low through max that you typed, even from an earlier session (v2.1.223 or later), unless it came from a -p run. Both version gates hold on both release channels (stable 2.1.292, latest 2.1.302; npm dist-tags, 2026-10-16).
Point it at something other than your working tree when you need to. The target comes after the level and flags:
```
/code-review high main...feature/billing-retry
/code-review src/payments/
/code-review 142
```
The first reviews a ref range, the second a path, the third pull request 142.
Commit before you use --fix. A background review applies its edits outside your session’s checkpoints, and /rewind restores only the files Claude had already edited in your conversation. To undo the rest, use git: git diff shows the edits, git restore . reverts tracked files and git clean -n lists new files to remove. A review that runs in the foreground (-p, or CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1) edits during your own turn, so /rewind works as usual.
```
/code-review medium --fix
```
Post the findings where the team works. --comment puts them on the GitHub pull request as inline comments, or on a GitLab merge request as one note through the glab CLI (v2.1.257 or later; pass the merge request as its URL or !123):
```
/code-review medium --comment 142
```
Change how many findings you get when the usual limit is wrong for the diff. --max-findings <n> reports up to n findings and --max-findings all reports every finding, in place of the usual limit (v2.1.288 or later, both channels). Later reviews reuse the value until you pass --max-findings default; a value from a -p run is not remembered:
```
/code-review high --max-findings all main...feature/billing-retry
```

Take the findings from the last /code-review. For each finding rated as a bug:
1. Write a test that fails because of the bug. Run it and show me the failure.
2. Fix the code with the smallest change that makes the test pass.
3. Run the full test suite, typecheck and lint, and report each command with its exit code.
For each finding you think is wrong, do not change code: explain in one sentence why
it is a false positive and which file:line proves it.
End with a table: finding | test added | fixed / false positive.

The failing test is the point: a fix whose test went from red to green is evidence you can check in a second, and a fix without one is another diff to read.

Write your team’s review rules once

A review that does not know your conventions reports the wrong things. Put the rules in one place that every reviewer reads.

CLAUDE.md is read by /code-review, by the GitHub Action and by managed Code Review, which flags a change that violates it at whichever severity fits. Anthropic’s Claude Code team reported on 2026-10-15 that it keeps this file short and points to other docs from it, because every review loads it.
REVIEW.md at the repository root is read only by managed Code Review, so a rule that must hold everywhere belongs in CLAUDE.md. Write a REVIEW.md the reviewer follows covers what goes in it.

Add a short review section to the project CLAUDE.md:

## Review rules
- Blocking: missing authorization on a route under src/api/, SQL built from strings,
  an error swallowed in src/payments/, a migration that is not backward compatible,
  a test assertion removed or loosened.
- Do not flag: formatting, naming, import order (dprint and oxlint own those),
  anything under src/gen/, any lockfile.
- The `any` type under src/legacy/ is intentional. Do not flag it.
- Every finding cites file:line and names the test or command that demonstrates it.

Then give the team one review command. A skill with context: fork runs as a separate subagent that starts from the skill text alone, without the author’s conversation, which is the independence you want from a reviewer. Save this as .claude/skills/pr-check/SKILL.md:

---
description: Independent pre-PR review of the current branch against origin/main. Use before opening a pull request.
disable-model-invocation: true
context: fork
allowed-tools: Read Grep Glob Bash(git diff *) Bash(git log *)
---

## Changes under review

!`git diff --stat origin/main...HEAD`

## Instructions

Review the diff between origin/main and HEAD. Read each changed file in full, not only
the hunks. Apply the "Review rules" section of CLAUDE.md. You never edit files.

Check, in this order: authorization and input validation, error handling at every
boundary, data and migration safety, and whether each changed behaviour has a test
that would fail without it.

Reply in exactly this shape:
VERDICT: APPROVE | REQUEST_CHANGES
FINDINGS:
- [blocker|major|minor] path:LINE: problem. Evidence: <test or command>
UNTESTED: <changed behaviour with no covering test, or "none">
CHECKED: <each command you ran>

allowed-tools pre-approves these tools; it does not remove the others, so “You never edit files” is an instruction, not a restriction. For a reviewer that cannot edit at all, or one Claude can delegate to on its own, write a subagent with a tools list (see custom subagents). Do not name the skill review: /review already belongs to /code-review. disable-model-invocation: true means only a person starts it. Skill mechanics: custom commands and skills.

Block a push on a critical finding

A pre-push hook is the last private check. It must be fast, it must fail only on something it can name, and your script, not the model’s prose, decides the outcome. The hook below pipes the diff into claude -p, allows only read tools, caps spend, and reads the verdict from structured_output, which --json-schema validates.

Save the hook as .githooks/pre-push and make it executable (chmod +x .githooks/pre-push). The hook needs jq on PATH; without it the hook prints a warning and lets the push through:

#!/usr/bin/env bash
set -uo pipefail
command -v jq >/dev/null || { echo "pre-push: jq missing; review skipped" >&2; exit 0; }

base=$(git merge-base origin/main HEAD) || exit 0
diff=$(git diff --no-color "$base"...HEAD)
[ -z "$diff" ] && exit 0

if [ "$(printf '%s' "$diff" | wc -l)" -gt 1500 ]; then
  echo "pre-push: diff over 1500 lines; run /code-review high before you push." >&2
  exit 0
fi

schema='{"type":"object","properties":{"verdict":{"enum":["pass","block"]},"findings":{"type":"array","items":{"type":"string"}}},"required":["verdict","findings"]}'

if ! out=$(printf '%s' "$diff" | claude -p \
  "Review this diff for blocking defects only, as defined in the Review rules section of CLAUDE.md. Ignore style. Return verdict block only for a defect you can name by file and line; write each as 'file:line - problem - fix'." \
  --output-format json --json-schema "$schema" \
  --permission-mode dontAsk --allowedTools "Read" "Grep" "Glob" \
  --max-budget-usd 0.50); then
  echo "pre-push: Claude review did not complete; push allowed, CI still gates the merge." >&2
  exit 0
fi

if [ "$(jq -r '.structured_output.verdict // "missing"' <<< "$out")" = "block" ]; then
  echo "pre-push: blocked by Claude review:" >&2
  jq -r '.structured_output.findings[]' <<< "$out" >&2
  echo "Fix the findings, or push with --no-verify and say why in the pull request." >&2
  exit 1
fi

Point Git at the tracked hooks directory, once per clone:
Terminal window
```
git config core.hooksPath .githooks
```
Prove it blocks. On a scratch branch, add a route that reads a user ID from the query string and returns that user’s record with no authorization check, commit it, and push. The hook must print a file:line finding and exit 1. If it passes, tighten the Review rules until it fails.

Three choices are deliberate. --permission-mode dontAsk denies every tool call that would prompt, so the review cannot edit files. The hook fails open when Claude cannot finish (network, budget, outage), because a local hook that blocks on an outage gets bypassed with --no-verify for good. And it skips very large diffs, because a quick check on 3,000 lines is theatre; those need /code-review high or Ultrareview. Do not add --bare to start faster: bare mode skips CLAUDE.md, so the Review rules would never load. Headless flags: task automation with headless mode.

Review security-sensitive changes with /security-review

When a branch touches authentication, session handling, input parsing, file paths or secrets, run /security-review before you open the pull request. It reviews the branch diff with a security focus. For a check that runs while Claude writes, install the security-guidance plugin, which runs as hooks. It needs Python 3.8 or later on PATH:

claude plugin install security-guidance@claude-plugins-official

Anthropic’s Claude Code team reported on 2026-10-15 that it does not merge a pull request while any bug or security finding is open: you fix it (a later commit that fixes the issue clears it on its own) or close the thread with a short reason. The article says the open-source security review GitHub Action or /security-review can set up the same thing; make a security finding block a merge builds that gate.

Scanners, the Claude Security plugin and exploit tests as proof are covered in security audits with Claude Code. Security gates for agents from other vendors are compared in agent security gates.

Run a security review of the diff between origin/main and HEAD. Do not edit files.
Check each item and answer yes, no or not applicable, citing file:line:
1. Every new or changed route checks authorization, not only authentication.
2. Every user-controlled value is validated before it reaches a query, a shell
   command, a file path or an outbound URL.
3. Database queries are parameterized; HTML output is escaped.
4. Error responses and logs leak no tokens, emails, stack traces or request bodies.
5. No credential, key or token appears in code, tests or fixtures.
6. New dependencies: name each one and say why existing code or dependencies
   could not do the job.
For every "no", give severity (critical/high/medium/low), the CWE ID if one fits,
and the smallest fix. If everything passes, list what you checked.

Get a second opinion on a high-risk branch

Some changes deserve more than one reader: payments, permissions, data migrations, anything that is hard to roll back. Two options go deeper than /code-review.

Ultrareview runs a cloud fleet of reviewer agents and reproduces each finding before it reports it. Its page labels it a research preview (checked 2026-10-16), so its pricing and availability can change. From the shell:

claude ultrareview                 # current branch against the default branch
claude ultrareview 142             # pull request 142
claude ultrareview 142 --post      # also post the findings to the pull request as you
claude ultrareview --json > bugs.json

In a session the same review is /code-review ultra. It needs a claude.ai login (an API-key-only session must run /login first) and typically takes 15 to 25 minutes. A branch review accepts up to 500 changed files and 8,000 changed lines by default (the page says the values can change); if the repository is too large to bundle, push the branch, open a draft pull request and run claude ultrareview <number>. Running claude ultrareview yourself is also how you consent to usage-credit billing; a claude -p '/code-review ultra' run stops before launching when the review would bill credits. Where Ultrareview is unavailable (Zero Data Retention, the HIPAA configuration, Bedrock, Google Cloud, Foundry), /code-review ultra falls back to a local review; an organization that uses customer-managed encryption keys cannot run it at all, and runs /code-review locally instead.

The pr-review-toolkit plugin from Anthropic’s claude-plugins-official marketplace adds /pr-review-toolkit:review-pr and six specialised subagents, such as a silent-failure hunter and a test analyser. Pass aspects to run only the ones you need:

claude plugin install pr-review-toolkit@claude-plugins-official --scope project

/pr-review-toolkit:review-pr tests errors

It costs about 2,000 tokens of always-on context per session (measured with claude plugin details on Claude Code 2.1.283), so install it at project scope in the repositories that need it rather than globally. Note that the plugin named code-review in the same marketplace is invoked as /code-review:code-review; a plain /code-review always runs the built-in skill.

How do you run managed Code Review on every pull request?

Managed Code Review reviews the pull requests in the GitHub repositories an Owner of your Claude organization turns it on for. Several agents read each change, a verification step filters false positives, and the findings arrive as inline comments tagged Important, Nit or Pre-existing (a bug this pull request did not introduce), plus a summary and a Claude Code Review check run. It runs on Anthropic infrastructure and does not build or run your code (Code Review, checked 2026-10-16). Its live page carries no research-preview label, and Anthropic’s 2026-10-15 article calls it “generally available on Team and Enterprise plans”; the 2026-03-09 launch announcement still says research preview, so trust the page and the article.

It needs a Team or Enterprise plan and GitHub (including GitHub Enterprise Server and GitHub Enterprise Cloud with data residency), plus a Claude organization on those plans even if your developers use Bedrock, Google Cloud’s Agent Platform or Microsoft Foundry. It is unavailable with Zero Data Retention or the HIPAA configuration, is not covered by the Business Associate Agreement (BAA) and does not yet support customer-managed encryption keys (CMEK). An Owner turns it on in Admin settings > Claude Code (Set up Code Review; the CI side is in running Claude Code in CI/CD).

Which review level should each repository use?

An Owner sets one level for the organization and can override it per repository; there is no model choice, and a new level applies to later reviews. Quick is a lighter pass, the fastest and cheapest; Standard, the default, balances depth, speed and cost; Deep is the most thorough, the slowest and the most expensive. Anthropic’s Claude Code team reported on 2026-10-15 that its admins set each repository to one of the three, and that “Deep is worth it where one missed bug costs more than the extra review time.” Use Quick for routine code and Deep for payments, authorization, migrations and anything hard to roll back.

When should reviews run?

Each repository has a Review runs setting. Once after PR creation reviews when a pull request is opened, reopened or marked ready. After every push reviews each push, so the cost multiplies by the pushes; a repository you add from the admin page starts there, unless its GitHub organization is covered as a whole. Manual reviews only when someone comments. Anyone with write access can start a review with a new top-level comment that begins @claude review; @claude review always also reviews every later push. Automatic reviews skip drafts and pull requests from forks, and a comment command works on both. A later automatic review focuses on what changed since the last one, posts fewer nits and pre-existing findings and counts what it left out in its summary; @claude review covers the whole pull request again.

How do you block a merge on a finding?

A review never approves or blocks a pull request. Its check run ends neutral (or skipped, when an automatic review did not run because a push changed no files) and never as a failure, and you can merge without answering a finding unless your repository requires it. Two controls make findings block:

Require every thread to be resolved. Turn on Require conversation resolution before merging in the branch protection rule (GitHub’s about protected branches).

Fail a CI job on the severity counts. The last line of the check run’s Details is a machine-readable comment with a count per severity; normal counts Important findings, including earlier ones whose threads are still open. This script waits for the review and fails when normal is above zero:

#!/usr/bin/env bash
# usage: code-review-gate.sh OWNER/REPO HEAD_SHA [WAIT_SECONDS] [POLL_SECONDS]
set -euo pipefail
repo="$1"; sha="$2"; wait_max="${3:-900}"; poll="${4:-15}"
url="repos/$repo/commits/$sha/check-runs?check_name=Claude%20Code%20Review"
run=""
for ((waited = 0; waited <= wait_max; waited += poll)); do
  run=$(gh api "$url" --jq '.check_runs | max_by(.id) // empty | "\(.id) \(.status) \(.conclusion)"') \
    || { echo "gate: cannot list check runs: blocking" >&2; exit 1; }
  case "$run" in *" completed "*) break ;; esac
  sleep "$poll"
done
case "$run" in *" completed "*) ;; *) echo "gate: no finished Claude Code Review run on $sha after ${wait_max}s: blocking" >&2; exit 1 ;; esac
case "$run" in *" skipped") echo "gate: review skipped because the push changed no files" >&2; exit 0 ;; esac
out=$(gh api "repos/$repo/check-runs/${run%% *}" --jq '.output') \
  || { echo "gate: cannot read the check run: blocking" >&2; exit 1; }
[ "$(jq -r '.title' <<< "$out")" = "Code review found no issues" ] && exit 0
counts=$(jq -r '.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson' <<< "$out" 2>/dev/null) \
  || { echo "gate: no severity line in the check run: no verdict, blocking" >&2; exit 1; }
echo "severity counts: $counts"
[ "$(jq -r '.normal // 0' <<< "$counts")" -eq 0 ] || { echo "gate: Important findings are open" >&2; exit 1; }

It fails closed on a timeout, an API error and a missing severity line (a review that failed, timed out, was canceled or was superseded leaves none, and no verdict is not zero findings). A skipped run means the push changed no files, so it passes; earlier findings still count through the first control. It needs a review on every new commit, so use it only on repositories set to After every push; on the other two settings a new commit gets no review, so rely on the first control. Anthropic documents the same parsing in Read and request reviews on a pull request.

What does managed Code Review cost?

There is no flat per-review price (checked 2026-10-16). Reviews bill on token usage through usage credits, to the organization, and the cost grows with the level, the size of the change, the surrounding code and the issues to verify. For a pilot, set a monthly spend limit at claude.ai/admin-settings/usage, turn Code Review on for a few repositories at Once after PR creation or Manual, then multiply each repository’s Average cost (Admin settings > Claude Code) by its pull requests per month, and by the pushes per pull request for After every push. A review is skipped, with a comment that names the cause, when the spend limit, the organization’s limit or the usage credits balance runs out. The 2026-03-09 announcement said reviews “generally average $15–25”, wording the current costs page does not repeat, so use your own average.

How do you write a REVIEW.md the reviewer follows?

REVIEW.md at the repository root tailors managed Code Review; one in a subdirectory adds checks for that path. The review reads it from the pull request’s base or default branch, never from the pull request’s own changes, so merge the change first. Protect the default branch: instructions that lower a severity, exclude paths or cap nits are honoured only when the root file is read from a protected default branch. On an unprotected default branch the review reads the root file only and the check run says so; if it cannot confirm your protection it reads none (Customize Code Review, checked 2026-10-16).

Anthropic’s Claude Code team reported on 2026-10-15 that its code owners’ good REVIEW.md files are short, say what failure looks like in that repository (“for docs it’s ‘it lies,’ for config it’s ‘it misroutes’”), cap the nits, list paths to skip, ask for a file and line as evidence instead of a guess from a name, and ask for a summary that starts with a count and says plainly when there is nothing to fix. The team also checks separately that the reviewer follows the file. An example built from those traits:

# Review instructions

## What failure looks like here

- Docs: a page that lies. A command, flag or default the code lacks is Important.
- Config: a value that misroutes. A secret in a file is Important.
- src/payments/: an unscoped query or a swallowed error is Important.
- Style and naming are Nit at most.

## Cap the nits

At most five Nits per review.

## Do not report

- Anything CI enforces (lint, formatting, types), src/gen/ and lockfiles

## Evidence

Cite file:line for every claim about behaviour; never infer it from a name.

## Summary

Start with a count, for example "2 Important, 3 Nit". If nothing needs fixing, say so and stop.

Anthropic’s page says REVIEW.md changes what a review finds and reports, not its format, so treat the summary rule as a request and read a few real summaries before relying on it.

Fix repeated findings at the source. The team fixes the cause in the skill, with a lint rule or in the instruction files, and Anthropic’s page says to ask a maintainer to add a rule to REVIEW.md. Our mapping: formatting and type errors go to the formatter, linter or a hook (then list the category under “Do not report”); a convention every session should follow goes to CLAUDE.md; severity, nit caps and generated files go to REVIEW.md; a multi-step check goes to the team review skill. When a review misses something, the team asks what the model did not have in front of it and puts the fix into a CLAUDE.md, a skill or a new check.

How do you answer every Code Review finding?

Anthropic’s Claude Code team reported on 2026-10-15 that every finding has to be answered: you fix it or resolve the thread with a reason, and often an agent picks up the fix overnight. Its adoption checklist says to “require every review thread resolved before merge” without naming the setting; with the public product the documented lever is branch protection that requires conversation resolution (see how to block a merge on a finding). To answer (checked 2026-10-16):

Fix it: push the change; the next review resolves the thread when it judges the issue fixed.
Dismiss a false positive: write the reason in the thread, then resolve it on GitHub. A reply alone does not dismiss a finding.
Explain or disagree: reply. A reply starts no review; the next one reads it and can resolve the thread or post one follow-up.
Get a review without pushing: comment @claude review.

List the review threads on pull request PR_NUMBER with `gh api graphql`:
repository(owner: OWNER, name: REPO) { pullRequest(number: PR_NUMBER) {
reviewThreads(first: 100) { nodes { id isResolved path line comments(first: 20) {
nodes { body author { login } } } } } } }. For every thread where isResolved is
false, do one thing. FIX it: failing test, smallest fix, full suite, push, reply
with the commit hash. Or, if the finding is wrong or intended, reply with one
sentence that cites file:line, then resolve the thread with the resolveReviewThread
mutation. After three review rounds, stop and list the findings that keep
returning. End with a table: thread | fix or reason | evidence.

Replace PR_NUMBER, OWNER and REPO with your values. The article says a person is accountable for every change that ships, whoever typed it, so the person directing the agent checks each reason.

How do you stop an agent author and an agent reviewer from looping?

An agent author and an agent reviewer can keep each other busy indefinitely. Anthropic’s Claude Code team reported on 2026-10-15 that one CLI pull request went through more than fifty rounds of review and fixes overnight, and that about 59% of what the reviewer kept flagging was code present since its first pass. Noise costs more with an agent author, which fixes every nit and so adds another commit and another round. The team changed re-review in four ways (checked against the public product on 2026-10-16):

A round cap: after three rounds the reviewer asks the author to step back and reconsider the approach. The Code Review pages list no such setting, so use the CLAUDE.md block in this section, with Once after PR creation or Manual.
Diff-only re-review after the first few passes. The closest built-in behaviour is that a later automatic review focuses on what changed (Anthropic does not say it is the same mechanism).
Flag the class of bug, so the author fixes every instance: tell the author agent to search for the class, and add it to REVIEW.md.
No repeats of posted findings. The pages describe no repeat filter; a re-review reads replies and can post one follow-up.

For its internal pull requests the team reports (self-reported) that passing after one review-and-fix round rose from 65% to 78%, needing five or more rounds fell from 8.9% to 1.5%, and mean reviews to pass fell from 2.08 to 1.32. It tracks rounds-to-pass alongside recall. Our adaptation for your author agents’ CLAUDE.md:

## Review rounds

- Answer every review finding: fix it, or resolve the thread with one sentence that
  cites file:line. Never re-fix a finding you already answered.
- When a finding is one instance of a class of bug, fix every instance in one commit.
- After three rounds on one pull request, stop, list the findings that keep returning
  and ask the human whether to change the approach.

How do you know the reviewer catches what matters?

A review that reports nothing looks the same whether the code is clean or the reviewer is blind. Measure it the way you measure a test suite: plant defects and count what comes back.

Keep a fixture branch, review-fixture, with five planted defects, one per class you care about: a missing authorization check, SQL built from strings, an error swallowed in a payment path, an off-by-one in pagination, and a test assertion loosened so it always passes. Keep the list of planted defects off the branch; a reviewer that can read the answer key is not being measured.
Run each reviewer three times on that branch — /code-review medium main...review-fixture, /pr-check, and the pre-push prompt through claude -p. Models are not deterministic, so one run proves little.
Record four numbers per reviewer: planted defects caught (out of five), findings that were not planted and are wrong (false positives), wall-clock time, and total_cost_usd from the JSON output.
Rerun the fixture whenever you change the Review rules, the model, the effort level or the Claude Code version. A drop in the catch rate is a regression, the same as a failing test.
Add every incident to the fixture. Anthropic’s Claude Code team reported on 2026-10-15 that it turned past incident pull requests (with their fix-forwards and reverts), each bug confirmed by engineers who know the code, into an eval its reviewer runs daily and every reviewer change is scored against. It also sorts each reviewer comment by the author’s response (fixed, wrong, intended, or did not matter) and runs the reviewer on known-clean pull requests. Start smaller: add the pull request behind each revert or incident, and tally author responses for a month.

Create a branch named review-fixture from main. Do not push it.
Plant exactly five defects in realistic places in this codebase, one of each:
1. A route that returns another user's data because it skips the authorization check.
2. A database query built by string concatenation from request input.
3. A caught error in payment or billing code that is logged and then ignored.
4. An off-by-one in a pagination or date-range boundary.
5. A test whose key assertion is loosened so it passes for wrong output.
Make each change look like ordinary work, with no hint comments, and commit each one
separately with a message that does not name the defect. Write the answer key
(file:line and class of each defect) to ../review-fixture-key.md, outside the
repository, and never commit it: a reviewer reads the whole checkout.

Who signs off on what:

Evidence	Owner
Catch rate and false-positive rate on the fixture, rerun after each change	Tech lead, who owns the Review rules
`pass` verdict from the pre-push gate and a clean `/code-review`	The author
Tests, types and lint green in CI, outside Claude’s control	CI
Approval on `CODEOWNERS` paths: migrations, auth, money, tests, CI config, `CLAUDE.md`	A named code owner
Every Claude Code Review thread fixed or resolved with a reason	Branch protection that requires conversation resolution
Revert and incident rates, the guardrail that shows human time was saved and not moved	Tech lead, reviewed monthly next to review rounds per pull request

An automated review is a sensor, not the approval. What a person reads instead of the full diff is set out in reviewing an agent’s pull request without reading every line, and what the pull request must carry in the evidence bundle.

When automated code review goes wrong

Symptom	Cause	Recovery
The team stops reading Claude’s findings	Style and low-confidence findings drown the real ones	Run `/code-review low` day to day (it keeps the findings it is most confident in) and `medium` or higher before risky merges; list “Do not flag” categories in `CLAUDE.md` and cap nits in `REVIEW.md`
Findings suddenly broaden or narrow	A bare `/code-review` reused a level typed in an earlier session	Type the level; pin it in the team skill or hook
`/rewind` did not undo the review’s fixes	Background `--fix` edits sit outside checkpoints	Commit before `--fix`; undo with `git restore .`, remove new files after `git clean -n`, or `git revert`
A `REVIEW.md` rule is ignored locally	Local `/code-review` does not read `REVIEW.md`	Move rules that must hold everywhere into `CLAUDE.md`
The pre-push gate passes a branch it should fail	The prompt did not ask for that defect class	Add the class to the Review rules and rerun the fixture until it is caught
Pushes hang or fail during an API outage	The hook waits on the network	Keep the fail-open branch; CI stays the blocking gate
The reviewer approves code the same session wrote	Reviewer and author share context	Use the forked `/pr-check`, a fresh session or `claude ultrareview`
A pull request loosens its own review	The branch edits `CLAUDE.md`, `.claude/` or `.githooks/`	Put those paths under `CODEOWNERS`
`/code-review:code-review` and `/code-review` differ	They are different reviewers: marketplace plugin and built-in skill	Pick one per stage and write it down
Ultrareview does not start	Zero Data Retention, the HIPAA configuration, CMEK, a cloud provider without Ultrareview, an API-key-only login, or `-p` stopped for billing consent	Run `/login` with a claude.ai account, run `claude ultrareview` yourself, or use `/code-review high` locally
Ultrareview refuses the diff as too large	Over the default limit of 500 files or 8,000 lines	Split the change into smaller pull requests
Ultrareview asks for PR mode	The repository is too large to bundle for upload	Push the branch, open a draft pull request and run `claude ultrareview <number>`
Managed Code Review found a bug, yet the pull request merged	Its check run is neutral, and branch protection did not require resolved threads	Require conversation resolution, or fail a CI job on `normal` (block a merge)
A `REVIEW.md` change has no effect on its own pull request	It is read from the base or default branch only; on an unprotected default branch the review reads the root file only, and rules that lower severity, skip paths or cap nits count only from a protected one	Merge the change first and protect the default branch with a classic rule or a ruleset
No review started on a pull request	The repository is set to Manual, the pull request is a draft or from a fork, or a budget limit was reached	Comment `@claude review` (write access needed); after a “Code review skipped” comment, an admin first raises the limit at claude.ai/admin-settings/usage
A finding was answered but still blocks the merge	A reply alone does not dismiss a finding	Resolve the thread, or push a fix
Review rounds never end	An agent author fixes every finding and an agent reviewer finds a few more each round	Put the round cap and class-of-bug rule in the author’s `CLAUDE.md`, and use Once after PR creation or Manual
Review spend is higher than planned	After every push multiplies the cost by the pushes	Move busy repositories to Once after PR creation or Manual, and read each Average cost

Where to go next with review automation

Prerequisite: a gate is only as strong as its oracle, so start from testing and debugging with Claude Code.
Run the same review on every pull request in running Claude Code in CI/CD, and make security findings block a merge with security audits with Claude Code.
Guard the merge queue when agents open most pull requests: running the review queue.
Why evidence replaces line-by-line reading: reading evidence instead of code, human in the loop and governance and autonomy.
Other tools and bots: code review inside the agent, AI code review bots, code review with Codex and code review with Cursor. The whole stage: review and ship with Claude Code.