milestone-planning
Milestone Planning
Plan roadmap structure before task-local spec work. This skill owns Milestone -> optional Module -> Task docs governance, not task-local specs or implementation.
Composition
- Entry: reached from
doc-driven-spec-workflowafter scope is clear enough to plan delivery structure. - Owns: milestone boundaries, optional module grouping, roadmap-layer task breakdown, backlog/handoff governance, planning-stage
docs/tasks/documents. - Does not own: repository scaffold bootstrap, task-local
spec.md, task-localplan.md, readiness checks, implementation, verification, branch closing. - Handoff: stop at a planning review pause after roadmap/task docs change. On user continuation, default to committing those reviewed docs before handing off into
task-preparation. Leaving them uncommitted is an explicit user-approved exception with reason and affected files.
Core Rules
| Boundary | Rule |
|---|---|
| Milestone | Start from release goal, phase boundary, or acceptance boundary, not feature count. Use one milestone for the same delivery goal plus same completion definition and no meaningful stage boundary. Split when phase boundaries, exit criteria, release timing, or frozen history differ. |
| Module | Optional. Use only for multiple durable capability areas with distinct ownership, dependency graphs, risk profiles, release boundaries, or acceptance criteria. |
| Task | One independently reviewable implementation round delivering one coherent capability outcome, including required tests, migrations, docs/status updates, refactors, and verification. When the user needs roadmap-level tasks so a first implementation task can be chosen, prefer user-visible or operator-visible capability boundaries. Do not hide multiple independently selectable capabilities inside a vague core, MVP, foundation, or polish task. |
More from adol1111/doc-driven-spec-workflow
doc-driven-spec-workflow
Use when a docs-driven repository request is unclear about whether the next step is scaffold initialization, clarification, roadmap decomposition, or current-task execution.
36task-spec-execution
Use when older prompts, installed workflows, or tests still refer to task-spec-execution and need a compatibility redirect into the split task-preparation or task-execution-simple stages.
35docs-workflow-bootstrap
Use when initializing, bootstrapping, creating, or scaffolding the minimum docs-driven workflow layout for a repository before roadmap planning, specs, or implementation tasks exist.
33task-execution-simple
Use when task-local spec or plan work is complete and a concrete docs/tasks task should be implemented through the repository's simple direct execution path.
11task-preparation
Use when a docs-driven repository has a selected or selectable concrete docs/tasks task and needs task-local spec or plan governance before code execution.
10doc-driven:task-spec-execution
Use when a docs-driven repository has a selected or selectable concrete docs/tasks task and needs task-local spec or implementation governance before code changes.
1