Agent Config Adapter

---
name: team-review
description: Multi-lens parallel review and bug triage using Agent Teams. Spawns specialized reviewers that challenge each other's findings. Use when user says "team review", "review PR with team", "triage bug", "investigate issue", "parallel review", or "audit module".
allowed-tools: Bash, Read, Write, Grep, Glob, Task, WebSearch, WebFetch, Bash(gh:*), Bash(git:*)
---

# Team Review — Multi-Lens Review & Bug Triage

Spawn a team of specialized reviewers or investigators that work in parallel,
challenge each other, and produce a synthesized findings report.

## Trigger Phrases

- "Team review PR #123"
- "Triage this bug with a team"
- "Parallel review of [module]"
- "Audit [area] with multiple lenses"
- "Investigate [issue] — competing hypotheses"

---

## MODE DETECTION

Determine mode from user input:

| User says | Mode |
|---|---|
| PR number, "review PR", "review changes" | **PR Review** |
| Bug description, "triage", "investigate", "why is X broken" | **Bug Triage** |
| "audit", "review module", "review codebase" | **Code Audit** (uses PR Review teammates against a directory) |

---

## MODE 1: PR REVIEW

### Phase 1: Gather Context

```bash
# Get PR details and diff
gh pr view <number> --json title,body,files,additions,deletions
gh pr diff <number>
```

Assess PR size. If fewer than 3 files changed or under 50 lines, **skip the
team** — use a single agent instead. Tell the user why.

### Phase 2: Create Team

Create an agent team with these teammates:

**Teammate: security-reviewer**
- Prompt: "You are reviewing PR #<number> for security issues. Focus on: authentication/authorization bypasses, injection vulnerabilities (SQL, XSS, command), secrets or credentials in code, insecure data handling, OWASP Top 10. Read the PR diff and affected files. Report findings with severity (Critical/High/Medium/Low) and specific line references. Challenge other reviewers if their suggestions introduce security risks."
- Tools: Read-only. No writes.

**Teammate: performance-reviewer**
- Prompt: "You are reviewing PR #<number> for performance impact. Focus on: N+1 queries, unnecessary re-renders, missing indexes, memory leaks, bundle size impact, caching opportunities, algorithmic complexity. Read the PR diff and affected files. Report findings with impact (High/Medium/Low) and specific suggestions. If the security reviewer flags something, verify the suggested fix won't create a performance regression."
- Tools: Read-only. No writes.

**Teammate: architecture-reviewer**
- Prompt: "You are reviewing PR #<number> for code quality and architecture. Focus on: naming and readability, separation of concerns, pattern consistency with the rest of the codebase, error handling, testability, unnecessary complexity or over-engineering. Read the PR diff and affected files. Report findings with priority (Must-fix/Should-fix/Nit). Challenge other reviewers if their suggestions violate existing codebase patterns."
- Tools: Read-only. No writes.

**Teammate: test-reviewer** (optional — spawn if PR touches logic, skip for config/docs PRs)
- Prompt: "You are reviewing PR #<number> for test coverage. Focus on: missing test cases for new code paths, edge cases not covered, assertion quality, test isolation, whether existing tests need updating. Read the PR diff, affected files, and existing test files. Report gaps with specific test cases that should be added."
- Tools: Read-only. No writes.

**Lead behavior:**
- Use delegate mode — do NOT review code yourself
- Wait for ALL teammates to finish
- If a teammate stalls for too long, nudge them
- After all report, synthesize findings

### Phase 3: Synthesis

Lead produces a unified review in this format:

```
## PR Review: #<number> — <title>

### Critical (must fix before merge)
- [Security] <finding> — <file>:<line>
- [Perf] <finding> — <file>:<line>

### Should Fix
- [Arch] <finding> — <file>:<line>
- [Test] <finding>

### Nits
- [Arch] <finding> — <file>:<line>

### Cross-Review Conflicts
- Security suggested X, but Performance noted it would cause Y
  → Recommended resolution: Z

### Verdict: APPROVE / REQUEST_CHANGES / NEEDS_DISCUSSION
```

### Phase 4: Cleanup

- Shut down all teammates
- Clean up the team
- Optionally post review as PR comment if user approves:
  ```bash
  gh pr review <number> --comment --body "<review>"
  ```

---

## MODE 2: BUG TRIAGE

### Phase 1: Gather Context

Collect from user:
- Bug description / error message
- Steps to reproduce (if available)
- Affected area of codebase

If user provides hypotheses, use those. Otherwise, generate 3-4 hypotheses by
reading the affected code area and error patterns.

### Phase 2: Create Team

Create an agent team. One teammate per hypothesis.

**Teammate template (repeat per hypothesis):**
- Name: `investigator-{n}` (e.g., investigator-1, investigator-2)
- Prompt: "You are investigating a bug: '<bug description>'. Your hypothesis is: '<hypothesis>'. Your job is to find evidence that SUPPORTS or DISPROVES this hypothesis. Read relevant code, trace the execution path, check logs/error handling, and look for related issues. You can run tests to reproduce but DO NOT modify any code. When other investigators share their findings, actively try to disprove their hypothesis if you have contradicting evidence. Report: evidence for, evidence against, confidence level (High/Medium/Low), and suggested fix if confirmed."
- Tools: Read-only + can run tests (Bash for test commands only). No writes.

**Lead behavior:**
- Use delegate mode
- After initial investigation round, tell teammates to challenge each other
- Wait for the challenge round to complete
- Synthesize into root cause report

### Phase 3: Synthesis

Lead produces:

```
## Bug Triage: <description>

### Hypotheses Tested
| # | Hypothesis | Confidence | Evidence |
|---|---|---|---|
| 1 | <hypothesis> | High/Med/Low | <summary> |
| 2 | <hypothesis> | High/Med/Low | <summary> |

### Root Cause
<Most likely cause with supporting evidence>

### Disputed Findings
- Investigator 1 claimed X, but Investigator 3 found Y that contradicts it

### Suggested Fix
<Concrete fix with file:line references>

### Confidence: HIGH / MEDIUM / LOW
```

### Phase 4: Cleanup

- Shut down all teammates
- Clean up the team

---

## SIZE GUARDRAILS

Don't waste tokens on small tasks:

| PR size | Team? |
|---|---|
| < 3 files, < 50 lines | No — single agent review |
| 3-10 files | 3 teammates (skip test-reviewer) |
| 10+ files or 500+ lines | Full 4 teammates |

| Bug complexity | Team? |
|---|---|
| Obvious cause from error message | No — single agent fix |
| Multiple possible causes | 3 investigators |
| Cross-system mystery | 4-5 investigators |

---

## ANTI-PATTERNS

**DO NOT:**
- Spawn a team for trivial PRs or obvious bugs
- Let the lead review code itself — delegate mode only
- Allow teammates to modify code — read-only always
- Skip the synthesis phase — raw findings are not useful
- Keep teammates running after synthesis is done

**DO:**
- Check PR size before spawning
- Generate hypotheses from code context, not guesses
- Encourage cross-review challenges between teammates
- Produce actionable, line-referenced findings
- Clean up the team after every run

No companion files

Add companion files to enhance this skill