Run /code-review before you push: levels, --fix and two gotchas

The cheapest code review you’ll get today is the one you run before opening the pull request. Claude Code’s /code-review command reviews your branch in the terminal, and the managed PR review service isn’t required: Anthropic’s docs say it’s the route for plans without Team or Enterprise.

By default it covers your branch’s commits ahead of its upstream plus any uncommitted changes. If there’s nothing on the branch or in the working tree, there’s nothing to report. To aim it elsewhere, pass a target: a file path, a PR number, a branch name, or a range such as main...my-feature.

/code-review high main...my-feature

Pick the effort level on purpose

The level changes what you get back, not just how long it takes. At low and medium the review reports only the findings it’s most confident in, so you see fewer false positives. From high through max it broadens coverage and may include findings the review is less sure about.

My suggestion: medium for the routine pre-push pass, high on changes touching auth, money or migrations. Treat the extra findings at high as leads to check, not verdicts.

On models without tuned review settings, including Opus 5.5 and Sonnet 5.5, medium also reports cleanup and CLAUDE.md convention findings, according to the 2.1.288 changelog. Expect some of your medium results to be style notes rather than bugs.

Gotcha one: the level sticks

If you type /code-review with no level, it reuses the last level you typed, even from an earlier session. Claude Code prints a notice such as “Reusing high effort, the level you typed last time”. Run /code-review medium once to reset it. A level passed in a non-interactive -p run doesn’t update the remembered one.

The same stickiness applies to --max-findings <n> (v2.1.288 or later), which raises or lowers the usual finding limit. all reports everything. The value is reused until you pass --max-findings default, so a one-off all on a big refactor will quietly follow you into small reviews.

Gotcha two: –fix isn’t on the rewind stack

--fix applies the findings to your working tree after the review. Handy, but the review runs as a background subagent with its own context window, and the docs say its edits land outside your session’s checkpoints. /rewind won’t undo them. Use git.

So commit or stash first, then fix:

git add -A && git commit -m "wip: before review fixes"

/code-review medium --fix

Then git diff HEAD~1 shows exactly what the review changed, and git reset --hard HEAD throws it away. Read that diff the way you’d read any other contributor’s patch. A finding applied mechanically can fix the flagged line and miss the caller.

It reads CLAUDE.md, not REVIEW.md

The local review follows your CLAUDE.md like any session. It does not read REVIEW.md, the review-only file the managed PR service uses for severity rules, nit caps and skip lists. If you’ve tuned REVIEW.md to keep the PR bot quiet, those rules don’t apply to your local run. Anything you want in both places belongs in CLAUDE.md.

Don’t let it run when you didn’t ask

Claude can start /code-review on its own when you ask it in plain language to review your changes, and a scheduled task can run it. If you’d rather it only ran when you type it, add this to ~/.claude/settings.json:

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

While the review runs you can keep working. The findings arrive in your conversation when it finishes, and you can ask Claude to fix what it found, or have --comment post them on the PR as inline comments.