executing-plans

关键约束

在此技能执行期间，绝对不得调用 EnterPlanMode 或 ExitPlanMode。 此技能在普通模式下运行，执行磁盘上已有的计划。此处不需要计划模式，且很危险——它会限制实现所需的 Write/Edit 工具。

执行计划

概览

加载计划，严格审查，执行所有任务，并在完成后报告。

开始时宣布：“我正在使用执行计划技能来实现此计划。”

**注意：**Superpowers 在支持子 Agent 的情况下效果最佳。如果有子 Agent 可用，请使用 superpowers-extended-cc:subagent-driven-development，而不是此技能。

咨询计划作者

开始时执行一次：运行 ListAgents，检查编写计划的会话是否仍然活跃（交接提示通常会注明该会话）。如果活跃，记下其名称——执行过程中遇到任何歧义或设计问题时，先通过 SendMessage 询问该会话，再做猜测或打扰你的人工协作者。如果会话未列出，则向你的人工协作者提出歧义问题。

流程

步骤 0：加载持久化任务

1. 调用 TaskList 检查是否已有原生任务
2. 关键——定位任务文件： 先查找 <plan-path>.tasks.json；如果未找到，则使用 glob 查找匹配的 .tasks.json
3. 如果任务文件存在且原生任务列表为空：使用 TaskCreate 从 JSON 重新创建任务：
   • 包含 .tasks.json 中完整的 description（不只是主题）
   • 如果存在 metadata 字段（files、verifyCommand、acceptanceCriteria），一并包含
   • 使用 TaskUpdate 恢复 blockedBy
4. 如果已有原生任务：确认它们与计划一致，从第一个 pending/in_progress 任务继续
5. 如果两者都没有：继续执行步骤 1b，从计划中创建任务

每次任务状态变更后都要更新 .tasks.json。

步骤 0.5：验证工作区（Worktree 检查）

调用 using-git-worktrees 前，先检查是否已有 worktree：

1. 运行 git worktree list 查看所有现有 worktree
2. 如果计划分支已有 worktree：切换到该目录——不要创建新的 worktree
3. 如果当前位于 main/master 且没有 worktree：必需的子技能： 使用 superpowers-extended-cc:using-git-worktrees 创建一个

步骤 1：加载并审查计划

1. 读取计划文件
2. 严格审查——找出计划中任何疑问或顾虑
3. 如果有顾虑：开始前先告知你的人工协作者
4. 如果没有顾虑：继续设置任务

步骤 1b：根据计划创建任务（如有需要）

如果 TaskList 未返回任务，或任务与计划不符：

1. 解析计划文档，查找 ## Task N: 或 ### Task N: 标题
2. 对找到的每项任务，使用 TaskCreate，并提供：
   • subject：计划中的任务标题
   • description：完整的结构化内容（Goal、Files、Acceptance Criteria、Verify、Steps），末尾附上包含 files、verifyCommand、acceptanceCriteria 的 json:metadata 代码围栏
   • activeForm：表示正在进行的动作（例如，“正在实现 X”）
3. 关键——依赖关系： 对计划或 .tasks.json 中每个带有 blockedBy 的任务：
   • 调用 TaskUpdate，并提供 taskId 和 addBlockedBy: [阻塞任务 ID 列表]
   • 不要跳过此步骤——依赖关系对于正确的执行顺序至关重要
4. 调用 TaskList 并确认 blockedBy 关系显示正确（例如：“blocked by #1, #2”）

步骤 2：执行任务

对于每项任务：

1. 标记为 in_progress
2. 严格按照每个步骤执行（计划中的步骤都很小）
3. 使用元数据进行验证： 解析任务描述中的 json:metadata 代码块。运行 verifyCommand，并在标记完成前检查每项 acceptanceCriteria。
4. 用户设置的门槛不可跳过。 如果任务的元数据包含 "userGate": true，或其 tags 数组包含 "user-gate"，你必须：
   • 严格按照指定方式执行门槛——不得采用内联捷径、较省事的替代方案，也不得声称“我已经非正式地验证过了”。
   • 为 acceptanceCriteria 中的每一项收集具体输出（命令输出、实体状态、日志行、子 Agent 结果）。
   • 如果目前无法证明任何一项标准，则将任务保持为 in_progress，并向用户说明阻碍。不要将其关闭。
   • 不要重新评判计划已经确定的事项。 只有自计划制定以来发生了重大变化（分支或测试夹具不同、出现新阻碍，或计划假设不再成立），才能再次向用户提出计划中已确定的验证方式。若没有变化，就按既定方式执行。只有在真正不可逆的操作步骤（例如强制推送或线上合并）才暂停征求同意，并将请求表述为“确认此不可逆操作”，绝不能问“是否改用较简单的检查”。没有情况变化却重新询问已确定的方式，就是在规避门槛。
5. 标记为 completed
6. 同步 .tasks.json： 读取任务文件，将该任务的 "status" 更新为 "completed"（或在步骤 1 中更新为 "in_progress"），将 "lastUpdated" 设置为当前 ISO 时间戳，然后写回。这可确保持久化文件与原生任务状态同步，便于跨会话续接。

步骤 3：完成开发

所有任务完成并通过验证后：

• 宣布：“我正在使用 finishing-a-development-branch 技能来完成这项工作。”
• 必需的子技能： 使用 superpowers-extended-cc:finishing-a-development-branch
• 按照该技能验证测试、提供选项并执行选择

何时停止并寻求帮助

遇到以下情况时，立即停止执行：

• 遇到阻碍（缺少依赖项、测试失败、指令不明确）
• 计划存在关键缺陷，无法开始执行
• 不理解某项指令
• 验证反复失败

请寻求澄清，不要猜测。

何时重新审视前面的步骤

在以下情况下返回审查（步骤 1）：

• 合作方根据你的反馈更新了计划
• 基本方案需要重新考虑

不要强行绕过阻碍——停止并寻求帮助。

请记住

• 首先批判性地审查计划
• 严格按照计划步骤执行
• 不要跳过验证
• 计划要求使用技能时，请引用相应技能
• 遇到阻碍就停止，不要猜测
• 未经用户明确同意，绝不要在 main/master 分支上开始实现

集成

必需的工作流技能：

• superpowers-extended-cc:using-git-worktrees - 确保工作区隔离（创建新工作区或验证现有工作区）
• superpowers-extended-cc:writing-plans - 创建此技能要执行的计划
• superpowers-extended-cc:finishing-a-development-branch - 所有任务完成后结束开发