| name | review-branch |
| description | Perform a thorough read-only multi-model code review with dedicated agents for standards, spec compliance, soundness, tests, performance, and architecture. Use when the user asks to review a branch, PR, commit range, worktree, diff, or code changes without requesting edits or fixes. |
Review Branch
Review broadly and report precisely. This skill is strictly read-only: never edit files,
apply fixes, create commits, or change branches in the user's checkout.
1. Resolve the Scope
Honor an explicit target and base exactly. Targets may be a branch, PR, commit/range,
worktree, diff, or file set. For a branch comparison, use a three-dot diff against the
merge-base. Respect stacked branches: their parent branch, not main, is the base.
If no target is supplied:
- A dirty worktree means staged, unstaged, and relevant untracked changes only.
- A clean worktree means the current branch against its merge-base with the inferred
upstream/default branch.
- Ask one short question when target or base is ambiguous.
For a target not checked out, use an isolated git worktree; never switch the user's
checkout. Pasted code not mapped to workspace files may be reviewed without citations to
workspace line numbers, but identify that limitation.
Capture the exact diff command/range, commit list, changed files, and applicable repository
instructions. Discover intent from user context first, then a readily identifiable linked
PR, issue, or spec. Continue without a spec and explicitly omit the Spec reviewer.
2. Size the Review
Review the complete target when coherent. Shard by package or subsystem at roughly 2,000
changed lines, 25 files, or earlier for clearly independent areas. Include relevant
cross-shard interfaces. Run at most ten subagents concurrently, using waves when needed.
3. Dispatch Dedicated Reviewers
Read REVIEWERS.md. Give every reviewer the exact scope, commits, intent,
standards sources, and common output contract. Launch in one parallel dispatch per wave:
reviewer-alt: documented standards and local conventions.reviewer-alt: spec compliance and scope, only when a spec exists.reviewer-alt-xhigh: soundness, contracts, errors, security, concurrency.reviewer-fast: tests, edge cases, performance, operational risks.reviewer-alt: architecture and thermo-nuclear maintainability.reviewer-primary: independent architecture and thermo-nuclear review.
Architecture reviewers must work independently and must not see each other's findings. If
the named agents are unavailable, stop and ask the user to restart your agent harness; do not
silently substitute models.
4. Adjudicate
The coordinator must independently open every cited current file and verify the finding,
line numbers, and quoted source. Reject or correct findings that cannot be confirmed.
Deduplicate overlap without hiding material disagreement. Do not use majority vote;
adjudicate from code, intent, standards, and tests. Report unresolved disputes explicitly.
Keep every noteworthy validated finding, including uncertain concerns, with a confidence
score. Suppress cosmetic noise. Preserve the review axes so intent, correctness, and
maintainability do not mask each other.
5. Report
Lead with findings ordered by severity. Group them under:
- Soundness and Security
- Spec
- Architecture and Maintainability
- Tests and Performance
- Standards
Each finding must retain exact path:line, quote, severity, confidence, impact, evidence,
and recommendation. Mark disagreements and distinguish provable bugs from plausible risks.
State No findings for clean axes and No spec available when applicable.
End with the reviewed scope and commands, finding counts by severity and axis, the worst
confirmed issue, and residual risks or testing gaps. Do not modify code even when a fix is
obvious; offer full-review-and-fix as a separate follow-up when useful.
