executing-plans

执行计划

概述

这项技能通过严谨的分批执行，将获批的计划文档转化为可运行的代码。每个步骤都通过 TDD 实现，在继续之前进行验证，并在检查点进行审查。它提供了从计划到生产代码的结构框架，并设有一致的质量关卡。

开始时声明：“我正在使用执行计划技能，按照 [计划路径] 实现已获批的计划。”

触发条件

• 存在已获批且可以开始实施的计划文档
• 使用计划引用调用 /execute 命令
• 继续执行尚未完成的计划
• 计划获批后从规划技能切换过来

---

阶段 1：阅读计划

目标： 编写代码前，全面理解计划。

1. 从头到尾阅读整个计划文档
2. 找出所有实施步骤并统计数量
3. 梳理步骤之间的依赖关系（必须先完成什么）
4. 记录任何模糊之处或待解决的问题
5. 继续之前，请用户确认已理解

计划理解检查清单

检查项	问题
目标是否清晰	能否用一句话说明计划的目标？
步骤数量	有多少个实施步骤？
依赖关系	哪些步骤依赖哪些步骤？
模糊之处	是否有不清晰或说明不足的步骤？
验证	每个步骤是否都有验证方法？

停止——未满足以下条件之前，请勿进入阶段 2：

• 能用一句话说明计划的目标
• 能列出所有实施步骤
• 已梳理依赖关系
• 已记录所有模糊之处，并与用户确认解决
• 用户已确认可以继续

---

阶段 2：创建任务批次

目标： 将计划拆分为规模小且可执行的任务批次。

批次大小决策表

任务复杂度	批次大小	示例
简单（配置、样板代码）	最多 5 项任务	ENV 变量、导入、类型定义
标准（功能、逻辑）	3 项任务	端点、服务、组件
复杂（集成、安全）	2 项任务	OAuth 流程、支付处理
关键（数据迁移、身份验证）	1 项任务	数据库迁移、凭据处理

任务要求（STIC）

标准	描述
Specific（具体）	清晰定义要实现的内容
Testable（可测试）	可通过自动化测试验证
Independent（独立）	尽可能减少与批次中其他任务的耦合
Compact（精简）	可在一次专注的工作时段内完成（2-5 分钟）

任务模板

Task: [concise description]
Plan Step: [reference to plan section]
Files to Create/Modify: [list of exact file paths]
Acceptance Criteria:
  - [specific, testable criterion 1]
  - [specific, testable criterion 2]
Dependencies: [other tasks that must be done first, or "none"]
Verification: [exact command to run]

停止——未满足以下条件之前，请勿进入阶段 3：

• 已为当前批次创建任务
• 每项任务都有明确的验收标准
• 已满足依赖关系（先前任务已完成）
• 任务已按依赖关系排序（优先处理独立任务）

---

阶段 3：执行任务

目标： 使用 TDD 一次执行一项任务。

单项任务工作流

1. ANNOUNCE which task you are starting
2. IMPLEMENT using test-driven-development skill:
   a. Write failing test (RED)
   b. Write minimal code to pass (GREEN)
   c. Refactor (REFACTOR)
   d. Repeat RED-GREEN-REFACTOR for each behavior
3. VERIFY using verification-before-completion skill:
   a. Run full test suite (not just new tests)
   b. Run lint, type-check, build as applicable
   c. Confirm all checks pass
4. MARK task as complete
5. PROCEED to next task

执行规则

规则	理由
一次处理一项任务	任务 1 验证通过前，不要开始任务 2
严格遵循 TDD	测试未失败前，不编写生产代码
不偏离计划	如果需要修改计划，请停止并与用户讨论
不跳过验证	每项任务都必须通过验证才能标记为完成
汇报进度	宣布每项任务的开始和完成

任务结果决策表

结果	操作	下一步
验证通过	标记为已完成	下一个任务
测试失败，原因显而易见且可修复	修复并重新验证	同一任务
测试失败，原因不明确	调用 systematic-debugging	修复后继续同一任务
计划步骤含糊不清	停止并询问用户	等待澄清
计划步骤不可行	报告阻碍	等待指示
发现意外依赖项	报告并调整顺序	调整批次

停止——在进入下一个任务之前，必须：

• 满足当前任务的验收标准
• 所有测试均通过（新增测试和现有测试）
• 已执行完成前验证
• 已将任务标记为完成

---

第 4 阶段：批次检查点

目标： 完成一个批次中的所有任务后，进行全面检查。

检查点步骤

1. 运行完整测试套件——所有测试，而不仅是当前批次的测试
2. 运行所有验证命令——lint、类型检查、构建、格式检查
3. 检查已实现的内容——总结已完成的任务及其结果
4. 根据计划评估进度——目前完成了多少？
5. 识别执行过程中出现的问题或风险
6. 向用户汇报并询问下一步指示

检查点报告模板

BATCH CHECKPOINT
================
Batch: [N] of [estimated total]
Tasks Completed: [list]

Verification Results:
  Tests:      [X passed, Y failed, Z skipped]
  Build:      [pass/fail]
  Lint:       [pass/fail, N warnings]
  Type-check: [pass/fail]

Progress: [N of M plan steps complete] ([percentage]%)

Issues Encountered:
  - [issue 1 and how it was resolved]

Risks or Concerns:
  - [risk 1]

Next Batch Preview:
  - [task 1]
  - [task 2]
  - [task 3]

Awaiting direction: Continue with next batch / Adjust plan / Other?

停止——在进入下一个批次之前，必须：

• 完整测试套件通过
• 所有验证命令均通过
• 已向用户提交检查点报告
• 用户已确认继续

---

第 5 阶段：继续、调整或完成

目标： 根据每个检查点后的用户指示采取行动。

指示决策表

