⚡

执行计划Skill executing-plans

该技能用于高效执行软件实现计划，通过代理团队或子代理并行执行独立任务，遵循行为驱动开发（BDD）和测试驱动开发（TDD）原则。关键词：执行计划、代理团队、BDD、TDD、任务批处理、软件开发、测试验证。

测试 0 次安装 0 次浏览 更新于 3/16/2026

name: 执行计划 description: 当用户有完整的实现计划（plan.md）并准备执行其中定义的任务时，应使用此技能。主动使用代理团队或子代理并行执行独立任务批次，遵循BDD/TDD原则。 argument-hint: [计划文件夹路径] user-invocable: true version: 1.5.0

执行计划

高效执行书面实现计划。主动使用代理团队或子代理并行执行独立任务批次，遵循BDD/TDD原则。

初始化

  1. 解析计划路径：
    • 如果$ARGUMENTS提供路径（例如docs/plans/YYYY-MM-DD-topic-plan/），在其中查找_index.md或plan.md。
    • 如果未提供参数：
      • 在docs/plans/中搜索匹配模式YYYY-MM-DD-*-plan/的最新*-plan/文件夹。
      • 如果找到，向用户确认：“执行此计划：[路径]？”
      • 如果未找到或用户拒绝，询问用户计划文件夹路径。
  2. 计划检查：验证计划文件存在并包含可操作任务。

背景知识

核心原则：执行前审查，批次验证，明确阻塞项，证据驱动方法。

必备技能：无论执行模式如何，都必须加载superpowers:agent-team-driven-development和superpowers:behavior-driven-development。

第一阶段：计划审查与理解

阅读计划，理解项目和需求。

  1. 阅读计划：阅读所有计划文件（_index.md和任务文件）以理解范围、架构和依赖关系。
  2. 理解项目：探索代码库结构、关键文件和与计划相关的模式。
  3. 检查阻塞项：参考./references/blocker-and-escalation.md。

第二阶段：任务设置（强制）

必须：在任何执行开始前创建任务跟踪系统。

  1. 范围批次：从depends-on字段构建依赖图，然后主动重构任务为并行批次。
    • 计算依赖层级：层级0 = 无依赖，层级N = 所有depends-on任务在更早层级
    • 在每个层级内，按类型分组任务以最大化并行性（例如，所有“编写测试”任务在一个批次，所有“实现”任务在下一个批次）
    • 强制：每个批次必须包含≥2个任务。如果层级只有1个任务，将其与没有文件冲突的相邻层级任务组合
    • 仅当是整个计划中唯一剩余任务时，才允许单任务批次
    • 每个批次应包含3-6个任务
  2. 创建任务：使用TaskCreate工具按批次顺序注册每个任务。每个任务必须包括：
    • subject：命令式简短标题（例如“实现登录处理器”）
    • description：计划中的详细任务描述，包括文件、验证步骤和BDD场景参考
    • activeForm：进行时形式用于进度显示（例如“正在实现登录处理器”）

第三阶段：批次执行循环

按批次执行任务。主动对独立任务使用并行执行。

对于每个批次：

  1. 选择执行模式（严格优先级 — 明确说明任何降级原因）：

    • 代理团队（默认）：除非特定技术原因阻止，否则使用。文件冲突或批次内的顺序depends-on不是降级的有效原因 — 通过进一步拆分批次解决。
    • 子代理并行（仅降级如果）：代理团队开销不成比例（例如批次恰好有2个小任务）。明确说明原因。
    • 线性执行（最后手段仅如果）：批次内的任务有不可避免的文件冲突无法拆分，或批次确实只包含1个任务。明确说明原因。

  2. 代理团队执行：

    • 创建代理团队，为并行执行分配队友
    • 将任务分配给队友，明确文件所有权边界
    • 等待队友完成所有任务
    • 验证批次中的所有任务
    • 标记任务完成

  3. 子代理并行执行：

    • 为每个独立任务并发生成子代理
    • 每个子代理加载superpowers:behavior-driven-development技能
    • 验证批次中的所有任务
    • 标记任务完成

  4. 线性执行：

    • 对于批次中的每个任务：
      • 使用加载superpowers:behavior-driven-development技能的子代理执行
      • 验证任务
      • 标记任务完成

  5. 批次之间：

    • 报告进度和验证结果
    • 自动进入下一批次

参考./references/batch-execution-playbook.md。

Git提交

将实现更改提交到git，使用正确的消息格式。

参考../../skills/references/git-commit.md获取详细模式、提交消息模板和要求。

关键要求：

  • 在所有任务完成后提交实现更改
  • 前缀：feat(<scope>):用于实现更改
  • 主题：少于50个字符，小写
  • 页脚：Co-Authored-By带模型名称

提交时机：

  • 在计划中所有任务完成后提交实现更改
  • 提交应反映完成的功能，而非单个任务
  • 使用有意义的范围（例如feat(auth):、feat(ui):、feat(db):）

第四阶段：验证与反馈

闭环。

  1. 发布证据：记录输出和测试结果。
  2. 确认：获取用户确认。
  3. 更新跟踪器：标记任务完成。
  4. 循环：重复第三至第四阶段直到完成。

退出标准

所有任务执行并验证，证据捕获，无阻塞项，用户批准收到，最终验证通过。

参考文献

  • ./references/blocker-and-escalation.md — 识别和处理阻塞项的指南
  • ./references/batch-execution-playbook.md — 批次执行模式
  • ../../skills/references/git-commit.md — Git提交模式和要求