Plan
Turn a gated spec into milestones and atomic tasks: what ships in what order,
what blocks what, what fails first, and what is explicitly out of scope.
Migrated from .claude/commands/plan.md under ADR-064, which makes skills the
single user-invocable surface.
Triggers
plan how to build this, break this into milestones, decompose this spec,
plan this work
If you arrived here without a spec, run the front-gate first
Planning a spec that was never gated manufactures work. If there is no /spec
output for this work (no requirement, no design, no testable acceptance
criteria), do not decompose it into milestones yet. Run spec first: it applies
the front gate (the six forcing questions, the front-gate-before-pipeline
pattern) and confirms a named blocked user, a documented status quo, and a
concrete observation before any downstream step runs. Return here once the spec
exists.
Skip this only when the user explicitly asks to plan an ungated idea and accepts
that trade-off.
Plan: the problem statement from the conversation (under Copilot CLI the skill tool takes no argument vector, so state it in your message)
If $ARGUMENTS is empty, check for recent spec output in the conversation. If
none is found, ask what to plan rather than inferring it.
Process
- Read the spec or issue.
- Map sub-problems to existing code. What already exists? Use Grep and Glob to
verify rather than assuming.
agent_type: "project-toolkit:milestone-planner": You are a project planner. Break
the spec into milestones with clear exit criteria. Each milestone is
independently shippable. Sequence by dependencies. Flag parallel
opportunities.agent_type: "project-toolkit:task-decomposer": You are a work breakdown specialist.
Decompose each milestone into atomic tasks. Each task is independently
verifiable with a clear done definition. Size by complexity (S/M/L), not time.skill: "execution-plans" to persist the plan as a versioned artifact.agent_type: "project-toolkit:analyst": You are a risk analyst. Run a pre-mortem on
this plan. What fails first? What dependencies are fragile? What assumptions
are untested?agent_type: "project-toolkit:critic": You are a plan reviewer. Validate: is scope
complete? Can tasks execute in the stated sequence? Are estimates credible?
Is anything missing?
Evaluation Axes
| Axis |
Question |
| Scope integrity |
Nothing unnecessary, nothing missing |
| Dependency ordering |
Can tasks execute in the stated sequence? |
| Risk coverage |
Does every P0 risk have a mitigation? |
| Estimate confidence |
Complexity-based sizing (S/M/L), never time-based |
| Reversibility |
Which steps are hard to undo? |
Principles
- Programming by Intention. Each task reads like an intent, not an
implementation detail.
- OODA loop. Observe (read the spec), Orient (map to existing code), Decide
(sequence tasks), Act (commit the plan). Faster loops win.
- First principles. Question the requirement, try to delete the step, then
optimize, then speed up, then automate. Never automate something that should
not exist.
Output
| Section |
Contents |
| Milestones |
Numbered, each with exit criteria |
| Tasks per milestone |
Atomic, with acceptance criteria and S/M/L sizing |
| Dependency graph |
What blocks what, what can run in parallel |
| Risk register |
Risk, likelihood, impact, mitigation |
| Deferred items |
Explicitly out of scope for this plan |
Verification
Anti-Patterns
| Avoid |
Why |
Instead |
| Planning an ungated idea |
Produces a credible milestone list for work no user asked for |
Run spec first, or record that the user accepted the trade |
| Time estimates |
Anchor on a number nobody can hold, and rot on contact |
Size by complexity, S/M/L |
| Mapping sub-problems from memory |
Plans a rewrite of code that already exists |
Grep and Glob before claiming something is missing |
| Milestones that ship only together |
Removes the option to stop early, which is the point of a milestone |
Split until each one is independently shippable |
| Silent scope cuts |
The reader cannot tell a decision from an oversight |
List them under Deferred items |
Extension Points
- New evaluation axis. Add a row to the axes table and a matching
Verification checkbox, so the axis is both stated and checked.
- Different persistence. Step 5 delegates to
execution-plans. A project
that tracks plans elsewhere swaps that one call, not the process.
- Parallel decomposition. Steps 3 and 4 run per milestone. For a large spec
they can fan out per milestone rather than running once over all of them.
1---2name: plan-23description: Decompose a spec into milestones and atomic tasks with dependency ordering, risk register, and complexity sizing. Use when you say `plan how to build this`, `break this into milestones`, or `decompose this spec`, and run it after spec. Do NOT use to decide what to build (use spec), and do NOT use to write the code (use build).4license: MIT5---67# Plan89Turn a gated spec into milestones and atomic tasks: what ships in what order,10what blocks what, what fails first, and what is explicitly out of scope.1112Migrated from `.claude/commands/plan.md` under ADR-064, which makes skills the13single user-invocable surface.1415<!-- Copilot CLI: project instructions (CLAUDE.md) load via the plugin instructions tree; no include directive needed. -->16## Triggers1718`plan how to build this`, `break this into milestones`, `decompose this spec`,19`plan this work`2021## If you arrived here without a spec, run the front-gate first2223Planning a spec that was never gated manufactures work. If there is no `/spec`24output for this work (no requirement, no design, no testable acceptance25criteria), do not decompose it into milestones yet. Run `spec` first: it applies26the front gate (the six forcing questions, the `front-gate-before-pipeline`27pattern) and confirms a named blocked user, a documented status quo, and a28concrete observation before any downstream step runs. Return here once the spec29exists.3031Skip this only when the user explicitly asks to plan an ungated idea and accepts32that trade-off.3334Plan: the problem statement from the conversation (under Copilot CLI the skill tool takes no argument vector, so state it in your message)3536If `$ARGUMENTS` is empty, check for recent spec output in the conversation. If37none is found, ask what to plan rather than inferring it.3839## Process40411. Read the spec or issue.422. Map sub-problems to existing code. What already exists? Use Grep and Glob to43 verify rather than assuming.443. `agent_type: "project-toolkit:milestone-planner"`: You are a project planner. Break45 the spec into milestones with clear exit criteria. Each milestone is46 independently shippable. Sequence by dependencies. Flag parallel47 opportunities.484. `agent_type: "project-toolkit:task-decomposer"`: You are a work breakdown specialist.49 Decompose each milestone into atomic tasks. Each task is independently50 verifiable with a clear done definition. Size by complexity (S/M/L), not time.515. `skill: "execution-plans"` to persist the plan as a versioned artifact.526. `agent_type: "project-toolkit:analyst"`: You are a risk analyst. Run a pre-mortem on53 this plan. What fails first? What dependencies are fragile? What assumptions54 are untested?557. `agent_type: "project-toolkit:critic"`: You are a plan reviewer. Validate: is scope56 complete? Can tasks execute in the stated sequence? Are estimates credible?57 Is anything missing?5859## Evaluation Axes6061| Axis | Question |62|------|----------|63| Scope integrity | Nothing unnecessary, nothing missing |64| Dependency ordering | Can tasks execute in the stated sequence? |65| Risk coverage | Does every P0 risk have a mitigation? |66| Estimate confidence | Complexity-based sizing (S/M/L), never time-based |67| Reversibility | Which steps are hard to undo? |6869## Principles7071- **Programming by Intention.** Each task reads like an intent, not an72 implementation detail.73- **OODA loop.** Observe (read the spec), Orient (map to existing code), Decide74 (sequence tasks), Act (commit the plan). Faster loops win.75- **First principles.** Question the requirement, try to delete the step, then76 optimize, then speed up, then automate. Never automate something that should77 not exist.7879## Output8081| Section | Contents |82|---------|----------|83| Milestones | Numbered, each with exit criteria |84| Tasks per milestone | Atomic, with acceptance criteria and S/M/L sizing |85| Dependency graph | What blocks what, what can run in parallel |86| Risk register | Risk, likelihood, impact, mitigation |87| Deferred items | Explicitly out of scope for this plan |8889## Verification9091- [ ] A spec exists for this work, or the user accepted planning an ungated idea92- [ ] Sub-problems mapped against real code, verified with Grep or Glob93- [ ] Every milestone has exit criteria and is independently shippable94- [ ] Every task has a done definition and an S/M/L size, never a time estimate95- [ ] Plan persisted through `execution-plans`, not left in the conversation96- [ ] Pre-mortem run, and every P0 risk carries a mitigation97- [ ] Deferred items listed explicitly rather than left unstated9899## Anti-Patterns100101| Avoid | Why | Instead |102|-------|-----|---------|103| Planning an ungated idea | Produces a credible milestone list for work no user asked for | Run `spec` first, or record that the user accepted the trade |104| Time estimates | Anchor on a number nobody can hold, and rot on contact | Size by complexity, S/M/L |105| Mapping sub-problems from memory | Plans a rewrite of code that already exists | Grep and Glob before claiming something is missing |106| Milestones that ship only together | Removes the option to stop early, which is the point of a milestone | Split until each one is independently shippable |107| Silent scope cuts | The reader cannot tell a decision from an oversight | List them under Deferred items |108109## Extension Points110111- **New evaluation axis.** Add a row to the axes table and a matching112 Verification checkbox, so the axis is both stated and checked.113- **Different persistence.** Step 5 delegates to `execution-plans`. A project114 that tracks plans elsewhere swaps that one call, not the process.115- **Parallel decomposition.** Steps 3 and 4 run per milestone. For a large spec116 they can fan out per milestone rather than running once over all of them.
rjmurillo