review

name	review
description	Universal code review - auto-detects scope from git changes, spec, commit, or brief
argument-hint	[scope=frontend|backend|all] [feature=name] [spec=path] [mode=pushed|local] [commit=hash]
hooks	{"PostToolUse":[{"matcher":"Edit|Write","hooks":[{"type":"command","command":"if [[ -d \"backend\" ]]; then\n cd backend && go build ./... 2>&1 | head -10 && golangci-lint run ./... 2>&1 | head -20 || true\nfi\n","once":true}]}]}

YOU ARE EXECUTING THE /review SKILL. The user triggered this skill. Follow ALL instructions below step by step. Do NOT treat this as a freeform conversation - execute the skill workflow.

Think carefully for code review. Follow CLAUDE.md rules.

Critical Instruction

YOU MUST use the Task tool with subagent_type to launch agents. NEVER read or analyze code files directly yourself. Agents do the heavy lifting - you orchestrate and aggregate their results.

Tool Strategy

Use Task tool with these subagent_type values:

• explore-docs - Documentation lookup
• explore-codebase - Code pattern search
• explore-db - Database schema exploration
• backend-code-optimizer - Go code quality analysis (returns score + issues)
• frontend-code-reviewer - React/TS code quality analysis (returns score + issues)

---

1. DETERMINE SOURCE & SCOPE

Spec Handling

• Spec alone (/review spec:file.md): Extract file list FROM the spec (exclusive source)
• Spec + other source (/review spec:file.md mode:local): Spec provides CONTEXT, other source determines files

File Source Priority (use first available):

1. $ARGUMENTS.feature -> Search codebase for feature-related files
2. $ARGUMENTS.commit -> git show --name-only $ARGUMENTS.commit
3. $ARGUMENTS.mode -> Git diff (pushed or local)
4. $ARGUMENTS.spec alone -> Extract files from spec
5. Default: mode=local (uncommitted changes)

If mode = "pushed" (or default when no args and clean working tree)

git log origin/$(git rev-parse --abbrev-ref HEAD) -1 --format="%H %s"
git show --name-only --format="" HEAD
git show HEAD

If mode = "local" (default)

git diff origin/$(git rev-parse --abbrev-ref HEAD)...HEAD --name-only
git status --porcelain
git diff HEAD

If spec provided

• Read the spec file for context (requirements, architecture, expected behavior)
• Spec alone: Extract all referenced files from spec as review targets
• Spec + other source: Use spec as context only, files come from other source

If commit provided

git show --name-only $ARGUMENTS.commit
git show $ARGUMENTS.commit

If feature provided

This is a feature-based review, independent of git changes.

1. Use Task(subagent_type="explore-codebase") to find all files related to the feature
2. Apply scope filter if provided (backend -> backend/**/*.go, frontend -> frontend/src/**/*.{ts,tsx})
3. Collect the file list from agent response -> these become the review targets

Auto-Categorize Files

Pattern	Domain
backend/**/*.go	Backend
frontend/src/**/*.{ts,tsx}	Frontend
Other	Config/Docs

Apply forced scope if provided: $ARGUMENTS.scope

Report Scope

## Review Scope

**Source**: [feature/mode/spec/commit]
**Feature**: [feature name if provided, otherwise "N/A"]
**Spec Context**: [spec file path if provided, otherwise "None"]
**Commit**: [hash if applicable]
**Detected Scope**: [backend/frontend/both]

### Backend ([count] files)
- [file list]

### Frontend ([count] files)
- [file list]

### Other ([count] files)
- [file list]

---

2. REVIEW (PARALLEL)

MANDATORY: Use Task tool with subagent_type for each agent. Do NOT read files directly.

CRITICAL: Launch ALL applicable agents in a SINGLE message with MULTIPLE tool calls (parallel execution). Do NOT launch one agent, wait for it, then launch the next. Every matching condition below = one agent in the SAME message.

Scale agent count to the actual breadth of the diff and the review dimensions that apply. No upper limit, and do not gate on file counts. Assess the real scope and spawn accordingly:

• Per domain in scope: at least Correctness + Architecture (the floor). Add Performance, Duplication, Test-coverage, and any other applicable dimension as the change warrants.
• One focused agent per (dimension × file-cluster). On a large diff, partition the file set across several agents per dimension so no single agent reviews too many files. More files / more dimensions = more agents, with no cap.

Backend Review (when backend files present, ≥2 agents minimum, no maximum)

1. Correctness & Safety - Task(subagent_type="backend-code-optimizer", prompt="Read and review these Go files for correctness and safety: [file list]. Focus on: error handling, nil safety, context propagation, edge cases, bugs, business logic errors. Spec context: [spec summary if available]. Provide quality score and categorized issues.")
2. Architecture & Conventions - Task(subagent_type="backend-code-optimizer", prompt="Read these Go files: [file list]. Then search for similar existing patterns in backend/ to compare against. Focus on: Clean Architecture compliance, layer boundaries, dependency direction, naming conventions, DRY principle. Spec context: [spec summary if available]. Provide quality score and categorized issues.")
3. Performance (conditional: multi-file or I/O-heavy changes) - Task(subagent_type="backend-code-optimizer", prompt="Read and review these Go files for performance: [file list]. Focus on: concurrency patterns, query efficiency, N+1 queries, memory allocation, unnecessary copies, context cancellation. Provide categorized issues.")
4. Duplication scan (conditional: new code added) - Task(subagent_type="backend-code-optimizer", prompt="Read these new Go files: [new file list]. Then search backend/ for existing code that duplicates the same functionality. Check for reusable helpers, services, and patterns that already exist. Report any duplications found.")
5. Test coverage - Task(subagent_type="backend-code-optimizer", prompt="Check test coverage for these Go files: [file list]. For each file, check if a corresponding *_test.go exists. Verify tests cover happy path + error cases. Check if tests follow project patterns (testify, hand-written mocks, *Env struct). Report missing tests and inadequate coverage.")

