用途
Plan 是 Beat 工作流中负责“规划执行”的技能，用途是把已经存在且完成的变更规格（spec artifacts）拆解成实现任务，生成并维护 tasks.md。它强调任务来自规格产物，而不是从一段描述凭空生成，因此明确要求至少有一个规格产物（gherkin 或 proposal）已经完成，否则应停止并先运行 /beat:design。
主要能力
- 选择变更：未指定名称时，从 beat/changes/ 目录（排除 archive/）推断；只有一个则直接使用，多个则让用户选择。
- 工作区隔离：在读写任何文件前调用 using-git-worktrees，如果已经在 worktree 中则检测并继续。
- 就绪检查：读取 status.yaml，确认 gherkin 为 done（Gherkin 驱动）或 gherkin 为 skipped 且 proposal 为 done（Proposal 驱动）。如果是 distill 变更则给出警告并需要确认；如果 tasks 已经是 done，则提示会重新生成 tasks.md。
- 读取产物：proposal.md、features/*.feature、design.md，以及 beat/config.yaml（用于输出语言、注入上下文和 rules.tasks 约束）。
- 复杂度评估与角色建议：根据 feature 与场景数量、design.md 中的组件或服务数量、是否存在 @e2e 场景、是否涉及外部依赖、数据库或 API 变更来判断；始终包含测试覆盖角色，其他角色（集成、架构、用户体验、安全、范围）按信号动态建议，用户可增删或自定义。
- 生成初始 tasks.md：调用 superpowers:writing-plans，把它作为任务生成来源，而不是自己手写；若该技能不可用，则用带提示注释的方式降级生成。
- 评审派发：1–2 个角色使用单个 Explore 智能体；3 个及以上时每个角色一个 Explore 智能体并行派发；每个智能体只拿到规格产物与初始 tasks.md，不给对话历史或会话上下文。
- 合并与更新：去重相同问题、冲突时取更保守的建议，必要时触发 ADR 门槛，并把评审结果直接写入 tasks.md（补充缺失任务、拆分过宽任务、补测试覆盖说明、按依赖关系调整顺序），而非单独输出报告。
- 提交与推进：提交 tasks.md、更新后的 status.yaml，以及本次运行写出的文档（包括 ADR），然后把阶段推进到 implement，并展示完成摘要。
使用方式
命令入口为 /beat:plan（Plan Complete 摘要中提示后续用 /beat:apply 开始实现）。运行时可选择指定变更名称；若省略则按上下文推断。前置技能包括 using-git-worktrees（首次写文件前，MUST）和 writing-plans（创建任务时，MUST）；若某个前置技能未安装，应跳过并继续，但不得因为自认为不必要而跳过。
任务拆分原则
- 单一关注点：一个任务只处理一个组件、服务或 API 端点。
- 约 200 行代码上限：每个任务新增约 200 行代码（不含测试）。
- 最多 2–3 个文件：每个任务最多触及 2–3 个源文件。
- 可独立验证：完成任务后即可运行测试，不依赖后续任务。
- “and then” 测试：任务描述若需要“然后”则拆分。
- 例外：项目初始化或脚手架类任务在保持单一关注点的前提下可超出文件数限制。
同时要求插入 Quality Principles 区块，规定测试应验证行为而非接线（主断言若是 toHaveBeenCalledWith 应改写为断言函数输出），以及单个新文件不超过约 300 行。
ADR 门槛
当评审以“承担关键作用的理由”拒绝某个替代方案，且未来评审者可能需要重新讨论时，必须运行三条件 ADR 门槛（是否难以逆转、脱离上下文是否令人意外、是否是真实权衡的结果）；若三条都成立，则询问用户是否记录为 ADR，用户可拒绝。
适用场景
把规格产物拆解为实现任务（tasks.md）、实施前的多角色执行计划评审、为已有变更重新生成或更新任务。
限制
不用于创建 proposal、gherkin 或 design.md 等规格产物；不用于探索想法或调查问题；不用于实现代码；不用于验证实现。所有判断都必须在读取规格产物之后进行，且不得在没有至少一个已完成规格产物的情况下继续。如果评审发现的是规格层面的问题（缺少场景、设计缺口），应向用户指出，而不是在任务中静默补偿。评审无法完成时须给出提示，说明 tasks.md 未经过评审，并建议重新运行 /beat:plan。