roadmap

Output style (plain words, no dashes)

Write everything this skill produces (the roadmap it writes, and every message shown to the engineer) in plain, simple language. Keep the technical terms that carry real meaning, but explain each one in plain words so a busy reader understands it fast. Do not use dashes of any kind: no em dash, no en dash, and no hyphen used as punctuation. Use short sentences, commas, or parentheses instead. Clear beats clever.

What this skill does

Turns an idea into an ordered, coarse, living plan — and keeps that plan honest as the product ships. It is the entry point when the question is "what do I build, in what order, how heavy is each, and which ones need a decision first?" — not "how do I build this one thing?" (that's /architect and /develop).

A roadmap here is deliberately coarse and small. It has two parts: a slim At a glance table (# · Feature · Phase · Status) and the plan as clean feature sections grouped by phase (see roadmap-template.md). Each feature is a short section: a clean heading (### N. Name plus short tags only when they matter — needs a decision, an approach override, full weight), a one- or two-line intent, a single Done when: line (the acceptance-criteria seeds, the WHAT), and its checkbox steps.

A feature grows a defined shape as it moves through the pipeline. A not-yet-designed feature has one box (its entry command). When its ADR is captured, /architect fills in the built-ready shape: Design it (ADR) ticked, the ADR linked, a Build it: /develop <feature> box with 2 to 5 milestone sub-items rolled up from the ADR's ## Build plan, then Verify it: /verify <feature> and Test it: /test <feature>. The atomic build tasks never live here — they stay in the ADR's ## Build plan; the roadmap carries only the milestone rollup, so it stays coarse while every box is a command or a tracked milestone. Status lives in the table and beside the heading; the ADR and code pointers appear once they exist. /roadmap seeds the what; /architect designs the how and defines the milestones; /develop builds them; /verify and /test close the feature; /sync reconciles conventions after.

One command, inferred intent. You always run /roadmap [what] — never a subcommand. The skill reads the situation (is there a roadmap yet? did you name a single feature or none? is this a brownfield repo?) and does the right thing, the way /architect infers its mode. The three behaviors below are what it infers into, not modes you select: