How I use Claude Code to review pull requests — a complete workflow

Code review is one of those tasks that sounds simple but actually requires holding a lot of context simultaneously. You need to understand the business requirement, the architectural implications, the edge cases, and the style conventions — all while reading someone else's code.

I've been using Claude Code to help with PR reviews for a few months now, and it's changed how I approach the whole process. Here's the exact workflow I use.

The problem with manual PR review

When I review a pull request manually, I usually:

1. Open the diff in GitHub
2. Try to remember the relevant architecture from memory
3. Miss things because I'm reviewing in isolation, without running the code
4. Leave comments that are vague because I'm not 100% sure myself

This leads to reviews that take 45 minutes and still miss real bugs.

The Claude Code approach

With Claude Code, I pull the branch locally and run a structured review session.

Step 1: Fetch and checkout the PR branch

git fetch origin
git checkout origin/feature/user-auth-refactor

Step 2: Generate a diff summary

git diff main...HEAD > /tmp/pr-diff.txt

Then in Claude Code:

> Read /tmp/pr-diff.txt and give me a high-level summary of what this PR is doing. Then list any obvious bugs, security issues, or performance concerns you see.

Step 3: Deep-dive on specific files

After getting the summary, I focus on the files that matter most:

> Read src/auth/middleware.js and src/auth/tokens.js. The PR changes the token validation logic. Are there any edge cases in the new implementation that could cause authentication bypass?

Step 4: Check test coverage

> Look at the test files added in this PR. Are there any scenarios that aren't tested? Specifically check for: expired tokens, malformed input, concurrent requests, and error paths.

Step 5: Generate review comments

This is where it gets really useful:

> Based on your analysis, write me specific GitHub review comments I can paste. Format them as: FILE:LINE - COMMENT. Be constructive and specific.

Claude generates comments like:

src/auth/tokens.js:47 - The token expiry check uses `>` instead of `>=`. 
This means tokens expire exactly 1 millisecond after the stated expiry time 
rather than at the boundary. This could cause race conditions in high-traffic 
scenarios where a token is validated milliseconds before expiry.

src/auth/middleware.js:83 - Missing error handling for the case where 
jwt.verify() throws a JsonWebTokenError. Currently this would cause an 
unhandled exception rather than returning a 401.

These are real, specific, useful comments — not "looks good" or vague suggestions.

The CLAUDE.md trick for consistent reviews

I've added a review checklist to my CLAUDE.md file:

## PR Review Checklist
When reviewing a PR, always check:
- SQL injection risks in any new queries
- Missing input validation on new endpoints
- Error handling completeness (every async call has .catch or try/catch)
- Rate limiting on new public endpoints
- N+1 queries in any new database code
- Secrets or tokens accidentally committed
- Tests cover happy path AND error paths

Now every review session automatically uses this checklist without me having to prompt for it.

Reviewing architecture decisions

For bigger PRs, I ask Claude to think about the architectural implications:

> This PR adds a new caching layer in Redis. Given the existing architecture 
(read src/db/connection.js and src/cache/ for context), is this the right 
approach? What are the tradeoffs compared to using the existing in-memory 
cache?

This surfaces concerns that a line-by-line review would completely miss.

The rate limit problem

Here's what I've noticed: complex PR reviews are token-hungry. A big PR might have:

• 500 lines of diff to read
• 10 related files to understand
• Test files to evaluate
• 2-3 rounds of back-and-forth questions

I hit Claude's rate limits regularly on big PRs. When that happens in the middle of a review, I lose context and have to start over.

I switched to using SimplyLouie as my Claude Code endpoint — it's $2/month and gives me a dedicated proxy without the usage caps that Claude's own rate limiting imposes. I point Claude Code at it with:

export ANTHROPIC_BASE_URL=https://simplylouie.com/api/proxy

No more mid-review interruptions.

The complete review workflow in practice

Here's what a full review looks like, start to finish:

# 1. Get the PR branch
git fetch origin && git checkout origin/feature/payment-refactor

# 2. Generate diff
git diff main...HEAD > /tmp/review.txt

# 3. Start Claude Code session
claude

# In the session:
> Read /tmp/review.txt. Summarize the change and flag any concerns.
> Now read src/payments/ directory. Check the new Stripe integration for 
  edge cases: failed charges, webhook replay attacks, idempotency.
> Generate specific GitHub review comments for everything you found.
> Are there any tests I should ask the author to add before merging?

Total time: 15-20 minutes. Comments are more specific than what I'd write manually. I catch more real bugs.

Results

In the last month using this workflow:

• Average review time: 18 minutes (down from 45)
• Real bugs caught in review (before merge): up significantly
• Review comments quality: much more specific, with line numbers and code suggestions
• Author satisfaction: people actually like the reviews because they're actionable

The key insight

Claude Code doesn't replace your judgment as a reviewer — it handles the mechanical parts (remembering context, checking patterns, listing edge cases) so you can focus on the judgment parts (is this the right design? does this match the product requirement?).

The best reviews combine Claude's pattern-matching with your domain knowledge about the system.

---

If you want to try this without rate limit interruptions, SimplyLouie is $2/month — start with the 7-day free trial, no charge until day 8.