How to review Claude Code pull requests

The method is the same one you use on any agent pull request: shape, edges, one traced path, evidence. Two things are specific to Claude Code. Check whether CI ran at all, because Anthropic's documentation says GitHub does not trigger workflows on commits made with the default GITHUB_TOKEN, so a workflow that passes that token through produces a pull request with no checks on it. And ask the session that wrote the change to draw it, because it is still there and it already understands the diff.

I have reviewed a lot of these. This is what is worth knowing about the ones that come from Claude Code specifically, checked against Anthropic's own documentation on 7 September 2026, because these products move fast enough that a claim without a date is worthless.

Where a Claude Code pull request comes from

There is more than one path, and they leave different traces:

• Someone ran Claude Code locally and pushed a branch. The pull request is a normal one and the person who ran the session is on the hook for it.
• Someone wrote @claude in an issue or a pull request comment, and the anthropics/claude-code-action workflow picked it up. Anthropic calls this interactive mode: Claude replies in a comment on the same thread and updates it as it works.
• A workflow supplies a prompt input, so the action runs without a mention. That is automation mode, and by default its results land in the workflow run log instead of a comment.
• Claude Code on the web opened it, including its auto-fix path for pull requests.

Worth knowing before you comment: the action runs two checks on whoever triggered it. On issue and pull request events the triggering user needs write access to the repository, and bot actors are rejected unless the workflow lists them in allowed_bots, which is how they stop agents from triggering each other in a loop.

Read the workflow files before you read the code

This is item two on the checklist for agent-authored code and it is doubly worth it here, because the agent has permission to touch them. The Claude GitHub App installs with Actions and Workflows at read and write alongside Contents, Issues and Pull requests, so a change to .github/ is inside what it can do.

The specific thing to check is the one from the top of this post. Anthropic's troubleshooting section is explicit: GitHub does not trigger workflows on commits made with the default GITHUB_TOKEN, so if a workflow passes github_token: ${{ secrets.GITHUB_TOKEN }} to the action, Claude's pushes produce no CI runs. A pull request with no checks looks a lot like a pull request with passing checks if you are scanning quickly. Look for the checks, not for the absence of red.

What Claude Code Review does, and where it stops

Claude Code Review is the managed service, separate from the action. As of September 2026 it is in research preview for Team and Enterprise plans. A fleet of agents analyses the diff and surrounding code in parallel, a verification step checks candidates against actual behaviour, and the survivors are posted as inline comments on the lines where they were found, tagged Important, Nit or Pre-existing. Anthropic puts the average review at 20 minutes and $15 to $25 in token cost, scaling with the size of the pull request.

It is good at what it does. Findings arrive with the reasoning attached, the check run always completes with a neutral conclusion so it never blocks a merge through branch protection, and you can tune severity, nit volume and skip rules in a REVIEW.md at the repository root.

What it does not do is tell you what the change is. Every finding is anchored to a line, which means the questions that have no line stay unanswered: does this component need to exist, does it duplicate the client we already have two directories away, did the pull request touch three lanes when its title named one. A reviewer still owns those, and they are the ones that cost the most to get wrong. If you want that comparison drawn out properly, AI pull request summaries versus diagrams is the same argument about the other kind of tool.

Ask the session to draw the change

The session that wrote the code is the cheapest place to get a picture of it. It has the diff, the reasoning that produced it, and the surrounding files already in context, which is exactly the material a diagram needs and exactly what a reviewer lacks.

That is what the PR Lens agent skill does. Install it once:

npx skills add coldteadotai/pr-lens

Then, in the session that just made the change, say it literally:

Diagram the change you just made with PR Lens and attach it to the pull request.

The agent reads the diff, writes the graph document itself, runs npx @coldtea/pr-lens-cli validate until the document satisfies the contract, renders it, and attaches the result to the pull request with gh pr create --attach, so the diagram lands with the change instead of behind it. Claude Code is already the model here, so there is no provider key in the loop. If a diagram names something wrongly, the skill teaches the agent to fix .github/pr-lens.yml with a rename or an exclusion rather than editing generated SVG.

The hosted GitHub App covers the case where you are not in the session at all: install it on the repositories you review, and every pull request opened in them, including the ones the action opens, gets drawn and redrawn on each push as one comment that updates in place. Green is new, amber is changed, red and struck through is gone.

CLAUDE.md is a review lever

Anthropic's guidance is that Claude follows the guidelines in CLAUDE.md when it creates pull requests, and Code Review reads the same file as project context and flags newly introduced violations as nit-level findings. The same file therefore shapes both what gets written and what gets flagged.

That makes it the right place for the rules you keep repeating in review comments. Two that pay for themselves on agent output: name the existing helper or client the agent should reuse for a common job, and say which directories are off limits without an explicit request. Both target the failure GitHub calls code reuse blindness, and neither is something a line-level reviewer catches reliably.

Then run the ordinary clock

None of the above replaces the pass. Once you know where the pull request came from and you have the shape in front of you, the same ten minutes applies: two on the shape against the title, two on CI, configuration and deletions, four tracing one path from entry point to storage, two on evidence. That clock is in how to review a 400-line pull request in ten minutes, and it is worth budgeting because agent pull requests are large: LinearB's 2026 benchmarks put AI-assisted pull requests at 408 changed lines at the 75th percentile, against 157 for unassisted ones.

One Claude-specific note on evidence. Because the action replies in the thread, you can ask the pull request a question and get an answer, which you cannot do with most agent output. Use it. "Show me the test that covers the retry path" is a better comment than a paragraph of speculation, and if the answer is a new commit, the checks question from earlier applies to that commit too.

For the same playbook against a different agent, Cursor background agent pull requests arrive from a cloud VM with artifacts attached, which changes the evidence step. The general method is in the complete guide to reviewing AI-generated pull requests.