Pull request reviews with Claude Code, 10 steps for a PR workflow nobody blocks anymore

You open GitHub in the morning, three pull requests are waiting. One is yours, two from colleagues. The reviewer job costs you an hour each time, because you want to read the code, check the tests, walk through the CI log and at the end check out the branch locally. Exactly this loop is what Claude Code can shorten, if you use it right.

Important upfront. Claude Code does not replace the human reviewer. What it is good at is reading ahead, structuring findings and phrasing concrete comments. What it is bad at is architecture judgement and grasping business context. We use it as a first pass, not as the final authority.

I assume you have Claude Code installed locally and that you got through mini module L1-08 to L1-10 plus the git-für-ki-quickstart playbook. If branches and pull requests are still shaky for you, take a look there first.

Step 1, check out the right branch locally

First rule. Never review from the GitHub diff alone. You need the branch locally, because Claude Code works with the working tree, not with web diffs.

git fetch origin
git checkout -b review/pr-142 origin/feature/auth-flow

Give yourself a review branch with a clear prefix. That way you can later list all open reviews with git branch | grep review/ and nothing lies in the wrong branch.

If the PR targets a different base branch than what you have, pull the base first. Otherwise you read diffs against an old state.

Step 2, make the diff visible in the working tree

Claude Code only sees what is in the working tree. So Claude can read the PR diff, you give it the command the way it would read it itself.

In the Claude Code chat:

git diff origin/main...HEAD > .review-diff.txt

That writes the full diff into a file you can then reference. Careful, do not commit the file. Add .review-diff.txt to .gitignore or delete it after the review.

Alternatively you can ask Claude Code directly to generate the diff. It runs the git diff and reads the result itself. Works the same way, but on large diffs it is worse because the result stays in context.

Step 3, start with a structured prompt

The difference between a usable and an unusable AI review is the prompt. Generic "review this PR" gives you generic waffle. You need a list of concrete questions.

My standard prompt for a review pass:

You are reviewer for the diff in .review-diff.txt.
Check in this order:
1. Are there obvious bugs (off-by-one, null refs, wrong type casts)
2. Is user input processed without validation
3. Are the new tests meaningful (do they test what they should test)
4. Is there code duplication against existing code in the repo
5. Are conventions from CLAUDE.md violated

Output as a numbered list with file path, line number and a concrete suggestion.
No praise, only findings.

I have this prompt as a slash command in ~/.claude/commands/review-pr.md. Then /review-pr is enough and the loop runs.

Step 4, press findings into a list

What Claude Code gives back is mostly too long. Long prose, two sentences per finding, a wall of text. Compress it into a tight list.

Follow-up prompt:

Turn the findings into a Markdown table:
| File | Line | Severity | Finding | Suggestion |

Severity is high, medium, low.
High is bugs and security issues.
Medium is convention violations.
Low is style and taste.

You can paste this table straight into the GitHub PR comment. The colleague sees in one glance what is important and what is taste.

Step 5, check every finding yourself before you post it

This is the most important step. You post nothing unchecked.

Claude Code hallucinates in reviews regularly. It claims a function does not exist when it sits two files away. It complains about validation that already happens in the middleware layer. It sees "duplicated code" that is not duplicated at all.

I go through every table row manually. For severity high, always open the file and verify. For severity medium, reading the line in the diff usually suffices. For severity low I can sometimes trust, but never blindly.

What does not hold up flies out. Three good findings beat ten with two hallucinated ones in between.

Step 6, run the tests locally

Before you post the review comment, run the test suite of the repo once. Sometimes the diff looks clean, but the branch is broken anyway because a migration is missing or an env var is unset.

npm test
# or
pnpm test
# or whatever the repo uses

If tests fail, that belongs in your review comment. A PR that breaks tests locally is not a PR that should be merged.

Tip, when you have the repo locally for the first time and tests are red, ask first whether they were red before. You do not want to blame the colleague for broken tests that have been broken for two weeks.

Step 7, check performance hotspots visually

AI code has a quirk. It likes to build unnecessary loops, redundancies and O(n^2) patterns because they work at first glance. Check this on purpose.

In the diff in .review-diff.txt look for:
- nested for loops or map-in-map
- await inside a for loop (instead of Promise.all)
- N+1 queries against the DB
- sync file operations in async functions

If you find something, give me file and line and write a better suggestion.

That catches 80 percent of the performance issues the reviewer would otherwise miss. The remaining 20 percent need profile data and do not belong in the first pass.

Step 8, write the comment with a human voice

What you eventually post on GitHub must not sound like AI output. First it bothers colleagues, second it is more honest if you use your own voice.

I take the table from step 4, shorten it to the findings that survived step 5, and write an introductory paragraph myself. Something like:

Walked through the diff. Three findings I would block on, two for discussion. Tests pass locally. The migration in 003 I would look at again, there is an index that is never used.

This intro paragraph you write yourself. The rest of the table you can copy from the Claude output, but you own every entry.

Step 9, present contested findings as discussion, not as a block

Sometimes it is not clear whether a finding is really a block or taste. Here a good review makes the difference.

Instead of "this is wrong" write "I would do this differently, because...". Instead of "blocks merge" write "no block, but worth a refactor in my opinion". The colleague does not feel attacked and you keep the door open for a real discussion.

Claude Code phrases things directively often. That is too harsh in a review setting. When you adopt into your comment, soften the tone where it fits. Stay factually hard on bugs and security, softer on style and convention.

Step 10, clean up the review setup

Last step that often gets forgotten. You tidy up before you do the next PR.

git checkout main
git branch -D review/pr-142
rm .review-diff.txt

If you do not do this, after two weeks you have 30 review branches in your local repo, a few .review-diff.txt files lying around and Claude Code finds an old .review-diff.txt at the next session that confuses it.

I have a slash command in ~/.claude/commands/review-cleanup.md for the cleanup that deletes the branch and removes the diff file. Turns three commands into one.

What's next

When you have run this loop three, four times, you notice where Claude Code is good in your repo and where not. In some repos its architecture findings are usable, in others not. On tests it is mostly reliable, on migrations and infra code often not.

If you want to bring the loop into the team, look at the playbook Claude Code in a team, maintaining CLAUDE.md together. There it shows how to distribute the /review-pr slash command so everyone gets the same output.

Whoever wants to go a step further and run reviews automated in the pipeline, Claude Code Headless in CI/CD is the right next playbook. Beware, headless reviews have different traps than interactive ones, that is its own discipline.

Source

• Claude Code Slash Commands
• Git diff documentation