执行计划

概述

加载计划，批判性审查，批量执行任务，批次之间报告以供审查。

核心原则： 批量执行，设置检查点供审查。

开始时声明： "我正在使用 executing-plans skill 来实现此计划。"

过程

步骤 1：加载并审查计划

1. •读取计划文件 (docs/plans/YYYY-MM-DD-*.md)
2. •检查执行进度：查找 [ ] 和 [x] 标记，确认哪些任务已完成、哪些待执行
3. •从第一个未完成任务 [ ] 继续执行
4. •批判性审查 - 识别关于计划的任何问题或顾虑
5. •如果有顾虑：在实施前向你的人类伙伴提出
6. •如果没有顾虑：创建 TodoWrite 并继续

步骤 2：执行批次

默认：前 3 个任务

对每个任务：

1. •标记为 in_progress
2. •完全按照每个步骤执行（计划中有小步骤）
3. •按指定运行验证
4. •标记为 completed
5. •同步更新计划文档：将任务标记从 [ ] 改为 [x]

同时更新进度追踪文件 docs/plans/progress.md：

• •记录任务开始时间
• •记录任务完成时间
• •更新任务状态
• •添加完成说明

步骤 3：报告

当批次完成时：

• •展示已实现的内容
• •展示验证输出
• •说："等待反馈。"

步骤 4：继续

根据反馈：

• •如果需要，应用更改
• •执行下一批次
• •重复直到完成

步骤 5：完成开发

所有任务完成并验证后：

• •调用 finishing-a-development-branch skill
• •遵循该技能验证测试、呈现选项、执行选择

混合执行模式

什么是混合执行

混合执行 = 根据任务依赖关系，智能调度并行/串行执行：

• •可并行任务：无前置依赖、无共享资源冲突的任务，可以同时执行
• •串行任务：有前置依赖或需要共享资源的任务，按顺序执行

何时使用混合执行

当计划中有多个独立任务时，混合执行可以显著提高效率：

• •前端组件开发（多个独立组件可并行）
• •API 端点开发（多个独立端点可并行）
• •工具函数编写（多个独立函数可并行）

混合执行流程

步骤 1：分析依赖

• •读取计划中所有任务
• •分析每个任务的"依赖"字段：
  • •前置任务：必须先完成的任务
  • •可并行任务：可以同时执行的任务
  • •外部依赖：外部包、API、配置
• •构建任务依赖图

步骤 2：识别可并行任务

• •找出所有无前置依赖的任务
• •检查是否有共享资源冲突（如修改同一文件）
• •标记可并行执行的任务组

步骤 3：执行并行任务

• •同时启动多个子代理处理并行任务
• •每个子代理独立执行一个任务
• •等待所有并行任务完成

步骤 4：执行串行任务

• •按依赖顺序执行串行任务
• •如果某任务依赖的并行任务未完成，等待

步骤 5：退化为串行

• •如果没有可并行的任务（所有任务都有依赖）
• •自动切换为子代理驱动模式（串行执行）

并行度控制

• •最大并行数：建议 2-4 个任务同时执行
• •过多并行的风险：资源竞争、难以跟踪、合并冲突多
• •推荐策略：同批次并行任务不超过 3 个

混合执行示例

任务 A（无依赖）→ 可并行
任务 B（无依赖）→ 可并行
任务 C（依赖 A）→ 串行
任务 D（依赖 A、B）→ 串行

执行顺序：
1. 并行执行 A、B
2. 等待 A、B 完成
3. 串行执行 C（依赖 A）
4. 串行执行 D（依赖 A、B）

里程碑评审点

什么是里程碑

里程碑 = 计划中的一组相关任务完成后的检查点。 例如：

• •完成一个功能模块
• •完成一个 API 端点
• •完成一组相关的代码修改

里程碑评审流程

每个里程碑完成后：

1. •暂停执行 - 不要立即开始下一个任务
2. •对照检查 - 对照原始需求检查当前进度
3. •评估状态 - 已完成 / 部分完成 / 需要调整
4. •与用户确认 - 确认后才能继续

里程碑评审检查清单

• • 当前里程碑的所有任务完成了吗？
• • 实现与原始需求一致吗？
• • 有遗漏的功能吗？
• • 需要调整后续计划吗？
• • 用户确认可以继续吗？

里程碑评审 - 需求变更检查

在里程碑评审时，额外检查：

1. •扫描需求目录 - 检查 docs/requirements/ 是否有新的相关需求
2. •检查需求变更 - 已有需求是否有修改
3. •识别冲突 - 新需求是否与当前实现冲突

如果发现需求变更：

• •记录变更内容
• •告知用户可能的冲突点
• •与用户确认是否需要调整计划

计划调整

何时需要调整

• •发现计划遗漏的步骤
• •需求发生了变化
• •发现新的依赖或风险
• •实现过程中遇到未预见的难题

调整流程

1. •记录当前状态 - 暂停并记录已完成的工作
2. •分析差异 - 明确计划与实际的差异
3. •提出调整方案 - 列出需要添加/修改/删除的步骤
4. •与用户确认 - 调整方案需要用户批准
5. •更新计划 - 修改计划文档
6. •继续执行 - 按更新后的计划执行

调整原则

• •计划是活的，可以细化
• •不要害怕暂停，停下来想清楚更重要
• •每次调整都要记录原因
• •用户确认后才能继续

何时停止并寻求帮助

立即停止执行当：

• •批次中遇到阻碍（缺少依赖、测试失败、指令不清）
• •计划有严重缺陷阻止开始
• •你不理解某个指令
• •验证反复失败

询问澄清而不是猜测。

检查清单

执行前确认：

• • 计划文件存在且可读
• • 理解每个任务的步骤
• • 知道如何验证每个任务

执行中确认：

• • 按计划步骤执行
• • 运行验证命令
• • 记录任何问题

执行后确认：

• • 所有测试通过
• • 代码可运行
• • 无引入新问题

工作流

writing-plans → executing-plans (里程碑评审 + 可调整)
                           ↓
              批次 1 → 报告 → 反馈
                           ↓
              批次 2 → 报告 → 反馈
                           ↓
              批次 N → 完成
                           ↓
              verification-before-completion (代码质量)
                           ↓
              execution-validation (需求-实现对照)
                           ↓
              update-blueprint

技术栈

根据项目实际情况确定。

• •覆盖率: 80%