Coordinates multiple specialized reviewer agents over one change set to produce a single trustworthy review. Use when a review task is decomposed into parallel specialist scopes (security, performance, correctness, style), when multiple sub-agents independently gather evidence, or when findings from different reviewers must be deduplicated, calibrated, and synthesized before a final verdict. Trigger phrases: multi-agent review, parallel review, reviewer fan-out, review synthesis, reviewer coordination. Do NOT use for single-reviewer code review or for generic agent teamwork unrelated to change-set review.
Coordinates multiple specialized reviewer agents over one change set to produce a single trustworthy review. Use when a review task is decomposed into parallel specialist scopes (security, performance, correctness, style), when multiple sub-agents independently gather evidence, or when findings from different reviewers must be deduplicated, calibrated, and synthesized before a final verdict. Trigger phrases: multi-agent review, parallel review, reviewer fan-out, review synthesis, reviewer coordination. Do NOT use for single-reviewer code review or for generic agent teamwork unrelated to change-set review.
Decompose the change set into reviewer scopes. Analyze the diff to identify distinct concern areas (e.g., security surface, data-layer changes, API contract, test coverage, performance-sensitive paths). Assign each area to exactly one primary reviewer agent; minimize scope overlap to control redundancy.
Register and configure reviewer agents. Each reviewer must declare its specialty, the file/path patterns it will inspect, the severity scale it uses, and the evidence format it will produce. Use a reviewer registry or manifest so the orchestrator can validate completeness and detect scope gaps before fan-out.
Fan out for independent evidence gathering. Dispatch all reviewers in parallel. Each reviewer operates on its assigned scope with no access to other reviewers' in-progress findings. Every finding must include: file path, line range, severity, category, a one-sentence description, and verbatim evidence (code snippet or log excerpt).
Deduplicate and merge findings. After all reviewers report, group findings by file and line range. Identify duplicates (same location + same root cause) and near-duplicates (overlapping location, related root cause). Keep the strongest evidence and the most specific description; discard weaker duplicates with a merge note.
Resolve conflicts. When two reviewers disagree on severity or recommend contradictory fixes for the same location, escalate to a conflict-resolution step: present both positions with evidence, apply the project's severity rubric, and record the resolution rationale. Never silently drop a finding to hide a conflict.
Calibrate severity. Normalize severity labels across all reviewers to one shared scale before synthesis. Align on definitions (e.g., critical = data loss or security breach path reachable from changed code; high = correctness bug affecting production path; medium = maintainability or minor risk; low = style or nit).
Synthesize the final review. Produce a single ordered findings list sorted by severity, then by file path. Append a summary section with: total finding count by severity, scopes that passed cleanly, unresolved conflicts (if any), and an explicit verdict token (APPROVE, REQUEST_CHANGES, or ESCALATE).
Reference Guide
Topic
Reference
Load When
Review orchestration checklist
references/checklist.md
Any multi-agent review task, reviewer pipeline change, or review-synthesis logic review
Constraints
Each reviewer must operate independently during evidence gathering; sharing intermediate findings before merge introduces confirmation bias.
Every finding requires verbatim evidence (file path, line range, code snippet or log); reject findings that contain only a description with no supporting artifact.
Do not silently drop or downgrade a finding during deduplication; document every merge decision with a rationale.
Conflicts between reviewers must be surfaced and resolved, not hidden; unresolved conflicts must appear in the final report.
Do not let a single reviewer cover the entire change set; the minimum decomposition is two scopes. If the change is too small to split, this skill does not apply — use a single-reviewer code-review skill instead.
Enforce a bounded reviewer count per review (recommend 2–5); unbounded fan-out wastes context and increases merge complexity without proportional quality gain.
Severity labels must be calibrated to a shared scale before synthesis; mixed scales in the final report are a hard-fail.
