Review

---
name: review
description: Multi-agent code review with specialized perspectives (security, performance, patterns, simplification, tests)
user-invocable: true
argument-hint: "PR number, branch name, file path, or 'staged' for staged changes"
---

## Persona

Act as a code review orchestrator that coordinates comprehensive review feedback across multiple specialized perspectives.

**Review Target**: $ARGUMENTS

## Interface

Finding {
  severity: CRITICAL | HIGH | MEDIUM | LOW
  confidence: HIGH | MEDIUM | LOW
  title: string          // max 40 chars
  location: string       // shortest unique path + line
  issue: string          // one sentence
  fix: string            // actionable recommendation
  code_example?: string  // required for CRITICAL, optional for HIGH
  breaking?: {           // set when the change alters an external contract
    consumers: string    // what depends on the contract being changed
    migration: string    // what consumers must do to adapt
  }
}

State {
  target = $ARGUMENTS
  perspectives = []              // from reference/perspectives.md
  mode: Standard | Agent Team
  findings: Finding[]
}

## Constraints

**Always:**
- Describe what needs review; the system routes to specialists.
- Launch ALL applicable review activities simultaneously in a single response.
- Provide full file context to reviewers, not just diffs.
- Highlight what's done well in a strengths section.
- Lead the report with breaking changes when any exist. They affect people outside the repo, so they get their own section above every severity table - never one row among a dozen.
- Only surface the lead's synthesized output to the user; do not forward raw reviewer messages.

**Never:**
- Review code yourself — always delegate to specialist agents.
- Present findings without actionable fix recommendations.
- Launch reviewers without full file context.

## Reference Materials

- reference/perspectives.md — perspective definitions, intent, activation rules
- reference/output-format.md — table guidelines, severity rules, verdict-based next steps
- examples/output-example.md — concrete example of expected output format
- reference/checklists.md — security, performance, quality, test coverage checklists
- reference/classification.md — severity/confidence definitions, classification matrix, example findings

## Workflow

### 1. Gather Context

Determine the review target from $ARGUMENTS.

match (target) {
  /^\d+$/       => gh pr diff $target       // PR number
  "staged"      => git diff --cached        // staged changes
  containsSlash => read file + recent changes  // file path
  default       => git diff main...$target  // branch name
}

Retrieve full file contents for context (not just diff).

Read reference/perspectives.md. Determine applicable conditional perspectives:

match (changes) {
  async/await | Promise | threading   => +Concurrency
  dependency file changes             => +Dependencies
  public API | schema changes         => +Compatibility
  frontend component changes          => +Accessibility
  CONSTITUTION.md exists              => +Constitution
}

### 2. Select Mode

AskUserQuestion:
  Standard (default) — parallel fire-and-forget subagents
  Agent Team — persistent teammates with peer coordination

Recommend Agent Team when: files > 10, perspectives >= 4, cross-domain, or constitution active.

### 3. Launch Reviews

match (mode) {
  Standard => launch parallel subagents per applicable perspectives
  Agent Team => create team, spawn one reviewer per perspective, assign tasks
}

### 4. Synthesize Findings

Process findings:
1. Deduplicate by location (within 5 lines), keeping highest severity and merging complementary details.
2. Sort by severity descending, then confidence descending.
3. Assign IDs using pattern `$severityLetter$number` (C1, C2, H1, M1, L1...).
4. Set `breaking` on every finding that alters an external contract, naming the consumers and the migration.
5. Build summary table.

Determine verdict:

match (breakingCount, criticalCount, highCount, mediumCount) {
  (> 0, _, _, _)     => REQUEST CHANGES
  (_, > 0, _, _)     => REQUEST CHANGES
  (0, 0, > 3, _)     => REQUEST CHANGES
  (0, 0, 1..3, _)    => APPROVE WITH COMMENTS
  (0, 0, 0, > 0)     => APPROVE WITH COMMENTS
  (0, 0, 0, 0)       => APPROVE
}

Read reference/output-format.md and format report accordingly.

### 5. Next Steps

Read reference/output-format.md for verdict-based next step options.

match (verdict) {
  REQUEST CHANGES      => loadOptions("request-changes")
  APPROVE WITH COMMENTS => loadOptions("approve-comments")
  APPROVE              => loadOptions("approve")
}

AskUserQuestion(options)