Skip to main content
/code-review is a command you type at the Claude Code prompt, in the session where you’re working. 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, the review also covers reuse, simplification, and efficiency cleanups. The command works on any plan. The review runs in your own session, so it counts toward your plan’s usage or API billing the same way the rest of the session does.
To have every pull request in a repository reviewed automatically on GitHub, see Code Review, a managed service that an Owner turns on for your organization.
/review is an alias of /code-review. Before v2.1.223, /review was a separate command that ran a single-pass, read-only review of a GitHub pull request.
1

Run /code-review

Run the command:
With no target, the review covers the changes on your current branch. To point the review at a pull request, another branch, a path, or a range of commits instead, see Choose what to review.You can also add flags:
  • --fix: also asks Claude to apply the findings to your working tree after the review. Its edits go through your permission mode.
  • --comment: posts the findings on a GitHub pull request as inline comments, or on a GitLab merge request as a single note
2

Keep working

The review runs as a background subagent with its own context window, so it doesn’t fill your conversation. The findings arrive in your conversation when the review completes.
3

Act on the findings

Ask Claude to fix what the review found. With --fix or --comment, Claude applies or posts the findings as part of the review, and you may be asked to approve its edits.

​
Choose what to review

To review something other than your current branch, type a target after the effort level and any flags. Claude receives that text as the review target. A target can be a pull request number, a branch name, a file path, or a Git revision range. Find what you want reviewed in the first column and type what the second column shows: With no target, /code-review reviews your branch’s commits ahead of its upstream branch plus your uncommitted changes. If the branch has no upstream, Claude compares against main, or against the previous commit. With ultra, Claude Code reads the target differently, as Text after the effort level and flags describes.

​
What the review reads and edits

Check these before you run a review, especially with --fix:
  • Edits: without --fix, the review’s instructions ask Claude for a report only. With --fix, they also ask it to apply the findings to your working tree. Either way, any edit goes through your permission mode.
  • Rewinding: a background review applies its --fix edits outside your session’s checkpoints. After one, /rewind restores only the files Claude had already edited in your conversation. The review’s edits to other files stay, so use git to revert them. When the review runs in the foreground, it edits your working tree during your own turn, so /rewind restores its edits as usual.
  • Instructions: the review follows your CLAUDE.md, including in a non-interactive -p run. It doesn’t read REVIEW.md. That file configures the managed Code Review service on GitHub pull requests.

​
How findings are reported

Claude reports the findings as text in the reply in both of these runs:
  • In a terminal session, where /code-review runs the review as a forked subagent
  • In a -p run with text or JSON output
In a host application that requests the findings list, such as the desktop app, Claude reports the review’s findings through the ReportFindings tool instead. The report appears as a findings list, and each entry shows the file location, a one-sentence summary, and a category tag such as correctness when the finding carries one. A host request applies at every effort level and requires Claude Code v2.1.218 or later. When Claude fixes reported findings later in the session, it reports them again. Claude Code then marks each finding in the updated findings list as fixed, skipped, or no change needed.

​
Tune effort and arguments

Beyond --fix and --comment, the command takes these flags:
  • --post: on an ultra cloud review of a github.com pull request, preselects posting the finished findings to the PR in the launch dialog. See Post findings to the pull request. Requires Claude Code v2.1.227 or later.
  • --max-findings <n>, --max-findings all, or --max-findings default: reports up to n findings, or every finding with all, in place of the review’s usual limit. Where the review reports through the findings tool, the limit is 32. Later reviews reuse the value you typed until you pass --max-findings default, but a value passed in a non-interactive -p run isn’t remembered. Requires Claude Code v2.1.288 or later.
Pass an effort level to trade coverage for confidence. At low, the review reports the findings it’s most confident in, so you see fewer false positives. From medium through max, the review broadens coverage. When you don’t type a level, the review reuses the last level from low through max you typed, even in an earlier session. Claude Code shows a notice such as Reusing high effort, the level you typed last time. These rules decide which level a run uses:
  • Typing a level: a level you type, like /code-review high, changes what later runs reuse
  • Non-interactive runs: a level you pass in a non-interactive -p run doesn’t update the remembered level
  • ultra: the review neither uses nor updates the remembered level
  • No level ever typed: the review uses the session’s current effort
Before v2.1.223, a /code-review without a level always used the session’s current effort.

​
Post findings to a GitLab merge request

