code-review

# Code Review Gate

You are a **Code Review Gate** responsible for ensuring code quality, security, and correctness BEFORE commits reach version control.

## Purpose

**Problem**: Bugs, security issues, and quality problems slip into commits because reviews happen after code is already committed.

**Solution**: Mandatory pre-commit review using `code-reviewer` agent with structured feedback and approval workflow.

## When to Use This Skill

**Manual invocation ONLY**: `/code-review`

**When to invoke**:
- Before running `git commit`
- After completing feature implementation
- Before creating pull request
- When user asks "review my changes"

**NOT auto-triggered** (disable-model-invocation: true)

---

## The 5-Phase Review Workflow

### Phase 1: IDENTIFY CHANGES

**Goal**: Determine what needs review

**Git commands**:
```bash
# See all changes
git status

# Staged changes (will be committed)
git diff --cached --stat
git diff --cached

# Unstaged changes (might want to stage first)
git diff --stat
git diff

# Recent commits (if reviewing after commit)
git log -1 --stat
git show HEAD
```

**Categorize changes**:
- **New files**: Complete review needed
- **Modified files**: Focus on changes only
- **Deleted files**: Check dependencies (use impact-analysis)
- **Renamed files**: Verify refactoring correctness

**Deliverable**: List of files to review with change types

---

### Phase 2: LAUNCH REVIEWER

**Goal**: Get structured code review from code-reviewer agent

**Prepare review prompt**:
```
Task(
  subagent_type="code-reviewer",
  description="Pre-commit code review",
  prompt="""
Review these changes for bugs, security issues, performance problems, and code quality:

**Files Changed**:
[List files with brief description of changes]

**Context**:
- Purpose: [what this code does]
- Related: [related files or systems]

**Focus Areas**:
- [BUG]: Logic errors, edge cases
- [SECURITY]: Vulnerabilities, input validation
- [PERF]: Performance issues, N+1 queries
- [QUALITY]: Code smells, maintainability
- [STYLE]: Formatting, naming (low priority)

Provide structured feedback with:
1. Issues categorized by severity
2. Specific line references
3. Suggested fixes
4. Verdict: APPROVE or REQUEST_CHANGES
"""
)
```

**Wait for review results**

**Deliverable**: Structured code review with categorized issues

---

### Phase 3: ANALYZE FEEDBACK

**Goal**: Prioritize issues and plan fixes

**Issue Categories** (from code-reviewer):

**CRITICAL (Must fix before commit)**:
- [BUG] - Logic errors, crashes, data corruption
- [SECURITY] - Vulnerabilities, injection risks, auth bypasses

**WARNINGS (Should fix before commit)**:
- [PERF] - Performance issues, scalability problems
- [QUALITY] - Code smells, maintainability issues

**SUGGESTIONS (Optional, can defer)**:
- [STYLE] - Formatting, naming conventions
- [DOCS] - Missing or unclear comments

**Verdict Analysis**:

**APPROVE**:
- No critical issues found
- No warnings that block commit
- Code meets quality standards
- → Proceed to commit (Phase 5)

**REQUEST_CHANGES**:
- Critical issues present (MUST fix)
- Warnings that should be addressed
- → Fix issues (Phase 4)

**NEEDS_DISCUSSION**:
- Unclear requirements
- Architectural concerns
- → Consult user or brainstorm-coordinator

**Deliverable**: Prioritized issue list with fix plan

---

### Phase 4: FIX ISSUES

**Goal**: Address critical and warning issues

**Fixing Strategy**:

**For each CRITICAL issue**:
1. Read file with issue
2. Understand the problem
3. Apply minimal fix
4. Verify fix doesn't break tests
5. Mark as resolved

**For each WARNING**:
1. Assess impact (breaking change? refactor needed?)
2. Apply fix if straightforward
3. Create TODO if complex (defer to separate commit)
4. Mark as resolved or deferred

**Example fix workflow**:
```bash
# Read file
Read(file_path="src/auth/login.ts")

# Apply fix
Edit(
  file_path="src/auth/login.ts",
  old_string="if (user.password == password)",  # BUG: == instead of proper comparison
  new_string="if (await bcrypt.compare(password, user.password))"
)

# Run tests
npm test src/auth/login.test.ts

# Verify fix
Read(file_path="src/auth/login.ts", offset=40, limit=10)
```

**Deliverable**: All critical issues fixed, warnings addressed

---

### Phase 5: RE-REVIEW & APPROVE

**Goal**: Verify fixes and get final approval

**Re-review process**:

**If fixes were applied**:
```
Task(
  subagent_type="code-reviewer",
  description="Re-review after fixes",
  prompt="""
Re-review changes after addressing previous feedback:

**Previous Issues**:
[List issues that were fixed]

**Files Changed** (after fixes):
[Updated file list]

Focus on:
- Verify previous issues resolved
- No new issues introduced by fixes
- Overall code quality

Provide verdict: APPROVE or REQUEST_CHANGES (if still issues)
"""
)
```

**Wait for verdict**

**Verdict Handling**:

**APPROVE**:
- ✅ All issues resolved
- ✅ No new issues from fixes
- → Proceed to commit

**REQUEST_CHANGES** (still issues):
- ❌ Return to Phase 4 (fix remaining issues)
- ❌ Maximum 2 iterations (prevent infinite loop)
- ❌ After 2 iterations, ask user for guidance

**Deliverable**: Final APPROVE verdict

---

### Phase 6: COMMIT (After Approval)

**Goal**: Commit reviewed, approved code

**Pre-commit checklist**:
```bash
# Ensure all changes staged
git add <fixed-files>

# Final status check
git status

# Run tests one more time
npm test

# Commit with descriptive message
git commit -m "$(cat <<'EOF'
feat: Add user authentication

- Implement JWT-based auth
- Add login/logout endpoints
- Secure password hashing with bcrypt

Fixes: #123

Co-Authored-By: Claude Sonnet 4.5 (1M context) <noreply@anthropic.com>
EOF
)"
```

**Post-commit**:
```bash
# Verify commit
git show HEAD
```

**Deliverable**: Clean commit with reviewed, approved code

---

## Integration Points

### With Other Skills

- **After /workflow**: Review work before committing
- **After /debug**: Review bug fixes for correctness
- **After /refactor-safely*