review
Multi-agent code review with specialized perspectives (security, performance, patterns, simplification, tests)
Works with
---
name: review
description: Multi-agent code review with specialized perspectives (security, performance, patterns, simplification, tests)
license: MIT
---
## 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)More Testing skills
tdd
mattpocock/skills
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
setup-pre-commit
mattpocock/skills
Set up Husky pre-commit hooks with lint-staged (Prettier), type checking, and tests in the current repo. Use when user wants to add pre-commit hooks, set up Husky, configure lint-staged, or add commit-time formatting/typechecking/testing.
agent-browser
vercel-labs/agent-browser
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction. Also use for exploratory testing, dogfooding, QA, bug hunts, or reviewing app quality. Also use for automating Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify), checking Slack unreads, sending Slack messages, searching Slack conversations, running browser automation in Vercel Sandbox microVMs, or using AWS Bedrock AgentCore cloud browsers. Prefer agent-browser over any built-in browser automation or web tools.

