executing-plans
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseExecuting Plans
执行计划
Overview
概述
This skill turns an approved plan document into working code through disciplined, batch-based execution. Each step is implemented with TDD, verified before proceeding, and reviewed at checkpoints. It provides the structural framework for moving from plan to production code with consistent quality gates.
Announce at start: "I'm using the executing-plans skill to implement the approved plan at [plan path]."
该skill通过规范的批次化执行流程，将获批的计划文档转化为可运行的代码。每个步骤都采用TDD实现，推进前先经过验证，并在检查点进行评审。它提供了从计划到生产代码的结构框架，配备一致的质量关卡。
启动时声明： "我正在使用executing-plans skill来执行[计划路径]下的获批计划。"
Trigger Conditions
触发条件
- An approved plan document exists and is ready for implementation
- command invoked with a plan reference
/execute - Resuming a partially completed plan execution
- Transition from planning skill after plan approval
- 存在获批的计划文档，且已准备好进入实施阶段
- 调用附带计划引用的命令
/execute - 恢复执行部分完成的计划
- 计划获批后从planning skill切换至执行阶段
Phase 1: Read the Plan
阶段1：解读计划
Goal: Thoroughly understand the plan before writing any code.
- Read the entire plan document from start to finish
- Identify all implementation steps and count them
- Map dependencies between steps (what must be done first)
- Note any ambiguities or open questions
- Confirm understanding with the user before proceeding
目标： 在编写任何代码前全面理解计划内容。
- 从头到尾通读完整的计划文档
- 识别所有实施步骤并统计数量
- 梳理步骤之间的依赖关系（哪些内容必须优先完成）
- 标注所有歧义点或待解决的问题
- 推进前先与用户确认对计划的理解是否正确
Plan Comprehension Checklist
计划理解检查清单
| Check | Question |
|---|---|
| Goal clarity | Can you explain the plan's goal in one sentence? |
| Step count | How many implementation steps are there? |
| Dependencies | Which steps depend on which? |
| Ambiguities | Are there any unclear or underspecified steps? |
| Verification | Does every step have a verification method? |
STOP — Do NOT proceed to Phase 2 until:
- You can explain the plan's goal in one sentence
- You can list all implementation steps
- Dependencies are mapped
- Any ambiguities are noted and resolved with user
- User has confirmed you may proceed
| 检查项 | 问题 |
|---|---|
| 目标清晰度 | 你能否用一句话说明计划的目标？ |
| 步骤数量 | 共有多少个实施步骤？ |
| 依赖关系 | 各步骤之间的依赖关系是什么？ |
| 歧义点 | 是否存在表述不清或说明不足的步骤？ |
| 验证方式 | 每个步骤是否都有对应的验证方法？ |
停止 — 满足以下条件前切勿进入阶段2：
- 你可以用一句话说明计划的目标
- 你可以列出所有实施步骤
- 已梳理完成所有依赖关系
- 所有歧义点已标注并和用户沟通解决
- 用户已确认你可以继续推进
Phase 2: Create Task Batch
阶段2：创建任务批次
Goal: Break the plan into small, executable task batches.
目标： 将计划拆分为小型、可执行的任务批次。
Batch Size Decision Table
批次大小决策表
| Task Complexity | Batch Size | Examples |
|---|---|---|
| Simple (config, boilerplate) | Up to 5 tasks | ENV vars, imports, type definitions |
| Standard (features, logic) | 3 tasks | Endpoints, services, components |
| Complex (integrations, security) | 2 tasks | OAuth flows, payment processing |
| Critical (data migration, auth) | 1 task | Database migrations, credential handling |
| 任务复杂度 | 批次大小 | 示例 |
|---|---|---|
| 简单（配置、样板代码） | 最多5个任务 | 环境变量、导入声明、类型定义 |
| 标准（功能、逻辑） | 3个任务 | 接口、服务、组件 |
| 复杂（集成、安全） | 2个任务 | OAuth流程、支付处理 |
| 关键（数据迁移、鉴权） | 1个任务 | 数据库迁移、凭证处理 |
Task Requirements (STIC)
任务要求（STIC）
| Criterion | Description |
|---|---|
| Specific | Clear definition of what to implement |
| Testable | Can be verified with automated tests |
| Independent | Minimal coupling to other tasks in the batch (where possible) |
| Compact | Completable in a focused session (2-5 minutes) |
| 标准 | 说明 |
|---|---|
| Specific（明确） | 对要实现的内容有清晰的定义 |
| Testable（可测试） | 可以通过自动化测试进行验证 |
| Independent（独立） | 与批次内其他任务的耦合度尽可能低 |
| Compact（紧凑） | 可在专注的会话内（2-5分钟）完成 |
Task Template
任务模板
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]STOP — Do NOT proceed to Phase 3 until:
- Tasks created for the current batch
- Each task has clear acceptance criteria
- Dependencies are satisfied (previous tasks complete)
- Tasks ordered by dependency (independent tasks first)
Task: [简洁描述]
Plan Step: [对应计划章节的引用]
Files to Create/Modify: [精确的文件路径列表]
Acceptance Criteria:
- [明确、可测试的验收标准1]
- [明确、可测试的验收标准2]
Dependencies: [必须优先完成的其他任务，或"none"]
Verification: [要运行的精确命令]停止 — 满足以下条件前切勿进入阶段3：
- 已为当前批次创建所有任务
- 每个任务都有清晰的验收标准
- 所有依赖已满足（前置任务已完成）
- 任务已按依赖关系排序（独立任务优先）
Phase 3: Execute Tasks
阶段3：执行任务
Goal: Execute each task one at a time using TDD.
目标： 采用TDD逐个执行每个任务。
Per-Task Workflow
单任务工作流
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 task1. 声明你即将开始执行的任务
2. 使用test-driven-development skill进行实现：
a. 编写失败的测试（RED）
b. 编写最少的代码让测试通过（GREEN）
c. 重构（REFACTOR）
d. 为每个行为重复红-绿-重构流程
3. 使用verification-before-completion skill进行验证：
a. 运行完整测试套件（不仅仅是新增测试）
b. 根据场景运行lint、类型检查、构建命令
c. 确认所有检查通过
4. 标记任务为完成
5. 推进到下一个任务Execution Rules
执行规则
| Rule | Rationale |
|---|---|
| One task at a time | Do not start task 2 until task 1 is verified |
| Follow TDD strictly | No production code without a failing test |
| Do not deviate from the plan | If plan needs changes, stop and discuss with user |
| Do not skip verification | Every task must pass verification before marking complete |
| Report progress | Announce start and completion of each task |
| 规则 | 逻辑 |
|---|---|
| 一次执行一个任务 | 任务1验证通过前不要启动任务2 |
| 严格遵循TDD流程 | 没有失败的测试就不要编写生产代码 |
| 不要偏离计划 | 如果计划需要修改，停止并和用户讨论 |
| 不要跳过验证 | 每个任务标记完成前必须通过验证 |
| 同步进度 | 声明每个任务的开始和完成状态 |
Task Outcome Decision Table
任务结果决策表
| Outcome | Action | Next Step |
|---|---|---|
| Verification passes | Mark complete | Next task |
| Test failure, obvious fix | Fix and re-verify | Same task |
| Test failure, unclear cause | Invoke | Same task after fix |
| Plan step is ambiguous | Stop and ask user | Wait for clarification |
| Plan step is not feasible | Report blocker | Wait for direction |
| Unexpected dependency found | Report and reorder | Adjust batch |
STOP — Do NOT proceed to next task until:
- Current task's acceptance criteria are met
- All tests pass (new and existing)
- Verification-before-completion has been executed
- Task marked as complete
| 结果 | 动作 | 下一步 |
|---|---|---|
| 验证通过 | 标记为完成 | 下一个任务 |
| 测试失败，有明确修复方案 | 修复后重新验证 | 同一个任务 |
| 测试失败，原因不明 | 调用 | 修复后回到当前任务 |
| 计划步骤存在歧义 | 停止并询问用户 | 等待澄清 |
| 计划步骤不可行 | 上报阻塞问题 | 等待指示 |
| 发现未预期的依赖 | 上报并重新排序 | 调整批次 |
停止 — 满足以下条件前切勿进入下一个任务：
- 当前任务的验收标准已全部满足
- 所有测试通过（新增测试和存量测试）
- 已执行verification-before-completion流程
- 任务已标记为完成
Phase 4: Batch Checkpoint
阶段4：批次检查点
Goal: After completing all tasks in a batch, perform a full checkpoint review.
目标： 完成批次内所有任务后，执行全面的检查点评审。
Checkpoint Steps
检查点步骤
- Run full test suite — all tests, not just those from the current batch
- Run all verification commands — lint, type-check, build, format
- Review what was implemented — summarize completed tasks and outcomes
- Assess progress against the plan — how far through are we?
- Identify any issues or risks that came up during execution
- Report to user and ask for direction
- 运行完整测试套件 — 所有测试，不仅仅是当前批次的测试
- 运行所有验证命令 — lint、类型检查、构建、格式化
- 评审已实现内容 — 总结已完成的任务和结果
- 对照计划评估进度 — 当前完成了多少进度？
- 识别执行过程中出现的所有问题或风险
- 上报给用户并询问下一步指示
Checkpoint Report Template
检查点报告模板
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?STOP — Do NOT proceed to next batch until:
- Full test suite passes
- All verification commands pass
- Checkpoint report presented to user
- User has confirmed to continue
BATCH CHECKPOINT
================
Batch: [批次号] / [预估总批次]
Tasks Completed: [任务列表]
Verification Results:
Tests: [X passed, Y failed, Z skipped]
Build: [pass/fail]
Lint: [pass/fail, N warnings]
Type-check: [pass/fail]
Progress: [已完成N个/M个计划步骤] ([百分比]%)
Issues Encountered:
- [问题1及解决方式]
Risks or Concerns:
- [风险1]
Next Batch Preview:
- [任务1]
- [任务2]
- [任务3]
Awaiting direction: Continue with next batch / Adjust plan / Other?停止 — 满足以下条件前切勿进入下一个批次：
- 完整测试套件运行通过
- 所有验证命令执行通过
- 已向用户提交检查点报告
- 用户已确认可以继续
Phase 5: Continue, Adjust, or Complete
阶段5：继续、调整或完成
Goal: Act on user direction after each checkpoint.
目标： 根据每个检查点后用户的指示执行对应动作。
Direction Decision Table
指示决策表
| User Direction | Action | Next Phase |
|---|---|---|
| "Continue" | Create next batch of tasks | Phase 2 |
| "Adjust plan" | Discuss changes, update plan document | Phase 2 (with updated plan) |
| "Stop here" | Summarize progress, note remaining work | Completion |
| "Skip ahead to [step]" | Verify dependencies are met, then jump | Phase 2 (at new step) |
| "Go back and redo [task]" | Revert if needed, re-execute with corrections | Phase 3 |
Never proceed to the next batch without explicit user approval.
| 用户指示 | 动作 | 下一阶段 |
|---|---|---|
| "继续" | 创建下一批任务 | 阶段2 |
| "调整计划" | 讨论变更，更新计划文档 | 阶段2（使用更新后的计划） |
| "在此停止" | 总结进度，标注剩余工作 | 完成 |
| "跳转到[步骤]" | 验证依赖满足后跳转 | 阶段2（从新步骤开始） |
| "返回重做[任务]" | 必要时回滚，修正后重新执行 | 阶段3 |
没有用户明确批准的情况下，切勿推进到下一个批次。
Critical Blocker Handling
严重阻塞处理
When you encounter something that prevents task completion, do NOT work around it. Stop and escalate.
当遇到导致任务无法完成的问题时，切勿绕过问题。停止并上报。
Blocker Classification
阻塞分类
| Type | Examples | Action |
|---|---|---|
| Ambiguous spec | Plan step could mean multiple things | Present interpretations, ask user |
| Missing dependency | Required API or library unavailable | Report with alternatives |
| Contradiction | Step conflicts with another part of the plan | Identify both sides, ask user |
| Security concern | Planned approach has vulnerability | Report risk, propose safer alternative |
| Feasibility | Step cannot be implemented as described | Explain why, propose alternatives |
| 类型 | 示例 | 动作 |
|---|---|---|
| 规范歧义 | 计划步骤可能有多种含义 | 给出你的理解，询问用户 |
| 依赖缺失 | 所需的API或库不可用 | 上报并提供替代方案 |
| 内容矛盾 | 步骤与计划的其他部分冲突 | 指出矛盾点，询问用户 |
| 安全隐患 | 计划的实现方案存在漏洞 | 上报风险，提出更安全的替代方案 |
| 可行性问题 | 步骤无法按描述实现 | 说明原因，提出替代方案 |
Blocker Report Format
阻塞报告格式
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.Do NOT guess what the user intended. Do NOT implement a workaround without approval. Do NOT skip the blocked task silently. DO present options with clear tradeoffs. DO continue with non-blocked tasks if possible (but flag the skip).
CRITICAL BLOCKER
================
Task: [被阻塞的任务]
Blocker: [清晰的问题描述]
Impact: [问题解决前哪些内容无法推进]
Options:
A. [方案及利弊]
B. [方案及利弊]
C. [跳过该步骤继续]
Awaiting direction before proceeding.切勿猜测用户的意图。切勿未经批准实现绕过方案。切勿静默跳过被阻塞的任务。务必提供带有明确利弊的选项。可以在可能的情况下继续执行未被阻塞的任务（但要标注跳过的内容）。
Subagent Dispatch Option
子代理调度选项
For larger plans, individual tasks can be dispatched to subagents for parallel execution.
对于大型计划，可将单个任务派发给子代理并行执行。
When to Suggest Subagent Dispatch
建议使用子代理调度的场景
| Condition | Threshold |
|---|---|
| Independent tasks in plan | 10+ tasks with few dependencies |
| Task specification quality | Each task has clear acceptance criteria |
| Speed requirement | User has indicated urgency |
| Task interdependency | Low coupling between tasks |
When conditions are met, suggest switching to the skill for the remaining work.
subagent-driven-development| 条件 | 阈值 |
|---|---|
| 计划中存在独立任务 | 10个以上低依赖任务 |
| 任务说明质量高 | 每个任务都有清晰的验收标准 |
| 速度要求 | 用户明确表示需要加急 |
| 任务依赖度 | 任务之间耦合度低 |
满足条件时，建议切换到 skill完成剩余工作。
subagent-driven-developmentAnti-Patterns / Common Mistakes
反模式/常见错误
| Anti-Pattern | Why It Fails | Correct Approach |
|---|---|---|
| Implementing entire plan at once | No checkpoints, no quality gates | Batch-based execution with checkpoints |
| Skipping TDD because "it's simple" | Bugs accumulate, regressions appear | Every task uses TDD, no exceptions |
| Working around blockers silently | User unaware, wrong assumptions baked in | Stop and escalate blockers |
| Proceeding without approval after batch | Direction may have changed | Always checkpoint and wait |
| Deviating from the plan | Unauthorized changes, scope creep | Discuss changes before implementing |
| Running only new tests | Regressions go undetected | Full test suite at checkpoints |
| Marking tasks complete without verification | False progress, accumulated bugs | Verification is mandatory |
| Batches larger than 5 tasks | Hard to review, too much risk per batch | Keep batches small |
| Skipping checkpoint report | User loses visibility into progress | Always present full checkpoint |
| Not committing at batch boundaries | Huge diffs, hard to revert | Commit after each batch |
| 反模式 | 失败原因 | 正确做法 |
|---|---|---|
| 一次性实现整个计划 | 没有检查点，没有质量关卡 | 带检查点的批次化执行 |
| 因为"很简单"跳过TDD | 漏洞累积，出现回归问题 | 每个任务都使用TDD，没有例外 |
| 静默绕过阻塞问题 | 用户不知情，错误假设被固化到代码中 | 停止并上报阻塞问题 |
| 批次完成后未经批准直接推进 | 方向可能已经变更 | 每次都走检查点流程并等待确认 |
| 偏离计划 | 未授权变更，范围蔓延 | 实现前先讨论变更 |
| 只运行新增测试 | 回归问题无法被发现 | 检查点运行完整测试套件 |
| 未验证就标记任务完成 | 虚假进度，漏洞累积 | 验证是强制要求 |
| 批次超过5个任务 | 难以评审，每个批次风险过高 | 保持小批次 |
| 跳过检查点报告 | 用户无法感知进度 | 每次都提交完整的检查点报告 |
| 批次边界不提交代码 | 差异过大，难以回滚 | 每个批次完成后提交代码 |
Anti-Rationalization Guards
反合理化防护
<HARD-GATE>
Do NOT skip any verification step. Do NOT proceed past a checkpoint without user approval. Do NOT deviate from the approved plan without discussion.
</HARD-GATE>
If you catch yourself thinking:
- "I know what comes next, I'll skip the checkpoint..." — No. Report and wait.
- "This verification is redundant..." — Run it anyway. Fresh evidence only.
- "The plan is close enough, I'll adjust as I go..." — Discuss adjustments first.
<HARD-GATE>
切勿跳过任何验证步骤。没有用户批准的情况下切勿通过检查点。未经讨论切勿偏离获批计划。
</HARD-GATE>
如果你发现自己有以下想法：
- "我知道接下来要做什么，跳过检查点吧..." — 不行，上报并等待。
- "这个验证是多余的..." — 还是要运行，只采信最新的验证结果。
- "计划差不多对，我边做边调吧..." — 先讨论调整方案。
Subagent Dispatch Opportunities
子代理调度场景
| Task Pattern | Dispatch To | When |
|---|---|---|
| Independent plan steps with no shared state | Parallel subagents via | When dependency analysis shows no blockers between steps |
| Code review of completed step | | After each major plan step completion |
| Test execution for completed features | Background | When tests can run independently of ongoing work |
Follow the skill protocol when dispatching.
dispatching-parallel-agents| 任务模式 | 调度对象 | 时机 |
|---|---|---|
| 无共享状态的独立计划步骤 | 通过 | 依赖分析显示步骤之间无阻塞时 |
| 已完成步骤的代码评审 | | 每个主要计划步骤完成后 |
| 已完成功能的测试执行 | 后台 | 测试可以独立于正在进行的工作运行时 |
调度时遵循 skill协议。
dispatching-parallel-agentsIntegration Points
集成点
| Skill | Relationship | When |
|---|---|---|
| Upstream — provides approved plan document | Plan is the input to this skill |
| Per-task — TDD cycle for every code task | Phase 3 execution |
| Per-task — verification gate | Before marking any task complete |
| On failure — investigate unexpected failures | When task encounters errors |
| At checkpoints — review code quality | Phase 4 batch review |
| Alternative — parallel execution path | For large independent task sets |
| On failure — retry with alternatives | When task approaches fail |
| Complementary — provides task tracking | Can be used together |
| Skill | 关系 | 时机 |
|---|---|---|
| 上游 — 提供获批的计划文档 | 计划是本skill的输入 |
| 单任务 — 每个代码任务的TDD循环 | 阶段3执行 |
| 单任务 — 验证关卡 | 标记任何任务完成前 |
| 出错时 — 排查意外故障 | 任务遇到错误时 |
| 检查点 — 评审代码质量 | 阶段4批次评审 |
| 替代方案 — 并行执行路径 | 适用于大型独立任务集 |
| 出错时 — 用替代方案重试 | 任务执行失败时 |
| 补充 — 提供任务跟踪能力 | 可搭配使用 |
Concrete Examples
具体示例
Example: Batch Creation from Plan
示例：从计划创建批次
Plan: "Add user authentication with 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]计划："添加基于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]Completion Criteria
完成标准
The plan execution is complete when:
- All plan steps have been implemented as tasks
- All tasks have passed verification
- Full test suite passes
- Final checkpoint report presented to user
- User confirms the plan is complete
满足以下条件时计划执行完成：
- 所有计划步骤都已作为任务实现
- 所有任务都已通过验证
- 完整测试套件运行通过
- 已向用户提交最终检查点报告
- 用户确认计划已完成
Skill Type
Skill类型
RIGID — Follow this process exactly. Batches, checkpoints, and verification gates are non-negotiable. No task is complete without verification. No batch proceeds without user approval.
RIGID（刚性） — 严格遵循本流程。批次、检查点和验证关卡是不可协商的要求。未验证的任务不算完成。没有用户批准的批次不能推进。