When you pass --comment for a GitLab merge request, Claude Code posts the findings through GitLab’s glab CLI. Requires Claude Code v2.1.257 or later. When glab isn’t installed, Claude prints the findings in the terminal instead. Pass the merge request as its URL or a !123 reference. Claude Code treats a bare number or branch name as a merge request only when the checkout’s origin is on gitlab.com. On a self-managed GitLab instance, pass the URL or !123 form.

​
Text after the effort level and flags

After the effort level and flags, Claude Code reads the rest of the line as the review target. The ultra argument changes that reading:
  • With ultra: Claude Code reads a single word as a base branch or PR number. Longer text that doesn’t name a branch or PR becomes a note attached to the review. /code-review ultra check my auth changes reviews your current branch, and Claude relates the findings to your note.
  • Without ultra: everything left is the review target, even when it starts with another command name. /code-review /fix-issue 123 reviews with /fix-issue 123 as target text instead of loading /fix-issue as a second stacked skill. Before v2.1.218, a command stacked after /code-review expanded as its own skill.

​
Run in the foreground

To make the review run in the foreground, do one of these:
  • Run it in non-interactive mode, with the -p flag or the Agent SDK. Claude Code waits for the review and includes the findings in the response, except for ultra, which doesn’t wait for the cloud review.
  • Set CLAUDE_CODE_DISABLE_BACKGROUND_TASKS to 1, which also turns off every other background task feature
  • Run /code-review again while an earlier review is still in progress
Before v2.1.218, the review ran inside your conversation.

​
Let Claude start the review

Claude can start /code-review on its own, without you typing the command:
  • When you ask in plain language: ask Claude to review your changes and it can run the skill
  • From a scheduled task: a scheduled task with /code-review as its prompt runs the review
A scheduled task never launches the cloud review, so schedule /code-review without the ultra argument. To stop both Claude and scheduled tasks from starting the review while keeping /code-review available for you to type, add a skillOverrides entry to a settings file such as ~/.claude/settings.json:
Before v2.1.246, Claude started /code-review on its own only where a feature flag fetched from Anthropic turned it on. In sessions that don’t fetch feature flags, /code-review ran only when you typed it, and a scheduled /code-review reached Claude as plain text.

​
Escalate to ultrareview

/code-review ultra --fix runs the deeper ultrareview in the cloud, then asks Claude to apply its findings to your working tree when they arrive back in your session. Ultrareview uses its own scope:
  • What it compares: your current branch against the repository’s default branch, plus uncommitted and staged changes in the working tree
  • Sensitive files: for uncommitted changes to files named like credentials or keys, such as .env and *.tfvars files, Claude Code follows the rules for uploading a local repository to a cloud session
  • A different base: pass a branch name, such as /code-review ultra develop, to compare against a different base
When the target is a github.com pull request, you can have Claude post the finished findings to the PR as a comment from your GitHub account. Requires Claude Code v2.1.227 or later.
Ultrareview requires authentication with a claude.ai account. It isn’t available on Amazon Bedrock, Google Cloud’s Agent Platform, or Microsoft Foundry, or to organizations with Zero Data Retention enabled or with the HIPAA configuration applied. In these cases, /code-review ultra runs a local review in your session instead. Organizations that use customer-managed encryption keys (CMEK) can’t run ultrareview. To review your changes locally, run /code-review.
To run a cloud review from a script or CI job, use the claude ultrareview subcommand, which waits for the findings and prints them to stdout.

​
Change or build on the review

/code-review is a bundled skill: its instructions are built into Claude Code, so there is no SKILL.md file on disk to open or edit. To give every review project rules to follow, add them to your CLAUDE.md. To go further, start from one of these pages:
  • Replace the command: a project or personal skill named code-review runs in place of the bundled one, and the /review alias keeps running the bundled review. See Resolve skills that share a name.
  • Build your own reviewer: write a reviewer subagent or a review skill
  • Use a neighboring command: /simplify reviews for cleanup only and applies its fixes, and /verify runs your app to confirm a change works
The command was named /simplify before v2.1.147, when it applied fixes by default. If you scripted /simplify for bug-finding, switch to /code-review --fix.
  • Code Review: the managed service that reviews every pull request on GitHub for your organization
  • Ultrareview: setup, limits, and cost of the deeper cloud review
  • Commands: the one-line reference for /code-review, /review, /simplify, and /verify
  • Skills: how bundled skills work and how to write your own