Claude Code for PR Reviews: Automated Code Review on GitHub and Locally

Automated code review is one of the highest-ROI uses of an AI agent. A good review on every pull request catches bugs earlier, distributes knowledge across the team, and lets senior engineers spend their review time on architecture rather than typos. Claude Code, combined with GitHub Actions, makes this practical to set up in under an hour.

This guide covers two complementary workflows: an automated GitHub Action that reviews every PR, and a local workflow for reviewing your own changes before you push.

Part 1: Claude Code as a GitHub PR Reviewer

Anthropic maintains an official GitHub Action — `anthropics/claude-code-action` — that runs Claude Code inside your CI pipeline. It can review PRs automatically on open, respond to `@claude` mentions in comments, or run on a schedule.

Step 1: Add the API key to GitHub secrets

In your repository, go to Settings → Secrets and variables → Actions, and add a new secret called `ANTHROPIC_API_KEY` with your Anthropic API key. For production use we recommend a dedicated team key with usage limits set in the Anthropic console.

Step 2: Create a review workflow file

Add `.github/workflows/claude-review.yml`: ``` name: Claude Code Review

on: pull_request: types: [opened, synchronize, reopened] issue_comment: types: [created]

jobs: review: if: github.event_name == 'pull_request' || contains(github.event.comment.body, '@claude') runs-on: ubuntu-latest permissions: contents: read pull-requests: write issues: write steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - uses: anthropics/claude-code-action@v1 with: anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} mode: review model: claude-sonnet-4 review_prompt: | Review this PR for: correctness, security issues, error handling, performance red flags, and adherence to our CLAUDE.md conventions. Be concrete: quote the line, explain the issue, suggest a fix. Skip stylistic nits. ```

Step 3: Tune the review prompt

The `review_prompt` is the single biggest lever for review quality. Keep it focused on what humans miss: - Bugs that tests do not cover - Security issues (injection, auth bypass, secrets in code) - Error and edge-case handling - Concurrency and race conditions - Accidental API or contract changes

Explicitly tell it what to skip (formatting, lint rules your linter already catches, bikeshed preferences). Otherwise reviews become noise and the team tunes them out.

Step 4: Add a CLAUDE.md at the repo root

The action reads your CLAUDE.md automatically. This is where you encode the project-specific rules you want enforced on every PR — database migration rules, environment variable handling, test coverage expectations, deprecated APIs to avoid.

Step 5: Choose your model tier

For PRs, Claude Sonnet 4 is the right default — it is fast enough to post a review within a minute and catches the vast majority of real issues. Escalate to Opus 4 only on critical repositories (auth, billing, infrastructure) where the cost of a missed bug is high.

Interactive Review via `@claude` Mentions

Once the workflow is live, any team member can mention `@claude` in a PR comment to ask a follow-up question: "Is this safe for production?", "What breaks if we remove this check?", "Rewrite this function using async/await." The agent responds in the same thread.

Part 2: Reviewing Your Own Code Locally Before You Push

Getting the review *before* CI runs is faster and cheaper than fixing issues after. Claude Code has a built-in `/review` command for this.

The local review loop

From inside your project: ``` claude > /review ```

This runs a review on your current diff (staged + unstaged, or the diff against your base branch). Claude walks the changes, surfaces issues, and suggests specific fixes you can accept or reject.

Reviewing a specific range

For a larger review — the whole branch, for example — you can pipe the diff directly: ``` git diff origin/main...HEAD | claude -p "Review this diff for bugs, security issues, and missing tests. Be specific and cite line numbers." ```

The `-p` flag runs Claude Code non-interactively with a single prompt, making it easy to compose with shell pipelines.

Pre-commit and pre-push hooks

To make this automatic, wire Claude Code into git hooks. A minimal `.git/hooks/pre-push`: ``` #!/usr/bin/env bash set -e DIFF=$(git diff origin/main...HEAD) echo "$DIFF" | claude -p "Review for bugs, security issues, and missing tests. Output CRITICAL/HIGH/MEDIUM/LOW issues only. If no issues, output OK." ```

For team-wide adoption, use a hook manager like `husky` or `lefthook` so the hooks travel with the repository.

A Sensible Default Architecture

The setup we recommend to clients: 1. Local pre-push hook runs a fast Sonnet review, blocks push only on critical issues. 2. GitHub Action runs a full Sonnet review on every PR, posts comments with line anchors. 3. `@claude` mentions give reviewers an on-demand expert in the PR thread. 4. Nightly Opus review on the main branch catches anything that slipped through.

This layered approach catches issues at the cheapest possible moment and keeps human reviewers focused on what matters.

What Not to Automate Away

AI review is additive, not replacement. Reserve human review for: - Architectural decisions and API contracts - Anything touching authentication, billing, or data retention - Changes that affect customers visibly - Engineering judgment calls on trade-offs

Claude Code is an excellent first reviewer. It should never be the only reviewer on anything that matters.

At FindCoder, we set up this workflow for every client engagement in the first week. The consistent outcome: faster PR cycles, fewer bugs reaching staging, and — most importantly — a team that trusts its tooling.