Three review workflows, and what each one is worth

The branch is finished and it is bigger than you wanted. Lesson 5.5 gave you /code-review as the second opinion that stops the writer grading itself; Lesson 8.5 had you brief a reviewer of your own. Neither said that "review" now names three separate products: one that runs on your plan's normal usage, one that bills usage credits per run, and one your organisation may not have. They read different files, verify to different standards, and put their findings in different places.

Self-review first: seeing your own diff

/diff reviews "the changes in your working tree, including the edits Claude has made so far" (Commands). In practice it is the step that catches what no reviewer is placed to catch — this file should not be in the diff at all. A reviewer reads what the change does; only you know what it was supposed to do.

The local review: scope, effort, and where the fixes land

The local command "reviews a diff in your terminal without installing the GitHub App" and reports "correctness bugs and reuse, simplification, and efficiency cleanups" (Code review). Its default target is narrower than people assume — your branch's commits ahead of its upstream plus uncommitted changes, "so it needs work on the branch or in the working tree to have something to report". On a branch already merged, nothing is ahead of upstream and the review has nothing to report, which is not a clean bill of health. You can pass a file path, a PR number, a branch name, or a ref range such as main...my-feature, so /code-review 1234 reviews a colleague's pull request before you approve it, and --comment posts what it found back as inline PR comments.

/code-review high main...my-feature
/code-review 1234 --comment
/code-review ultra develop

/review is an alias of it, taking the same effort levels and flags. It was not always: before v2.1.223 it was a separate command running a single-pass, read-only review of a GitHub pull request by number, and from v2.1.186 through v2.1.201 it ran the same multi-agent engine as /code-review medium (Commands). A script or a finger habit that types /review expecting a PR-only reviewer now gets your working diff instead.

Effort is the confidence-versus-coverage dial from Lesson 5.5, with one detail that also landed in v2.1.223: type no level and the review reuses the last level from low through max you typed, even from an earlier session, saying so with a notice such as Reusing high effort, the level you typed last time. ultra neither updates nor uses that memory, and a level passed in a -p run does not update it. Before v2.1.223, and if you have never typed a level at all, the review uses the session's current effort instead.

--fix applies the findings to your working tree after the review. From v2.1.218 that review runs in the background by default, which is where Lesson 11.4's undo boundary — built there in full — reappears somewhere it looks safe: a background review applies its --fix edits outside your session's checkpoints, so /rewind does not undo them and git is what reverts them. A foreground review edits during your own turn and /rewind restores it as usual — which is what you get when you start a second review while one is running, in a -p or Agent SDK run, or with CLAUDE_CODE_DISABLE_BACKGROUND_TASKS set to 1. Before v2.1.218 every review ran inside your conversation, so this boundary arrived with an upgrade, in a command whose own text never changed.

Its neighbour /simplify applies cleanup fixes but "doesn't look for correctness bugs" (Commands) — a clean /simplify says nothing about whether the code works.

The cloud review: verified findings, real money

/code-review ultra sends the change to a fleet of reviewer agents in a remote sandbox. One property is the reason to pay:

every reported finding is independently reproduced and verified, so the results focus on real bugs rather than style suggestions — Ultrareview

Its scope is its own, not the local default: your current branch against the repository's default branch, plus uncommitted and staged changes. Pass a branch name for a different base, or a PR number — in PR mode nothing is uploaded from your machine.

A local review takes seconds to a few minutes and counts toward normal usage. This one takes roughly 5 to 10 minutes and costs: 3 free runs on Pro and Max, then roughly $5 to $25 per review in usage credits. The free runs are a one-time allotment that does not refresh, Team and Enterprise get none, and a free run is spent on starting rather than on succeeding — "A review you stop early or that fails to complete still uses a free run", while a paid review bills only for the portion that ran. Before launching, Claude Code shows a confirmation dialog with the scope, your remaining free runs and the estimated cost, and "Claude doesn't start an ultrareview on its own" (Ultrareview) — unlike the local command, which Claude can start for you and a scheduled task can run, a behaviour that needed a feature flag before v2.1.246.

