executing-plans

name	executing-plans
description	当你有一份书面实现计划需要在单独的会话中执行，并设有审查检查点时使用

执行计划

概述

加载计划，批判性审查，执行所有任务，完成后报告。

开始时宣布： "我正在使用 executing-plans 技能来实现此计划。"

注意： 如果任务量大（3+ 独立任务）且子代理可用，使用 subagent-driven-development 技能效果更好——每个任务在独立上下文中执行，质量更高。

流程

步骤 1：加载并审查计划

1. 读取计划文件
2. 批判性审查——识别计划中的任何问题或疑虑
3. 如果有疑虑：在开始之前向你的人类伙伴提出
4. 如果没有疑虑：创建 TodoWrite 并继续

审查时重点检查：

• 步骤之间是否有依赖遗漏？（A 依赖 B，但 B 排在 A 之后）
• 验证条件是否明确？（"确认可用"不算，"运行 npm test 全部通过"才算）
• 是否有隐含的环境假设？（Node 版本、数据库连接、API Key）

审查示例：

计划文件：docs/plan.md
任务清单：5 个任务

审查发现：
- 任务 3（添加数据库迁移）应在任务 2（编写数据模型）之后，顺序正确 ✓
- 任务 4 的验证条件写的是"确认功能正常"→ 需澄清：具体跑什么测试？
- 计划未提及 Python 版本要求 → 需确认

向伙伴提出：
"计划整体可执行。有两个问题：(1) 任务 4 的验证条件不够具体，建议改为
'运行 pytest tests/test_api.py 全部通过'；(2) 需要确认 Python 版本要求。"

步骤 2：执行任务

对于每个任务：

1. 标记为进行中 — 更新 TodoWrite
2. 理解目标 — 重读任务描述，明确完成标准
3. 执行实现 — 严格按照计划步骤执行（计划已有小步骤）
4. 运行验证 — 按要求运行测试或检查
5. 提交变更 — 每完成一个任务提交一次，commit message 引用任务编号
6. 标记为已完成 — 更新 TodoWrite

每个任务的节奏：

--- 任务 2/5：添加用户验证 ---
[标记进行中]

目标：为 /api/users 添加输入验证
完成标准：所有验证测试通过，无效输入返回 400

[实现]
- 添加 validateUser() 中间件
- 编写 3 个验证规则（email 格式、密码强度、用户名长度）

[验证]
$ npm test -- --grep "validation"
  ✓ 拒绝无效 email (12ms)
  ✓ 拒绝弱密码 (8ms)
  ✓ 拒绝过长用户名 (5ms)
  3 passing

[提交]
$ git add src/middleware/validate.js tests/validation.test.js
$ git commit -m "feat: 添加用户输入验证（任务 2/5）"

[标记完成]
--- 任务 2/5 完成 ---

批量审查检查点：

• 每完成 3 个任务后，暂停回顾：整体方向还对吗？有没有偏离计划？
• 如果发现前面的实现有问题，先修复再继续，不要带着问题往下走

阶段检查点（Phase Checkpoint）

当计划跨多个阶段时（诊断→修复→验证），在阶段边界插入检查点，防止单 session 过长导致 context 膨胀和注意力衰减。

触发条件（任一满足即暂停）：

• 累计已完成 tasks >= 3 且剩余 tasks >= 2
• 当前 context 使用率 > 60%（estimatedTokens / contextWindow）
• 任务类型从"分析/计划"切换到"实现/执行"（如 review → patch_proposal）

检查点动作：

1. 暂停执行，输出进度摘要：

📊 进度：已完成 3/5 任务
   ✅ Task 1: bash 格式修复
   ✅ Task 2: grep 格式修复
   ✅ Task 3: 测试加固
   ⏳ Task 4: per-message budget（待执行）
   ⏳ Task 5: 全量验证（待执行）

   Context 使用率：62%（380K / 612K）

   选择：[继续执行] [开新 session 继续] [停止]

2. 如果用户选择"开新 session 继续"：

   • 输出 handoff summary：

     ## Session Handoff
     
     **进度：** 3/5 任务已完成
     **已完成：** Task 1 (commit abc1234), Task 2 (commit def5678), Task 3 (commit ghi9012)
     **待执行：** Task 4 (per-message budget 窗口感知), Task 5 (全量验证)
     **计划文档：** docs/superpowers/plans/yyyy-mm-dd-<plan-name>.md
     **当前分支：** feat/tianshu-sycophancy-trap-2.5
     

   • 指引新 session：加载计划文档 → 从 Task 4 开始 → 验证已完成任务无误 → 继续

3. 如果用户选择"继续执行"：正常继续下一个任务

实现方式： 在计划文档中，阶段边界插入 <!-- checkpoint --> 注释标记。 执行到标记处时触发上述检查点逻辑。

步骤 3：处理常见异常

测试失败：

1. 读错误信息，定位失败原因
2. 区分：是实现 bug？还是测试本身有问题？还是计划描述有误？
3. 实现 bug → 修复并重跑
4. 测试有问题 → 修复测试，向伙伴说明
5. 计划有误 → 停下来，向伙伴报告并建议修正

依赖缺失：

任务 3 需要 Redis 连接，但计划中没有提及 Redis 配置。
→ 停止执行
→ 向伙伴报告："任务 3 需要 Redis，计划中未包含配置步骤。
   建议：在任务 3 前插入 '配置 Redis 连接' 步骤。"

指令不清：

• 不要猜测意图，不要"合理推断"
• 列出你的理解和困惑，让伙伴澄清
• 等待回复后再继续

步骤 4：完成开发

所有任务完成并验证后：

• 运行全量验证：npx tsc --noEmit && npm test
• 使用 deliver_task 工具交付（包含 commit SHA、测试结果、偏离说明）

完成报告模板：

## 执行报告

**计划：** docs/superpowers/plans/<plan-file>.md
**分支：** <当前分支>
**任务：** N/N 已完成

### 完成的任务
1. ✅ ...
2. ✅ ...

### 验证结果
- tsc: exit 0
- 测试：N/N 通过
- 无新 lint 警告

### 偏离计划的地方
- <偏离说明及理由>

何时停下来求助

在以下情况立即停止执行：

• 遇到阻塞（缺少依赖、测试失败、指令不清）
• 计划有严重缺陷导致无法开始
• 你不理解某条指令
• 验证反复失败（同一测试失败 2 次以上）

不确定时就问，不要猜测。

何时回到之前的步骤

回到审查（步骤 1）当：

• 伙伴根据你的反馈更新了计划
• 根本性的方案需要重新考虑

不要硬闯阻塞 — 停下来问。

注意事项

• 先批判性审查计划
• 严格按照计划步骤执行
• 不要跳过验证
• 每个任务单独提交，commit message 引用任务编号
• 计划要求时引用相应技能
• 遇到阻塞时停下来，不要猜测
• 未经用户明确同意，绝不在 main/master 分支上开始实现

集成

关联技能：

• writing-plans — 创建此技能要执行的计划
• subagent-driven-development — 如果任务量大、需要并行委派，使用子代理模式替代本技能