Automate Code Review Claude Code: A Practical Workflow

A senior engineer on your team spends Tuesday morning on three pull requests. Two of them are routine: a missing test, an unhandled null, a variable named data2, an import left dangling. The third needs real thought about a caching tradeoff. By the time she reaches the third, she has burned ninety minutes leaving comments a linter and a careful reader could have caught. That first pass is exactly the work to hand off. When you automate code review Claude Code handles the mechanical scan so your reviewers spend their attention on design and judgment, where it actually pays off.

This is a tactical guide to a first-pass review that runs before a human opens the PR. It catches the obvious issues, flags missing tests and style drift, and writes its findings as comments. It does not approve, merge, or decide whether the change should exist. Those calls stay with people. Claude Code is the agentic coding tool from Anthropic, and the review setup below uses its built-in commands plus a CI hook.

Start with the interactive /review pass

Before you automate anything in CI, run the review by hand a few times. This tells you what Claude catches well on your codebase and where it produces noise. Inside an interactive session on a feature branch, the slash command does the work.

# From your feature branch, in an interactive Claude Code session:
/review

Claude reads the diff against your base branch and reports what it finds: probable bugs, missing test coverage, naming and style issues, and convention violations. The Claude Code overview documents the slash commands and how sessions read your working tree. Run this on five or six recent PRs and keep a short log of what it flagged correctly versus what was noise. That log becomes the basis for your conventions file.

The first runs almost always over-flag. Claude does not yet know your house style, so it questions patterns your team settled years ago. Do not fight this by ignoring the output — fix it at the source, which is the next step.

Teach it your conventions with CLAUDE.md

The difference between a review tool your team trusts and one they mute is whether it knows your codebase. Claude Code reads a CLAUDE.md file at the repo root automatically, and that file is where you record the rules a generic reviewer would not know. The memory documentation explains how these files load and nest per directory.

Keep the review section specific and short. Vague guidance produces vague reviews.

## Code review conventions

- We use snake_case for database columns, camelCase in app code. Do not flag the mismatch at the ORM boundary.
- Every new endpoint needs a test in `tests/api/`. Flag PRs that add a route without one.
- We do not use barrel files (`index.ts` re-exports). Flag new ones.
- Prefer early returns over nested conditionals. Suggest a refactor when nesting goes past two levels.
- Never approve. Report findings as comments only.

Each time Claude flags a false positive during your manual runs, add a line here that explains the rule. Within a week of edits, the noise drops sharply because the reviewer now shares your team’s assumptions. This is the same file that drives faster ramp-up in our guide to Claude Code engineer onboarding, so the investment compounds across more than review. It is one piece of the broader setup covered in our Claude Code for engineering teams hub.

Wire the first-pass review into CI

Once the manual pass is useful, move it to the pull request itself so every PR gets reviewed before a human opens it. Anthropic ships a GitHub Action for this, and the Claude Code GitHub repository is the canonical place to find the current action and setup steps. The shape of the workflow is simple: on a pull request, check out the code, run Claude with a review prompt, and post the findings as a comment.

name: claude-first-pass-review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Claude first-pass review
        uses: anthropics/claude-code-action@main
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            Review this pull request as a first pass.
            Follow the conventions in CLAUDE.md.
            Report bugs, missing tests, and style issues as
            comments. Do not approve or request changes.

The permissions block matters: pull-requests: write lets the action post comments, and you deliberately do not grant approval rights. The review shows up as a comment within a minute or two of the PR opening, so the human reviewer arrives to a diff that already has the obvious problems annotated. For the exact flags and non-interactive invocation patterns, the CLI reference covers running Claude headless inside automation.

This first-pass review pairs naturally with two other automations you can add to the same pipeline: generating the pull request description from the diff, and generating the tests the review keeps asking for. Together they turn a raw branch into a reviewable PR with very little human setup.

Be honest about what not to automate

The temptation, once the pipeline works, is to let it do more. Resist it. A first-pass review that posts comments is safe; an automated reviewer that approves and merges is a liability. Keep a named human as the required approver on every PR, and treat Claude’s output as one more reviewer’s comments rather than a gate.

Some changes deserve extra human scrutiny no matter how clean the automated pass looks. Auth and permission changes, data migrations, anything touching money or personal data, and changes to the review pipeline itself all need a person who owns the outcome. The automated pass can still comment on these — it just cannot be the only reviewer. The same caution applies to bug triage automation: the tool sorts and annotates, but a human decides what actually ships.

There is also a quality ceiling on large diffs. Review accuracy drops on sprawling pull requests for the same reason human review does — there is too much context to hold at once. The fix is process, not tooling: keep PRs small, and when a change is genuinely large, point Claude at one directory at a time rather than the entire diff. A tool that reviews three hundred lines well beats one that skims three thousand.

What to do this week

Pick one active repository and add the review conventions block to its CLAUDE.md, then run /review by hand on your next three pull requests and log what it catches versus what is noise. That log tells you whether the CI step is worth wiring up, and it does so in under an hour of real work. When you are ready to roll this out across a team and connect it to the rest of your pipeline, the Claude Code course walks through the full setup end to end.

Frequently Asked Questions

Does automating code review with Claude Code replace human reviewers?

No. It replaces the first pass — the part where a human scans for missing tests, obvious bugs, naming, and convention violations. Humans still own design tradeoffs, security judgment, and whether the change is the right thing to build at all. Treat the Claude pass as a filter that hands cleaner PRs to your team.

How do I run a code review with Claude Code?

Inside an interactive session, type /review on a branch or PR and Claude reads the diff and reports issues. You can also wire it into CI with a GitHub Action so every pull request gets a first-pass review automatically before a human opens it.

What should I never let Claude Code auto-approve?

Never auto-merge on a passing Claude review. Treat its output as comments, not approvals. Security-sensitive code, auth changes, data migrations, and anything touching money or PII should always get a named human reviewer regardless of what the automated pass says.

How do I stop Claude from flagging the same false positives every PR?

Encode your conventions in CLAUDE.md and a review prompt file. When Claude flags something that is actually your house style, add a line to CLAUDE.md explaining the rule. The next review respects it instead of re-flagging it.

Does this work on large pull requests?

It works, but quality drops on sprawling diffs the same way human review does. Keep PRs under a few hundred lines where you can. For large changes, point Claude at one file or directory at a time rather than the whole diff at once.