/review
Multi-agent code review with specialized perspectives (security, performance, patterns, simplification, tests)
$ npx -y skills add rsmdt/the-startup --skill review --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/review
Context preview
The summary Claude sees to decide when to auto-load this skill.
Multi-agent code review with specialized perspectives (security, performance, patterns, simplification, tests)
SKILL.md
review.SKILL.mdname: 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)
Read more
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)
The Agentic Startup - A collection of Claude Code commands, skills, and agents.
Repo: rsmdt/the-startup
Other skills on the-startup.
- /analyze
Deep-dive codebase analysis that explains how things actually work — business rules, architecture patterns, auth flows, data models, integrations, and performance hotspots. Use whenever the user asks "how does X work", "map the Y flow", "what are the business rules for Z",
Open skill - /brainstorm
You MUST use this before any creative work — creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements, and design before implementation.
Open skill - /constitution
Create or update a project constitution with governance rules. Uses discovery-based approach to generate project-specific rules.
Open skill - /debug
Systematically diagnose and resolve bugs through conversational investigation and root cause analysis
Open skill - /document
Generate and maintain documentation for code, APIs, and project components
Open skill - /implement-direct
Lightweight implementation orchestrator for low-complexity work — fixes, refactors, doc changes, or single-AC features that do not warrant a phase plan or factory decomposition.
Open skill