There is a ceiling too: up to 500 changed files and 8,000 changed lines by default for a branch review, values that can change, with the refusal naming the limits in effect. A refusal is information — the change is too big for one pass, which is usually also true of the human asked to approve it.

PR-time Code Review: severities that do not block

The managed surface, and the first question is whether you can have it: "Code Review is in research preview, available for Team and Enterprise subscriptions. It is not available for organizations with Zero Data Retention enabled" (Code review).

It runs on GitHub pull requests: agents analyse the diff and surrounding code in parallel, a verification step checks candidates against actual code behaviour to filter out false positives, and survivors post as inline comments on the lines where they were found. By default it aims at "correctness: bugs that would break production, not formatting preferences or missing test coverage". It is not the cheap one either: reviews complete in 20 minutes on average and each averages $15 to $25, billed as usage credits separately from your plan's included usage. That bill lands on the organisation, which is why whether every push gets reviewed is an Owner's setting and not yours.

The third row is a triage instrument, not a decoration: a pre-existing finding is real and is not yours, and treating it as PR feedback is how a two-file change becomes a week. The check it writes is deliberately toothless:

The check run always completes with a neutral conclusion so it never blocks merging through branch protection rules. — Code review

Gating is something you build: the Details text ends in a machine-readable comment carrying per-severity counts, which your CI can parse with gh and jq. And replying to an inline comment does not prompt Claude to respond — to act on a finding, fix the code and push.

Tuning the reviewer: CLAUDE.md versus REVIEW.md

That last cell is the trap: the local review follows your CLAUDE.md like any session, "but it doesn't read REVIEW.md", so every calibration rule you put there is invisible to the command you run in your terminal and visible only to the product you may not have. REVIEW.md is freeform markdown at the repository root, and the lever to reach for first attacks noise at its source:

Verification bar: require evidence before a class of finding is posted. For example, "behavior claims need a file:line citation in the source, not an inference from naming" cuts false positives that would otherwise cost the author a round trip. — Code review

That is Lesson 8.5's discount, moved into a file the finding agents read. Other levers the page names: redefine what Important means here, cap nits per review, skip paths CI already enforces, add repo-specific checks, set re-review convergence, and shape the summary. Imports are not expanded there and referenced files are not read along with it, so put the rules in the file — and keep it short, because "a long REVIEW.md dilutes the rules that matter most", the economy Lesson 6.6 made about CLAUDE.md.

Real, stylistic, unfounded: triaging a findings list

A findings list is a list of claims. What was already done to each claim before it reached you differs by surface:

And one disposition applies to every row:

A reviewer prompted to find gaps will usually report some, even when the work is sound, because that is what it was asked to do. Chasing every finding leads to over-engineering — Best practices

Read that precisely. The documentation's word for what gets filtered out is false positive — a finding that does not hold up. It does not say reviewers invent problems, and neither should you; it says a reader instructed to find gaps returns a list whose length is partly a property of the instruction. In this course's terms: sort each finding into real, stylistic (it differs from how you would have written it) and unfounded (it does not survive being checked). The last two are cheap to ignore and expensive to chase.

The security layer that runs whether you ask or not

With the security guidance plugin installed there is a fourth reviewer you never invoke: a pattern match on each file edit, a background model review of the diff at the end of each turn, and a deeper agentic review on each commit or push Claude makes. Its independence is designed in — "The plugin does not ask the same Claude instance that wrote the code to grade itself". Two limits decide its worth. "None of the layers block writes or commits": findings reach the writing Claude as instructions, and the review model can miss issues. And the deepest layer has a blind spot — it "fires only on commits and pushes Claude makes through its Bash tool. Commits you run from your own shell, including the ! shell escape inside a session, are not reviewed" (Security guidance). So the careful habit of committing by hand at the end of a session is exactly the one that skips it: the end-of-turn review still saw the diff, the commit review never ran.

Choosing, on purpose

None of these is a gate. Each is an opinion in a confident voice, and --fix applies that opinion to your working tree before you have read it — on a local run, and on an ultra run when the findings arrive back in your session. The discipline is Lesson 11.4's: know what the tool covers before you rely on having been covered.