---
name: plan-review
description: Plan and testplan quality review before implementation. Produces APPROVED/REVISE verdict.
---

# Skill: plan-review

Plan and testplan quality review before implementation.

## Invoked by

📋✅ Plan Reviewer mode

## Required Inputs

| Input | Source | Example |
|-------|--------|---------|
| `TICKET_KEY` | Jira issue key | `PROJECT-123` |
| `MODULE` | Module/component name | `auth`, `api`, `core` |

## Output

Markdown file: `docs/<MODULE>/<TICKET_KEY>/<TICKET_KEY>-plan-review.md`

## Steps

### 1. Read the planning documents

- Assessment (`*-assessment.md`) — required
- Implementation plan (`*-plan.md`) — required
- Test plan (`*-testplan.md`) — required

If any required document is missing, flag as REVISE immediately.

### 2. Read the Jira ticket

Cross-reference: do the plan documents address ALL requirements from the ticket?

### 3. Read affected source code

For each file/class mentioned in the plan:
- Verify the file exists at the stated path
- Verify class/method names are correct
- Verify patterns described match actual code
- Check if the plan missed related files

### 4. Run the plan review checklist

#### Assessment Review

| # | Check |
|---|-------|
| 1 | Problem statement complete and matches Jira ticket |
| 2 | Affected components identified — any missing? |
| 3 | Current state description matches actual code |
| 4 | Risk assessment realistic |
| 5 | Solution options evaluated with justification |

#### Implementation Plan Review

| # | Check |
|---|-------|
| 6 | All requirements covered |
| 7 | Correct project patterns referenced |
| 8 | File paths correct and exist |
| 9 | Implementation order logical (dependencies first) |
| 10 | No gaps between steps |
| 11 | Database migrations planned (if needed) |
| 12 | Error handling planned (not just happy path) |
| 13 | No scope creep beyond ticket requirements |

#### Test Plan Review

| # | Check |
|---|-------|
| 14 | Coverage complete — every plan step has a test |
| 15 | Test types appropriate (unit vs integration) |
| 16 | Edge cases covered (null, empty, boundary values) |
| 17 | Test class naming correct |
| 18 | Test method naming correct |
| 19 | Test data defined |

### 5. Run expert-panel-review skill

Before generating the verdict, run the `expert-panel-review` skill for multi-perspective analysis. Panel confidence < 70% → verdict MUST be REVISE.

### 6. Generate plan review document

```markdown
# Plan Review: <TICKET_KEY> — <Summary>

**Date:** <today>
**Module:** <MODULE>
**Reviewer:** Lumen (Plan Reviewer)
**Documents:** assessment.md v<N>, plan.md v<N>, testplan.md v<N>
**Verdict:** ✅ APPROVED / 🔄 REVISE

---

## Summary

<1-2 sentence summary>

## Checklist

| # | Check | Result | Note |
|---|-------|--------|------|
| 1 | Problem statement complete | ✅/❌ | |
| ... | ... | ... | ... |

## Findings

### ❌ Must revise (blocking)

1. **<document>** — <issue>

### ⚠️ Suggestions (non-blocking)

1. **<document>** — <suggestion>

## Traceability Matrix

| Requirement | Plan Step | Test Case | Status |
|------------|-----------|-----------|--------|
| <req 1> | Step <N> | T-<NN> | ✅ Covered |

## Verdict

**✅ APPROVED** — Plan is complete and ready for implementation.
— or —
**🔄 REVISE** — <N> items need rework. Back to Planner.
**Panel Confidence:** <X>%
```

### 7. Store in BigMind

```python
memory_store_fact(
    category="codebase",
    fact=f"{TICKET_KEY}: Plan review — {verdict}. {findings} findings ({blockers} blocking)."
)
```

## Verdict Criteria

| Verdict | Criteria |
|---------|---------|
| ✅ APPROVED | All checklist items pass. No blocking findings. Panel confidence ≥ 70%. |
| 🔄 REVISE | Any checklist item fails, or panel confidence < 70%. |

## Review Loop

1. Planner produces v1 documents
2. Plan Reviewer reviews → REVISE with findings
3. Planner revises → v2 documents
4. Plan Reviewer reviews → APPROVED
5. User gives GO
6. Pipeline proceeds

Max 3 iterations recommended.