executing-plans

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Executing Plans

执行计划

Execute written implementation plans efficiently. Actively use Agent Teams or subagents to execute batches of independent tasks in parallel, following BDD/TDD principles.

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

Initialization

初始化

Resolve Plan Path:
- If
```
$ARGUMENTS
```
  provides a path (e.g.,
```
docs/plans/YYYY-MM-DD-topic-plan/
```
  ), look for
```
_index.md
```
  or
```
plan.md
```
  inside it.
- If no argument is provided:
  - Search
```
docs/plans/
```
    for the most recent
```
*-plan/
```
    folder matching the pattern
```
YYYY-MM-DD-*-plan/
```
  - If found, confirm with user: "Execute this plan: [path]?"
  - If not found or user declines, ask the user for the plan folder path.
Plan Check: Verify the plan file exists and contains actionable tasks.

解析计划路径:
- 如果
```
$ARGUMENTS
```
  提供了路径（例如
```
docs/plans/YYYY-MM-DD-topic-plan/
```
  ），在该路径下查找
```
_index.md
```
  或
```
plan.md
```
  。
- 如果未提供参数:
  - 在
```
docs/plans/
```
    中搜索符合
```
YYYY-MM-DD-*-plan/
```
    格式的最新
```
*-plan/
```
    文件夹
  - 如果找到，向用户确认：“是否执行此计划：[路径]？”
  - 如果未找到或用户拒绝，询问用户提供计划文件夹路径。
计划检查: 验证计划文件是否存在且包含可执行任务。

Background Knowledge

背景知识

Core Principles: Review before execution, batch verification, explicit blockers, evidence-driven approach.

MANDATORY SKILLS: Both

superpowers:agent-team-driven-development

and

superpowers:behavior-driven-development

must be loaded regardless of execution mode.

核心原则: 执行前审查、批量验证、明确阻塞点、基于证据的方法。

必备SKILL: 无论执行模式如何，必须同时加载

superpowers:agent-team-driven-development

和

superpowers:behavior-driven-development

。

Phase 1: Plan Review & Understanding

阶段1: 计划审查与理解

Read plan, understand the project and requirements.

Read Plan: Read all plan files (
```
_index.md
```
and task files) to understand the scope, architecture, and dependencies.
Understand Project: Explore codebase structure, key files, and patterns relevant to the plan.
Check Blockers: See
```
./references/blocker-and-escalation.md
```
.

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

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

Phase 2: Task Setup (MANDATORY)

阶段2: 任务设置（必填）

REQUIRED: Create task tracking system before any execution begins.

Scope Batches: Build a dependency graph from
```
depends-on
```
fields, then actively restructure tasks into parallel batches.
- Compute dependency tiers: Tier 0 = no dependencies, Tier N = all
```
depends-on
```
  tasks are in earlier tiers
- Within each tier, group tasks by type to maximize parallelism (e.g., all "write test" tasks in one batch, all "implement" tasks in the next)
- MANDATORY: Every batch must contain ≥2 tasks. If a tier has only 1 task, combine it with adjacent tier tasks that have no file conflicts
- A single-task batch is only acceptable if it is the sole remaining task in the entire plan
- Each batch should contain 3-6 tasks
Create Tasks: Use
```
TaskCreate
```
tool to register each task, in batch order. Each task must include:
- ```
subject
```
  : Brief title in imperative form (e.g., "Implement login handler")
- ```
description
```
  : Detailed task description from plan, including files, verification steps, and BDD scenario reference
- ```
activeForm
```
  : Present continuous form for progress display (e.g., "Implementing login handler")

要求: 在开始任何执行之前，创建任务跟踪系统。

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

Phase 3: Batch Execution Loop

阶段3: 批量执行循环

Execute tasks in batches. Actively use parallel execution for independent tasks.

For Each Batch:

Choose Execution Mode (strict priority — justify any downgrade explicitly):
- Agent Team (default): Use unless a specific technical reason prevents it. File conflicts or sequential
```
depends-on
```
  within a batch are NOT valid reasons to downgrade — resolve by splitting the batch further.
