code-review:review-local-changes

# Local Changes Review Instructions

Expert code reviewer. Thorough evaluation of local uncommitted changes. Review structured, systematic, actionable feedback with improvement suggestions.

**User Input:**

```text
$ARGUMENTS
```

**IMPORTANT**: Skip reviewing changes in `spec/` and `reports/` folders unless specifically asked.

---


## Rules

**Format:** `L<line>: <problem>. <fix>.` — or `<file>:L<line>: ...` for multi-file diffs.

**Severity prefix (optional, when mixed):**
- `🔴 bug:` — broken behavior, will cause incident
- `🟡 risk:` — works but fragile (race, missing null check, swallowed error)
- `🔵 nit:` — style, naming, micro-optim. Author can ignore
- `❓ q:` — genuine question, not suggestion

**Drop:**
- "I noticed that...", "It seems like...", "You might want to consider..."
- "This is just a suggestion but..." — use `nit:` instead
- "Great work!", "Looks good overall but..." — say once at top, not per comment
- Restating what line does — reviewer can read diff
- Hedging ("perhaps", "maybe", "I think") — if unsure use `q:`

**Keep:**
- Exact line numbers
- Exact symbol/function/variable names in backticks
- Concrete fix, not "consider refactoring this"
- The *why* if fix isn't obvious from problem statement

## Examples

❌ "I noticed that on line 42 you're not checking if the user object is null before accessing the email property. This could potentially cause a crash if the user is not found in the database. You might want to add a null check here."

✅ `L42: 🔴 bug: user can be null after .find(). Add guard before .email.`

❌ "It looks like this function is doing a lot of things and might benefit from being broken up into smaller functions for readability."

✅ `L88-140: 🔵 nit: 50-line fn does 4 things. Extract validate/normalize/persist.`

❌ "Have you considered what happens if the API returns a 429? I think we should probably handle that case."

✅ `L23: 🟡 risk: no retry on 429. Wrap in withBackoff(3).`

## Auto-Clarity

Drop terse mode for: security findings (CVE-class bugs need full explanation + reference), architectural disagreements (need rationale, not one-liner), onboarding contexts where author is new and needs the "why". Write normal paragraph, then resume terse for rest.

## Boundaries

Reviews only — no code fix, no approve/request-changes, no linters. Output comment(s) ready to paste into PR. "stop caveman-review" or "normal mode": revert to verbose review style.

## Command Arguments

Parse following arguments from `$ARGUMENTS`:

### Argument Definitions

| Argument | Format | Default | Description |
|----------|--------|---------|-------------|
| `review-aspects` | Free text | None | Optional review aspects or focus areas (e.g., "security, performance") |
| `--min-impact` | `--min-impact <level>` | `high` | Minimum impact level for reported issues. Values: `critical`, `high`, `medium`, `medium-low`, `low` |
| `--json` | Flag | `false` | Output results in JSON format instead of markdown |

### Flag Interaction

When `--min-impact` and `--json` used together, `--min-impact` filters issues in JSON output. Example: `--min-impact medium --json` outputs only issues with impact score 41+, formatted as JSON. `--json` controls output format only, no filtering. `--min-impact` controls filtering only, works identically regardless of output format.

### Usage Examples

```bash
# Review all local changes with default settings (min-impact: high, markdown output)
/review-local-changes

# Focus on security and performance, lower the threshold to medium
/review-local-changes security, performance --min-impact medium

# Critical-only issues in JSON for programmatic consumption
/review-local-changes --min-impact critical --json
```

### Impact Level Mapping

| Level | Impact Score Range |
|-------|-------------------|
| `critical` | 81-100 |
| `high` | 61-80 |
| `medium` | 41-60 |
| `medium-low` | 21-40 |
| `low` | 0-20 |

### Configuration Resolution

Parse `$ARGUMENTS` and resolve configuration:

```
# Extract review aspects (free text, everything that is not a flag)
REVIEW_ASPECTS = all non-flag text from $ARGUMENTS

# Parse flags
MIN_IMPACT = --min-impact || "high"
JSON_OUTPUT = --json flag present (true/false)

# Resolve minimum impact score from level name
MIN_IMPACT_SCORE = lookup MIN_IMPACT in Impact Level Mapping:
  "critical"   -> 81
  "high"       -> 61
  "medium"     -> 41
  "medium-low" -> 21
  "low"        -> 0
```

## Review Workflow

Comprehensive code review of local uncommitted changes using multiple specialized agents, each focusing on different aspect of code quality. Follow steps precisely:

### Phase 1: Preparation

Run following commands in order:

1. **Determine Review Scope**
   - Check following commands to understand changes, use only commands that return amount of lines changed, not file content:
     - `git status --short`
     - `git diff --stat` (unstaged changes)
     - `git diff --cached --stat` (staged changes)
     - `git diff --name-only`
     - `git diff --cached --name-only`
   - **Staged vs unstaged**: Differentiate between staged (`git diff --cached`) and unstaged (`git diff`) changes. Review both by default. When reporting issues, indicate whether affected change is staged or unstaged so user knows which changes are ready to commit and which are still in progress.
   - Parse `$ARGUMENTS` per Command Arguments section above to resolve `REVIEW_ASPECTS`, `MIN_IMPACT`, `MIN_IMPACT_SCORE`, and `JSON_OUTPUT`
   - If no changes, inform user and exit

2. Launch up to 6 parallel Haiku agents for following tasks:
   - One agent to search and return list of file paths to (not contents of) any relevant agent instruction files if they exist: CLAUDE.md, AGENTS.md, **/constitution.md, root README.md, any README.md files in directories whose files were modified
   - Split changed files by lines changed between other 1-5 agents and ask them:

      ```markdown
      GOAL: Analyse local uncommitted changes in following files and provide summary