Claude Code review: /code-review, /security-review and PR reviews

Claude Code reviews code in several ways: the bundled /code-review command (alias /review) checks your branch for correctness bugs, /security-review checks it for vulnerabilities, /code-review ultra runs a deeper review in the cloud, and the managed Code Review service comments on every GitHub pull request for Team and Enterprise organizations. You can also run reviews in your own CI with GitHub Actions.

This guide explains what each option does, when to use it, and how to get useful reviews rather than noise. All commands and limits come from Anthropic's Claude Code docs, read on 24 October 2026.

What are the ways to get a Claude Code review?

The docs compare five ways to get a review. This table shows four of them, plus /security-review from the commands reference.

The fifth option in the docs is to write your own reviewer as a subagent or skill.

How does /code-review work?

/code-review is a bundled skill: its instructions are built into Claude Code, so there's no SKILL.md on disk to edit. In the docs' words, "Claude reviews the changes on your branch, looks for correctness bugs, and reports what it found in your conversation." Depending on your model and effort level, it also covers reuse, simplification and efficiency cleanups.

The review runs as a background subagent with its own context window, so it doesn't fill your conversation, and the findings arrive when it finishes.

Choosing what to review

With no target, it reviews your branch's commits ahead of its upstream plus uncommitted changes. You can point it elsewhere:

Flags and effort levels

/code-review [low|medium|high|xhigh|max|ultra] [--fix] [--comment] [--max-findings n|all|default] [pr#|branch|path]

• --fix applies the findings to your working tree. Edits go through your permission mode.
• --comment posts findings as inline comments on a GitHub pull request, or as a single note on a GitLab merge request (v2.1.257 or later, using the glab CLI).
• --max-findings raises or lowers how many findings are reported (v2.1.288 or later).
• The effort level trades coverage for confidence. At low you see the findings Claude is most confident in. From medium to max, coverage widens.

If you don't type a level, the review reuses the last level from low to max you typed, even from an earlier session.

What it reads

/code-review follows your CLAUDE.md, including in non-interactive -p runs. It does not read REVIEW.md, which only configures the managed Code Review service. So put rules you want in every review, such as "all database queries must be scoped to a tenant," in CLAUDE.md.

One caution from the docs: a background review's --fix edits happen outside your session's checkpoints, so /rewind won't undo them. Use git to revert.

Replacing it with your own

A project or personal skill named code-review runs in place of the bundled one, and /review keeps running the bundled review. That's how skills like Matt Pocock's code review skill, which checks standards and spec compliance, can take over the name. If you want both, give yours a different name.

What does /security-review check?

The commands reference describes /security-review as a command to "Analyze the changes on your current branch for security vulnerabilities." It reviews the diff between your branch and origin's default branch, looking for risks like injection, auth issues and data exposure.

It needs an origin remote. If it fails with an ambiguous argument error, that's the documented cause.

Run it before you open a pull request that touches auth, input handling, file uploads or anything that builds queries or shell commands. It complements /code-review rather than replacing it, since /code-review is aimed at correctness.

When should you use ultrareview?

Ultrareview is a research preview that runs "a fleet of reviewer agents in a cloud sandbox." The docs say every reported finding is independently reproduced and verified, and your terminal stays free while it runs.

/code-review ultra            # current branch vs default branch
/code-review ultra develop    # compare against another base
/code-review ultra 1234       # a github.com pull request

Limits worth knowing:

• It requires signing in with a claude.ai account. It isn't available on Amazon Bedrock, Google Cloud's Agent Platform or Microsoft Foundry, or with Zero Data Retention; in those cases /code-review ultra runs a local review instead.
• As of October 2026, Pro and Max include 3 free runs, a one-time allotment. After that, each review typically costs $5 to $25 in usage credits, and the launch dialog shows the estimate before you confirm.
• Claude never starts an ultrareview on its own.

Save it for large or risky changes where a missed bug costs more than the review.

How does Code Review work on GitHub pull requests?

Code Review is a managed service for Team and Enterprise plans. An Owner of your Claude organization turns it on, installs the Claude GitHub App and picks repositories. After that, Claude reviews pull requests on its own.

A review runs in four stages on Anthropic infrastructure: several agents look for issues in parallel, a verification step filters false positives, findings are deduplicated and ranked, and the results are posted. Each finding is an inline comment marked Important (fix before merging), Nit (minor) or Pre-existing (a bug the PR didn't introduce). A review never approves or blocks a pull request.

Useful details:

• Each repository can review once when a PR opens, after every push, or only on request.
• Anyone with write access can comment @claude review for one review, or @claude review always to subscribe the PR to push-triggered reviews.
• Review levels are Quick, Standard (the default) and Deep.
• Add a REVIEW.md at the repo root to set what counts as Important, cap nits and skip generated files.
• Billing is on token usage through usage credits, separate from plan usage, with an org-wide monthly spend limit.

On other plans, a GitHub Actions review workflow runs Anthropic's code-review plugin on your own runners instead.

How do you get useful reviews instead of noise?

The tools find bugs, but your setup decides how good the signal is.

1. Keep diffs small. A focused change with one purpose is easier for any reviewer, human or AI, to check.
2. Write the rules down. Put team conventions in CLAUDE.md. For the managed service, use REVIEW.md to say what not to report, such as anything CI already enforces.
3. Start at low effort. Use /code-review low for routine changes and raise the level for risky ones.
4. Run security review separately. Treat /security-review as its own pass on sensitive changes.
5. Verify before you fix. Anthropic's docs note that Code Review "may miss bugs, security vulnerabilities, or other issues," and the same caution applies to every option. Read each finding and confirm it before applying --fix.
6. Keep a human approver. None of these tools approves a PR, and that's deliberate.

For tasks the bundled command doesn't cover, such as reviewing for accessibility or API design, write a prompt or skill. The code review prompts collection has ready-made starting points.

Where should you keep custom review prompts and skills?

Once you have a review prompt or a code-review skill that works for your team, keep it somewhere you can reuse it. Kipt stores prompts and SKILL.md folders as Markdown in a private GitHub repo you own, with {{name}} blanks for things like the base branch. You can install every saved skill into Claude Code with npx skills add https://github.com/<you>/<repo>.git --all -g.