用途
将清晰的方向转化为路线图结构。此技能负责文档治理，而非任务内设计。它用于规划方向已足够清晰、可以分解时，以及里程碑边界、模块分组或任务拆分仍需决策时，或用户需要先得到路线图级任务、之后才能开始任务级 spec.md 工作时。当目标、约束或“现在与以后”边界仍不清楚，或当前任务已从已确认路线图状态中选定，或当前工作是任务级 spec、计划、实现或分支收尾时，不应使用。
先读文档
- docs/tasks/index.md
- docs/tasks/planning-inbox.md
- docs/tasks/backlog.md
- docs/tasks/ 下相关的里程碑、模块与任务文档
- 当前用户提示
权责范围
该技能拥有：里程碑边界、可选模块边界、路线图级任务分解、路线图已确认状态及其后果、planning-inbox、backlog 与 Handoff Notes 治理、规划评审暂停与规划交接上下文。
不负责：任务级 spec.md、任务级 plan.md、执行隔离或实现、就绪检查、验证流程或分支收尾、伪装成路线图结构的实现级排序。
入口检查
- 如果规划方向仍未解决，退回 planning-clarification。
- 如果 Open Milestones 为空，先检查 planning-inbox.md、backlog.md 与提示证据，再分解。
- 如果没有证据指明具体短期目标或路线图错位，提出规划模式问题。
- 如果用户要求在 Roadmap confirmed 内开始工作：不可以，保持分解为临时状态，直到里程碑结构被明确确认。
- 如果用户进入后续里程碑，先解决前一个里程碑的收尾。
- 确认里程碑或将 Roadmap confirmed 从 no 改为 yes 时，检查 backlog.md 中符合该里程碑目标的延期任务。
默认流程
- 确认当前问题是路线图结构而非规划歧义。
- 依据交付目标、阶段边界或退出标准选择里程碑边界，而非依据功能数量。
- 仅当存在多个持久能力领域、且各自拥有不同的所有权、风险、依赖、发布或验收边界时，才添加模块。
- 按连贯的能力成果拆分路线图任务。每个任务应可独立评审、独立交接、独立完成。
- 确认里程碑时，将匹配的 backlog.md 任务提升进里程碑，或明确保持延期。
- 在路线图文档中记录里程碑、模块与任务边界的理由。
- 创建或重写路线图文档后，停在规划评审暂停点。
边界规则
- 里程碑边界关乎发布或阶段意义，不是为了让里程碑大小视觉上均衡。
- 不要因为原始请求宽泛就保留一个巨大里程碑。存在真实的阶段、退出或发布边界时就拆分。
- 模块是可选的。不要为一个能力领域创建单一的兜底模块。
- 不要用微小的一次性模块作为隔离任务的桶。
- 任务边界必须停留在实现设计之上。路线图任务说明落地什么能力，而非代码变更如何排序。
- 不要在 core、foundation、mvp 或 polish 等模糊任务名中隐藏多个可选能力。
- 不要用文件、端点、测试、迁移或重构切片命名路线图任务。
- 除非该治理工作本身就是用户可见的交付成果，否则不要把实现、测试、文档、验证或评审跟进拆成独立的路线图任务。
- 任务顺序属于相关的有序列表，而非数字目录前缀。
- 活跃里程碑期间新发现的未来工作，默认先进入该里程碑的 Handoff Notes，而不是任务级 plan.md。
- planning-inbox.md 存储目标与候选里程碑方向，而非具体任务。
- backlog.md 存储具体的延期任务，而非宽泛目标。
目标定义
目标是期望的未来状态、产品成果、机会或阶段方向。它说明在决定路线图形状之前，什么应当成真以及为何重要。目标通常应宽于一个实现任务，但不必巨大。它之后可能成为一个里程碑、多个里程碑，或在澄清后被丢弃。目标不是代码变更、端点、迁移、测试套件、重构切片或已可选定的实现成果。
当某项可以在未先决定阶段方向的情况下，直接给出带成果、粗略范围、验收清单与成功信号的具体 task.md 时，它就被视为任务形态。
如果提升一个 planning inbox 项会自然产生一个里程碑与一个同名单任务、且无额外边界决策，则把该项重新归类为 backlog 任务或当前里程碑任务，除非该项本身是真实的发布、迁移或阶段边界。
用成果或阶段命名目标，而不是用可能的实现机制。
示例：
- 好的 planning-inbox 目标：API contract stability，目标文本如“让后端响应足够可预测，使前端与外部客户端能一致处理成功、校验失败与业务失败。”
- 任务形态而非目标：Unify API business error model and response envelope。这已经命名了具体实现成果，很可能成为一个 task.md。
- 对该任务形态项的更好归类：把 Unify API business error model and response envelope 放入 backlog.md 或当前里程碑，并可选择归入 API contract stability 这样的目标下。
- 由该目标得出的好里程碑：API Contract Stabilization，退出标准围绕已记录的响应语义、客户端安全的兼容性与契约测试。
- 该里程碑下的好任务：Define response envelope and business error semantics、Adapt callers to the unified response contract、Add API contract coverage and migration notes。
- 差的提升形态：planning inbox 目标 Unify API business error model and response envelope -> 里程碑 Unify API business error model and response envelope -> 一个任务 Unify API business error model and response envelope。这在各层重复标签，而非做出路线图决策。
Handoff Notes 路由
- 在当前里程碑 index.md 中记录 Handoff Notes，而非任务级 plan.md。
- 仅当某项必须完成才能满足当前里程碑退出标准时，才将其保留在当前里程碑。
- 当某项明显是里程碑形态的未来工作、但不需要关闭当前里程碑时，移到后续里程碑。
- 当某项是未分配给里程碑的具体任务形态跟进时，移到 docs/tasks/backlog.md。
- 当某项是尚未准备好成为里程碑的目标、阶段、机会或方向时，移到 docs/tasks/planning-inbox.md。
- 仅当某项被明确丢弃或不再值得追踪时移除。
- 如果用户明确决定该项优先级足够高、可打断当前路径，则重新规划它，而不是仅作为 handoff 跟进。
任务状态生命周期
- 新路线图任务以 planned 开始。
- 当任务仅被分解、排序或作为未来候选选定，保持在 planned。
- 仅当任务级准备或实现工作真正开始时，才移到 in_progress。
- 仅当所选任务因外部依赖、未解决决策、失败前置条件或明确停止条件而当前无法推进时，使用 blocked。
- 不要仅凭路线图规划就标记任务 completed；完成属于实现、验证、必需文档/状态更新与收尾成果解决后的执行环节。
- 始终保持任务 Status 为单选。
Planning Inbox
planning-inbox.md 是目标层。它存储未来产品目标、机会、候选阶段与长期路线图方向。planning inbox 目标应描述要规划的未来状态或阶段，而非将实现它的确切任务。不要把具体任务形态工作存入 planning-inbox.md；除非属于某个开放里程碑，否则移到 backlog.md。当目标准备好成为开放里程碑或需要规划澄清时，从 planning-inbox.md 取出该项。当 planning inbox 目标成为里程碑时，检查 backlog.md 中匹配该目标的延期任务。
Backlog
backlog.md 是任务层。它存储值得保留但未分配给开放里程碑的具体延期任务。backlog 项应为任务形态：有成果、粗略范围、来源，以及可能的目标或里程碑归属。当里程碑规划、里程碑确认或 Roadmap confirmed 从 no 改为 yes 将其提升为活跃里程碑考量时，从 backlog.md 取出该项。backlog 项在被提升为里程碑任务、明确丢弃或被不同任务取代后移除。
如果受阻
当没有证据指明具体短期目标或错位时，提出规划模式问题： “你本次迭代是否已有具体短期目标，还是我们需要先重新对齐路线图的下一阶段？” 当路线图结构仍取决于未解决的目标或边界歧义时，退回 planning-clarification。当未解决项阻碍里程碑确认、里程碑关闭或跨里程碑移动时，直接停下并询问。
评审与跟进
路线图文档变更后，停在规划评审暂停点。在评审暂停后，明确的继续推进语言视为允许例行跟进。评审后的默认例行跟进是：提交已评审的规划文档（除非用户明确要求保持未提交），然后报告交接上下文并走向下一个适用阶段。不要把规划评审批准视为跳过未解决硬性门禁的许可。
硬性门禁
- 当较早的里程碑仍显示开放且未解决时，不要进入后续里程碑。
- 当路线图结构仍明确未确认时，不要把 continue 视为里程碑确认。
- 当任何 Handoff Notes 项仍未解决时，不要关闭里程碑。
- 不要向已完成里程碑添加跟进工作。改为创建新的开放里程碑、backlog 任务或 planning inbox 目标。
输出
- 推荐里程碑结构
- 为何是一个还是多个里程碑
- 是否需要模块
- 每个里程碑或模块的任务列表
- 不明显时的交付顺序
- 假设或开放问题
停止点
规划评审暂停，或就路线图歧义、确认或关闭的直接阻塞问题。
交接
Decided、Undecided、Next skill、Stop point。
参考
使用 references/roadmap-template.md 作为路线图文档形态。