Frontend Review (when frontend files present, ≥2 agents minimum, no maximum)

1. Component Quality & Hooks - Task(subagent_type="frontend-code-reviewer", prompt="Read and review these React/TypeScript files for correctness: [file list]. Focus on: React patterns, hook dependency arrays, state management, unnecessary re-renders, Shadcn UI usage, error handling. Spec context: [spec summary if available]. Provide quality score and categorized issues.")
2. TypeScript & Patterns - Task(subagent_type="frontend-code-reviewer", prompt="Read these React/TypeScript files: [file list]. Then search for similar existing components/hooks in frontend/src/ to compare against. Focus on: type safety, conventions, naming, DRY principle, consistent patterns. Spec context: [spec summary if available]. Provide quality score and categorized issues.")
3. UX & i18n (conditional: UI component changes) - Task(subagent_type="frontend-code-reviewer", prompt="Read and review these UI files: [file list]. Focus on: responsive design, loading/error states, accessibility, useTranslations (from next-intl) usage for all user-facing text, proper Shadcn component usage. Provide categorized issues.")
4. Duplication scan (conditional: new code added) - Task(subagent_type="frontend-code-reviewer", prompt="Read these new files: [new file list]. Then search frontend/src/ for existing components, hooks, or utilities that duplicate the same functionality. Report any duplications found.")

Supporting (as needed, launched in the SAME message)

Condition	Task tool call
Database changes	Task(subagent_type="explore-db", prompt="dev - Check tables related to [feature]. Verify schema, constraints, RLS")
External library	Task(subagent_type="explore-docs", prompt="[library] [specific API] best practices")

Skip Conditions

• If scope=frontend -> skip all backend agents entirely
• If scope=backend -> skip all frontend agents entirely
• If no frontend files changed -> skip frontend agents
• If no backend files changed -> skip backend agents
• If no files changed at all -> report "No files to review" and stop

Agent outputs to integrate:

• Quality scores -> merge into section 4
• Issues categorized as Critical/Important/Nice-to-have -> merge into section 5
• Optimization recommendations

---

3. AGGREGATE RESULTS

Aggregate and format the results from section 2 agents. Do NOT re-analyze files yourself.

Use the analysis format from checklists/backend-checklist.md and checklists/frontend-checklist.md.

## Code Review Analysis

### Files Reviewed (from agent reports)
- `path/to/file` - [purpose of changes]

---

4. QUALITY SCORES

Aggregate scores from specialized agents (section 2). Skip domains with no agent output.

Use scoring criteria from checklists.

Global Score

Weighted average based on file count per domain.

## Global Quality Score: X/100

Formula: (Backend Score x backend_files + Frontend Score x frontend_files) / total_files

[1-2 sentence overall assessment]

---

5. PROPOSE FIXES

## Recommended Fixes

### Critical (must fix)
1. **[Issue]**
   - File: `path:line`
   - Problem: [description]
   - Fix: [how to fix]

### Important (should fix)
1. ...

### Nice-to-have
1. ...

---

6. VALIDATE

Ask with AskUserQuestion: "Code review complete. What would you like to do?"

Options:

• "Apply all fixes"
• "Apply Critical only"
• "Apply Critical + Important"
• "No fixes needed"

---

7. IMPLEMENT (if requested)

This is the core purpose of the review command: identify issues AND fix them.

After user validation, implement fixes directly using Edit tool. Do NOT just report - actually modify the files.

Order:

1. Critical issues first
2. Important issues
3. Nice-to-have (if approved)

Implementation approach:

• Use Edit tool to apply each fix
• Include simplification recommendations from agents
• Apply one fix at a time, verify it doesn't break anything
• Track progress with TodoWrite

Rules:

• Do not break existing functionality
• Do not change business logic unless it's a bug
• Keep changes minimal but complete
• Apply ALL approved fixes, don't stop halfway
• If logic seems wrong, ASK before changing

---

8. VERIFY

Run verification based on scope:

# Backend (if backend files changed)
cd backend && go build ./... && go vet ./... && golangci-lint run ./... && go test ./...

# Frontend (if frontend files changed)
cd frontend && npm run test:run && npm run build

Backend and frontend tests are MANDATORY: All existing tests must pass (zero regressions).

Database (if schema changes): run get_advisors via explore-db (dev/prod).

---

9. SUMMARY

Use the summary format from templates/review-report.md.

---

Rules

• USE AGENTS - Task tool with subagent_type, never analyze directly
• REVIEW IN PARALLEL - launch multiple specialized review agents per scope in a single message
• MEASURE - provide quality scores per domain
• PRIORITIZE - Critical > Important > Nice-to-have
• SIMPLIFY - include simplification recommendations from agents
• FIX WHAT YOU FIND - after user approval, actually implement fixes with Edit tool
• MINIMAL CHANGES - fix issues, don't refactor unless asked
• CHECK i18n - verify useTranslations (from next-intl) for all frontend text
• VERIFY BUILDS - run build commands before completing