用户指示	操作	下一阶段
“继续”	创建下一批任务	第 2 阶段
“调整计划”	讨论变更并更新计划文档	第 2 阶段（使用更新后的计划）
“到此为止”	总结进度并说明剩余工作	完成
“跳到 [step]”	确认依赖项已满足，然后跳转	第 2 阶段（从新步骤开始）
“返回并重做 [task]”	如有需要则回退，并修正后重新执行	第 3 阶段

未经用户明确批准，绝不进入下一个批次。

---

关键阻碍处理

遇到妨碍任务完成的问题时，不要绕过它。请停止并上报。

阻碍分类

类型	示例	操作
规范含糊不清	计划步骤可能有多种含义	列出不同解释并询问用户
缺少依赖项	所需的 API 或库不可用	报告问题并提供替代方案
存在矛盾	某个步骤与计划的其他部分冲突	指出冲突双方并询问用户
安全问题	计划的方案存在漏洞	报告风险并提出更安全的替代方案
可行性问题	无法按描述实现某个步骤	说明原因并提出替代方案

阻碍报告格式

CRITICAL BLOCKER
================
Task: [which task is blocked]
Blocker: [clear description of the problem]
Impact: [what cannot proceed until this is resolved]
Options:
  A. [option with tradeoffs]
  B. [option with tradeoffs]
  C. [skip this step and continue]

Awaiting direction before proceeding.

不要猜测用户的意图。不要未经批准就实施变通方案。不要默默跳过受阻任务。务必清楚列出选项及其利弊。**如果可行，**继续处理未受阻的任务（但要标明跳过的任务）。

---

子 Agent 调度选项

对于较大的计划，可以将单个任务分派给子 Agent 并行执行。

建议调度子 Agent 的情形

条件	门槛
计划中相互独立的任务	依赖关系较少，且任务达到 10 项或更多
任务规范质量	每个任务都有明确的验收标准
速度要求	用户已表示希望尽快完成
任务相互依赖程度	耦合度较低

满足这些条件时，建议剩余工作切换到 subagent-driven-development 技能。

---

反模式 / 常见错误

反模式	失败原因	正确做法
一次性实施整个计划	没有检查点和质量关卡	按批次执行，并设置检查点
因为“很简单”而跳过 TDD	Bug 会不断累积，出现回归问题	每项任务都使用 TDD，不例外
悄悄绕过阻碍	用户不知情，错误假设会被固化	停下并上报阻碍
批次结束后未经批准就继续	方向可能已经改变	始终设置检查点并等待
偏离计划	未经授权的更改、范围蔓延	实施更改前先讨论
只运行新增测试	无法发现回归问题	在检查点运行完整测试套件
未经验证就标记任务完成	进度失实，Bug 不断累积	必须进行验证
每批任务超过 5 项	难以审查，每批风险过高	保持批次规模较小
跳过检查点报告	用户无法了解进度	始终提供完整的检查点报告
未在批次边界提交	差异过大，难以回退	每批完成后提交

---

防止自我合理化

不要跳过任何验证步骤。未经用户批准，不要越过检查点。未经讨论，不要偏离已批准的计划。

如果你发现自己在想：

• “我知道接下来该做什么，可以跳过检查点……”——不行。报告情况并等待。
• “这项验证是多余的……”——照样运行。只接受新鲜证据。
• “计划差不多就行，我会边做边调整……”——先讨论调整方案。

---

子 Agent 调度机会

任务模式	调度对象	时机
没有共享状态的独立计划步骤	通过 Agent 工具并行调度子 Agent	依赖分析确认步骤之间没有阻碍时
审查已完成步骤的代码	code-reviewer Agent	每个主要计划步骤完成后
执行已完成功能的测试	后台 Bash 任务	测试可以独立于当前工作运行时

调度时遵循 dispatching-parallel-agents 技能协议。

---

集成点

技能	关系	时机
planning	上游——提供已批准的计划文档	计划是此技能的输入
test-driven-development	每项任务——每个代码任务都执行 TDD 循环	第 3 阶段执行期间
verification-before-completion	每项任务——验证关卡	将任何任务标记为完成之前
systematic-debugging	失败时——调查意外失败	任务遇到错误时
code-review	检查点——审查代码质量	第 4 阶段批次审查期间
subagent-driven-development	替代方案——并行执行路径	针对大型独立任务集
resilient-execution	失败时——使用替代方案重试	任务执行方式失效时
task-management	互补——提供任务跟踪	可配合使用

---

具体示例

示例：根据计划创建批次

计划：“使用 JWT 添加用户身份验证”

Batch 1 (3 tasks):
  Task 1: Write failing test for JWT token generation
    Files: tests/auth/jwt.test.ts
    Verification: npm test -- --grep "JWT generation" → FAIL (expected)

  Task 2: Implement JWT token generation
    Files: src/auth/jwt.ts
    Verification: npm test -- --grep "JWT generation" → PASS

  Task 3: Write failing test for auth middleware
    Files: tests/middleware/auth.test.ts
    Verification: npm test -- --grep "auth middleware" → FAIL (expected)

[CHECKPOINT after batch 1]

Batch 2 (3 tasks):
  Task 4: Implement auth middleware
  Task 5: Write failing test for login endpoint
  Task 6: Implement login endpoint

[CHECKPOINT after batch 2]

---

完成标准

满足以下条件时，计划执行才算完成：

1. 所有计划步骤都已作为任务实施
2. 所有任务都已通过验证
3. 完整测试套件通过
4. 已向用户提交最终检查点报告
5. 用户确认计划已完成

---

技能类型

严格——严格遵循此流程。批次、检查点和验证关卡都不可妥协。未经验证，任何任务都不算完成。未经用户批准，不得继续执行任何批次。