roadmap

Skill: roadmap

The decomposition layer between the idea and the per-feature pipeline. SDD builds one feature at a time under docs/features/<slug>/; roadmap answers the question that comes before any feature: how does the overall idea break into steps, what depends on what, and in which order — and in what parallel lanes — do we walk them. One living docs/roadmap.md, repo-level utility (like survey).

Three load-bearing properties, in priority order:

1. Steps — the idea decomposed into incremental, source-anchored slices (each row cites the brief/PRD section it comes from; size XS–XL per ../_shared/size-matrix.md).
2. Dependencies — an explicit graph: every edge has a one-line reason (data model, UI zone, auth precondition). No edge without a real blocker.
3. Execution path — waves that respect the graph: wave N only contains steps whose deps are in earlier waves, and steps inside one wave are conflict-safe in the codebase (different modules / UI zones — so they can run as parallel worktree lanes). Each wave row names the zone.

Not here: RICE or any scoring (order IS the prioritization), dates (a decomposition, not a promise), solution detail (lives in the feature's spec). Question phrasing → ../_shared/ask-style.md; prose follows artifact_language, table structure and the Status values stay English → ../_shared/artifact-language.md.

Owner

Whoever owns product direction (PM / lead / the solo maintainer).

Inputs

• The idea source: docs/idea-brief.md / a PRD / a vision note (ask which, if several).
• (Optional) docs/design-system.md, docs/architecture-map.md — zones for conflict-safety.
• (Optional) existing docs/features/*/ + existing docs/roadmap.md — current statuses.

Protocol

1. Locate sources. Find the idea source (docs/idea-brief.md first, then PRD candidates). None found → say so and STOP: a roadmap without a source is fiction. If docs/roadmap.md exists, this run updates it (statuses, new steps, re-waving) — never silently rebuilds.
2. Dispatch the decomposer. Spawn the roadmapper agent — subagent_type: "sdd:roadmapper" (fallback general-purpose, same prompt, per ../_shared/agent-roster.md) — naming the source paths, the size heuristics pointer, and (updates) the current roadmap + feature statuses. It returns the full draft: steps table · mermaid graph · waves (+ ≤5 open decomposition questions).
3. Review with the owner. Present the draft in prose (steps + waves; the mermaid goes to the file, never dumped raw to the terminal — same rule as design). Then one AskUserQuestion call: (a) steps to merge/split/drop (multiSelect over flagged candidates
   • the agent's open questions), (b) confirm the wave layout or name what must move. Apply.
4. Write. Fill ./templates/roadmap.md → docs/roadmap.md; set updated_at.
5. Structural self-check — per ../_shared/self-check.md, re-read from disk, verify 4 items: (1) every step row carries a source anchor; (2) every Depends on id resolves to an existing step id, and no step sits in a wave ≤ any of its dependencies' waves; (3) statuses ∈ {idea, spec'd, building, shipped} and every spec'd+ step links an existing docs/features/<slug>/ (test -d); (4) zero dates outside Shipped (\b20\d\d- scan) and updated_at = today. Fix + re-check ≤2 cycles; surface the rest.
6. Commit + handoff. Propose commit roadmap: <what changed>. Emit the stage-handoff block per ../_shared/handoff.md (utility variant) — What I did (incl. «self-check: 4/4 pass») + Review (docs/roadmap.md) + Run next: /sdd:specify <first unblocked step> (greenfield) or resume your backbone stage.