用途
写作路线图（writing-roadmaps）用于把一个过大的想法转化为持久、带检查点的拆解文档：文档中的步骤可勾选，每步都小到可独立交付而不使应用处于损坏状态，且每步可追溯到工单。它适用于多周迁移、多版本发布、分阶段重写等任务；判断标准是中间状态是否必须可独立发布。若任务可放入一个规格加计划的周期，即使很大，也不应使用本技能，而应直接使用 brainstorming 到 writing-plans 的流程。
主要能力
- 区分路线图与“大计划”：路线图只在中间状态必须独立可发布时使用。
- 核心原则：任一步骤合并后应用仍能构建运行，无断裂的导入、半迁移的类型或悬空引用。排序时对每个已交付步骤前缀检查应用是否处于有效状态；通常先做增量变更（新模块、新表、双写），再做破坏性变更，并保证过渡期读路径可用。
- 步骤拆分：简单步骤作为路线图中的扁平检查项；自带架构决策的步骤放入 docs/<feature-slug>/steps/<step-slug>/ 独立文件夹。多数步骤应保持扁平，避免过度嵌套。
- 工单粒度：按步骤判断一个检查点一个工单，或把紧密耦合的检查点归入一个工单，并内联标注，避免静默假设。
- 依赖标注：仅在检查点确实需要另一检查点先完成时，在检查行末标注 (depends: <id>)，以便执行时可识别可并行项；不要为保险给每项都标依赖。
- 路线图保存后编写功能级 PRD，并在路线图 Context 段加入链接；路线图不早于该 PRD 定稿。
- 生成 docs/<feature-slug>/roadmap-state.json：每个检查点一条记录，初始 status 为 not-started，仅为立即建文件夹的检查点填写 stepFolder，并按依赖标签填充 dependsOn。
- 自审占位符、内部矛盾、步骤顺序的核心原则检查、歧义检查点及 PRD 链接，并就地修正。
- 经批准后询问用户如何继续，可提供“稍后保存”、并行起草工单（如 jira-writer 生成可粘贴文本）和批量计划起草（如 batch-plan-validate）等选项；不得自动启动。
使用方式
需进入原生计划模式，并与 brainstorming 相同的对话纪律：一次只问一个问题。流程为：探索项目上下文并查找既有路线图结构；逐个提出澄清问题（当前状态、目标状态、硬约束、发布是否有固定日期或只是逻辑检查点）；提出 2 至 3 种目标终态架构方案并给出推荐；按核心原则拆解步骤并决定扁平或嵌套、工单粒度与依赖；通过 ExitPlanMode 请求设计批准；写入磁盘并生成状态文件；自审；请用户复核路线图与 PRD；最后询问后续操作。默认保存位置为 docs/<feature-slug>/，提交到 git 并永久保留；项目自身约定（含个人覆盖文件）优先。
适用场景与限制
适用于需要有序中间状态且每个状态可独立发布的大型迁移、分版本上线和分阶段重写。不适用于一个规格加计划即可完成的任务。使用前必须具备 superpowers:brainstorming 的背景，并在写盘前阅读 roadmap-conventions；路线图本身不含代码，验证发生在各检查点自己的实现计划中。工单起草技能通常只生成供粘贴到 Jira 界面的文本，不通过 API 创建工单，真实工单 ID 需用户回填替换 TBD。迁移完成后不应删除路线图文件夹，它是迁移历史的持久记录。资料未提供具体安装命令、收费或价格信息。