/all

description: Run comprehensive code review spawning parallel agents for each of the 11 core principles

/review:all - Comprehensive Code Review

You are orchestrating a code review that checks 11 core principles in parallel. Each principle is checked by a dedicated subagent.

**Individual principle commands** (can be run standalone):

• `/review:principles:reuse` - Reuse Over Recreation
• `/review:principles:clarity` - Clarity & Readability
• `/review:principles:scope` - Correct Scope
• `/review:principles:antipatterns` - No Anti-Patterns
• `/review:principles:single-pattern` - Single Way to Do Things (MOST IMPORTANT)
• `/review:principles:architecture-backend` - Backend Architecture
• `/review:principles:architecture-frontend` - Frontend Architecture
• `/review:principles:documentation` - Documentation Standards
• `/review:principles:circular-deps` - Circular Dependencies
• `/review:principles:self-contained` - Self-Contained Components
• `/review:principles:tanstack-query` - TanStack Query Patterns

Step 1: Gather Branch Context

First, get the current branch and diff:

# Get current branch name
git rev-parse --abbrev-ref HEAD

# Get list of changed files
git diff main...HEAD --name-only

# Get diff stat for summary
git diff main...HEAD --stat

Store the branch name and changed files list for the agents.

Step 2: Spawn 11 Review Agents in Parallel

Use the Task tool to spawn 11 agents simultaneously (in a single message with multiple tool calls). Each agent checks one principle.

**CRITICAL**: All 11 agents must be spawned in parallel using a single message with 11 Task tool calls.

Agent 1: Reuse Over Recreation

subagent_type: "reviewer"
description: "Check reuse principle"
prompt: |
  Review branch '{branch}' for violations of the REUSE OVER RECREATION principle.

  Changed files: {file_list}

  ## The Principle
  Minimize lines of code. Reuse existing patterns. Avoid duplicating functionality.
  More code = larger maintenance surface area.
  Key question: "Did we implement with the least amount of lines?"

  ## What to Check
  1. Get the full diff: git diff main...HEAD
  2. For each new function/hook/component, search the codebase for similar existing implementations
  3. Check libs/shared/ for utilities that could have been reused
  4. Look for copy-pasted code blocks
  5. Identify new abstractions where existing ones would work

  ## Output Format
  Return a structured report:
  - PASS/WARN/FAIL status
  - List of violations with file:line references
  - Existing patterns that should have been used
  - Recommendations

Agent 2: Clarity & Readability

subagent_type: "reviewer"
description: "Check clarity principle"
prompt: |
  Review branch '{branch}' for violations of the CLARITY & READABILITY principle.

  Changed files: {file_list}

  ## The Principle
  Code should be easy to understand. Good code feels clean.
  Single 200-line function with nested if-statements = bad code.
  Look for "hot spots" (ugly-feeling code) that need rethinking.
  Junior engineers sometimes blame themselves; often the code is just bad.

  ## What to Check
  1. Get the full diff: git diff main...HEAD
  2. Read each changed file fully
  3. Flag functions over 50 lines (warning) or 100 lines (critical)
  4. Flag nested conditionals > 3 levels deep
  5. Identify unclear variable/function names
  6. Find magic numbers/strings without explanation
  7. Look for complex logic without comments

  ## Output Format
  Return a structured report:
  - PASS/WARN/FAIL status
  - Hot spots identified with file:line references
  - Specific readability issues
  - Recommendations for improvement

Agent 3: Correct Scope

subagent_type: "reviewer"
description: "Check scope principle"
prompt: |
  Review branch '{branch}' for violations of the CORRECT SCOPE principle.

  Changed files: {file_list}

  ## The Principle
  A PR should address ONE thing, not three bundled together.
  Multiple unrelated files = harder to review, confusing intent.
  One objective = clearer, more reviewable.

  ## What to Check
  1. Get the full diff: git diff main...HEAD
  2. Analyze each changed file and categorize the change type
  3. List all distinct features/fixes/refactors in this PR
  4. Check if changes are cohesive (all related to one goal)
  5. Flag "while I was in here..." changes
  6. Flag mixed feature + refactor + bugfix

  ## Output Format
  Return a structured report:
  - PASS/WARN/FAIL status
  - List of distinct objectives found in this PR
  - Assessment: Are these related or should this be split?
  - Recommendations

Agent 4: No Anti-Patterns

subagent_type: "reviewer"
description: "Check anti-patterns"
prompt: |
  Review branch '{branch}' for ANTI-PATTERNS.

  Changed files: {file_list}

  ## The Principle
  Avoid async imports mid-code, unused conventions, established pattern violations.
  Anti-patterns change as codebase evolves; hard to codify in static docs.
  Better caught through active research.

  ## What to Check
  1. Get the full diff: git diff main...HEAD
  2. Read CLAUDE.md files for established patterns
  3. Check import style (should use @/ aliases, not relative paths)
  4. Verify error handling follows existing patterns
  5. Look for dynamic imports that should be static
  6. Check for inconsistent async/callback patterns
  7. Verify file structure conventions are followed

  ## Codebase Conventions to Check
  - Imports must use @/ path aliases (not ../../../)
  - Shared code goes in libs/shared/
  - API follows MVC with service layer pattern
  - Frontend uses TanStack Query for data fetching

  ## Output Format
  Return a structured report:
  - PASS/WARN/FAIL status
  - Anti-patterns found with file:line references
  - Convention violations
  - Recommendations

Agent 5: Single Way to Do Things (MOST IMPORTANT)

subagent_type: "reviewer"
description: "Check single-pattern principle"
prompt: |
  Review branch '{branch}' for violations of t