Review Implementation Plan
Perform a read-only review of a plan before implementation.
Rules
- Do not edit files while reviewing.
- Read the plan and enough project context to validate it.
- Findings come first, ordered by severity.
- Report only issues that affect correctness, maintainability, scope, safety, or testability.
- Do not nitpick wording unless it creates implementation ambiguity.
- If the user asks to revise the plan, report findings first, then edit only after explicit instruction.
Clarifying Questions
- Ask before reviewing if the plan target, relevant context, base branch, review depth, or permission to read project files is unclear.
- Do not proceed on assumptions that affect whether the plan is correct, safe, or executable.
- Ask numbered questions with lettered options; option A must be recommended. Continue once the review target and context are clear.
Do Not Trigger
- Code diff or PR review.
- Creating a new plan.
- Executing a plan.
Checklist
Check correctness, scope control, concrete task files, tests, verification commands, compatibility/migration safety, operational risk, and project fit. Cite line numbers when available; otherwise cite section or task names.
Output
**Findings**
1. [critical/major/minor] [section/task] [issue]
Impact: [why it matters]
Fix: [specific plan change]
**Open Questions**
1. [Only if blocking]
**Verdict**
[APPROVE / APPROVE WITH RESIDUAL RISK / NEEDS REVISION]
**Suggested Next Step**
[Revise plan / implement / investigate]
Use APPROVE only when the plan is clear, concrete, testable, scoped, and safe. Use APPROVE WITH RESIDUAL RISK for non-blocking context or verification gaps. Use NEEDS REVISION when findings should be fixed before implementation.
If there are no findings, say No blocking findings and list residual risks or None identified.
1---2name: review-implementation-plan3description: Review implementation plans before coding. Use when the user asks to review, validate, sanity-check, de-risk, simplify, or find gaps in a plan, especially docs/plans files, task checklists, migrations, refactors, and multi-step feature plans.4---56# Review Implementation Plan78Perform a read-only review of a plan before implementation.910## Rules1112- Do not edit files while reviewing.13- Read the plan and enough project context to validate it.14- Findings come first, ordered by severity.15- Report only issues that affect correctness, maintainability, scope, safety, or testability.16- Do not nitpick wording unless it creates implementation ambiguity.17- If the user asks to revise the plan, report findings first, then edit only after explicit instruction.1819## Clarifying Questions2021- Ask before reviewing if the plan target, relevant context, base branch, review depth, or permission to read project files is unclear.22- Do not proceed on assumptions that affect whether the plan is correct, safe, or executable.23- Ask numbered questions with lettered options; option A must be recommended. Continue once the review target and context are clear.2425## Do Not Trigger2627- Code diff or PR review.28- Creating a new plan.29- Executing a plan.3031## Checklist3233Check correctness, scope control, concrete task files, tests, verification commands, compatibility/migration safety, operational risk, and project fit. Cite line numbers when available; otherwise cite section or task names.3435## Output3637```markdown38**Findings**391. [critical/major/minor] [section/task] [issue]40 Impact: [why it matters]41 Fix: [specific plan change]4243**Open Questions**441. [Only if blocking]4546**Verdict**47[APPROVE / APPROVE WITH RESIDUAL RISK / NEEDS REVISION]4849**Suggested Next Step**50[Revise plan / implement / investigate]51```5253Use `APPROVE` only when the plan is clear, concrete, testable, scoped, and safe. Use `APPROVE WITH RESIDUAL RISK` for non-blocking context or verification gaps. Use `NEEDS REVISION` when findings should be fixed before implementation.5455If there are no findings, say `No blocking findings` and list residual risks or `None identified`.
gslava