Files
Ken Yasue 3274aa41e2 Restructure milestone plan into phase files; /execute-milestones now requires a phase file
- /plan-milestones groups milestones into phases and generates one file per phase (phase1-milestones.md, phase2-milestones.md, ...) plus roadmap.md; milestone numbering stays global across phases
- /execute-milestones takes a required phase file argument (phase1-milestones.md | full path | phase1 | 1) and executes only that file's milestones one by one; with no argument it lists available phase files and stops; closes the phase in the roadmap when done
- milestone-planning skill/template rewritten around the Phase > Milestone > Feature hierarchy; milestone-execution skill scoped to one phase file per run
- /add-feature, AGENTS.md, README, and docs/milestones/README.md updated to phase-file references

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-02 12:18:32 +02:00

150 lines
6.7 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
description: Plan development milestones grouped into phases and generate one phase file (phaseN-milestones.md) with the milestones and features for each phase
agent: build
---
# Plan Milestones (Milestone Planning Phase)
This command breaks the product down into **phases**, each containing one or more **milestones**, and generates one file per phase under `docs/milestones/` (`phase1-milestones.md`, `phase2-milestones.md`, …). Each milestone lists the features it contains, sized so that each feature can be implemented with one `/add-feature` run. Each phase file is the execution unit for `/execute-milestones`.
**Planning preferences (optional)**: `$ARGUMENTS` (e.g. `/plan-milestones 2 phases, MVP in phase 1, auth first`)
## How to Run
```
opencode
> /plan-milestones
> /plan-milestones 2 phases, MVP first, payments last
```
## Position in the Workflow
```
/setup-project
/define-design
/generate-app web | flutter | winui3
/plan-milestones ← you are here
/execute-milestones phase1-milestones.md (one phase file at a time)
```
## Pre-Run Check
1. Confirm the persistent documents exist. If any of these are missing, stop and tell the user to run `/setup-project` first:
- `docs/product-requirements.md`
- `docs/functional-design.md`
- `docs/architecture.md`
2. Check whether the design files (`docs/design/ui-blueprint.json` etc.) exist. If they do not, warn the user that milestones will be planned without a design spec and suggest running `/define-design` first. Continue only if the user accepts.
3. Create the milestones directory if it does not exist:
```bash
mkdir -p docs/milestones
```
## Procedure
### Step 0: Read the Inputs
Read all of the following:
- `docs/product-requirements.md` (especially user stories and priorities)
- `docs/functional-design.md`
- `docs/architecture.md`
- `docs/design/ui-blueprint.json` and `docs/design/design-brief.md` (if present)
- `docs/ideas/*` (if present)
- The planning preferences provided in `$ARGUMENTS` (if any)
### Step 1: Gather Planning Preferences (ask the user once)
If `$ARGUMENTS` does not already answer these, ask the user about the following. If the user does not provide detailed preferences, **propose a sensible default** derived from the PRD priorities and confirm it before proceeding.
- **Number of phases** (default: 23) and **milestones per phase** (default: 13)
- **MVP definition** — what is the smallest product worth releasing? (phase 1 must deliver it)
- **Priorities** — features that must come first or last
- **Constraints** — deadlines, dependencies on external systems, team capacity
Collect the answers in a single round; do not pause again until generation is complete.
### Step 2: Load the Milestone Planning Skill
Follow the **milestone-planning** skill (loaded automatically) for the planning rules and the phase file template.
### Step 3: Build the Feature Inventory
Derive the complete list of features from the documents:
- Every user story / requirement in the PRD (with its priority)
- Every functional module in the functional design
- Every screen and user action in `ui-blueprint.json` (if present)
Size each feature so it can be implemented with **one `/add-feature` run**. Split anything larger; merge trivial fragments.
### Step 4: Group Features into Milestones, and Milestones into Phases
- Number milestones globally and consecutively across all phases (`01`, `02`, …).
- **Milestone 1 is the MVP core**: the smallest set of features that forms a coherent, end-to-end usable product.
- Later milestones build on earlier ones, ordered by priority and dependency (a feature never lands before something it depends on).
- **Phase 1 delivers the MVP**: it contains milestone 1 (plus any milestone needed to make the MVP releasable). Later phases group the remaining milestones by theme and priority — each phase should be a meaningful release on its own.
- Every feature belongs to **exactly one** milestone, and every milestone to **exactly one** phase. Explicitly park out-of-scope items in a final "Later / Icebox" section of the roadmap.
### Step 5: Create the Roadmap Overview
Create `docs/milestones/roadmap.md` containing:
- A table of all phases and their milestones: phase, file, milestone number, name, goal, feature count, status (`Not started` / `In progress` / `Completed`)
- The ordering rationale (why this sequence)
- A pointer to the current phase file and current milestone
- The "Later / Icebox" list of consciously deferred items
### Step 6: Create One File per Phase
For each phase, create `docs/milestones/phase[N]-milestones.md` (e.g. `phase1-milestones.md`, `phase2-milestones.md`) following the milestone-planning skill's template. Each phase file contains:
- The phase header: goal, status, and its ready-to-run command: `/execute-milestones phase[N]-milestones.md`
- One section per milestone in the phase (goal, scope, dependencies, definition of done)
- Under each milestone, its features — and each feature includes:
- A checkbox for status tracking (`- [ ]`)
- Description and user value
- Related PRD requirements / user stories
- Affected screens from `ui-blueprint.json` (if a design spec exists)
- Acceptance criteria
- The ready-to-run command: `/add-feature [feature name]`
### Step 7: Consistency Check
Re-read all generated files and confirm:
- Every P0/P1 requirement in the PRD is covered by a milestone (or explicitly parked in the icebox).
- Every feature appears in exactly one milestone, and every milestone in exactly one phase file.
- Milestone numbering is global and consecutive across the phase files.
- Dependencies are ordered correctly across milestones and phases.
- Phase 1 delivers a coherent, usable MVP on its own.
- Each feature name works as a `/add-feature` argument, and each phase file name works as an `/execute-milestones` argument.
Fix any inconsistencies found before finishing.
## Completion Criteria
- `docs/milestones/roadmap.md` exists
- One `phase[N]-milestones.md` per phase exists
- Every feature is assigned to exactly one milestone (in exactly one phase file) with acceptance criteria
Completion message:
```
"Milestone planning is complete!
Milestone documents created:
✅ docs/milestones/roadmap.md (overview + status)
✅ docs/milestones/phase1-milestones.md (MVP phase: milestones 01NN)
✅ docs/milestones/phase2-milestones.md (milestones NNNN)
Next steps:
- Review docs/milestones/ and adjust priorities if needed
- Run /execute-milestones phase1-milestones.md to implement phase 1 (a separate steering directory is created per milestone)
- Or go feature by feature: run /add-feature [first feature of milestone 1]
- Either way, each feature is marked complete in its phase file as it finishes
"
```