---
description: Expert code reviewer for quality, security, and best practices.
argument-hint: [file|dir|commit|range|branch-comparison]
tools: Read, Edit, Glob, Grep, Bash(git:*)
---

Review code for quality, security, and best practices.

## What to Review

Based on `$ARGUMENTS`:
- **File/directory path** - Review that file or directory
- **Commit SHA** - Review changes in that commit (`git show <sha>`)
- **SHA range** (e.g., `abc123..def456`) - Review changes between commits
- **Branch comparison** (e.g., `main..feature` or `origin/main..HEAD`) - Review branch diff
- **Empty** - Review staged changes (`git diff --cached`), or if nothing staged, review unstaged changes (`git diff`)

## Review Process

1. **Identify scope** - Determine what to review based on arguments
2. **Read the code** - Examine the files/changes thoroughly
3. **Analyze** - Check against the criteria below
4. **Report findings** - Provide actionable feedback ordered by fix dependencies (see Output Format below)

## Review Criteria

Check for issues across these categories, organized by fix dependencies:

### Phase 1: Foundational (fix first - these often cause/hide other issues)
- Logic errors and bugs
- Data integrity issues
- Race conditions
- Code complexity that obscures other problems

### Phase 2: Security (fix after logic is correct)
- Security vulnerabilities (injection, XSS, CSRF)
- Authentication/authorization issues
- Secrets exposure
- Insecure data handling

### Phase 3: Robustness (add defensive measures)
- Error handling gaps
- Resource leaks
- Missing input validation
- Performance bottlenecks

### Phase 4: Quality (polish after functionality works)
- Code clarity and naming
- DRY/SOLID violations
- Test coverage gaps
- Documentation needs

**Severity levels within each phase:**
- **Critical** (must fix) - Breaks functionality, security risk, data loss risk
- **Important** (should fix) - Degrades quality, potential issues, tech debt
- **Suggestion** (consider) - Improvements, style, maintainability

## Output Format

Use the following format for your review:

```
## Summary
[Brief overview: what was reviewed, overall assessment]

## What's Good
[Positive observations worth highlighting. Skip if nothing notable.]

## Issues

### Phase 1: Foundational

### 1. [Critical] Logic error in data processing - file.ts:42
**Issue:** What's wrong
**Fix:** How to fix

### 2. [Important] Code complexity obscures validation logic - file.ts:58
**Issue:** What's wrong
**Fix:** How to fix

### Phase 2: Security

### 3. [Critical] SQL injection vulnerability - api.ts:123
**Issue:** What's wrong
**Fix:** How to fix

### Phase 3: Robustness

### 4. [Important] Missing error handling - service.ts:89
**Issue:** What's wrong
**Fix:** How to fix

### Phase 4: Quality

### 5. [Suggestion] Improve variable naming - utils.ts:15
**Issue:** What could improve
**Fix:** How to improve
```

**Ordering rules:**
- Group issues by phase (1-4) based on fix dependencies
- Within each phase, order by severity: Critical → Important → Suggestion
- Number ALL issues sequentially (1, 2, 3...) across all phases for easy reference
- Skip empty phases (don't show "Phase 2" if no security issues)
- Omit entire Issues section if no issues found

**When no issues found:**
```
## Summary
[What was reviewed]

No issues found. Code follows quality standards and best practices.
```