reviewing a diff

The bundled /code-review skill points Claude Code at a change and reviews it the way a careful colleague would: correctness bugs first, then reuse, simplification, and efficiency cleanups — not a style linter, it reads for intent, not just syntax, and it only runs when you actually invoke it, never silently on its own. Left with no arguments it reviews your current working diff, but you can just as easily hand it a PR number, a branch, or a path instead.
/code-review | | reviews the current working diff at whatever effort level you last used |'ccr_cmd1'
/code-review <PR # path> | | points the review at something other than your current working diff |'ccr_cmd2'
An effort level tunes how hard it looks and how much it's willing to say. Low and medium report fewer findings, but each one is high-confidence — a good default when you just want the obvious bugs caught. High and max widen the net considerably: more coverage, but some findings may be worth a second look rather than acted on immediately. Leave the level off entirely and it quietly reuses whichever one you typed last, so you don't have to repeat yourself pass after pass.
/code-review <low medium high max> | | sets how deep the pass goes and how many uncertain findings it's willing to surface |'ccr_cmd3'
Two flags change what happens to the findings themselves, rather than how they're found. --comment posts them as inline comments on a GitHub PR instead of just printing them to the terminal; --fix goes further and applies the findings directly to your working tree once the review finishes, so you review a diff of the fixes rather than a list of suggestions.
/code-review --comment | | posts findings as inline comments on the target PR |'ccr_cmd4'
/code-review --fix | | applies the review's findings to the working tree after the review runs |'ccr_cmd5'

ultrareview: a heavier multi-agent pass

/code-review ultra is the heaviest setting: instead of one pass running locally, it launches several review agents in the cloud that work the change in parallel. By default it bundles your current local branch — no GitHub remote required — or you can point it at a specific PR by number. It needs an actual git repository to work from; if you're not in one yet, Claude Code will offer to run git init first rather than failing outright. /ultrareview still works as a deprecated alias for the same command, kept around for old habits.
/code-review ultra | | runs a deep, multi-agent review of the current local branch in the cloud |'ccr_cmd6'
/code-review ultra <PR#> | | runs the same cloud review against a specific GitHub PR |'ccr_cmd7'
Because it spins up multiple agents in the cloud, ultrareview is user-triggered and billed on its own — it's a check you reach for on a change you specifically want scrutinized harder, not something to run as the default gate on every small diff. When the target is a PR on GitHub.com, --post offers to publish the finished findings back to that PR as a single comment from your own GitHub account (a comment, not a formal review) — an interactive session still confirms before posting, while a non-interactive one posts on the flag alone. --no-post hides that offer if you'd rather it never ask.

code-review vs. simplify

/code-review's closest sibling is /simplify, and it's easy to reach for the wrong one. /simplify looks at the same kind of changed code but narrows its attention to reuse, simplification, and efficiency cleanups — it deliberately does not hunt for correctness bugs, and rather than reporting findings for you to weigh, it applies them directly. Reach for /code-review when you want someone checking whether the change is actually correct; reach for /simplify once it already works and you just want it tightened up.

security review

A dedicated security-focused pass over pending changes checks for the OWASP-style categories a general review might skim past — injection, auth/authorization gaps, secrets accidentally committed, unsafe deserialization. Worth running as its own step rather than folding into a general review, since it's a different mindset: assume adversarial input, not just buggy input.

as a debugging partner

Beyond static review, Claude Code can actually run your code, reproduce a failure, add temporary logging, and iterate — the same general debugging method (reproduce, isolate, inspect state, form a hypothesis, test it) any engineer would follow, just with someone else driving the terminal alongside you rather than you doing every step alone. The bundled /run skill goes a step further for a specific claim: it launches your actual app and confirms a change does what it should, rather than trusting tests or type-checks alone to prove it.

what it's not a substitute for

An AI review is a second opinion, not a merge gate on its own — it can miss context a human reviewer who knows the system's history and constraints would catch, and it can be confidently wrong about something subtle. Treat findings as things to verify, especially anything flagged as high-severity, rather than facts to act on unread.

related topics

Debugging: gdb, pdb & a General Method — the underlying debugging discipline this page builds on.
GitHub Cheat Sheet — branch protection and required status checks, the non-AI half of a review gate.
Claude Skills — how /code-review and /run are packaged and invoked.
Hooks & Automation — enforcing a check automatically, instead of remembering to ask for a review.

reference

code.claude.com — overview