create-roadmap ยท diff
git:20261004.00bb0c5 to git:20261007.b35fc4b
45 added, 27 removed. Audit A to A.
---
name: create-roadmap
description: Sequence initiatives across Now/Next/Later horizons, aligned to goals, so prioritization and needs-assessment have a strategic plan to follow.
---
# Create Roadmap
Defines the project's roadmap as a single context-level artifact: the initiatives the project is betting on, sequenced across horizons (Now / Next / Later) and tied to the objectives in `goals.md`.
- Other skills consult the roadmap when deciding what to work on next. Without a roadmap, prioritization is ad hoc: every issue is ranked in isolation, sequencing constraints are invisible, and there is no shared view of what is committed versus exploratory. A plan (`plan.md`) describes how to build one feature; the roadmap describes what to build and in what order across the whole project.
+ Other skills consult the roadmap when deciding what to work on next.
+ Without a roadmap, prioritization is ad hoc: every issue is ranked in isolation, sequencing constraints are invisible, and there is no shared view of what is committed versus exploratory.
+ A plan (`plan.md`) describes how to build one feature; the roadmap describes what to build and in what order across the whole project.
## Prerequisites
- Apply the shared SDLC conventions in `skills/sdlc/references/shared.md`.
- `.sdlc/context/project-overview.md` (must exist, for purpose and scope).
- - `.sdlc/context/goals.md` (strongly recommended; every initiative aligns to an objective and key result. If absent, note that alignment cannot be checked and flag it as an open question).
+ - `.sdlc/context/goals.md` (strongly recommended; every initiative aligns to an objective and key result.
+ If absent, note that alignment cannot be checked and flag it as an open question).
- `.sdlc/context/roadmap.md` (optional; if present, revise rather than replace, per Revision Mode below).
- Existing features under `.sdlc/features/` and the open issue backlog (optional, to group into initiatives and detect orphaned work).
## Steps
1. Read `.sdlc/context/project-overview.md` for purpose, scope, and stakeholders.
- 2. Read `.sdlc/context/goals.md` if present; these objectives anchor every initiative. Read `.sdlc/context/service-levels.md` if present, for reliability constraints that bound what can be committed to Now.
+ 2. Read `.sdlc/context/goals.md` if present; these objectives anchor every initiative.
+ Read `.sdlc/context/service-levels.md` if present, for reliability constraints that bound what can be committed to Now.
3. Inventory in-flight and planned work: scan `.sdlc/features/` and, if the backlog is in GitHub, list open issues with `ghx issue list --state open`.
- 4. Confirm the horizon model with the user if not already stated: prefer **Now / Next / Later** (the default) over date-based quarters, because horizons avoid the false precision of dates. Note the current period.
+ 4. Confirm the horizon model with the user if not already stated: prefer **Now / Next / Later** (the default) over date-based quarters, because horizons avoid the false precision of dates.
+ Note the current period.
5. Identify the recurring **themes** for this period, each tied to a `goals.md` objective.
- 6. Group work into **initiatives** (a coherent bet that moves a metric), not individual tickets. For each initiative capture the objective it advances, an owner, the hypothesis, scope, dependencies, confidence, and a success signal tied to a key result or KPI.
+ 6. Group work into **initiatives** (a coherent bet that moves a metric), not individual tickets.
+ For each initiative capture the objective it advances, an owner, the hypothesis, scope, dependencies, confidence, and a success signal tied to a key result or KPI.
7. Place each initiative in the right horizon:
- - **Now**: committed, in-flight, or starting this horizon. Fully scoped.
- - **Next**: planned for the following horizon. Roughly scoped.
+ - **Now**: committed, in-flight, or starting this horizon.
+ Fully scoped.
+ - **Next**: planned for the following horizon.
+ Roughly scoped.
- **Later**: exploratory, hypothesis-level, low confidence.
- 8. Map **sequencing and dependencies** between initiatives (hard, soft, external), and render a **Mermaid Gantt chart** in the Timeline section visualizing the initiatives across the horizons, anchored to the current period. Use the horizons as `section` groups, approximate spans (not hard dates), and `after <id>` to show dependencies.
+ 8. Map **sequencing and dependencies** between initiatives (hard, soft, external), and render a **Mermaid Gantt chart** in the Timeline section visualizing the initiatives across the horizons, anchored to the current period.
+ Use the horizons as `section` groups, approximate spans (not hard dates), and `after <id>` to show dependencies.
9. State **Not Now** explicitly: deferred work and the condition that would promote it.
10. Record **capacity and hard constraints** if known (team capacity, regulatory deadlines, frozen periods).
11. Set a **review cadence** and today's date.
- 12. Write the output to `.sdlc/context/roadmap.md`. If it already exists, revise per Revision Mode.
+ 12. Write the output to `.sdlc/context/roadmap.md`.
+ If it already exists, revise per Revision Mode.
## Output Format
- Use the template at `skills/sdlc/templates/context/roadmap.md`. Write the result to `.sdlc/context/roadmap.md`.
+ Use the template at `skills/sdlc/templates/context/roadmap.md`.
+ Write the result to `.sdlc/context/roadmap.md`.
## Revision Mode
If `.sdlc/context/review-roadmap.md` exists with `verdict: changes-requested`, revise the existing `.sdlc/context/roadmap.md` to address each finding rather than regenerating from scratch.
Preserve content the review did not challenge.
Make the minimum changes that resolve every finding.
## Roadmap Design Guidance
- - **Roadmap is strategy and sequence, not a calendar.** Prefer horizons over dates. A date the team cannot honor is worse than a horizon it can; dates turn the roadmap into a commitment device and penalize realistic re-planning.
- - **Every initiative aligns to a goal.** An initiative with no objective is a request with no goal. If it advances nothing in `goals.md`, either the goals are incomplete or the initiative does not belong.
- - **Group into initiatives, not tickets.** An initiative is a bet: a coherent body of work that moves a metric. Individual features and issues are grouped into it, not the other way around.
- - **State the bet and the success signal.** For each initiative, write the hypothesis ("if we do this, X improves because Y") and how you will know it worked (a key result or KPI). An initiative with no success signal cannot be evaluated.
- - **Confidence falls toward Later.** Now is high-confidence and scoped; Next is medium; Later is a low-confidence hypothesis with open questions. If a Later item is high-confidence, it probably belongs in Next or Now.
+ - **Roadmap is strategy and sequence, not a calendar.** Prefer horizons over dates.
+ A date the team cannot honor is worse than a horizon it can; dates turn the roadmap into a commitment device and penalize realistic re-planning.
+ - **Every initiative aligns to a goal.** An initiative with no objective is a request with no goal.
+ If it advances nothing in `goals.md`, either the goals are incomplete or the initiative does not belong.
+ - **Group into initiatives, not tickets.** An initiative is a bet: a coherent body of work that moves a metric.
+ Individual features and issues are grouped into it, not the other way around.
+ - **State the bet and the success signal.** For each initiative, write the hypothesis ("if we do this, X improves because Y") and how you will know it worked (a key result or KPI).
+ An initiative with no success signal cannot be evaluated.
+ - **Confidence falls toward Later.** Now is high-confidence and scoped; Next is medium; Later is a low-confidence hypothesis with open questions.
+ If a Later item is high-confidence, it probably belongs in Next or Now.
- **Not Now matters as much as Now.** Stating what is deliberately deferred, and the condition that would promote it, protects focus and makes re-planning deliberate instead of silent.
- - **State dependencies plainly.** Mark hard dependencies that block an initiative. Do not put a dependent item in Now while its dependency sits in Next.
- - **Capacity bounds Now.** The Now horizon should be achievable with known capacity. An overloaded Now is a plan that will miss.
+ - **State dependencies plainly.** Mark hard dependencies that block an initiative.
+ Do not put a dependent item in Now while its dependency sits in Next.
+ - **Capacity bounds Now.** The Now horizon should be achievable with known capacity.
+ An overloaded Now is a plan that will miss.
## Outcome
If `$OUTCOME_YAML` is set, emit `verdict: approved` there per `skills/sdlc/references/shared.md`.
If the artifact could not be produced, omit the file.
In the same emission, list the artifact under `artifacts:` (`.sdlc/context/roadmap.md`).
## Example Usage
- **Scenario 1: Growth-focused quarter with Now/Next/Later**
- Goals objective: "Make existing users more active."
+ **Scenario 1: Growth-focused quarter with Now/Next/Later** Goals objective: "Make existing users more active."
Now: "Onboarding redesign" (in-flight, FEAT-42, owner Growth, confidence High, success signal: activation rate 40% to 60%).
Next: "In-product re-engagement emails" (rough scope, confidence Medium).
Later: "AI-assisted digest" (hypothesis, confidence Low, open question: do users want a digest at all).
Not Now: "Mobile app" (waiting on activation to improve first; promote when activation reaches 55%).
- **Scenario 2: Quarter-based alternative**
- Team prefers calendar quarters. Horizon scheme set to 2026 Q3 / Q4 / 2027 Q1, with the same initiative fields. Now = Q3, fully scoped; Next = Q4, rough; Later = 2027 Q1, exploratory.
+ **Scenario 2: Quarter-based alternative** Team prefers calendar quarters.
+ Horizon scheme set to 2026 Q3 / Q4 / 2027 Q1, with the same initiative fields.
+ Now = Q3, fully scoped; Next = Q4, rough; Later = 2027 Q1, exploratory.
- **Scenario 3: Early product, no backlog yet**
- No features or issues exist yet.
- Define the Now horizon from the goals directly (2-3 initiatives), keep Next and Later minimal, and flag "no backlog to roll up" as an open question. Revisit once issues exist.
+ **Scenario 3: Early product, no backlog yet** No features or issues exist yet.
+ Define the Now horizon from the goals directly (2-3 initiatives), keep Next and Later minimal, and flag "no backlog to roll up" as an open question.
+ Revisit once issues exist.
- **Scenario 4: Orphaned in-flight work**
- FEAT-17 is in-flight but advances no initiative.
- Either add the initiative it belongs to (and the objective), or move FEAT-17 to Not Now. Surface this as a finding for `/review-roadmap` rather than silently dropping it.
+ **Scenario 4: Orphaned in-flight work** FEAT-17 is in-flight but advances no initiative.
+ Either add the initiative it belongs to (and the objective), or move FEAT-17 to Not Now.
+ Surface this as a finding for `/review-roadmap` rather than silently dropping it.
## Completion Checklist
Before handing off to review, confirm:
- [ ] Every initiative aligns to a `goals.md` objective and has a success signal tied to a key result or KPI
- [ ] Horizons used (Now/Next/Later) with confidence falling toward Later; Not Now stated with promotion conditions
- [ ] Mermaid Gantt chart included in the Timeline section, anchored to the current period, with horizons as sections and dependencies via `after <id>`
Self-check the draft against the [`review-roadmap` checklist](../review-roadmap/SKILL.md) and fix what you can, so review finds less to flag.
## Next Step
A review subagent is dispatched automatically to run `/review-roadmap` to audit the roadmap for alignment, sequencing, focus, horizon discipline, and currency before relying on it for prioritization.
Once approved, `prioritize-issues` and `create-needs-assessment` read `.sdlc/context/roadmap.md` directly when ranking work and checking strategic fit.
In a greenfield project with no backlog yet, the reviewed roadmap's first Now initiative can go straight to `/create-requirements` (as a `p`-prefixed pending feature) instead of through `/create-issue`; see the review's Next Step.
## Useful Commands Reference
| Command | Description |
|---|---|
| `ghx issue list --state open --limit 100` | List open issues to group into initiatives (cached) |