roadmap

---
name: roadmap
description: Builds or updates a product or delivery roadmap from a charter, PRD, backlog, or stakeholder priorities. Use whenever someone says "build a roadmap", "what's our roadmap", "plan the next quarter", "now/next/later", or wants initiatives sequenced into themes and time horizons with dependencies and confidence. Produces a Now/Next/Later or quarterly roadmap - not a sprint plan.
version: 3.0.0
argument-hint: <charter, PRD, backlog, or priority list>
allowed-tools: Read
---

## Input

$ARGUMENTS

---

# Roadmap

A roadmap communicates intent and sequence, not commitments to dates for distant work. Near-term is firm; far-term is directional. Be honest about both.

---

## Step 1 — Validate the Input

Before generating anything, check what was provided.

**If no input was provided at all**, ask:
> "What should the roadmap cover? Paste the charter, PRD, backlog, or initiative list. I'll also need: the business/user outcome you're building toward, a rough time horizon or launch target, and your 2–4 delivery themes (if known)."

**If input was provided**, identify its type:
- Charter, PRD, or backlog → proceed to Step 2.
- Risk register, meeting notes, or status report → say: *"This looks like a [risk scan / meeting notes / status update] rather than a charter or backlog. I'll infer the feature roadmap from it, but you should validate the initiative list before sharing this externally."* Then proceed, flagging all inferred items in Assumptions.
- Unclear or mixed → extract what you can and flag gaps explicitly.

---

## Step 2 — Pre-Generation Interview

Gather these inputs **before** producing any roadmap output. If any are missing from the provided material, ask for them as a single grouped question — do not ask one at a time.

| Input | Required? | If missing |
|---|---|---|
| Business / user outcome | Yes | Ask: "What does success look like for users or the business?" |
| Time horizon or launch target | Yes | Ask: "What's the rough target — a date, a quarter, or a sprint count?" |
| Delivery themes | Recommended | Ask: "What are your 2–4 delivery themes? (e.g. Data Integration, Auth, Analytics, UX)" — or offer to infer them |
| What's already shipped | No | Ask if it's a mid-project roadmap: "What's already live or completed?" |
| Active risks or blockers | No | Ask: "Do you have a risk scan? I'll flag blockers against roadmap items." |
| Capacity / constraints | No | Ask if a launch date is firm: "Any hard constraints — team size, fixed deadlines, external dependencies?" |
| Existing roadmap | No | If supplied, or one exists in `project-artefacts/`, treat the run as an update (see Step 4) |

Only ask for what's genuinely missing. If the input material answers a question, do not ask it again.

---

## Step 3 — Classify Initiatives

Before filling the roadmap buckets, filter the input:

- **Include:** Customer/user-facing capabilities, architectural foundations, and integrations that unlock features.
- **Exclude:** Sprint tasks, access requests, process steps (go/no-go gates, UAT runs), internal tooling, and risk mitigations. These belong in a sprint plan, release checklist, or risk register — not the roadmap.

If you had to exclude items that the user may expect to see, note them briefly under Out of Scope.

---

## Step 4 — Define Themes

If themes were not provided, infer 2–4 from the initiative list and state them explicitly at the top of the roadmap. Every initiative maps to exactly one theme. Themes make the roadmap scannable — without them it's just a list.

**Build vs update.** If the user supplies an existing roadmap, or one already exists in the active project's `project-artefacts/` folder, treat the run as an update. Open the output with a short **Changes since [date of prior roadmap]** section listing every item that moved bucket, was added, or was parked, each with a one-line reason. Then give the full refreshed roadmap.

**Capacity sanity check.** If team size or capacity is known and the Now bucket obviously exceeds it (e.g. eight parallel initiatives for four people), state the mismatch in one line and ask which items move to Next before finalising. No capacity arithmetic or per-person maths - that belongs to /sprint-planning.

---

## Output Template

