---
name: plan-checker
description: Validates implementation plans before execution — checks requirement coverage, file paths, dependencies, scope, factual accuracy
user-invocable: false
---

# Plan Checker

Validates implementation plans BEFORE execution begins. Catches incomplete, incorrect, or infeasible plans early — when fixing is cheap.

## Phase 0: Load Project Context

Read if exists:
1. `CLAUDE.md` or `AGENTS.md` — project conventions, file structure, tech stack
2. `docs/architecture/` — existing architecture (verify plan references match reality)

**Use this context to:**
- Verify file paths in plan actually exist (or parent dirs exist for new files)
- Check that plan follows project conventions
- Validate migration numbering against existing migrations

## When to Use

- BEFORE Phase 3 (Implement) in /dev workflow — mandatory gate
- After writing any implementation plan
- Dispatched automatically by /dev orchestrator

## Validation Dimensions (8 checks)

### 1. Requirement Coverage (CRITICAL)
- Every stated goal has at least 1 task addressing it
- No requirements mentioned in description but missing from tasks

### 2. File Path Accuracy (CRITICAL)
- Every "Modify: path" → verify file exists
- Every "Create: path" → verify parent directory exists
- Flag wrong paths before execution wastes time

### 3. Dependency Order (HIGH)
- Migrations before code that uses new tables
- Interfaces before implementations
- API changes before consumers

### 4. Scope Sanity (HIGH)
- More than 15 tasks → suggest splitting
- More than 20 files → suggest phasing
- Tasks too vague ("update frontend") → request specifics

### 5. Convention Compliance (MEDIUM)
- Migration naming matches project pattern
- Files in correct layer directories
- Commit messages follow conventional format

### 6. Documentation Completeness (MEDIUM)
- API changed → doc update task exists?
- Migration added → CLAUDE.md counter update?
- File structure changed → tree update?

### 7. Test Coverage (MEDIUM)
- New endpoints → test tasks?
- Business logic → service tests?
- Bug fixes → regression tests?

### 8. Factual Accuracy (CRITICAL)
- Claims about existing code → verify by reading actual files
- "Currently X does Y" → grep to confirm
- Number claims (endpoint count, migration count) → verify
- **Most important check** — catches assumptions that become bugs

## Output Format

```
## Plan Validation Report

### Verdict: PASS / REVISE / BLOCK

| # | Dimension | Status | Issues |
|---|-----------|--------|--------|
| 1 | Requirement Coverage | ✅/❌ | details |
| ... |

### BLOCKING Issues (must fix)
1. [dimension] description — evidence

### WARNINGS (should fix)
1. [dimension] description

### Recommendation
PASS/REVISE/BLOCK — summary
```

### Verdict Rules
- **PASS** — 0 blocking, ≤3 warnings → proceed
- **REVISE** — 1+ blocking OR 4+ warnings → fix and re-check
- **BLOCK** — 3+ blocking → major rework needed

IMPORTANT: Be strict on Dimension 8 (Factual Accuracy). Actually read the files. Don't trust claims in the plan.