executing-plans

执行计划

概述

加载计划、严格审查计划、分批执行并设置检查点、验证，然后交接。

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

尽可能优先采用由子 Agent 驱动的开发方式。 每项任务使用全新上下文并分阶段审查（规范、质量，以及安全相关任务的安全性），其效果明显优于直接执行。子 Agent 不可用、任务耦合过紧而难以拆分，或计划足够小、调度开销超过收益时，使用此技能。

铁律

NO EXECUTION WITHOUT A CRITICAL REVIEW OF THE PLAN FIRST

忠实执行有缺陷的计划，只会高效地产生有缺陷的实现。审查不是走过场——它是让糟糕计划只浪费几分钟、而非几小时的唯一机会。

已经开始执行却没有审查？立即停下并审查。现在在任务 2 时纠正，远比到任务 9 时便宜。

检查清单

为每项创建一个待办事项：

1. 验证工作区——使用隔离分支或工作树，确保基线干净
2. 加载并严格审查计划——开始前提出疑虑
3. 建立待办列表——每项任务对应一个条目
4. 分批执行——每次执行 2-3 项任务，然后设置检查点
5. 在每个检查点进行验证——运行实际命令
6. 最终验证——运行完整测试套件并检查计划覆盖情况
7. 交接——执行 finishing-a-development-branch

步骤 1：验证工作区

**必需的子技能：**开始前使用 using-git-worktrees。

未经明确许可，绝不要在 main/master 上开始实施。 先检查：

git branch --show-current
git status --porcelain    # must be clean before starting

工作区不干净，就无法在审查时区分你的更改和之前已有的更改。

步骤 2：严格审查计划

编写任何代码前，先通读整个计划。检查以下内容：

检查项	警示信号
占位内容	“TBD”“添加错误处理”“为上述内容编写测试”“与任务 3 类似”
类型一致性	任务 3 中是 clearLayers()，任务 7 中却是 clearFullLayers()
未定义的引用	某任务使用了没有任何任务定义的类型或函数
文件路径	路径不存在，且没有任务会创建该路径
验证	步骤未提供命令，或命令未说明预期输出
顺序	任务 5 依赖任务 8 才会构建的内容
范围	多个互不相关的子系统本应拆分成不同计划

**如果发现问题：**开始前一次性提出所有问题。不要悄悄修改计划，也不要在整个会话中逐个发现问题。

Reviewed the plan. Three issues before I start:

1. Task 4 calls `validateToken()` — no task defines it. Task 2 defines
   `verifyToken()`. Same function, or a gap?
2. Task 6 modifies `src/auth/session.ts:40-58`; that file is 22 lines.
   The line range is stale.
3. Tasks 8-11 cover the notifications subsystem, independent of auth.
   Split into a second plan?

步骤 3：分批执行

每次处理 2-3 项任务，然后设置检查点。分批执行既能保持进度，也能避免错误在九项任务中不断累积。

对每项任务：

1. 标记为 in_progress
2. 严格遵循步骤——计划的细致程度是经过刻意安排的
3. 运行步骤指定的验证并查看输出
4. 按计划要求提交
5. 标记为 completed

严格遵循计划步骤意味着，计划要求先编写失败测试时，就先编写，并运行测试确认失败。跳过“运行并观察失败”这一步，是计划执行悄然走样的最常见原因——参见 test-driven-development。

不要合并提交。 每项任务单独提交，才能让检查点便于审查，也能在出错时撤销。

步骤 4：检查点

每批完成后，汇报并暂停：

Tasks 1-3 complete.

- Task 1: token verification — 6 tests, all passing
- Task 2: session store — 4 tests, all passing
- Task 3: middleware wiring — 3 tests, all passing

Full suite: 47 passed, 0 failed.
Deviation: Task 2 specified a Map; used a WeakMap so sessions are
garbage-collected with their request objects. Behavior is identical.

Continue with tasks 4-6?

检查点应报告证据，而非信心——提供实际命令输出，而不是“应该能正常运行”。参见 verifying-before-completion。

也可以在每个检查点安排审查者——参见 requesting-code-review。如果该批次涉及安全相关代码，则安排 security-reviewer，并将严重或高危问题视为阻断项。

第 5 步：处理偏差

计划总会遇到实际情况。请判断接下来该怎么做：

情况	处理方式
步骤中的代码有拼写错误或明显的小问题	修复，并在检查点说明
步骤的方法可行，但存在更好的方法	按计划执行，并说明替代方案。不要擅自改进。
步骤按原样无法完成	停下。说明原因，提出替代方案并等待回复。
步骤对代码库的假设有误	停下。应更新计划，而不是绕开问题。
任务后来发现没有必要	停下并询问，不要悄悄跳过
发现无关的 Bug	记录下来，不要修复。执行时扩大范围会使计划失去意义。

绝不要悄悄偏离计划。 无论偏差多小，都要在下一个检查点报告。

何时停止并询问

出现以下情况时，请立即停止：

• 出现阻碍因素，例如缺少依赖项、环境问题或基线测试失败
• 指令确实不清楚
• 同一项验证连续失败两次
• 发现计划对代码库的假设有误
• 实施某个步骤需要重构计划未预料到的代码

询问，不要猜测。 在任务 3 中猜错，会影响之后的每一项任务。

如果验证反复失败： 请停止并使用 systematic-debugging。不要接连尝试修复——连续三次修复失败，说明问题并不在你认为的地方。

第 6 步：最终验证

交付之前，必需子技能： 使用 verifying-before-completion。

• 已完成计划中的每项任务
• 在本条消息中运行了完整测试套件——已查看输出，失败数为 0
• Linter 和构建均成功运行
• 重新审阅计划目标：实现是否达成目标？
• 已向用户报告所有偏差
• git status 显示工作区干净；所有更改均已提交

计划覆盖检查： 逐项核对计划要求，并指出实现这些要求的代码。测试套件通过只能证明测试通过，不能证明计划已全部完成。

第 7 步：交接

必需子技能： 使用 finishing-a-development-branch 验证测试、说明合并/PR/保留/丢弃选项并完成清理。

常见错误

审阅前就开始执行。 计划中的缺陷会被原样实现。

跳过“观察测试失败”。 计划要求运行测试并确认其失败。跳过这一步，就无法知道测试是否真的覆盖了问题。

悄悄偏离计划。 实现逐渐偏离计划，直到审查时才被发现。

最后一次性提交所有更改。 没有可回滚的检查点，差异也难以审查。

硬闯阻碍因素。 在一个本来就错了的步骤上，接连进行三次修复。

“既然顺手就改一下”。 执行期间进行无关重构，会使差异难以审查，也让偏差无从察觉。

凭记忆声称已完成。 “之前所有测试都通过了”不算验证。现在就运行测试。

集成

必需工作流技能：

• using-git-worktrees — 必需：开始前使用隔离工作区
• writing-plans — 创建此技能要执行的计划
• test-driven-development — 正确执行测试优先步骤的方法
• verifying-before-completion — 必需：声称完成之前使用
• finishing-a-development-branch — 必需：所有任务完成后结束开发

遇到问题时：

• systematic-debugging — 验证反复失败时使用
• receiving-code-review — 根据检查点审查反馈采取行动

替代方案：

• subagent-driven-development — 有子 Agent 时优先使用