track-roadmap
Track Roadmap
Overview
Maintain ROADMAP.md in the project root as a living, high-level feature plan, so decisions about what to build next are intentional, not reactive. Keep it to features (user-visible capabilities), not tasks — task-level work belongs in track-session. A healthy roadmap is 5-15 committed features readable in under 2 minutes.
Workflow
Every mode runs the same four beats — read the current state, propose a change, confirm with the user, write the file. Only the middle two differ:
| Mode | Command | Propose / confirm |
|---|---|---|
| Generate | /track-roadmap or generate |
Offer a codebase scan, ask 4 discovery questions, propose a feature list, write after the user confirms |
| Update | /track-roadmap update |
Ask what changed (add/remove/complete/reword), apply after confirmation |
| Audit | /track-roadmap audit |
Scan code to mark each feature Done/In-Progress/Not-Started/Unclear, review relevance with the user, update |
| Brainstorm | /track-roadmap brainstorm |
Divergent ideation — explore directions before committing; viable ideas land in "Future Ideas" as status:idea |
| Resume | /track-roadmap resume |
Check session state, present remaining features, user picks one, hand off to /track-session |
Update is the common case: adding an item, marking one done, or logging shipped work all land there. There is no save mode — treat /track-roadmap save as Update. When the user asks to work through the whole roadmap, Resume takes the open features in file order, one session per feature, and moves to the next without asking once each session closes. In Update and Audit, edit the affected items in place rather than regenerating the file — ids, ordering, and untouched text survive, and a whole-file rewrite costs more tokens for the same result. Generate is the only mode that writes the file from scratch.