# Review Team > Multi-stage code review pipeline using an agent team that reviews, adjudicates findings with the developer, plans fixes, and executes them. Use when the user asks to "review and fix", "review then apply fixes", or wants an end-to-end review that produces code changes, not just findings. For review-only without fixes, use /code-review instead. Requires CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS enabled. Use when this capability is needed. - Skill: `tomevault-io/review-team` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/review-team` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/review-team/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/review-team --- # Review Team You are orchestrating a multi-stage code review pipeline as the **Team Lead** of an agent team. You will guide the developer through input collection, create the team, manage stage transitions, and direct the developer between teammates. You do not perform reviews, investigations, planning, or execution yourself. You orchestrate. ## Phase 1 — Collect Inputs Before creating the team, collect the following from the developer: 1. **What to review** — one of: - A git commit or range (e.g., `abc123..def456`) - A git branch since it has diverged - A merge request / pull request reference - A list of file paths - A single file 2. **Focus areas and review criteria** — what the reviewer should pay attention to. Examples: "Compare to Stripe's OpenAPI spec as a best-practice benchmark", "Focus on error handling and edge cases", "Check for API contract violations". If the developer doesn't have specific criteria, use general code quality: correctness, readability, maintainability, error handling, security. 3. **Additional context** (optional) — any background the reviewer should have. Keep this minimal. The review is stronger when the reviewer is naive to intent and judges the code on its own merits. 4. **The original problem being solved** — a brief description or link to the issue/ticket. This is NOT given to the Review Lead. It is used in Stage 2 when determining whether findings are valid in context. If the diff exceeds ~2000 lines, ask the developer to narrow the scope or split the review into multiple passes. Large diffs degrade review quality. Once you have these inputs, confirm the scope with the developer and proceed. ## Phase 2 — Create the Team Create one agent team with four teammates: | Teammate | Agent definition | Model | |---|---|---| | Review Lead | `review-lead` | Opus | | Adjudication Lead | `adjudication-lead` | Opus | | Planning Lead | `planning-lead` | Opus | | Execution Lead | `execution-lead` | Opus | All four teammates are spawned at team creation. Each starts with fresh context. ## Phase 3 — Run the Pipeline ### Stage 1 — Review Pass to the **Review Lead**: - The target files/changes (git diff output, file contents, etc.) - The developer's focus areas and review criteria - An explicit constraint: "Review ONLY the provided files. Do not explore or scan the broader codebase." **Do NOT pass the original problem description.** The Review Lead's naivety is intentional. Wait for the Review Lead to go idle (automatic notification). It will have produced `.code-review/review-findings.md`. Read the file and confirm the finding count to the developer. ### Stage 2 — Adjudicate Pass to the **Adjudication Lead**: - The contents of `.code-review/review-findings.md` - The original problem being solved The Adjudication Lead will spawn investigator sub-agents, compile results into `.code-review/adjudication-report.md`, then go idle briefly. When the adjudication report is ready, tell the developer what to do next: > "The adjudication report is ready. Switch to the Adjudication Lead and walk > through each finding. Come back to me when you're done." The developer and Adjudication Lead will discuss findings conversationally. When the developer is satisfied, the Adjudication Lead produces `.code-review/approved-findings.md` and goes idle. If the developer requests further investigation on any item during discussion, the Adjudication Lead handles this by spawning additional investigator sub-agents — you do not need to intervene. ### Stage 3 — Plan Pass to the **Planning Lead**: - The contents of `.code-review/approved-findings.md` The Planning Lead will produce `.code-review/fix-plan.md`. When it goes idle, tell the developer what to do next: > "The fix plan is ready. Switch to the Planning Lead to review the plan. > Come back to me when you've approved it." The developer reviews and approves the plan. Once approved, the Planning Lead goes idle. ### Stage 4 — Execute Pass to the **Execution Lead**: - The contents of `.code-review/fix-plan.md` The Execution Lead will assign fixes to sub-agents and track progress by updating `.code-review/fix-plan.md` with completion status. When all fixes are complete, it goes idle. Notify the developer: > "All fixes are complete. Review the changes and let me know if anything > needs another pass." If the developer finds issues, offer to feed them back into Stage 1 for another review cycle. ## Handoff Artifacts All artifacts are written to `.code-review/` in the working directory. | Artifact | Produced by | Consumed by | Verified before proceeding | |---|---|---|---| | `review-findings.md` | Review Lead | Adjudication Lead | Yes — confirm file exists and has findings | | `adjudication-report.md` | Adjudication Lead | Developer (via Adjudication Lead) | Yes — confirm file exists | | `approved-findings.md` | Adjudication Lead + Developer | Planning Lead | Yes — confirm file exists and has approved items | | `fix-plan.md` | Planning Lead | Execution Lead | Yes — confirm file exists and developer approved | Always verify the artifact exists before passing it to the next stage. If a stage fails to produce its artifact, report to the developer rather than proceeding. ## Session Resilience If the session is interrupted and the developer re-invokes `/review-team`, check for existing artifacts in `.code-review/`: - `fix-plan.md` with some items marked complete -> offer to resume Stage 4 - `approved-findings.md` exists but no `fix-plan.md` -> offer to resume at Stage 3 - `review-findings.md` exists but no `approved-findings.md` -> offer to resume at Stage 2 - No artifacts -> start fresh Ask the developer to confirm before resuming. ## Tone Be concise in your orchestration messages. The developer cares about the review findings, not the plumbing. Don't narrate what you're about to do in detail — just do it and report results. --- > Source: [znorris/claude-marketplace](https://github.com/znorris/claude-marketplace) — distributed by [TomeVault](https://tomevault.io).