Claude Code code review: three different things with the same name

Searching for Claude Code code review returns three separate products blended together. The local /code-review skill, the managed Code Review that comments on your PRs, and the GitHub Action you write yourself. What each one actually does, the gotchas that make each silently produce nothing, and how to pick.

If you search for Claude Code code review you get three different products blended into one answer, and the confusion is not your fault. There genuinely are three:

1. /code-review, a skill you type in your terminal. Free on any plan.
2. Code Review, a managed service that comments on your GitHub pull requests. Team and Enterprise, research preview.
3. The GitHub Action, where you write the workflow yourself and Claude runs inside your CI.

They overlap enough to be confusing and differ enough that picking wrong wastes real money. Being precise about which one you mean is most of the work, so this post separates them, then covers the failure modes that make each one quietly do nothing.

Where we speak from: we run /code-review and /security-review daily, and our repo has a code reviewer step in its own agent pipeline. We are not on a Team plan, so the managed service section is built from the documentation rather than from our own PRs, and it is marked as such.

1. /code-review, the local one

This is the one most people should start with, and the one most write-ups stop at.

Typed bare, it reviews your branch's commits ahead of upstream plus uncommitted working tree changes. Pass a target to review something else: a file path, a branch, a PR number, or a ref range like main...my-feature. Two flags matter: --fix applies findings to your working tree, --comment posts them as inline PR comments.

Effort is the real dial. low and medium report only high-confidence findings, so you get fewer false positives. high through max broaden coverage and will include things the review is less sure about. There is a detail worth knowing: when you do not type a level, it reuses the last level you typed, even from an earlier session, and prints a notice saying so. If your reviews suddenly got noisy, you probably typed max last week and forgot.

The review runs as a background subagent with its own context window, so it does not fill your conversation. That is good for context cost and it creates the first real gotcha.

Gotcha: /rewind does not undo a background review's --fix edits. Subagent edits fall outside your session checkpoints, so the usual undo does not reach them. Use git. If you want the review's edits inside your checkpoint history, run it in the foreground.

Gotcha: the local review does not read REVIEW.md. It follows CLAUDE.md like any session, but the review-specific instructions file described below is read only by the managed service. Teams write a careful REVIEW.md, run /code-review locally, and wonder why nothing changed.

Two neighbors worth knowing: /simplify is a cleanup-only pass that applies fixes without hunting for bugs, and /code-review ultra escalates to a deeper multi-agent review in the cloud. Ultra takes its scope from your branch against the default branch and is not available on Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, or under Zero Data Retention.

If you would rather Claude never start a review on its own, skillOverrides settles it:

{
  "skillOverrides": {
    "code-review": "user-invocable-only"
  }
}

2. Code Review, the managed service

This is the one people picture when they imagine Claude reviewing PRs: a fleet of agents analyzes the diff against your full codebase in parallel, each looking for a different class of issue, then a verification step checks candidates against actual code behavior before anything is posted. Findings land as inline comments on the exact lines, tagged by severity.

Severity is three markers, and the third is the interesting one. 🔴 Important is a bug to fix before merging, 🟡 Nit is minor, and 🟣 Pre-existing is a real bug that your PR did not introduce. Separating that third category is what keeps an unrelated landmine from reading as your fault.

It never blocks a merge. The check run always completes with a neutral conclusion, by design, so branch protection stays yours. If you do want to gate on it, parse the machine-readable severity counts out of the check run:

gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID \
  --jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson'

That returns something like {"normal": 2, "nit": 1, "pre_existing": 0}, where a non-zero normal means at least one bug worth fixing before merge.

REVIEW.md is the tuning surface, and it is not CLAUDE.md. CLAUDE.md is read as project context, with newly introduced violations flagged as nits. REVIEW.md goes directly to the agents that find, verify, rank, and report, which is why repo-specific rules land more reliably there than buried in a long CLAUDE.md. The things worth putting in it, in rough order of payoff: redefine what Important means for your repo, cap nit volume ("at most five, mention the rest as a count"), list paths to skip entirely, and set a re-review rule so a one-line fix does not reach round seven on style. Note that @ imports are not expanded, so rules have to be in the file itself.

Cost is the part to read twice. Reviews average $15 to $25 each, scale with PR size, and are billed through usage credits separately from your plan's included usage. The trigger setting multiplies that: once per PR, on every push, or manual. On a busy repo, "after every push" is the difference between a line item and a budget conversation. Reviews complete in 20 minutes on average.

Gotcha: private org membership silently kills @claude review. GitHub defaults organization membership to private, and in that case it does not identify you to Claude as a member. You may get a 👀 reaction and no review, even though a team grants you write access. Make your membership public or get added to the repo as a direct collaborator.

Gotcha: forks never review automatically. Regardless of trigger setting, a fork PR reviews only when someone comments @claude review. Pushing does not start one, and neither does clicking Re-run.

Also worth knowing: @claude review runs once, @claude review always subscribes the PR to reviews on later pushes. Before a change in July 2026 the bare command did the subscribing, so older instructions you find will have this backwards.

3. The GitHub Action, when you want the wiring

Use this when you want control of the prompt, model, and triggers, when you are not on a plan with the managed service, or when review is one job among several. /install-github-app scaffolds it, or you copy the workflow yourself.

Everything else about it is documented well enough. The part that bites:

Gotcha: it takes two lines to actually post a review. --comment in the prompt is necessary but not sufficient, because the action starts the MCP server that posts inline comments only when claude_args also names that tool:

prompt: "/code-review:code-review --comment ${{ github.repository }}/pull/${{ github.event.pull_request.number }}"
claude_args: '--allowedTools "mcp__github_inline_comment__create_inline_comment"'

Drop either line and the workflow runs, burns tokens, succeeds, and posts nothing. You find the review in the run log. The skill's own allowed-tools frontmatter naming the same tool does not cover this.

Two more that save an afternoon: CI does not run on Claude's commits if you pass github_token: ${{ secrets.GITHUB_TOKEN }}, because GitHub does not trigger workflows on commits made with the default token, so remove it and let the action authenticate as the app. And on public repositories, fork PRs get no secrets, so review only runs on same-repo branches.

/security-review, the separate pass

Correctness review and security review are different questions, and by default the review layers above focus on correctness rather than security. /security-review checks the current diff for vulnerabilities as its own pass, and the security-guidance plugin reviews changes for common vulnerabilities in the same session that wrote them, which catches things earlier than any gate can. We covered where this sits in a real threat model in the security post.

How to pick

• Solo or small team, want it now: /code-review before you push, at medium. Costs nothing extra, catches the embarrassing things, and you can escalate to high on anything touching auth or money.
• Team or Enterprise, want PR comments without maintaining YAML: the managed service, starting in Manual mode. Turn on automatic triggers per repo once you have seen what a review actually costs you.
• Want control, or not eligible: the GitHub Action, with both lines from the gotcha above.
• Any of the above: write REVIEW.md if you are on the managed service, keep CLAUDE.md short enough to be read, and remember that everything an agent reviews it also has to load, which is the same context economics as everything else.

The habit that made the biggest difference for us is not any of the three. It is running the review before opening the PR rather than after, because a finding you fix in your working tree costs one edit, and the same finding on a PR costs a comment, a push, a re-review, and someone else's attention. The tools are good enough now that the ordering is the interesting decision.