review

name	review
description	Run an orchestrated multi-agent code review over the current changes. Use when the user says "/review", "review my changes", "review this PR", "orchestra review", or asks for a structured code review before opening a PR. Spawns specialized reviewers (security, performance, code quality, docs) via the Orchestra MCP tools and emits one consolidated review with an approval verdict.

Orchestra: orchestrated code review

You are the review coordinator. Your job is to run the deterministic Orchestra MCP tools, then do the part only you can do — judge the findings — and emit one clean, consolidated review. Do not try to review the code yourself first; the specialists do that.

Backed by the orchestra MCP tools: get_diff, spawn_reviewers, emit_review, record_telemetry.

Procedure

1. Get the change set. Call get_diff (pass range if the user named one, e.g. main..HEAD; otherwise omit to review the working tree). It returns the tier, the roster to run, per-specialist models, the diffDir, the sharedContextPath, and the changed-file list.

   • If changedFiles is empty, tell the user there's nothing to review and stop.
   • Mention the tier and roster briefly (e.g. "Full review — 4 specialists").

2. Fan out. Call spawn_reviewers with the roster, diffDir, sharedContextPath, and models from step 1. It spawns the specialists concurrently as read-only claude -p subprocesses and returns their findings, a perReviewer breakdown (watch for status: "timeout" or "error"), and totals (tokens + cost).

   • If a specialist errored or timed out, note it — its domain wasn't covered.

3. Judge the findings. This is your real work. Over the returned findings:

   • Re-categorize anything filed under the wrong domain (a perf issue the code-quality reviewer raised belongs under performance).
   • Reasonableness filter: drop speculation, nitpicks, style preferences, and anything that contradicts the repo's own conventions. When you're unsure whether a finding is real, Read the actual source to confirm before keeping it. When still unsure, drop it. Bias toward signal.
   • You don't need to dedupe exact repeats by hand — emit_review collapses identical file+line+title findings — but do merge findings that are clearly the same issue described differently.

4. Emit the review. Call emit_review with your curated findings, plus tier, reviewers (the roster), range, and the totals from step 2. It applies the approval rubric, renders the markdown, and writes it to .orchestra/reviews/<timestamp>.md. Show the returned markdown to the user and state the decision.

5. Record telemetry. Call record_telemetry with tier, reviewers, the counts from emit_review's result (as findingsBySeverity), totals.tokens, totals.costUsd, and durationMs if you tracked it. This is fire-and-forget — don't block on it.

Approval rubric (applied by emit_review)

• Any critical → significant_concerns (blocks merge).
• 2+ warnings → minor_issues.
• Exactly 1 warning → approved_with_comments.
• Only suggestions / clean → approved.

The bias is toward approval — a single warning in an otherwise clean change still approves with comments rather than blocking.

Notes

• Sub-reviewers are read-only and recursion-isolated; they cannot spawn further reviews. You never need to manage that — it's enforced in spawn_reviewers.
• Keep your own commentary tight. The consolidated review markdown is the deliverable; don't restate every finding in prose around it.