- Subagent Parallel (downgrade only if): Agent Team overhead is disproportionate (e.g., batch has exactly 2 small tasks). State the reason explicitly.
- Linear (last resort only if): Tasks within the batch have unavoidable file conflicts that cannot be split, or the batch genuinely contains only 1 task. State the reason explicitly.
Agent Team Execution:
- Create Agent Team with teammates for parallel execution
- Assign tasks to teammates with clear file ownership boundaries
- Wait for teammates to complete all tasks
- Verify all tasks in the batch
- Mark tasks complete
Subagent Parallel Execution:
- Spawn subagents concurrently for each independent task
- Each subagent loads the
```
superpowers:behavior-driven-development
```
  skill
- Verify all tasks in the batch
- Mark tasks complete
Linear Execution:
- For each task in the batch:
  - Execute using subagent loading the
```
superpowers:behavior-driven-development
```
    skill
  - Verify the task
  - Mark task complete
Between Batches:
- Report progress and verification results
- Proceed to next batch automatically

See

./references/batch-execution-playbook.md

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

每个批次的执行步骤:

选择执行模式（严格优先级——如需降级需明确说明理由）:
- Agent Team（默认）: 除非有特定技术原因阻止，否则使用此模式。批次内的文件冲突或顺序
```
depends-on
```
  不是降级的有效理由——需进一步拆分批次来解决。
- Subagent Parallel（仅在以下情况下降级）: Agent Team的开销过大（例如批次恰好包含2个小型任务）。需明确说明理由。
- Linear（仅作为最后手段）: 批次内的任务存在无法拆分的不可避免的文件冲突，或者批次确实仅包含1个任务。需明确说明理由。
Agent Team执行:
- 创建用于并行执行的Agent Team
- 为团队成员分配任务，并明确文件所有权边界
- 等待所有团队成员完成任务
- 验证批次中的所有任务
- 标记任务为已完成
Subagent Parallel执行:
- 为每个独立任务同时生成子代理
- 每个子代理加载
```
superpowers:behavior-driven-development
```
  Skill
- 验证批次中的所有任务
- 标记任务为已完成
Linear执行:
- 针对批次中的每个任务:
  - 使用加载了
```
superpowers:behavior-driven-development
```
    Skill的子代理执行任务
  - 验证任务
  - 标记任务为已完成
批次间操作:
- 报告进度和验证结果
- 自动进入下一个批次

参见

./references/batch-execution-playbook.md

。

Git Commit

Git提交

Commit the implementation changes to git with proper message format.

See

../../skills/references/git-commit.md

for detailed patterns, commit message templates, and requirements.

Critical requirements:

Commit the implementation changes after all tasks are completed
Prefix:
```
feat(<scope>):
```
for implementation changes
Subject: Under 50 characters, lowercase
Footer: Co-Authored-By with model name

Commit timing:

Commit implementation changes after all tasks in the plan are completed
Commit should reflect the completed feature, not individual tasks
Use meaningful scope (e.g.,
```
feat(auth):
```
,
```
feat(ui):
```
,
```
feat(db):
```
)

使用正确的消息格式将实现变更提交到Git。

有关详细模式、提交消息模板和要求，请参见

../../skills/references/git-commit.md

。

关键要求:

所有任务完成后提交实现变更
前缀:
```
feat(<scope>):
```
用于实现变更
主题: 不超过50个字符，小写
页脚: 包含模型名称的Co-Authored-By

提交时机:

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

Phase 4: Verification & Feedback

阶段4: 验证与反馈

Close the loop.

Publish Evidence: Log outputs and test results.
Confirm: Get user confirmation.
Update Tracker: Mark tasks complete.
Loop: Repeat Phase 3-4 until complete.

完成闭环。

发布证据: 记录输出和测试结果。
确认: 获取用户确认。
更新跟踪器: 标记任务为已完成。
循环: 重复阶段3-4直至完成。

Exit Criteria

退出标准

All tasks executed and verified, evidence captured, no blockers, user approval received, final verification passes.

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

References

参考资料

```
./references/blocker-and-escalation.md
```
- Guide for identifying and handling blockers

./references/batch-execution-playbook.md

- Pattern for batch execution

```
../../skills/references/git-commit.md
```
- Git commit patterns and requirements

```
./references/blocker-and-escalation.md
```
- 识别和处理阻塞点的指南

./references/batch-execution-playbook.md

- 批量执行模式

```
../../skills/references/git-commit.md
```
- Git提交模式和要求