In Claude Code, /code-review is an automated code review: it looks at the changes you just made, hunts for correctness bugs and cleanup opportunities, and reports back a list of findings ranked by how serious they are. Think of it as a careful second reader who checks your work before anyone else sees it. Even if you don't write code yourself, this is worth understanding, because it is the same discipline any team uses to catch mistakes before they ship.

What Claude Code code review does

When you build software, you change files. A "diff" is simply the set of changes since the last saved version -- the new lines, the deleted lines, the edits. /code-review reads that diff and asks two questions: does this have any bugs, and can any of it be made cleaner or simpler? It then returns findings ordered most serious first, so the thing most likely to bite you sits at the top of the list.

/code-review

Review the changes you just made, before you save them. Click to copy.

It is a built-in skill, which means it ships with Claude Code -- there is nothing to install. You type it, and the review runs against whatever you have changed.

What a review looks like

The output is a short, ranked list. Each item names what it found, how severe it is, and where it lives in the code. Instead of a vague "looks good," you get something you can act on.

code-review findings
1Missing check on empty inputCould crash when the list is emptyHigh
2Same logic written twiceTwo blocks do the same thing -- combine themCleanup
3Unused leftover variableSafe to delete, no effect on behaviorMinor

A simplified view of a ranked findings list.

Set how deep the review goes

You can pass an effort level to control how broad the review is. A lighter pass returns fewer, high-confidence findings. A heavier pass casts a wider net and may surface things it is less sure about. The levels run from low up through max, so you choose the trade-off between speed and thoroughness.

Lighterlow / mediumFewer findings, higher confidence. Good for a quick check on a small change.
Heavierhigh / xhigh / maxBroader coverage that may include uncertain findings. Good before a big or risky change goes out.

Fix findings or post them on a pull request

A review is more useful when it plugs into what you do next. /code-review has two options for that:

  • Apply the fixes. Add --fix and Claude applies the findings to your working tree -- the copy of the files you are editing. You still review what changed, but you skip the manual patching.
  • Comment on a pull request. Add --comment and the findings post as inline comments on a GitHub pull request, which is the page a team uses to discuss a change before merging it. Now the whole team sees the notes in context.
/code-review --fix

Run the review, then apply the findings to your files. Click to copy.

A real example

Say you asked Claude to add a small feature -- a new field on a form, or a tweak to a report. It works, and you are about to save it. Before you do, you run /code-review. It comes back with three findings: one real bug where the code would fail on empty input, one spot where the same logic was written twice, and one leftover variable that does nothing. A quick read on your part would have caught none of these. You run it again with --fix, Claude patches all three, you glance at the changes, and you save with confidence.

The habit that pays off: run /code-review before you commit -- that is, before you lock in a change -- to catch problems a quick read would miss. It costs a minute and saves the cost of shipping a bug.

Related commands: /review and /simplify

Two nearby commands are easy to mix up, so here is the plain difference:

  • /review points the same review engine at a GitHub pull request by number, without pulling that change onto your machine first. It is how you get an automated first-pass review of someone else's work, or of a change already up for review.
  • /simplify does cleanup only. It looks for ways to make code shorter and clearer and applies the fixes, but it does not hunt for bugs. When you want the bug check, use /code-review.
One command reads your work like a careful colleague would, and tells you what to fix before anyone else sees it.