Code Review

# Code Review Slash Command

You are the orchestrator for an automated code review and fix loop. Your job is
to:

1. Spawn a reviewer subagent to analyze code changes
2. Show findings to the user and get approval
3. Spawn a fixer subagent to fix CRITICAL + HIGH priority issues
4. Run tests after each fix iteration
5. Repeat until no critical/high issues remain or max loops reached

## Parameters

Parse the command arguments with strict positional rules to avoid ambiguity:

- Format: `/code-review [max_loops] [target] [auto]`
- **All parameters are optional and positional**
- **Parsing rules:**
  1. First argument (if numeric): `max_loops` (default: 3)
  2. Second argument (or first if non-numeric): `target` (default: uncommitted)
     - Valid values: `uncommitted`, `staged`, `recent`, `branch`
  3. Third argument (or any remaining argument): `auto` flag (any value enables
     auto mode)

- `max_loops` (optional, default: 3) - Maximum review-fix iterations
  - Must be a positive integer
- `target` (optional, default: uncommitted) - What to review:
  - `uncommitted` - All unstaged + staged changes (git diff HEAD)
  - `staged` - Only staged changes (git diff --staged)
  - `recent` - Last commit (git diff HEAD~1)
  - `branch` - All changes since origin/main branch
- `auto` (optional) - If present (any value like "auto", "y", "yes"),
  automatically fix all CRITICAL and HIGH issues without asking for confirmation
  at each iteration. Test failures in auto mode will abort the loop.

**Examples:**

- `/code-review` → max_loops=3, target=uncommitted, auto=false
- `/code-review 2` → max_loops=2, target=uncommitted, auto=false
- `/code-review branch` → max_loops=3, target=branch, auto=false
- `/code-review 2 staged` → max_loops=2, target=staged, auto=false
- `/code-review auto` → max_loops=3, target=uncommitted, auto=true
- `/code-review 2 branch auto` → max_loops=2, target=branch, auto=true

## Instructions

### Step 1: Determine Scope

**If auto mode is enabled:**

1. Show warning: "Running in AUTO mode. This will automatically fix all CRITICAL
   and HIGH priority issues without asking. Continue? (yes/no)"
2. If user responds "no", EXIT immediately
3. Only proceed if user confirms with "yes"

**For all modes:**

Based on the target parameter, identify:

1. What git diff command to use
2. Run the appropriate git diff command
3. **If diff is empty (no changes found):**
   - Inform user: "No changes found to review for [target]"
   - EXIT successfully
4. Which files are changed
5. For Go files, identify corresponding test files (even if unchanged)
6. For Python files in pundora/, identify corresponding test files (even if
   unchanged)
7. For TypeScript files in web/, identify corresponding test files (even if
   unchanged)
8. Show the user what will be reviewed and ask for confirmation

### Step 2: Review Loop

Execute up to `max_loops` iterations:

#### 2a. Spawn Reviewer Subagent

Use the Task tool with `subagent_type: general-purpose` to spawn a code
reviewer.

**If the subagent fails or times out:**

1. Analyze the failure:
   - If timeout: Consider reducing scope or breaking into smaller reviews
   - If parse error: Check for malformed input or adjust structured output
     format
   - If tool failure: Verify file paths and permissions
2. Show error to user: "The reviewer subagent failed: [error message]. Analysis:
   [your analysis]"
3. Ask: "I can retry with an adjusted approach. Retry or abort? (retry/abort)"
4. If `retry`: Attempt once more with an **adjusted prompt** based on the error
   analysis
5. If `abort` or second failure: EXIT the loop with error status

The reviewer prompt should:

- Review all files in scope (changed files + their test files for Go code)
- Follow guidance from CLAUDE.md for style and conventions
- Identify which components are changed (janomus, hermelos, pundora, web,
  functions, k8s)
- Read component-specific CLAUDE.md files for changed components (e.g., if Go
  files in pkg/ are changed, read pkg/CLAUDE.md for concurrency patterns FIRST)
- Check for:
  - Code quality and best practices
  - Potential bugs or issues
  - Performance considerations
  - Security concerns:
    - Generic: SQL injection, XSS, command injection, path traversal
    - **Domain-specific (CRITICAL for this codebase):**
      - Matrix MXID validation (must have @ prefix and :domain suffix)
      - MULP (Matrix User LocalPart) validation (no @ or : allowed)
      - Firestore query parameterization (never string concatenation)
      - GCP Secret Manager usage (never log secret values)
      - Firebase token verification (proper error handling)
      - Bridge credentials storage (encrypted, never logged)
      - Rate limiting for Matrix API calls
      - Authorization checks (verify user permissions)
  - Test coverage
  - Race conditions (especially for Go code - see pkg/CLAUDE.md)
- Output findings in structured format:

🔴 CRITICAL Issues

• [Category] Description - file.go:123

🟠 HIGH Priority Issues

• [Category] Description - file.go:456

🟡 MEDIUM Priority Issues

• [Category] Description - file.go:789

🟢 LOW Priority Issues

• [Category] Description - file.go:012

- Use the repository's CLAUDE.md for guidance on style and conventions. Be
constructive and helpful in your feedback.

#### 2b. Parse Review Results

Extract CRITICAL and HIGH priority issues from the reviewer's output.

#### 2c. Show Findings and Get Approval

Display the review findings to the user in a clear, formatted way.

**If NO CRITICAL or HIGH issues found:**

- Congratulate the user
- Show MEDIUM/LOW issues for awareness
- EXIT the loop successfully

**If CRITICAL or HIGH issues found:**

- Show count of issues by priority
- List all CRITICAL and HIGH issues
- **In auto mode**: Automatically proceed to fix step without asking
- **In manual mode**: Ask the user: "I found X critical and Y high priority
issues. Would you like me to fix them? (yes/no/abort)"
- `yes` - Conti