用途
Implementation Plan 用于让一个已经界定好范围的 Feature 或子 Task 的内部执行策略变得可审查、可恢复，适用于当简短的方案预览不足以支撑执行时。它解决的是“如何安全地按顺序执行”这一问题，而非“做什么”或“如何设计”。
何时创建计划
当至少存在一个实质性触发条件时，才创建或更新计划：
- 用户希望在编码前审查执行策略；
- 实现跨越多个有意义的切片，且这些切片的稳定中间状态必须保持可恢复；
- 另一个会话或协作者需要比任务、规格和设计更持久的执行指导；
- 修改或部署顺序会影响正确性；
- 涉及数据、模式、协议或持久化格式的迁移；
- 必须跨版本或跨模块保持兼容性；
- 发布、功能开关、双运行或回退行为很重要；
- 所有权跨越多个模块或系统，且协调关系不明显；
- 验证必须按特定顺序进行以控制风险。
如果以上均不适用，则返回一份简要方案预览，涵盖变更面、执行顺序、实质性约束和验证接缝，然后停止。此时既不创建计划工件，也不创建“跳过计划”标记，并且除非用户当前请求单独指派了该确切的 Feature 或 Task，否则不开始实现。
独立工作
在制定计划前，先解析出一个确切的 Feature 或 Task。优先使用请求中给出的 ID、链接、路径或工件。否则读取 .waypoint/local.yaml，按 actor_id 过滤当前拥有的活跃 Feature；仅当任务分配记录在 Feature 所属工件或外部跟踪器中时，才使用已分配的任务。仅当恰好剩下一个候选时才继续；否则需要询问。绝不回退到其他参与者的工作、队列顺序、最近时间、Git 历史或当前分支。
随后阅读仓库说明、解析出的 Feature 或 Task、Feature 规格、相关技术设计、相关代码以及现有计划约定。
主要能力
- 识别需要持久化规划的实质性触发条件；
- 在合适时更新现有计划，否则在 Feature 或 Task 旁边提出最小的 Markdown 工件；
- 保留规格的范围和技术设计的选择，暴露矛盾而非添加需求或重新设计解决方案；
- 捕获执行策略、变更映射、有序切片、约束、回滚或遏制措施以及最终验证；
- 说明顺序为何重要，以及每个切片之后跟随的稳定状态是什么；
- 仅在计划工件存在后，才向 feature.md 或所属 task.md 添加计划 Reference，且只链接实际仓库原生文件名，不创建占位 Reference。
使用方式
该技能不要求固定的文档树、分支约定、工作流阶段、审查暂停或提交序列，也绝不规定每个切片一次提交。它负责单个 Feature 或 Task 内部的安全执行顺序，而非 Feature 分解、架构或行为。当 Feature 必须分配给多个执行者时，应使用 task-planning；不要将其 Task 图复制到本工件中。当存在未解决的审查关键性技术选择时，应保持顺序未定，并暴露对技术设计的需要。
仅当本地没有格式时，才使用 references/plan-template.md。可省略不相关的标题。
当另一个会话能够按顺序执行每个有意义的切片、识别其稳定状态、遏制或回滚实质性失败，并在无需从聊天中重建策略的情况下验证集成结果时，规划即告完成。
发布计划后即结束。批准实施计划仅授权计划工件本身，绝不授权代码更改或调用执行技能。
配套技能
- research：用于不熟悉的迁移约束；
- tdd：在有用时进行测试优先执行；
- code-review：进行独立风险审查；
- handoff：当另一位协作者将执行计划时使用。
这些配套技能来自 mattpocock/skills，可通过 npx skills add mattpocock/skills --skill <name> 安装。
适用场景与限制
适用于需要持久化执行策略的单个已界定 Feature 或 Task，尤其是涉及迁移、兼容性、发布回滚、跨模块协作或特定验证顺序的场景。不适用于 Feature 分解、架构设计或行为定义；不规定固定工作流、分支或提交约定；不授权代码更改。若没有实质性触发条件，则仅输出简要方案预览。