review-changes

What this skill does

# Review Git Changes

## Instructions

Perform thorough code review of current working copy changes, optionally compare to plan, and identify engineering issues.

### Phase 1: Discover Changes & Context

#### Step 1: Get Current Changes
```bash
# See changed files
git status

# See detailed diff
git diff

# See staged changes separately
git diff --cached

# See both staged and unstaged
git diff HEAD
```

#### Step 2: Identify Related Plan (if exists)

Search for related plan file:
- Check `.plans/` directory for relevant plan
- Look for plan mentioned in branch name
- Ask user if unsure which plan applies
- If no plan exists, review against general best practices

If plan exists:
- Read the entire plan
- Understand intended design and architecture
- Note specific requirements and constraints

#### Step 3: Categorize Changed Files

Group files by type:
- **New files**: Created from scratch
- **Modified files**: Existing files changed
- **Deleted files**: Removed files
- **Renamed/moved files**: Organizational changes

Create todo list with one item per changed file to review.

### Phase 2: Systematic File Review

For EACH changed file in the todo list:

#### Step 1: Read Current State
- Read the entire file in its current state
- Understand what it does
- Note its responsibilities

#### Step 2: Analyze the Changes

Read git diff to see exactly what changed:
- What was added?
- What was removed?
- What was modified?

#### Step 3: Assess Against Plan (if applicable)

If plan exists, check:
- **Does implementation match plan?**
  - Are planned features implemented correctly?
  - Is architecture followed?
  - Are file names as specified?

- **Scope adherence**:
  - Is this change in the plan?
  - Is it necessary for the plan's goals?
  - Is it scope creep?

- **REMOVAL SPEC compliance**:
  - If plan said to remove code, was it removed?
  - Is old code still present when it shouldn't be?

#### Step 4: Identify Engineering Issues

Check for **Bad Engineering**:
- **Bugs**: Logic errors, off-by-one, race conditions
- **Poor error handling**: Swallowed errors, generic catches
- **Missing validation**: No input validation, no null checks
- **Hard-coded values**: Magic numbers, hardcoded URLs/paths
- **Tight coupling**: Unnecessary dependencies between modules
- **Violation of SRP**: Class/function doing too many things
- **Incorrect patterns**: Misuse of design patterns
- **Type issues**: Use of `any`, missing types, wrong types
- **Missing edge cases**: Doesn't handle empty/null/error cases

Check for **Over-Engineering**:
- **Unnecessary abstraction**: Too many layers for simple logic
- **Premature optimization**: Complex code for unmeasured performance
- **Framework overuse**: Using heavy library for simple task
- **Feature creep**: Adding features not in requirements
- **Gold plating**: Excessive polish on non-critical code
- **YAGNI violations**: Code for "might need later" scenarios
- **Complexity without benefit**: Complicated when simple works

Check for **Suboptimal Solutions**:
- **Duplication**: Copy-pasted code instead of extraction
- **Reinventing wheel**: Custom code when standard library exists
- **Wrong tool**: Using inappropriate data structure/algorithm
- **Inefficient approach**: O(n²) when O(n) is obvious
- **Poor naming**: Unclear variable/function names
- **Missing reuse**: Existing utilities/types not used
- **Inconsistent patterns**: Doesn't match codebase style
- **Technical debt**: Quick hack instead of proper solution

#### Step 5: Check Code Quality

- **Readability**: Is code clear and self-documenting?
- **Maintainability**: Will this be easy to change later?
- **Testability**: Can this be tested easily?
- **Performance**: Any obvious performance issues?
- **Security**: Any security vulnerabilities?
- **Consistency**: Matches existing codebase patterns?

#### Step 6: Record Findings

Store in memory:
```
File: path/to/file.ts
Change Type: [New|Modified|Deleted]
Plan Compliance: [Matches|Deviates|Not in plan]
Issues:
  Bad Engineering:
    - [Specific issue with line number]
  Over-Engineering:
    - [Specific issue with line number]
  Suboptimal:
    - [Specific issue with line number]
Severity: [CRITICAL|HIGH|MEDIUM|LOW]
```

