How to Review a Teammate's Pull Request with Claude Code

Check out a PR locally and have Claude Code summarize the change and flag risks so your review is faster and deeper.

8 minIntermediate

Visit Claude Code

Reviewing someone else's pull request well takes time you often do not have. Claude Code can give you a fast orientation: what the change does, where the risk is, and which files deserve your close attention. Used as a first pass it makes your human review sharper, not lazier.

What you need

Claude Code in the repo
The GitHub CLI (gh) authenticated, or the PR branch checked out
The PR number you want to review

Step 1: Check out the PR branch locally

Pull the PR so Claude can read the full change in context, not just an isolated diff. The gh CLI makes this one command.

zsh - my-app

$gh pr checkout 482

Switched to branch 'feat/rate-limit'

$git diff main...HEAD --stat

src/middleware/rateLimit.ts | 96 +++++++++

Step 2: Ask for a summary and a risk map

Ask Claude to summarize the change against the base branch and rank the files by review risk. This tells you where to spend your attention before you read a single line.

Claude Code

You

This branch is PR #482. Compare it to main, summarize what it does, and rank the changed files by review risk with a one-line reason each.

Agent

Adds IP-based rate limiting middleware. Highest risk: rateLimit.ts (in-memory store will not work across instances). Medium: config.ts (new env var, no default). Low: tests and types.

Summary plus a ranked risk map orients the review.

Step 3: Drill into the risky files

Open the highest-risk file and ask pointed questions. Here the in-memory store is a real concurrency concern worth raising in the review. Confirm Claude's claim by reading the code yourself before you comment.

rateLimit.ts

Explorer

rateLimit.ts

config.ts

rateLimit.test.ts

src/middleware/rateLimit.ts

1// in-memory map: counts reset per process,

2// so each server instance tracks separately

3const hits = new Map<string, number>();

Step 4: Draft review comments you stand behind

Have Claude draft comments for the issues you confirmed, then edit them into your own voice. You own every comment you post, so verify each claim before it goes on the PR.

rateLimit.ts: the in-memory Map means limits are
per-instance. Behind a load balancer a client could
get N times the limit. Consider a shared store
(Redis) or document the single-instance assumption.

Verify before you comment

Claude's risk map is a lead, not a verdict. Read the code behind each flagged concern. Posting an incorrect review comment costs your credibility with the author.

Result: a review that opens with a clear summary, focuses on the one genuine scaling risk, and skips the boilerplate, all in a fraction of the usual reading time.