Claude Code reads a diff the way a reviewer does, and unlike a reviewer it can apply the fixes straight after. There’s a built-in command for it, so you don’t have to invent the prompt.
1. Run the built-in review
/code-review
What it does: reviews the current changes. /review is an alias for the same command, so
either works. Start here before writing your own prompt — it already knows to look at the diff.
2. Or point it at a specific PR
Use gh to check out PR #142, then review it for bugs, missing error handling,
and test coverage. This PR adds rate limiting to the login route.
What it does: has Claude fetch the branch with the gh CLI and review it against the PR’s
actual intent. That last sentence matters more than it looks — without the goal, it judges the
code against a guess.
3. Ask for correctness, not style
Vague review prompts get vague results. Name what you care about and what to ignore:
Review this diff for: (1) correctness bugs, (2) missing edge cases, (3) anything touching
auth or payments that deserves extra scrutiny. Skip formatting and naming comments.
What it does: aims the review at the failures a linter can’t catch, and suppresses the low-value nitpicks that bury them.
For a large PR, ask for a file-by-file pass, or hand the reading to a subagent so forty files of diff fill the subagent’s context window rather than your session’s.
4. Apply only what you accept
Apply the fixes for issues 1 and 3 only. Keep the changes minimal and don't touch anything else.
What it does: turns findings into a patch, scoped to what you agreed with. Numbering the ones you want is what keeps it from “improving” the rest of the file.
Verify it worked
Read the diff Claude produces, then run the tests. Treat it as a colleague’s suggested patch, not an auto-merge — it won’t push or merge on its own, and you stay the one who lands the change. If the review found nothing on a PR you know is risky, your prompt was too broad.
To run the same review automatically on every PR, see Claude Code with GitHub Actions. For the habits that keep multi-file changes reviewable in the first place, see working on a whole codebase safely.
Source: Claude Code slash commands reference.