📝 Written ● Beginner Updated 2026-05-13

Review pull requests with /review

Run /review on a pull request and the agent does the first pass for you. It reads the diff, the linked ticket, the existing tests, the surrounding code — and writes a review that points at things humans tend to miss when their attention is on style.

Code review is one of those tasks where the cost of doing it badly is invisible and the cost of doing it well is real time. A perfunctory "LGTM" passes through code that has bugs in it. A thorough review takes thirty minutes per PR, often longer, and you have a queue of them. The equilibrium that most teams settle into is somewhere uncomfortable: reviews that catch the obvious things but miss the subtle ones, paid for with reviewer time that could have gone to other work.

The agent is well-suited to closing some of that gap. It can read the full diff plus the relevant context (existing tests, surrounding functions, the linked ticket) faster than a human can scroll. It doesn't get tired on PR five of the morning. It's particularly good at the things busy reviewers skip: checking whether tests were added for new logic, noticing inconsistencies between this change and adjacent files, flagging error handling that's structurally different from neighboring patterns.

What the agent isn't good at is judgment — whether this change is the right approach, whether it fits the team's strategic direction, whether the trade-offs are acceptable. Those are still your call. The agent's review is a first pass that surfaces what's worth your attention; your review is the one that decides.

What you'll learn

Running /review on a local diff and on a remote PR
What the agent looks at (and what it can't)
How to read the review output and prioritize
Following up with targeted prompts on specific findings
When NOT to use it

Step 1: Review a local diff

The simplest case — your own changes before pushing

In your local checkout, with the branch you want to review checked out, type in the chat panel:

/review

The agent runs git diff against the merge base, plus git log to see what was committed. It writes a review covering: what the change does, whether the change matches its stated intent (from commit messages), bugs / race conditions / security issues, missing tests, style inconsistencies with surrounding code.

Step 2: Review a remote PR

Pass the PR URL or number

For a PR on GitHub:

/review https://github.com/myorg/myrepo/pull/1234
# or, when in the repo:
/review #1234

The agent uses gh (if installed) or fetches via the GitHub API. It reads the PR description, the linked issue if any, the diff, and recent comments. If you have a GitHub MCP server connected, the agent uses that instead — same result, structured tool calls.

For best results in unfamiliar codebases: have a CLAUDE.md in the repo. The agent's review benefits enormously from project-specific conventions (e.g., "we use Result types, not exceptions"). Without context, it falls back to generic best practices.

Step 3: Read the output strategically

Three tiers; only the top two need your attention

A typical review groups findings into rough tiers:

Tier 1: Probable bugs. "On line 47, user can be null here but isn't checked." Read these carefully. Most are real; a few are paranoia.
Tier 2: Missing pieces. "This function is non-trivial and has no tests." "Error path returns early without releasing the lock." These are the highest-value findings — things humans tend to miss when reading line-by-line.
Tier 3: Style. "Naming convention differs from the rest of the file." Useful but low priority; address only if the inconsistency would actually confuse a reader.

If you have time, address all three. If you don't, address Tiers 1 and 2 and ship.

Step 4: Follow up on specific findings

Conversation, not monologue

The first review is the agent's overview. To dig into a specific finding, just ask:

"Show me where the null check should go and propose the fix."
"Write a test that would catch the bug you flagged in UserService."
"Why do you think the error path doesn't release the lock — show me the code."

The agent now has the review context loaded; follow-up turns are cheap. This is where you turn "the agent found 7 things" into "the agent helped me fix 5 things and we discussed the other 2."

Step 5: Post the review back to GitHub

For PRs that aren't yours

If you're reviewing a teammate's PR and want to share the agent's findings, ask: "Post these as PR comments on GitHub." With the GitHub MCP or gh installed, the agent creates inline comments on the relevant lines, summarizes the high-level findings in a review body, and leaves the review in "comment" state (not approved, not requesting changes) for you to inspect.

You should always look before clicking "Submit review" — your name will be on it.

Step 6: When NOT to use it

The agent's blind spots

Architecture decisions. The agent can't tell you whether this PR moves the system in the right direction. It can describe what changes; it can't judge whether the change is wise. You decide.
Performance at scale. "This query looks fine" isn't a load test. The agent reads code, not production traces. For perf-sensitive changes, run benchmarks.
Security-critical code. Use /security-review specifically for that — a different skill that focuses on threat surfaces. /review is the general-purpose review.
Trivial changes. A one-line typo fix doesn't need an AI review. The overhead is bigger than the benefit.

Don't sign off without reading the code yourself. The agent's review is a tool for your attention, not a substitute for it. A clean review doesn't mean the PR is correct — it means the agent didn't find anything in the surface it looked at.