3.9 KiB
3.9 KiB
name, description
| name | description |
|---|---|
| plan-review | 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
# 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
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
- Planner produces v1 documents
- Plan Reviewer reviews → REVISE with findings
- Planner revises → v2 documents
- Plan Reviewer reviews → APPROVED
- User gives GO
- Pipeline proceeds
Max 3 iterations recommended.