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. 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.