build-roadmap · git:20260820.d4a30da · 2026-08-20 · sha256 643fb925b7a7af44

build-roadmap git:20260820.d4a30daA

Immutable. This exact content is served forever at /api/v1/blob/643fb925b7a7af44.

---
name: build-roadmap
description: Make sure to use this skill whenever the user mentions building a product roadmap, creating a roadmap, defining phases, /build-roadmap, planning strategic phases, or wants to map out the future of a product at a high level above the backlog. Use it to create or update a product-roadmap.md file and optionally scaffold aligned backlog items for a given phase.
---

# Build Roadmap — Product Roadmap Builder

## Context: Document Hierarchy

The project operates on a two-tier planning hierarchy:

| Level | Document | Versioning | Location |
|---|---|---|---|
| **L2** | `product-roadmap.md` | Phases (Phase 1, 2, 3…) | `.devops/backlog/` |
| **L3** | `<feature>-backlog.md` | Backlog items per phase | `.devops/backlog/` |

A **roadmap phase** is the strategic container. **Backlog items** are the executable deliverables that fulfill a phase. One phase → many backlog items.

---

## 1. Discover Existing Roadmap

Before doing anything else, scan for an existing `product-roadmap.md` in the project's `.devops/backlog/` directory. If one exists, read it in full to understand current phase definitions, scope, and version number.

---

## 2. Determine Mode (question)

Use the `question` tool to confirm intent. Present the three options:

- **Create** — Build a new roadmap from scratch (no roadmap exists yet).
- **Update** — Add a new phase or edit an existing phase in the current roadmap.
- **Scaffold Backlog** — Break a specific roadmap phase down into concrete backlog items.

Wait for the response before proceeding.

---

## 3. Phase Interview (question — per phase)

For **Create** and **Update** modes, interview the user for each phase being written or changed. Ask these questions using `question` before writing any file.

### Q1 — Strategic Intent
Ask: *"What is the core strategic focus of this phase? (What problem does it solve, and for whom?)"*
This becomes the `> Focus:` line in the roadmap.

### Q2 — Key Features
Ask: *"What are the main user-facing features or capabilities this phase delivers?"*
List at least one option per feature already known from context (pre-populate from conversation if the user has described them). Accept free-text additions.
Set `multiple: true`.

### Q3 — Technical Goals
Ask: *"What are the key technical milestones, infrastructure changes, or architectural decisions this phase requires?"*
Pre-populate options from codebase context where possible.
Set `multiple: true`.

### Q4 — Phase Boundary
Ask: *"What signals that this phase is complete? (e.g., a deployed feature, a passing benchmark, a shipped integration)"*
This becomes an implicit success criterion. Store it in the phase as a `> Done when:` callout if the user provides it.

Repeat Q1–Q4 for each additional phase the user wants to define.

---

## 4. Write or Update the Roadmap

After the interview, write `.devops/backlog/product-roadmap.md` using the gathered answers.

### Phase template:
```markdown
## Phase N: [Phase Title]

> **Focus:** [One-sentence strategic intent from Q1.]
> **Done when:** [Success signal from Q4, if provided.]

### Key Features
- **[Feature Name]** — [User-facing description from Q2.]

### Technical Goals
- [Technical milestone from Q3.]
```

**Structural rules:**
- Separate phases with `---` horizontal rules.
- Include a metadata header table: Document Version, Project, Last Updated.
- Write features from the **user's perspective**.
- Write technical goals from the **engineering perspective**.
- Keep each phase self-contained.
- Increment `Document Version` on every meaningful update (1.0 → 1.1; major restructure → 2.0).

---

## 5. Scaffold Backlog Items (question — when Scaffold mode or on completion)

After writing the roadmap, use `question` to ask:
*"Would you like to scaffold backlog items for any of these phases now?"*
Present each phase as a selectable option. Set `multiple: true`.

For each selected phase, apply the **backlog** skill workflow per Key Feature:

1. Create a `<feature-slug>-backlog.md` (suffixed with `-backlog`) in `.devops/backlog/` using the Pass-the-Parcel backlog template.
2. Set the **State & Gates** section (bottom of the doc): `Status: BACKLOG`, `Active Persona: Planner`, `Gate A: OPEN`.
3. Populate Phase 1 (Expansion & Scoping) using the roadmap phase as source material.
4. Add a bullet entry to `.devops/backlog/backlog-index.md` linking to the new file.
5. Include a `Roadmap Phase: Phase N` metadata line in the backlog plan header.

---

## 6. Output Summary

After all files are written, report:
- Files created or modified (with clickable links).
- Current phase count and titles.
- Any backlog items scaffolded (count + links).
- Any gaps or open decisions surfaced during the interview.