### [Product / Project] Roadmap
**Date:** [Today] | **Horizon:** [e.g. Q3 2026 / next 3 sprints / target launch: DD MMM YYYY] | **Format:** Now / Next / Later | **Next review:** [date or trigger, e.g. post-Q2 close]

#### Changes since [date of prior roadmap]
*(Update runs only — omit when building from scratch.)*
- [Initiative] moved [Next → Now] — [one-line reason]
- [Initiative] added to [bucket] — [one-line reason]
- [Initiative] parked — [one-line reason]

#### Roadmap Goal
[One sentence: the user or business outcome this roadmap is sequenced to achieve. Not a delivery milestone — an outcome.]

#### Hard Commitments
*(Only dates stated in the input — never infer one. Omit this section if there are none.)*
| Commitment | Fixed date | Sits in |
|---|---|---|
| [e.g. compliance deadline] | [Stated date] | [Now/Next] |

#### Themes
[Theme 1] | [Theme 2] | [Theme 3] | [Theme 4]

---

#### Shipped (if applicable)
| Initiative | Theme | Completed |
|---|---|---|
| [Name] | [Theme] | [Sprint / date] |

---

#### Now — committed (in progress or next up)
*Scope and timing are defined and resourced.*

| Initiative | Theme | Why now | Confidence |
|---|---|---|---|
| [Name] | [Theme] | [Priority driver or dependency unblocked] | High |

---

#### Next — planned (sequenced, not yet committed)
*Understood and estimated, but not yet in a sprint. Timing shifts if Now slips.*

| Initiative | Theme | Depends on | Confidence |
|---|---|---|---|
| [Name] | [Theme] | [Now item it follows] | Medium |

---

#### Later — directional (under consideration)
*Intent is set; scope and timing are not. Includes post-launch phase and next major bets.*

| Initiative | Theme | What must be true first | Confidence |
|---|---|---|---|
| [Name] | [Theme] | [Condition or predecessor] | Low |

*(For a quarterly view, replace the three buckets with Q1 / Q2 / Q3 columns and keep the same fields. If the input carries any effort signal - backlog estimates, an SOW, stated gut-feel - add a rough **Size** column (S/M/L) to each bucket table. If it carries none, omit the column rather than invent values.)*

---

#### Dependencies & Sequencing
- [Initiative A] must precede [Initiative B] because [reason].
- [External dependency]: [what the team is waiting on and from whom].

#### Active Blockers (if a risk scan was provided or blockers are evident)
| Blocker | Affects | Status | Owner |
|---|---|---|---|
| [Name] | [Initiative] | [Active / Monitoring] | [Name or TBD] |

#### Out of Scope / Not Now
- [Item] — [reason: deferred, separate workstream, post-launch, etc.]

#### Assumptions
- [assumed] [Anything inferred about scope, capacity, or timing — especially if input was not a charter or PRD]

---

## Confidence Definitions

Apply these consistently across all three buckets:

| Level | Meaning |
|---|---|
| **High** | Scope defined, resourced, no unresolved blockers |
| **Medium** | Scope understood, not yet committed; timing may shift if upstream items slip |
| **Low** | Direction set; scope, timing, and resourcing are open |

Do not assign High confidence to any initiative with an active critical blocker, unresolved dependency, or undefined scope.

---

## After Generating

1. If open questions remain (launch date unknown, themes unconfirmed, blockers unowned), list them after the roadmap under **"Before this roadmap is firm"** — no more than 3, each with a named owner or ask.
2. Follow the **Saving Artefacts** rules in `.claude/CLAUDE.md`. Default local path: `clients/CLIENT/project-artefacts/YYYY-MM-DD-roadmap.md`.
3. If priorities shifted to produce this roadmap, suggest a `/decision-log` entry — on an update run, the Changes since section gives that entry its content.
4. Suggest `/risk-scan` if active blockers are present and no risk register exists yet.