roadmap

name	roadmap
description	Produces a ROADMAP.md (sequenced product bets with rationale + an explicit deferred set) from an attested product brief/strategy; primes the editorial + compliance gates. Use after the brief/PRD to sequence what to build when.

roadmap

The sequencing producer of the product domain — it turns an attested PRODUCT-BRIEF.md (the why/who) and, when present, the prioritization output (the ranked what) into a ROADMAP.md (the what, in what order, and why): sequenced bets, each with a rationale tied to the success metric, and an explicit "deferred / not now" set. The bar is that the sequence has a stated logic (dependency / value / risk / learning) and commitments are not overstated — horizons are confidence-tagged bets, not guaranteed dates. Verified by Attestation: a named owner attests the sequencing is sound and owns the call; a roadmap cannot be tested or measured at decision time. roadmap runs after strategy/prioritization, not instead of them.

What this does / does not do

Does: resolve the roadmap sub_target, read the attested brief (and prioritization if present), and write a ROADMAP.md of sequenced bets + per-bet rationale + dependencies + horizons + an explicit deferred set, grounded in the brief's success metric; write a roadmap receipt. Does not: decide the problem/persona/ success metric (that is product-brief), rank the backlog under a framework (that is prioritization), build the bets (the target domain's executor does), issue the gate verdict (the editorial/compliance gates do — this primes them), or promise dates as guarantees (horizons are bets with confidence).

When NOT to use

• There is no attested PRODUCT-BRIEF.md (and no strategy) yet — run product-brief first; a roadmap with no problem/success contract sequences bets toward nothing.
• The work is ranking the backlog under a framework (RICE / value-effort) — that is prioritization; a roadmap sequences the chosen bets, it does not score them.
• A current, committed ROADMAP.md still fits and nothing changed — editing it beats rewriting a commitment stakeholders are tracking.
• The user wants the roadmap judged/attested or the bets built — that is the gates + the Attestation owner + the build domain, not roadmap.

Reference Routing

Situation	Reference
The ROADMAP.md contract template	references/roadmap-template.md
Per-sub_target must-declares · overlay · vocabulary	../acceptance/sub-targets.md · ../acceptance/overlay.md · ../vocabulary.md
The upstream product contract	the attested PRODUCT-BRIEF.md (+ prioritization output if present)

Inputs

• The attested PRODUCT-BRIEF.md (problem, persona, success metric, non-goals) — the anchoring contract.
• The prioritization output / ranked backlog, when present — the bets to sequence.
• The product domain pack (../vocabulary.md, ../acceptance/) + state/intake.json.

How to do it

1. Anchor on the brief: load PRODUCT-BRIEF.md; if absent, stop and route to product-brief (ordering: strategy before the roadmap). Carry the success metric forward as the frame every bet is judged against.
2. Gather the bets: take the prioritization output if it exists; otherwise list the candidate bets from the brief/PRD. Each bet is a unit of value, not a task.
3. State the sequencing logic: declare why this order (dependency / value-first / risk-first / learning-first). The logic is stated once and applied — a reader can see why bet B follows bet A.
4. Sequence into horizons: place the bets on now / next / later (or an equivalent), each with its rationale tied to the success metric and its dependencies named. Horizons are confidence-tagged, not dated guarantees (the compliance gate).
5. Name the deferred set: an explicit "not now" list — what is out of this roadmap and why — so scope is bounded and the cut is honest.
6. Flag assumptions: any commitment/market claim that is not yet validated is carried as a flagged assumption (record_type: alert), never stated as a guarantee (the compliance gate).
7. Write ROADMAP.md from references/roadmap-template.md; name the attestation owner.

Gate (before marking complete)

• A PRODUCT-BRIEF.md exists and every bet's rationale traces to its success metric.
• The sequencing logic is stated and each bet's placement follows it (not arbitrary).
• Horizons are confidence-tagged bets, not guaranteed dates (no overstated commitments).
• An explicit deferred / not-now set is present.
• An attestation owner is named.
• Unvalidated commitments are flagged assumptions, not facts (the compliance gate).

A gate failure is fixed before lock, not waived — these mirror the editorial/compliance gates.

Output

• ROADMAP.md at the product root (or product/ROADMAP.md if that dir exists) — persistence: Spec-Anchored. Sequenced bets · per-bet rationale tied to the success metric · stated sequencing logic · dependencies · horizons (confidence-tagged) · explicit deferred set · attestation owner.
• receipt (<workspace>/receipts/roadmap-receipt-<ts>.json): base schema + sub_target, bets, sequencing_logic, horizons, deferred, roadmap_path, attested_by, gate_checks. persistence: Spec-Anchored.

Proactive Triggers

• A bet with no rationale / no tie to the success metric: give it one or cut it — an orphan bet is the roadmap-as-wishlist failure mode.
• A horizon stated as a hard date: reframe it as a confidence-tagged bet, or the compliance gate fails it as an overstated commitment.
• No deferred set: an all-in roadmap hides the cut — name what is not now and why.
• No PRODUCT-BRIEF.md: stop and run product-brief first; do not sequence bets toward an unstated goal.

Completion Criteria

Done when: a ROADMAP.md exists anchored to an attested brief, with sequenced bets each carrying a rationale tied to the success metric, a stated sequencing logic, confidence-tagged horizons, an explicit deferred set, and a named attestation owner; a roadmap receipt records the gate checks.

Not done if: there is no product brief; a bet lacks a rationale or a tie to the metric; the sequence has no stated logic; horizons are dated guarantees; the deferred set is missing; or commitments were stated as fact rather than flagged.

Next step: prioritization if the bets still need ranking under a framework; the target domain's executor builds each bet (verified by that domain's mode); the named owner attests the roadmap (Attestation).

Related Skills

• product-brief: the prerequisite — decides the problem/persona/success metric. roadmap sequences bets toward that attested metric. Always run product-brief first.
• prioritization: ranks the backlog under a framework (RICE / value-effort). roadmap sequences the chosen bets into horizons; prioritization scores, roadmap sequences. Complementary.
• prd: specifies a chosen bet into testable requirements. A roadmap bet becomes a PRD becomes a build.