review

Review — find what's wrong with this change, then fix it

gather scope → build the pack → find candidates → verify in batches → sweep → cross-repo → fix → report

Your job is not to produce a report the user reads and acts on. It is to leave the tree better than you found it and hand back a short, honest account of what you changed, what you refused to change, and what only the user can decide.

This skill runs inline, and that is the whole design

Do not run this skill in a fork, a background agent, or anything else that returns before the review is done. It is a gate: the caller must not be able to commit, push or answer the user while it is still running. A detached run has already produced the worst failure this gate has had — the caller ended its turn on the dispatch, the user asked why nothing happened, the next turn started a second full fan-out over the same worktree, and the change was committed and pushed eight minutes before either review returned. Two competing reviews, twenty-eight million tokens, and the gate's own fixes landed as loose uncommitted work on top of the push.

So: you orchestrate in this context. Only the leaf agents are separate, and they are separate for a reason that has nothing to do with hiding latency — see below.

Blindness belongs at the leaves, not at the root. The finders and verifiers see the diff and nothing else: not the task, not the chat, not the author's reasoning. That is what makes their judgement worth having. You are not blind, and that is deliberate too — you know what the change was for, which is the only way to tell a deliberate behavior change from a bug, and the one call the finders provably cannot make. What you must never do is defend the code. When a candidate lands, read the line as if a stranger wrote it.

Invocation

/feature:review [--pass first|later|final] [--scope working|branch] [--repos a,b]
                [--root DIR] [--pr URL] [--level max|high|medium]
                [--no-fix] [--comment|--no-comment]