How I use Claude Code to review pull requests — a complete workflow
Code review is one of the most important parts of software development, but it's also one of the most time-consuming. When a large PR lands in my queue — 50+ files changed, thousands of lines of diff — I used to spend 30-45 minutes just orienting myself before I could give meaningful feedback.
Now I use Claude Code for PR review. Here's the exact workflow.
Why Claude Code for PR review?
The core problem with reviewing large PRs is context switching. You need to understand:
- What the PR is trying to do
- What the existing code does
- Whether the changes are correct
- Whether there are edge cases missed
- Whether the tests cover the important paths
Claude Code can hold all of that context simultaneously. It reads files, runs tests, and asks the right questions.
Step 1: Get oriented in 5 minutes
Before reading a single line of diff, I run:
# Check out the PR branch locally
git fetch origin
git checkout pr/feature-branch
# Then in Claude Code:
claude
Then I ask:
I'm reviewing a PR. The branch is feature/payment-refactor.
Please:
1. Run `git log main..HEAD --oneline` to see the commits
2. Run `git diff main --stat` to see what files changed
3. Read the PR description from .github/PULL_REQUEST_TEMPLATE.md if it exists
4. Give me a 3-sentence summary of what this PR does
Claude Code runs those commands and gives me a mental model of the PR before I touch any code.
Step 2: Review the most important files first
Not all files in a PR are equal. A change to src/utils/format.ts is low-risk. A change to src/payments/charge.ts is high-risk.
Look at the git diff. Which files have the highest-risk changes?
Rank them by: (1) business criticality, (2) complexity of changes, (3) test coverage.
Start with the riskiest file.
Claude Code reads the diff, looks at the file structure, and surfaces the dangerous stuff first. This alone saves me 20 minutes per review.
Step 3: Verify the logic is correct
For each risky file, I ask Claude Code to trace the logic:
Look at the changes in src/payments/charge.ts.
The old code did X, the new code does Y.
Are there any edge cases where the new behavior could cause:
- Double charges?
- Failed charges that appear to succeed?
- Race conditions with concurrent requests?
Show me the test cases that cover these paths.
This is where Claude Code earns its keep. It reads the implementation, finds the tests, runs them, and tells me what's covered and what isn't.
Step 4: Run the tests and check coverage
Run the test suite for the files changed in this PR.
Which tests pass? Which fail?
What code paths aren't covered by tests?
Claude Code executes this and comes back with actual results — not a guess. If something fails, I know immediately.
Step 5: Check for common issues
I have a checklist I give Claude Code for every PR:
Review this PR for:
1. SQL injection vulnerabilities (raw string concatenation in queries)
2. Missing input validation on new API endpoints
3. Hardcoded secrets or credentials
4. Missing error handling (unhandled promise rejections, bare except blocks)
5. N+1 query patterns in loops
6. Missing indexes for new WHERE clauses
Show me any issues found with file and line number.
This is the kind of review that catches real bugs. Not style issues — actual security and performance problems.
Step 6: Generate the review comments
Based on your analysis, write a PR review with:
- Overall assessment (approve/request changes/comment)
- 3-5 specific inline comments with file:line references
- Any blocking issues that must be fixed
- Any suggestions that are optional
Be direct and constructive.
Claude Code drafts the review. I read it, adjust the tone if needed, and post it.
The rate limit problem
Here's what nobody talks about: PR review is one of the most token-intensive things you can do with Claude Code.
A large PR means:
- Reading 30+ files to understand context
- Multiple rounds of "show me the tests", "run the tests", "look at the implementation"
- Comparing old and new code side-by-side
- Sometimes refactoring suggestions that require reading even more code
I hit the Claude Code 5-hour rate limit doing a single large PR review. It's not the Claude Code subscription that limits you — it's the per-session token budget.
If you're doing serious code review work, you need a way to keep going when the session limit hits.
The fix: a persistent API endpoint
I use SimplyLouie as my fallback API endpoint. It's ✌️2/month and gives me a stable ANTHROPIC_BASE_URL I can point Claude Code at:
export ANTHROPIC_BASE_URL=https://simplylouie.com/api
export ANTHROPIC_API_KEY=your-key-here
claude
When my Claude Code session runs dry mid-review, I switch to this endpoint and keep going. No 5-hour wait. The review gets done.
For context: ₦3,200/month in Nigeria. Rs165/month in India. Rp32,000/month in Indonesia. It's priced at 10% of ChatGPT specifically for developers in markets where $20/month is a significant expense.
My PR review CLAUDE.md template
I keep this in my project's CLAUDE.md to set context for every review session:
# PR Review Context
This repo is a Node.js/TypeScript API. Key files:
- src/payments/ — Stripe integration, highest risk
- src/auth/ — JWT handling, always review carefully
- src/db/ — Prisma ORM, watch for N+1 patterns
- src/api/ — Express routes, check validation
Test runner: `npm test`
Coverage: `npm run test:coverage`
Review priorities:
1. Correctness over style
2. Security over performance
3. Tests must cover happy path + error paths
Real results
Before: 45 minutes average for a large PR review, often missing edge cases.
After: 20 minutes, with more thorough coverage. Claude Code catches the N+1 queries and missing error handling that I'd miss when tired.
The workflow scales. Whether it's a 5-file PR or a 150-file PR, the approach is the same: orient first, risk-rank the files, trace the logic, verify with tests, write the review.
Claude Code is available at claude.ai/code. If you hit rate limits during large review sessions, SimplyLouie is ��️2/month and works as a drop-in API endpoint.
Top comments (0)