rbergman/review

Team Review

Team-based collaborative code review using Agent Teams.

Why teams > parallel subagents

Current /dm-work:review spawns 3 isolated subagents that report back independently. Findings may conflict, duplicate, or miss connections between concerns. With Agent Teams, reviewers can:

• Challenge each other ("I flagged this as security, but arch says the pattern is intentional")
• Cross-pollinate ("the perf issue I found is caused by the architecture pattern you identified")
• Converge on unified severity ratings instead of potentially conflicting ones

When to use

• Complex PRs touching multiple domains
• Security-sensitive changes where arch context matters
• When previous reviews produced conflicting findings
• For straightforward reviews use /dm-work:review (subagent-based) — reach for the team variant only when reviewers genuinely benefit from challenging each other

Team composition

| Role | Teammate | Model | Skills to inject | |------|----------|-------|-----------------| | Architecture | Teammate 1 | opus | dm-arch:solid-architecture, dm-arch:data-oriented-architecture | | Code Quality | Teammate 2 | opus | Language-specific dm-lang:*-pro skill | | Security | Teammate 3 | opus | (none — general security knowledge) | | Lead | You | opus | Synthesis and final assessment |

Code reviewer may split by domain (same as dm-work:review) for large reviews.

Scout phase

Still uses a haiku Explore subagent (not a teammate — too small for team overhead). Scout categorizes files, detects patterns, identifies hotspots, splits review domains.

Review protocol

Phase 1 — Scout (haiku subagent, same as dm-work:review)

• Categorize files, detect project type, identify hotspots
• Split into review domains with skill assignments

Phase 2 — Independent review (teammates work in parallel)

• Each reviewer examines their domain
• Produces initial findings with severity and confidence

Phase 3 — Cross-examination (teammates message each other)

• Reviewers share findings with the team
• Challenge findings they disagree with
• Identify connections between concerns
• Adjust severity based on cross-domain context
• 1-2 rounds of discussion

Phase 4 — Unified assessment (lead synthesizes)

• Merge findings, resolve conflicts
• Apply severity filter (--min-severity)
• Deduplicate by file+line
• Produce final assessment

Output format

Compatible with dm-work:review:

## Review: <scope> (<N> commits, <LOC> across <M> files)

### Verdict: <emoji> <summary>

**Critical** (<count>)
1. `file:line` - <description> [Consensus: arch+security agreed]

**High** (<count>)
...

**Architecture**: <verdict + summary>
**Code Quality**: <verdict + summary>
**Security**: <verdict + summary>

### Review Discussion Notes
[Key debates between reviewers and resolutions]

New addition: "Review Discussion Notes" section captures inter-reviewer debates and resolutions — this is the unique value of team review over subagent review.

Supports

• --pr N for PR mode (GitHub review comments)
• --commits <range> for explicit scope
• --only <acs> to filter reviewer types
• --min-severity <level> to filter output
• --skip-beads for local mode without bead creation

Related

• dm-work:review — subagent alternative for straightforward reviews
• dm-team:lead — team coordination protocol