code-review

name	code-review
description	Thorough post-implementation code review. Use when user says "code review", "review code", "review changes", or after implementation is complete. Reviews all changes, identifies issues, checks for unintended settled work modifications, and produces prioritized fix list.

Code Review

Performs thorough post-implementation review of all changes made in the session.

Workflow

Step 1: Inventory Changes

List all files created or modified in this session:

## Files Changed

### Created (X files)
- path/to/new/file.ts (XX lines)
- path/to/another.tsx (XX lines)

### Modified (X files)
- path/to/existing.ts (+XX/-XX lines)
- path/to/component.tsx (+XX/-XX lines)

Step 2: Review Each File

For each file, verify:

Correctness:

• Logic matches requirements
• Edge cases handled
• Error handling present
• Types are accurate

Code Quality:

• No commented-out code
• No debug statements left behind
• Consistent naming conventions
• Appropriate comments (explain why, not what)

Architecture Compliance:

• Follows project patterns
• Correct file locations
• Proper imports/exports
• No circular dependencies

Step 3: Settled Work Impact Check

Identify any changes to previously settled/completed work:

Only flag if change materially affects correctness, scalability, or safety.

Ignore:

• Stylistic differences
• Refactoring-only changes
• Import reordering

If unintended changes found:

⚠️ Unintended Change to Settled Work

File: [path]
Settled in: [Task/Phase reference]
Change: [What was modified]
Material impact: [Yes - reason / No - can ignore]

Step 4: Run Static Analysis

Execute available linting and type checking:

npm run lint
npm run type-check  # or tsc --noEmit

Report results:

• ✅ Linting passed
• ✅ Type checking passed
• ❌ [X] errors found (list them)

Step 5: Categorize Issues

Group findings by severity:

## Code Review Findings

### 🔴 Critical (blocks merge)
- [Issue]: [Description] — [File:Line]

### 🟡 Important (should fix)
- [Issue]: [Description] — [File:Line]

### 🟢 Minor (nice to have)
- [Issue]: [Description] — [File:Line]

### ✅ No Issues
[Category had no findings]

Step 6: Present Summary

## Code Review Summary

**Files Reviewed:** X created, Y modified
**Linting:** ✅ Pass / ❌ X errors
**Type Check:** ✅ Pass / ❌ X errors
**Settled Work:** ✅ No unintended changes / ⚠️ X items flagged

### Issues Found
- 🔴 Critical: X
- 🟡 Important: X  
- 🟢 Minor: X

### Recommended Fixes
1. [Priority 1 fix] — [File]
2. [Priority 2 fix] — [File]
3. [Priority 3 fix] — [File]

**Approval needed to proceed with fixes.**

Step 7: Await Approval

Do not fix issues automatically. Present the list and wait for:

• "fix all" — Fix all issues
• "fix critical" — Fix only critical issues
• "fix [1, 3]" — Fix specific numbered items
• "skip" — Proceed without fixes

Example Usage

User: "code review"

Response:

1. Inventory: 4 files created, 2 modified
2. Review each for correctness, quality, architecture
3. Check settled work: No unintended changes
4. Run lint/type-check: All pass
5. Findings: 0 critical, 2 important, 1 minor
6. Present prioritized fix list
7. Await approval

Key Principles

• Thorough: Review every file changed
• Prioritized: Critical → Important → Minor
• Material only: Don't flag stylistic settled work changes
• Approval required: Never auto-fix without consent