Claude for Code Review: A Practical Workflow

Most advice about using Claude for code review is out of date: it tells you to paste a diff into a chat window. That still works, but there are now three distinct ways to do this, and they differ in cost, depth and who can use them. Picking the wrong one is why people conclude AI review is either magic or useless.

Three Ways, and Who Each Is For

Start with the middle one if you write code daily. It needs no GitHub App, costs nothing beyond your existing plan, and catches the class of mistake you most want caught — the one still sitting in your working tree.

Reviewing Before You Push

In a Claude Code session, /code-review reviews the commits on your branch ahead of its upstream plus anything uncommitted. You can also point it somewhere specific — a file path, a branch name, a PR number, or a range like main...my-feature.

Two flags matter in practice. --fix applies the findings to your working tree after the review, and --comment posts them as inline PR comments. The review runs in the background with its own context, so it does not crowd out the conversation you were having.

You can also tune how hard it looks. Lower effort reports only high-confidence findings, which means fewer false positives; higher effort widens coverage and will include things it is less sure about. For a quick pre-push check, low is usually the right trade.

Reviewing Pull Requests Automatically

The managed GitHub integration is a different animal: several agents examine the diff against your full codebase in parallel, each hunting a different class of issue, then a verification step checks candidates against actual code behaviour before anything is posted. Findings land as inline comments on the exact lines.

Three things to know before you propose it to your team. It is a research preview limited to Team and Enterprise plans. It never blocks a merge — the check run always completes neutrally, so your existing review process stays intact. And it is billed separately from your plan through usage credits, averaging $15–25 per review, which scales with PR size.

The trigger you choose drives the bill. Reviewing on every push catches issues as a PR evolves and multiplies the cost by the number of pushes; manual mode costs nothing until someone comments @claude review on a PR.

A Change Worth Knowing About

Before a July 2026 update, commenting @claude review also subscribed the PR to reviews on every later push. It no longer does. If a workflow you copied from an older article depends on that behaviour, use @claude review always instead — the bare command now runs a single review and nothing more.

For any of these commands to work, post them as a top-level PR comment rather than a reply on a diff line, and put the command at the start of the comment.

Teaching It Your Standards

Out of the box the review targets correctness — bugs that would break production — rather than formatting or missing tests. Two files change that, and the difference between them is worth getting right.

Put general project context in CLAUDE.md and review-specific rules in REVIEW.md. The highest-value things to put in the latter are a cap on nits («report at most five, mention the rest as a count»), skip rules for generated files and anything CI already enforces, and a redefinition of what Important means for your repo — the default calibration assumes production code and will be wrong for a docs or prototype repository.

Keep it short. A long instruction file dilutes the rules that matter most, the same way a long custom-instruction block does.

What to Ask For in a Chat Review

If you are pasting a diff rather than using the tooling, the request matters more than the diff. «Review this» produces a list of generic observations; a narrow question produces something you can act on.

• «What breaks if this input is null or empty?» — targets the edge cases tests usually miss.
• «Which of these changes could affect behaviour outside the files shown?» — surfaces the risk a diff hides by definition.
• «Security only: anything here that leaks data or trusts input it shouldn't?» — one lens at a time beats a general sweep.
• «What did the author probably intend, and where does the code not do that?» — catches logic errors rather than style.
• «What context would you need to review this properly?» — surprisingly effective; the answer tells you what to paste next.

Give it the surrounding function or file, not just the changed lines. A diff strips exactly the context a reviewer needs, which is why human reviewers open the file too.

Where It Genuinely Falls Short

• It cannot know your product. A change can be technically correct and still wrong for the business, and no reviewer without that context will catch it.
• It does not replace tests. A review reasons about code; only running it proves anything.
• Reviews are best-effort — a failed or timed-out run does not retry on its own.
• The GitHub service is unavailable to organisations with zero data retention enabled.
• In a chat, it sees only what you paste. It will happily reason about a function it has not been shown.
• It flags confidently. Treat 🔴 findings as things to check, not verdicts.

A Workflow That Actually Fits

1. Write the change.
2. Run /code-review locally before pushing, at low effort for speed.
3. Fix what it found, or pass --fix and read the diff it produced.
4. Push. If your team has the GitHub integration, let the automatic review run.
5. Send it to a human, whose job is now the part machines cannot do: is this the right change at all?

Where to Go Next

If you review the same codebase repeatedly in chat, a project keeps the context loaded so you stop re-pasting conventions every time — see how to use Claude Projects. For the underlying concepts, the Claude glossary and the Claude knowledge base cover the terminology, and the Claude tool page has plans and limitations.

Bottom Line

Claude is good at the reviewing nobody enjoys: edge cases, inconsistencies, the thing you stopped seeing after the fourth read. It is not good at knowing whether the change should exist.

Use /code-review before you push, because it is free with your plan and catches problems while they are still cheap. Add the GitHub integration if a team is drowning in PRs and the $15–25 per review is cheaper than the bugs. And keep a human on the question of whether the code solves the right problem — that part has not moved.