用途：维护项目根目录的 ROADMAP.md，作为高层功能计划，让“下一步做什么”成为有意识的决策。只记录功能（用户可见能力），不记录任务级工作，任务级内容归 track-session。健康路线图为 5-15 个已承诺功能，2 分钟内可读完。
主要能力与模式：所有模式都遵循读取现状、提出变更、与用户确认、写入文件四步。Generate（/track-roadmap 或 generate）提供代码库扫描、4 个发现性问题、提出功能列表，确认后写入。Update（/track-roadmap update）询问变更（增/删/完成/改写），确认后应用，是常见场景；没有 save 模式，save 视为 Update。Audit（/track-roadmap audit）扫描代码将每个功能标记为 Done/In-Progress/Not-Started/Unclear，与用户复核相关性后更新。Brainstorm（/track-roadmap brainstorm）发散构思，可行想法以 status:idea 进入 Future Ideas。Resume（/track-roadmap resume）检查会话状态、呈现剩余功能、用户选择后交给 /track-session。Update 与 Audit 应就地编辑受影响条目，而非重写整个文件，以保留 id、顺序和未改动文本。
文件格式：frontmatter 需含 schema、project、description、last_updated。每个条目需有 id 和 status；id 为 r_ 加 2-10 个 [a-z0-9_] 字符且永久不变，新 id 默认 5 个随机字符，写入前需 grep 查重。状态有 idea/planned/in-progress/done，以及 deferred、dropped/skipped/rejected/cancelled（后四者进入看板 Closed 列）。可选元数据 started:、completed:（YYYY-MM-DD）和 depends:。每个分类标题下一行写 <!-- category:slug -->。每个功能一行：加粗标题加 1-2 句描述。备注用 > 行写在条目下，承载研究发现、开放问题和被拒方案，约五行以内，超出则移到 docs/ 下并留链接。
规则与限制：用户主导路线图，需提出变更并等待确认，不可自行增删改写。只写高层功能，如“用户认证”而非“加 bcrypt 哈希密码”。ROADMAP.md 是唯一事实来源。已完成功能应移动到 Completed 区并加 completed: 日期，而非删除。重命名功能保留 id；合并保留存活 id，拆分时一半保留原 id、另一半生成新 id。roadmap_ref 只能有一个 id。Resume 会覆盖活动会话计划，若有未完成任务应先询问。审计证据不明确记为 Unclear，不猜测。30 项以上路线图应审计，把推测性条目移入 Future Ideas，删除不再合适的条目。路线图漂移属正常，应运行 audit 调和。
适用场景：需要维护项目功能路线图、记录已完成工作、审计进度或进行功能构思的软件开发项目。
限制：资料未提供具体安装命令、收费、价格、平台支持或效果数据。