/review

Review code changes in parallel across multiple aspects

What it does

/review reviews code changes and reports what it finds. Unlike asking "review my changes" in a normal turn, it fans the work out across several reviewers running in parallel, each looking at a different aspect.

/review
/review pr 412
/review branch main tests types
/review commit HEAD~3

Target — what to review. Say which kind it is, and it takes the next word as its name:

Form	Reviews
(nothing)	all uncommitted changes
`pr <number>` or `pr <url>`	that pull request
`branch <name>`	HEAD against that branch
`commit <hash>`	that commit

Nothing is worked out from the shape of what you typed, which is the point: a number is not assumed to be a pull request, and a word is not assumed to be a branch. Two useful consequences — a branch called 1234 or tests is reachable like any other, and commit <branch> reviews that branch's own tip rather than comparing against it.

Name one target, not two: /review branch main pr 412 is refused rather than resolved to whichever came first.

Aspects — what to look for: code, errors, tests, types, comments, simplify, all. They go anywhere in the line, before or after the target: /review pr 412 tests types.

Naming no aspects lets it decide which apply from what actually changed — usually the right choice, since a docs-only diff doesn't need a types pass.

Any other bare word is refused rather than ignored, so /review 412 tells you to write /review pr 412 instead of quietly reviewing your uncommitted work under that number.

What it reviews, and what happens when it can't

The target is resolved before any reviewer starts, and the resolved scope is named in the running task and again at the top of the report. If it can't be resolved — a pull request that doesn't exist, a branch name with a typo, credentials that can't reach the remote, a clean working tree — /review says so and reviews nothing. It never quietly reviews something else.

Pull requests resolve over plain git, from the refs/pull/N/* refs GitHub publishes, so gh is not needed and its token's repository access is not involved. What is involved is git's own credentials for the remote, and the pull request's head is fetched into refs/remotes/<remote>/pr/N/* — a private cache, not a branch. GitHub remotes only; other hosts don't publish those refs, and a remote reached over a non-standard port or through ssh.github.com isn't recognised as GitHub — it says so rather than resolving it wrongly.

Why it runs in parallel

/review is routed to the dedicated review agent, and that matters: only that agent's ruleset grants the task tool, which is what lets the review spawn subagents. Without it the review would run as one long serial pass.

The practical consequence: a broad review of a large diff finishes in roughly the time of its slowest aspect, not the sum of all of them.

Note

Because it fans out, /review uses more model calls than a single turn. That's the trade for coverage and speed — worth knowing if you're watching budget.

When to use it over just asking

Ask normally	Use `/review`
"what does this function do"	"review my changes before I push"
"is this the right approach"	"audit the codebase for problems"
one file, one question	a diff, a branch, or a PR

If you're hunting for unknown defects across a codebase — "find all the bugs in here" — that's a review, not a bug fix. Use /review. Use /bug-fix when you already know which defect you're chasing.

Where it improves the result

Use case	Effect	Why
Reviewer	Much better	What it exists for. Parallel aspects means a single pass doesn't have to hold correctness, types, tests and style in mind at once — which is exactly where a serial review gets shallow.
Migration	Much better	The best check on a large mechanical change. A migration compiles and still changes behaviour; a multi-aspect review over the diff is how that gets caught.
Feature Development	Better	Run it on the branch before merge, when the diff is complete but nothing is committed to yet.
Testcase creation	Better	Point it at test files with the `tests` aspect to find missing cases and assertions that never fail.
Bug-Fixer	Some	Useful for finding unknown defects across a codebase. Once you can name one, /bug-fix drives it to a verified fix.
Design / Architecture / Planning	Some	It reviews code, not proposals — but it will tell you whether the code matches the design you intended.

Rough rule: /review is for a diff you already have. If there's nothing to look at yet, it's the wrong tool.