#### Step 7: Update Todo
Mark file as reviewed in todo list.

### Phase 2.5: Issue/Task Coverage Verification (MANDATORY)

**CRITICAL**: Before completing the review, verify that 100% of the original issue/task requirements are implemented.

#### Step 1: Identify Source Requirements

Locate the original requirements from:
- GitHub issue (`gh issue view <number>`)
- PR description referencing issues
- Task ticket or plan file in `.plans/`
- Commit messages describing the work

#### Step 2: Extract ALL Requirements

Create exhaustive checklist:
- Functional requirements (what it should do)
- Acceptance criteria (how to verify)
- Edge cases mentioned
- Error handling requirements

#### Step 3: Verify Each Requirement

| # | Requirement | Status | Evidence |
|---|-------------|--------|----------|
| 1 | [requirement] | ✅/❌/⚠️ | file:line or "Missing" |

#### Step 4: Coverage Assessment

```
Requirements Coverage = (Implemented / Total) × 100%
```

**Anything less than 100% = REQUEST CHANGES immediately**

Add to report:
```markdown
## Issue/Task Coverage

**Source**: [Issue #X / Plan file]
**Coverage**: X% (Y of Z requirements)

### Missing Requirements
- ❌ [Requirement X]: Not implemented
- ❌ [Requirement Y]: Partially implemented - [what's missing]

**VERDICT**: Coverage incomplete. Cannot approve until 100% implemented.
```

### Phase 3: Cross-File Analysis

After reviewing all files:

#### Step 1: Architectural Impact
- How do changes affect overall system architecture?
- Are there breaking changes?
- Do changes introduce new dependencies?
- Is there architectural drift from the plan?

#### Step 2: Pattern Consistency
- Are changes consistent with each other?
- Do they follow same patterns?
- Any conflicting approaches?

#### Step 3: Completeness Check
- Are all related changes present?
- Missing files that should be changed?
- Orphaned references?

### Phase 4: Generate Review Report

Create report at `.reviews/code-review-[timestamp].md`:

```markdown
# Code Review Report
**Date**: [timestamp]
**Branch**: [branch name]
**Related Plan**: [plan file or "None"]
**Files Changed**: X
**Issues Found**: Y

---

## Executive Summary
- **Critical Issues**: X (must fix before merge)
- **High Priority**: Y (should fix)
- **Medium Priority**: Z (consider fixing)
- **Low Priority**: W (suggestions)

**Overall Assessment**: [APPROVE|REQUEST CHANGES|REJECT]

---

## Plan Compliance (if applicable)

### Matches Plan ✅
- Feature X implemented correctly
- Architecture follows design
- File naming conventions followed

### Deviates from Plan ⚠️
- Implementation differs from planned approach in [area]
- Missing feature Y from plan
- Scope creep: Added Z not in plan

### REMOVAL SPEC Status
- ✅ Old code removed from `file.ts:50-100`
- ❌ Legacy function still exists in `auth.ts:42` (should be removed)

---

## Issues by Severity

### CRITICAL: Bad Engineering

#### Logic Bug in `src/services/auth.ts:125`
```typescript
// Current code:
if (user.role = 'admin') { // Assignment instead of comparison
  grantAccess()
}
```
**Issue**: Assignment operator used instead of equality check. This always evaluates to true and grants everyone admin access.
**Severity**: CRITICAL - Security vulnerability
**Fix**: Change `=` to `===`

#### Unhandled Promise in `src/api/client.ts:67`
```typescript
// Current code:
fetchData().then(data => process(data)) // No error handling
```
**Issue**: Promise rejection not handled, will crash silently
**Severity**: CRITICAL - Application stability
**Fix**: Add `.catch()` or use try/catch with async/await

### HIGH: Over-Engineering

#### Unnecessary Abstraction in `src/utils/formatter.ts`
```typescript
// Current code: 50 lines of abstraction
class FormatterFactory {
  createFormatter(type: string): IFor