Plan with review
When the user asks for a plan (or plan mode is active), run the two-pass workflow. Do not present a draft plan without QA; always run the QA pass and then present the final plan plus QA notes.
Default behavior
- Trigger: User asks for a plan, is in plan mode, or says "review this plan" / "missing parts" / "clarifications" in a planning context.
- Workflow: Draft plan → run Plan QA (checklist below) → incorporate fixes → present final plan then
## Plan QA notes.
- Always show QA notes: Do not hide or skip the Plan QA notes section, even when the final plan is concise.
- Blocking questions: Use AskQuestion only for true blockers; limit to 1–2 critical questions. Prefer listing assumptions/risks in QA notes over asking unless the answer is required before implementation.
Preflight (before drafting)
- Repo guidance: look for
AGENTS.md, CLAUDE.md, .agents/, .claude/commands/, and .claude/skills/. Incorporate their constraints; list conflicts or unknowns in Plan QA notes.
- Prior art: search workspace skills/commands and known external tools for patterns that overlap with the problem. Borrow what exists; flag what needs to be built from scratch. Re-inventing something an existing skill,
gh, or a standard tool already covers is an effort trap.
Ordering
Run Plan QA before presenting the final plan (and before finalizing any plan artifact), so gaps are caught before implementation.
Plan QA checklist
- Requirements coverage (user intent and constraints)
- Correctness risks / edge cases / failure modes
- Dependencies (internal/external, ordering, unknowns)
- Verification gates (how we’ll know we’re done; include at least one concrete gate)
- Safety/rollback (data loss, irreversible ops, security/privacy; permissions needed)
- Effort traps (scope too broad, missing boundaries):
- Does every component earn its complexity cost? Would removing it lose core value?
- What do existing tools, libs, or workspace skills already handle that the plan reimplements?
- YAGNI: is anything built before there is a concrete second use case for it?
- Unix philosophy: does this do one thing well, or is it several loosely-related tools stitched together?
- Phase ordering: does Phase 1 deliver the unique core value on its own (not just scaffold)? Could the user stop after Phase 1 and still get something useful? Are phases ordered by value delivered, not only by technical dependency?
- Deferred scope: for large plans, identify items that are genuinely out of scope for the initial implementation. List them in a separate section or companion file so the core plan stays focused and reviewable.
- Repo conventions (file placement, naming, link style, lint/test expectations)
Output contract
Final plan: Scope / constraints / non-goals | Approach (decisions + why) | Files & touchpoints | Step-by-step implementation with verification gates | Test/validation plan | Rollback/safety when applicable.
Plan QA notes (section ## Plan QA notes after the plan):
- Resolved in QA: issues incorporated into the final plan
- Open risks / issues: remaining risks/unknowns (not blockers)
- Assumptions made: for quick user correction
- Clarifications needed (blockers): only 1–2 critical questions before implementation
Precedence
- If the user explicitly invokes plan-with-review (e.g.
/plan-with-review), always run this two-pass workflow regardless of other instructions (e.g. "be brief").
1---2name: plan-with-review3description: Runs a two-pass planning workflow (draft → Plan QA → final plan + QA notes). Use when the user asks to create a plan, is in plan mode, requests an implementation plan, asks to "review this plan" for issues/missing parts/improvements/clarifications, or mentions planning, missing parts, or clarifications.4---56# Plan with review78When the user asks for a plan (or plan mode is active), run the **two-pass** workflow. Do not present a draft plan without QA; always run the QA pass and then present the final plan plus QA notes.910## Default behavior1112- **Trigger**: User asks for a plan, is in plan mode, or says "review this plan" / "missing parts" / "clarifications" in a planning context.13- **Workflow**: Draft plan → run Plan QA (checklist below) → incorporate fixes → present **final plan** then **`## Plan QA notes`**.14- **Always show QA notes**: Do not hide or skip the Plan QA notes section, even when the final plan is concise.15- **Blocking questions**: Use AskQuestion only for true blockers; limit to 1–2 critical questions. Prefer listing assumptions/risks in QA notes over asking unless the answer is required before implementation.1617## Preflight (before drafting)18191. **Repo guidance**: look for `AGENTS.md`, `CLAUDE.md`, `.agents/`, `.claude/commands/`, and `.claude/skills/`. Incorporate their constraints; list conflicts or unknowns in Plan QA notes.202. **Prior art**: search workspace skills/commands and known external tools for patterns that overlap with the problem. Borrow what exists; flag what needs to be built from scratch. Re-inventing something an existing skill, `gh`, or a standard tool already covers is an effort trap.2122## Ordering2324Run Plan QA **before** presenting the final plan (and before finalizing any plan artifact), so gaps are caught before implementation.2526## Plan QA checklist2728- Requirements coverage (user intent and constraints)29- Correctness risks / edge cases / failure modes30- Dependencies (internal/external, ordering, unknowns)31- Verification gates (how we’ll know we’re done; include at least one concrete gate)32- Safety/rollback (data loss, irreversible ops, security/privacy; permissions needed)33- **Effort traps** (scope too broad, missing boundaries):34 - Does every component earn its complexity cost? Would removing it lose core value?35 - What do existing tools, libs, or workspace skills already handle that the plan reimplements?36 - YAGNI: is anything built before there is a concrete second use case for it?37 - Unix philosophy: does this do one thing well, or is it several loosely-related tools stitched together?38- **Phase ordering**: does Phase 1 deliver the unique core value on its own (not just scaffold)? Could the user stop after Phase 1 and still get something useful? Are phases ordered by value delivered, not only by technical dependency?39- **Deferred scope**: for large plans, identify items that are genuinely out of scope for the initial implementation. List them in a separate section or companion file so the core plan stays focused and reviewable.40- Repo conventions (file placement, naming, link style, lint/test expectations)4142## Output contract4344**Final plan**: Scope / constraints / non-goals | Approach (decisions + why) | Files & touchpoints | Step-by-step implementation with verification gates | Test/validation plan | Rollback/safety when applicable.4546**Plan QA notes** (section `## Plan QA notes` after the plan):4748- **Resolved in QA**: issues incorporated into the final plan49- **Open risks / issues**: remaining risks/unknowns (not blockers)50- **Assumptions made**: for quick user correction51- **Clarifications needed (blockers)**: only 1–2 critical questions before implementation5253## Precedence5455- If the user explicitly invokes **plan-with-review** (e.g. `/plan-with-review`), always run this two-pass workflow regardless of other instructions (e.g. "be brief").
jmlrt