executing-an-implementation-plan
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseExecuting an Implementation Plan
执行实施计划
Execute plan phase-by-phase, loading each phase just-in-time to minimize context usage.
Core principle: Read one phase → execute all tasks → review → move to next phase. Never load all phases upfront.
REQUIRED SKILL: - The review loop (dispatch, fix, re-review until zero issues)
requesting-code-review分阶段执行计划,按需加载每个阶段以最小化上下文占用。
核心原则: 读取一个阶段 → 执行所有任务 → 审核 → 进入下一阶段。切勿提前加载所有阶段。
必备技能: - 审核循环(分配任务、修复、重新审核直至无问题)
requesting-code-reviewOverview
概述
When NOT to use:
- No implementation plan exists yet (use writing-implementation-plans first)
- Plan needs revision (brainstorm first)
不适用于以下场景:
- 尚未制定实施计划(请先使用writing-implementation-plans技能)
- 计划需要修订(先进行头脑风暴)
MANDATORY: Human Transparency
强制要求:对用户透明
The human cannot see what subagents return. You are their window into the work.
After EVERY subagent completes (task-implementor, bug-fixer, code-reviewer), you MUST:
- Print the subagent's full response to the user before taking any other action
- Do not summarize or paraphrase - show them what the subagent actually said
- Include all details: test counts, issue lists, commit hashes, error messages
Before dispatching any subagent:
- Briefly explain (2-3 sentences) what you're asking the agent to do
- State which phase this covers
Why this matters: When you silently process subagent output without showing the user, they lose visibility into their own codebase. They can't catch errors, learn from the process, or intervene when needed. Transparency is not optional.
Red flag: If you find yourself thinking "I'll just move on to the next step" without printing the subagent's response, STOP. Print it first.
用户无法查看Subagent的返回内容,你是他们了解工作进展的窗口。
每一个Subagent(task-implementor、bug-fixer、code-reviewer)完成任务后,你必须:
- 在执行其他操作前,向用户打印Subagent的完整响应
- 不要总结或改写 - 展示Subagent的实际输出内容
- 包含所有细节: 测试数量、问题列表、提交哈希值、错误信息
在分配任何Subagent之前:
- 简要说明(2-3句话)你要求该Agent执行的任务
- 说明这属于哪个阶段
为什么这很重要: 如果你在不向用户展示的情况下默默处理Subagent的输出,他们将失去对自己代码库的可见性。他们无法发现错误、从过程中学习或在需要时进行干预。透明性是必须的,而非可选。
警示信号: 如果你觉得“我直接进入下一步就好”而不打印Subagent的响应,请立即停止。先打印响应内容。
REQUIRED: Implementation Plan Path
强制要求:实施计划路径
DO NOT GUESS. If the user has not provided a path to an implementation plan directory, you MUST ask for it.
Use AskUserQuestion:
Question: "Which implementation plan should I execute?"
Options:
- [list any plan directories you find in docs/implementation-plans/]
- "Let me provide the path"If doesn't exist or is empty, ask the user to provide the path directly.
docs/implementation-plans/Never assume, infer, or guess which plan to execute. The user must explicitly tell you.
切勿猜测。 如果用户未提供实施计划目录的路径,你必须询问用户。
使用AskUserQuestion:
Question: "Which implementation plan should I execute?"
Options:
- [list any plan directories you find in docs/implementation-plans/]
- "Let me provide the path"如果不存在或为空,请直接让用户提供路径。
docs/implementation-plans/永远不要假设、推断或猜测要执行哪个计划。 用户必须明确告知你。
The Process
执行流程
1. Discover Phases
1. 发现阶段
DO NOT read the full phase files yet. List them and read only the header and task markers.
bash
undefined现在不要读取完整的阶段文件。 列出这些文件,仅读取标题和任务标记。
bash
undefinedList phase files
列出阶段文件
ls [plan-directory]/phase_*.md
ls [plan-directory]/phase_*.md
For each file, get the header (first 10 lines include title and Goal)
对每个文件,获取标题(前10行包含标题和目标)
head -10 [plan-directory]/phase_01.md
head -10 [plan-directory]/phase_01.md
Get task/subcomponent structure without reading full content
获取任务/子组件结构,无需读取完整内容
grep -E "START_TASK_|START_SUBCOMPONENT_" [plan-directory]/phase_01.md
The header includes the title (`# [Phase Title]`) and `**Goal:**` line. Extract the title for the task entry.
The grep output shows the task structure, e.g.:
Examples of headers you might see:
- `# Document Infrastructure Implementation Plan` — Phase 1 implied
- `# Phase 4: Link Resolution` — Phase number explicit
**Check for implementation guidance:**
After discovering phases, check if `.ed3d/implementation-plan-guidance.md` exists in the project root:
```bashgrep -E "START_TASK_|START_SUBCOMPONENT_" [plan-directory]/phase_01.md
标题部分包含标题(`# [Phase Title]`)和`**Goal:**`行。提取标题用于任务条目。
grep的输出展示了任务结构,例如:
你可能看到的标题示例:
- `# Document Infrastructure Implementation Plan` — 隐含为第1阶段
- `# Phase 4: Link Resolution` — 明确标注阶段编号
**检查实施指南:**
发现阶段后,检查项目根目录下是否存在`.ed3d/implementation-plan-guidance.md`:
```bashCheck for implementation guidance (note the absolute path for later use)
检查实施指南(记录绝对路径以备后用)
ls [project-root]/.ed3d/implementation-plan-guidance.md
If the file exists, note its **absolute path** for use during code reviews. If it doesn't exist, proceed without it—do not pass a nonexistent path to reviewers.
**Check for test requirements:**
Check if `test-requirements.md` exists in the plan directory:
```bashls [project-root]/.ed3d/implementation-plan-guidance.md
如果该文件存在,记录其**绝对路径**以便在代码审核时使用。如果不存在,则无需使用——不要将不存在的路径提供给审核人员。
**检查测试要求:**
检查计划目录下是否存在`test-requirements.md`:
```bashCheck for test requirements (note the absolute path for later use)
检查测试要求(记录绝对路径以备后用)
ls [plan-directory]/test-requirements.md
If the file exists, note its **absolute path** for use during final review. The test requirements document specifies what automated tests must exist for each acceptance criterion.ls [plan-directory]/test-requirements.md
如果该文件存在,记录其**绝对路径**以便在最终审核时使用。测试要求文档规定了每个验收标准必须具备的自动化测试。2. Create Phase-Level Task List
2. 创建阶段级任务列表
Use TaskCreate to create three task entries per phase (or TodoWrite in older Claude Code versions). Include the title from the header:
- [ ] Phase 1a: Read /absolute/path/to/phase_01.md — Document Infrastructure Implementation Plan
- [ ] Phase 1b: Execute tasks
- [ ] Phase 1c: Code review
- [ ] Phase 2a: Read /absolute/path/to/phase_02.md — API Integration
- [ ] Phase 2b: Execute tasks
- [ ] Phase 2c: Code review
...Why absolute paths in task entries: After compaction, context may be summarized. The absolute path in the task entry ensures you always know exactly which file to read.
Why include the title: Gives visibility into what each phase covers without loading full content.
使用TaskCreate(在旧版Claude Code中可使用TodoWrite)为每个阶段创建三个任务条目。包含标题中的内容:
- [ ] 阶段1a:读取/absolute/path/to/phase_01.md — 文档基础设施实施计划
- [ ] 阶段1b:执行任务
- [ ] 阶段1c:代码审核
- [ ] 阶段2a:读取/absolute/path/to/phase_02.md — API集成
- [ ] 阶段2b:执行任务
- [ ] 阶段2c:代码审核
...为什么任务条目中使用绝对路径: 上下文压缩后可能会被总结,任务条目中的绝对路径确保你始终清楚知道要读取哪个文件。
为什么包含标题: 无需加载完整内容即可让用户了解每个阶段的覆盖范围。
3. Execute Each Phase
3. 执行每个阶段
For each phase, follow this cycle:
对每个阶段,遵循以下循环:
3a. Read Phase File (just-in-time)
3a. 读取阶段文件(按需加载)
Mark "Phase Na: Read [path]" as in_progress.
Read ONLY that phase file now. Extract:
- List of tasks in this phase
- Working directory
- Any phase-specific context
Mark "Phase Na: Read" as complete.
将“阶段Na:读取[路径]”标记为in_progress。
现在仅读取该阶段文件。提取:
- 该阶段的任务列表
- 工作目录
- 任何阶段特定的上下文
将“阶段Na:读取”标记为已完成。
3b. Execute All Tasks
3b. 执行所有任务
Mark "Phase Nb: Execute tasks" as in_progress.
Before dispatching, verify test coverage for functionality tasks:
If a functionality task (code that does something) has no tests specified:
- Check if a subsequent task in the same phase provides tests
- If no tests exist anywhere for this functionality → STOP
- This is a plan gap. Surface to user: "Task N implements [functionality] but no corresponding tests exist in the plan. This needs tests before implementation."
Do NOT implement functionality without tests. Missing tests = plan gap, not something to skip.
Execute all tasks in sequence. For each task, dispatch with the phase file path:
task-implementor-fast<invoke name="Task">
<parameter name="subagent_type">ed3d-plan-and-execute:task-implementor-fast</parameter>
<parameter name="description">Implementing Phase X, Task Y: [description]</parameter>
<parameter name="prompt">
Implement Task N from the phase file.
Phase file: [absolute path to phase file]
Task number: N
Read the phase file and implement Task N (look for `<!-- START_TASK_N -->`).
Your job is to:
1. Read the phase file to understand context
2. Apply all relevant skills, such as (if available) ed3d-house-style:coding-effectively
3. Implement exactly what Task N specifies
4. Verify with tests/build/lint
5. Commit your work
6. Report back with evidence
Work from: [directory]
Provide complete report per your agent instructions.
</parameter>
</invoke>For subcomponents (grouped tasks), dispatch once for all tasks in the subcomponent:
<invoke name="Task">
<parameter name="subagent_type">ed3d-plan-and-execute:task-implementor-fast</parameter>
<parameter name="description">Implementing Phase X, Subcomponent A (Tasks 3-5): [description]</parameter>
<parameter name="prompt">
Implement Subcomponent A (Tasks 3, 4, 5) from the phase file.
Phase file: [absolute path to phase file]
Tasks: 3, 4, 5 (look for `<!-- START_SUBCOMPONENT_A -->`)
Read the phase file and implement all tasks in this subcomponent.
Your job is to:
1. Read the phase file to understand context
2. Apply all relevant skills, such as (if available) ed3d-house-style:coding-effectively
3. Implement all tasks in sequence
4. Verify with tests/build/lint after completing all tasks
5. Commit your work (one commit per task, or logical commits)
6. Report back with evidence for each task
Work from: [directory]
Provide complete report covering all tasks.
</parameter>
</invoke>Print each task-implementor's response before moving to the next task.
No code review between tasks. Execute all tasks in the phase first.
After all tasks complete, mark "Phase Nb: Execute tasks" as complete.
将“阶段Nb:执行任务”标记为in_progress。
分配任务前,验证功能任务的测试覆盖率:
如果某个功能任务(实现具体功能的代码)未指定测试:
- 检查同一阶段的后续任务是否提供测试
- 如果该功能完全没有对应的测试 → 立即停止
- 这是计划漏洞。告知用户:“任务N实现了[功能],但计划中没有对应的测试。在实施前需要补充测试。”
切勿在没有测试的情况下实施功能。缺少测试属于计划漏洞,不能跳过。
按顺序执行所有任务。 对每个任务,分配并提供阶段文件路径:
task-implementor-fast<invoke name="Task">
<parameter name="subagent_type">ed3d-plan-and-execute:task-implementor-fast</parameter>
<parameter name="description">实施阶段X,任务Y:[描述]</parameter>
<parameter name="prompt">
从阶段文件中实施任务N。
阶段文件:[阶段文件的绝对路径]
任务编号:N
读取阶段文件并实施任务N(查找`<!-- START_TASK_N -->`标记)。
你的职责是:
1. 读取阶段文件以了解上下文
2. 应用所有相关技能,例如(如果可用)ed3d-house-style:coding-effectively
3. 严格按照任务N的要求实施
4. 通过测试/构建/代码检查验证
5. 提交你的工作
6. 反馈验证证据
工作目录:[目录]
请按照你的Agent指令提供完整报告。
</parameter>
</invoke>对于子组件(分组任务),为子组件中的所有任务分配一次:
<invoke name="Task">
<parameter name="subagent_type">ed3d-plan-and-execute:task-implementor-fast</parameter>
<parameter name="description">实施阶段X,子组件A(任务3-5):[描述]</parameter>
<parameter name="prompt">
从阶段文件中实施子组件A(任务3、4、5)。
阶段文件:[阶段文件的绝对路径]
任务:3、4、5(查找`<!-- START_SUBCOMPONENT_A -->`标记)
读取阶段文件并实施该子组件中的所有任务。
你的职责是:
1. 读取阶段文件以了解上下文
2. 应用所有相关技能,例如(如果可用)ed3d-house-style:coding-effectively
3. 按顺序实施所有任务
4. 完成所有任务后通过测试/构建/代码检查验证
5. 提交你的工作(每个任务提交一次,或按逻辑提交)
6. 反馈每个任务的验证证据
工作目录:[目录]
请提供涵盖所有任务的完整报告。
</parameter>
</invoke>在进入下一个任务前,打印每个task-implementor的响应。
任务之间无需进行代码审核。 先执行完该阶段的所有任务。
所有任务完成后,将“阶段Nb:执行任务”标记为已完成。
3c. Code Review for Phase
3c. 阶段代码审核
Mark "Phase Nc: Code review" as in_progress.
MANDATORY: Use the skill for the review loop.
requesting-code-reviewContext to provide:
- WHAT_WAS_IMPLEMENTED: Summary of all tasks in this phase
- PLAN_OR_REQUIREMENTS: All tasks from this phase
- BASE_SHA: commit before phase started
- HEAD_SHA: current commit
- IMPLEMENTATION_GUIDANCE: absolute path to (only if it exists—omit entirely if the file doesn't exist)
.ed3d/implementation-plan-guidance.md
The implementation guidance file contains project-specific coding standards, testing requirements, and review criteria. When provided, the code reviewer should read it and apply those standards during review.
Note: Test requirements validation happens at final review, not per-phase. Per-phase reviews focus on code quality and whether the phase includes tests for its functionality.
If code reviewer returns a context limit error:
The phase changed too much for a single review. Chunk the review:
- Identify the midpoint of tasks in the phase
- Run code review for first half of tasks (commits for tasks 1 through N/2)
- Fix any issues found
- Run code review for second half of tasks (commits for tasks N/2+1 through N)
- Fix any issues found
When issues are found:
-
Create a task for EACH issue (survives compaction):
TaskCreate: "Phase N fix [Critical]: <VERBATIM issue description from reviewer>" TaskCreate: "Phase N fix [Important]: <VERBATIM issue description from reviewer>" TaskCreate: "Phase N fix [Minor]: <VERBATIM issue description from reviewer>" ...one task per issue... TaskCreate: "Phase N: Re-review after fixes" TaskUpdate: set "Re-review" blocked by all fix tasksCopy issue descriptions VERBATIM, even if long. After compaction, the task description is all that remains — it must contain the full issue details for the bug-fixer to understand what to fix. -
Dispatchwith the phase file:
task-bug-fixer
<invoke name="Task">
<parameter name="subagent_type">ed3d-plan-and-execute:task-bug-fixer</parameter>
<parameter name="description">Fixing review issues for Phase X</parameter>
<parameter name="prompt">
Fix issues from code review for Phase X.
Phase file: [absolute path to phase file]
Code reviewer found these issues:
[list all issues - Critical, Important, and Minor]
Read the phase file to understand the tasks and context.
Your job is to:
1. Understand root cause of each issue
2. Apply fixes systematically (Critical → Important → Minor)
3. Verify with tests/build/lint
4. Commit your fixes
5. Report back with evidence
Work from: [directory]
Fix ALL issues — including every Minor issue. The goal is ZERO issues on re-review.
Minor issues are not optional. Do not skip them.
</parameter>
</invoke>-
Mark "Fix issues" complete, then re-review per theskill.
requesting-code-review -
If re-review finds more issues, create new fix/re-review tasks. Continue loop until zero issues.
-
Mark "Re-review" complete when zero issues.
Plan execution policy (stricter than general code review):
- ALL issues must be fixed (Critical, Important, AND Minor)
- Ignore APPROVED/BLOCKED status - count issues only
- Three-strike rule: If same issues persist after three review cycles, stop and ask human for help
Minor issues are NOT optional. Do not rationalize skipping them with "they're just style issues" or "we can fix those later." The reviewer flagged them for a reason. Fix every single one.
Exit condition: Zero issues in all categories — including Minor.
Mark "Phase Nc: Code review" as complete.
将“阶段Nc:代码审核”标记为in_progress。
强制要求: 使用技能完成审核循环。
requesting-code-review需提供的上下文:
- WHAT_WAS_IMPLEMENTED:该阶段所有任务的总结
- PLAN_OR_REQUIREMENTS:该阶段的所有任务
- BASE_SHA:阶段开始前的提交哈希
- HEAD_SHA:当前提交哈希
- IMPLEMENTATION_GUIDANCE:的绝对路径(仅当文件存在时提供——如果不存在则完全省略)
.ed3d/implementation-plan-guidance.md
实施指南文件包含项目特定的编码标准、测试要求和审核标准。提供该文件后,代码审核人员应读取并在审核时应用这些标准。
注意: 测试要求验证在最终审核时进行,而非分阶段审核。分阶段审核重点关注代码质量以及阶段是否包含其功能的测试。
如果代码审核人员返回上下文限制错误:
该阶段的变更过多,无法通过单次审核完成。将审核拆分:
- 确定阶段任务的中点
- 对前半部分任务(任务1至N/2的提交)进行代码审核
- 修复发现的问题
- 对后半部分任务(任务N/2+1至N的提交)进行代码审核
- 修复发现的问题
发现问题时:
-
为每个问题创建一个任务(可在压缩后保留):
TaskCreate: "阶段N修复[严重]: <审核人员提供的完整问题描述>" TaskCreate: "阶段N修复[重要]: <审核人员提供的完整问题描述>" TaskCreate: "阶段N修复[次要]: <审核人员提供的完整问题描述>" ...每个问题对应一个任务... TaskCreate: "阶段N:修复后重新审核" TaskUpdate: 将“重新审核”任务设置为需等待所有修复任务完成完整复制问题描述,即使内容很长。上下文压缩后,任务描述是唯一保留的信息——必须包含完整的问题细节,以便bug-fixer了解需要修复的内容。 -
分配并提供阶段文件:
task-bug-fixer
<invoke name="Task">
<parameter name="subagent_type">ed3d-plan-and-execute:task-bug-fixer</parameter>
<parameter name="description">修复阶段X的审核问题</parameter>
<parameter name="prompt">
修复阶段X的代码审核问题。
阶段文件:[阶段文件的绝对路径]
代码审核人员发现以下问题:
[列出所有问题 - 严重、重要和次要]
读取阶段文件以了解任务和上下文。
你的职责是:
1. 理解每个问题的根本原因
2. 系统地修复问题(严重→重要→次要)
3. 通过测试/构建/代码检查验证
4. 提交修复内容
5. 反馈验证证据
工作目录:[目录]
修复所有问题——包括每个次要问题。目标是重新审核时零问题。
次要问题并非可选,请勿跳过。
</parameter>
</invoke>-
将“修复问题”标记为已完成,然后按照技能进行重新审核。
requesting-code-review -
如果重新审核发现更多问题,创建新的修复/重新审核任务。继续循环直至零问题。
-
当零问题时,将“重新审核”标记为已完成。
计划执行策略(比常规代码审核更严格):
- 所有问题必须修复(严重、重要和次要)
- 忽略APPROVED/BLOCKED状态 - 仅统计问题数量
- 三次失败规则: 如果同一问题在三次审核循环后仍然存在,请停止并向用户寻求帮助
次要问题并非可选。 不要以“只是样式问题”或“我们以后再修复”为理由跳过。审核人员标记这些问题是有原因的,必须全部修复。
退出条件: 所有类别(包括次要问题)均为零问题。
将“阶段Nc:代码审核”标记为已完成。
3d. Move to Next Phase
3d. 进入下一阶段
Proceed to the next phase's "Read" step. Repeat 3a-3c for each phase.
进入下一阶段的“读取”步骤。对每个阶段重复3a-3c。
4. Update Project Context
4. 更新项目上下文
After all phases complete, invoke the subagent (when available) to review changes and update CLAUDE.md files if needed.
ed3d-extending-claude:project-claude-librarian<invoke name="Task">
<parameter name="subagent_type">ed3d-extending-claude:project-claude-librarian</parameter>
<parameter name="description">Updating project context after implementation</parameter>
<parameter name="prompt">
Review what changed during this implementation and update CLAUDE.md files if contracts or structure changed.
Base commit: <commit SHA at start of first phase>
Current HEAD: <current commit>
Working directory: <directory>
Follow the ed3d-extending-claude:maintaining-project-context skill to:
1. Diff against base to see what changed
2. Identify contract/API/structure changes
3. Update affected CLAUDE.md files
4. Commit documentation updates
Report back with what was updated (or that no updates were needed).
</parameter>
</invoke>If librarian reports updates: Review the changes, then proceed to final review.
If librarian reports no updates needed: Proceed to final review.
If librarian subagent is unavailable: skip this entire step. Say aloud that you're skipping it because the plugin is not available.
ed3d-extending-claude所有阶段完成后,调用Subagent(如果可用)以审核变更并在需要时更新CLAUDE.md文件。
ed3d-extending-claude:project-claude-librarian<invoke name="Task">
<parameter name="subagent_type">ed3d-extending-claude:project-claude-librarian</parameter>
<parameter name="description">实施完成后更新项目上下文</parameter>
<parameter name="prompt">
审核本次实施期间的变更,如果合约或结构发生变化则更新CLAUDE.md文件。
基准提交:<第一阶段开始时的提交SHA>
当前HEAD:<当前提交SHA>
工作目录:<目录>
按照ed3d-extending-claude:maintaining-project-context技能执行:
1. 与基准版本对比查看变更
2. 识别合约/API/结构变更
3. 更新受影响的CLAUDE.md文件
4. 提交文档更新
反馈更新内容(或说明无需更新)。
</parameter>
</invoke>如果librarian反馈有更新: 审核变更,然后进入最终审核。
如果librarian反馈无需更新: 直接进入最终审核。
如果librarian Subagent不可用: 跳过整个步骤。告知用户你正在跳过该步骤,因为插件不可用。
ed3d-extending-claude5. Final Review Sequence
5. 最终审核流程
After all phases complete, run a sequence of specialized agents:
Code Review → Test Analysis (Coverage + Plan)所有阶段完成后,运行一系列专业Agent:
代码审核 → 测试分析(覆盖率+计划)5a. Final Code Review
5a. 最终代码审核
Use the skill for final code review:
requesting-code-reviewContext to provide:
- WHAT_WAS_IMPLEMENTED: Summary of all phases completed
- PLAN_OR_REQUIREMENTS: Reference to the full implementation plan directory
- BASE_SHA: commit before first phase started
- HEAD_SHA: current commit
- IMPLEMENTATION_GUIDANCE: absolute path (if exists)
- AC_COVERAGE_CHECK: "Verify all acceptance criteria (using scoped format ) from the design plan are covered by at least one phase. Flag any ACs not addressed."
{slug}.AC*
Continue the review loop until zero issues remain.
使用技能进行最终代码审核:
requesting-code-review需提供的上下文:
- WHAT_WAS_IMPLEMENTED:已完成的所有阶段的总结
- PLAN_OR_REQUIREMENTS:完整实施计划目录的引用
- BASE_SHA:第一阶段开始前的提交哈希
- HEAD_SHA:当前提交哈希
- IMPLEMENTATION_GUIDANCE:绝对路径(如果存在)
- AC_COVERAGE_CHECK:“验证设计计划中的所有验收标准(使用的格式)至少被一个阶段覆盖。标记任何未被覆盖的验收标准。”
{slug}.AC*
继续审核循环直至无问题。
5b. Test Analysis
5b. 测试分析
Only after final code review passes with zero issues.
Skip this step if test-requirements.md does not exist.
The test-analyst agent performs two sequential tasks with shared analysis:
- Validate coverage against acceptance criteria
- Generate human test plan (only if coverage passes)
Dispatch the test-analyst agent:
<invoke name="Task">
<parameter name="subagent_type">ed3d-plan-and-execute:test-analyst</parameter>
<parameter name="description">Analyzing test coverage and generating test plan</parameter>
<parameter name="prompt">
Analyze test implementation against acceptance criteria.
TEST_REQUIREMENTS_PATH: [absolute path to test-requirements.md]
WORKING_DIRECTORY: [project root]
BASE_SHA: [commit before first phase]
HEAD_SHA: [current commit]
Phase 1: Validate that automated tests exist for all acceptance criteria.
Phase 2: If coverage passes, generate human test plan using your analysis.
Return coverage validation result. If PASS, include the human test plan.
</parameter>
</invoke>If analyst returns coverage FAIL:
-
Dispatch bug-fixer to add missing tests:
<invoke name="Task"> <parameter name="subagent_type">ed3d-plan-and-execute:task-bug-fixer</parameter> <parameter name="description">Adding missing test coverage</parameter> <parameter name="prompt"> Add missing tests identified by the test analyst. Missing coverage: [list from analyst output] For each missing test: 1. Read the acceptance criterion carefully 2. Create the test file at the expected location 3. Write tests that verify the criterion's actual behavior—not just code that passes, but code that would fail if the criterion weren't met 4. Run tests to confirm they pass 5. Commit the new tests Work from: [directory] </parameter> </invoke> -
Re-run test-analyst
-
Repeat until coverage PASS or three attempts fail (then escalate to human)
If analyst returns coverage PASS:
The response will include the human test plan. Extract the "Human Test Plan" section.
Write the test plan:
bash
undefined仅在最终代码审核通过且无问题后执行。
如果test-requirements.md不存在,则跳过此步骤。
test-analyst Agent执行两个连续任务并共享分析结果:
- 验证验收标准的覆盖率
- 生成人工测试计划(仅当覆盖率通过时)
分配test-analyst Agent:
<invoke name="Task">
<parameter name="subagent_type">ed3d-plan-and-execute:test-analyst</parameter>
<parameter name="description">分析测试覆盖率并生成测试计划</parameter>
<parameter name="prompt">
分析测试实施与验收标准的匹配情况。
TEST_REQUIREMENTS_PATH: [test-requirements.md的绝对路径]
WORKING_DIRECTORY: [项目根目录]
BASE_SHA: [第一阶段开始前的提交哈希]
HEAD_SHA: [当前提交哈希]
阶段1:验证所有验收标准都有对应的自动化测试。
阶段2:如果覆盖率通过,使用你的分析结果生成人工测试计划。
返回覆盖率验证结果。如果通过,包含人工测试计划。
</parameter>
</invoke>如果analyst返回覆盖率失败:
-
分配bug-fixer添加缺失的测试:
<invoke name="Task"> <parameter name="subagent_type">ed3d-plan-and-execute:task-bug-fixer</parameter> <parameter name="description">添加缺失的测试覆盖率</parameter> <parameter name="prompt"> 添加测试分析人员识别出的缺失测试。 缺失的覆盖率: [来自analyst输出的列表] 对于每个缺失的测试: 1. 仔细阅读验收标准 2. 在预期位置创建测试文件 3. 编写验证标准实际行为的测试——不仅是能通过的代码,还要编写在标准未满足时会失败的代码 4. 运行测试确认通过 5. 提交新测试 工作目录:[目录] </parameter> </invoke> -
重新运行test-analyst
-
重复直至覆盖率通过或三次尝试失败(然后升级给用户)
如果analyst返回覆盖率通过:
响应中会包含人工测试计划。提取“人工测试计划”部分。
编写测试计划:
bash
undefinedCreate test-plans directory if needed
如有需要,创建test-plans目录
mkdir -p docs/test-plans
mkdir -p docs/test-plans
The filename uses the implementation plan directory name
文件名使用实施计划目录的名称
e.g., impl plan dir: docs/implementation-plans/2025-01-24-oauth/
例如:实施计划目录:docs/implementation-plans/2025-01-24-oauth/
test plan: docs/test-plans/2025-01-24-oauth.md
测试计划: docs/test-plans/2025-01-24-oauth.md
Write the test plan content to `docs/test-plans/[impl-plan-dir-name].md`, then commit:
```bash
git add docs/test-plans/[impl-plan-dir-name].md
git commit -m "docs: add test plan for [feature name]"Announce: "Human test plan written to "
docs/test-plans/[impl-plan-dir-name].md
将测试计划内容写入`docs/test-plans/[impl-plan-dir-name].md`,然后提交:
```bash
git add docs/test-plans/[impl-plan-dir-name].md
git commit -m "docs: add test plan for [feature name]"告知用户:“人工测试计划已写入”
docs/test-plans/[impl-plan-dir-name].md6. Complete Development
6. 完成开发
After final review passes:
-
Provide a report to the human operator
- For each phase:
- How many tasks were implemented
- How many review cycles were needed
- Any compromises made (there should be NO compromises, but if any were made). Examples:
- "I couldn't run the integration tests, so I continued on"
- "I couldn't generate the client because the dev environment was down"
- Note that these are PARTIAL FAILURE CASES and explain to the user what the user must do now.
- Were any code-review issues left outstanding at any point?
- For each phase:
-
Activate theskill. DO NOT activate it before this point.
finishing-a-development-branch
最终审核通过后:
-
向用户提供报告
- 对每个阶段:
- 实施的任务数量
- 需要的审核循环次数
- 做出的任何妥协(应该没有妥协,但如果有)。例如:
- “我无法运行集成测试,所以继续执行”
- “我无法生成客户端,因为开发环境已关闭”
- 注意这些是部分失败情况,并向用户说明他们现在必须采取的措施。
- 是否有任何代码审核问题未解决?
- 对每个阶段:
-
激活技能。切勿在此之前激活。
finishing-a-development-branch
Example Workflow
示例工作流
You: I'm using the `executing-an-implementation-plan` skill.
[Discover phases: phase_01.md, phase_02.md, phase_03.md]
[Read first 3 lines of each to get titles]
[Create tasks with TaskCreate:]
- [ ] Phase 1a: Read /path/to/phase_01.md — Project Setup
- [ ] Phase 1b: Execute tasks
- [ ] Phase 1c: Code review
- [ ] Phase 2a: Read /path/to/phase_02.md — Token Service
- [ ] Phase 2b: Execute tasks
- [ ] Phase 2c: Code review
- [ ] Phase 3a: Read /path/to/phase_03.md — API Middleware
- [ ] Phase 3b: Execute tasks
- [ ] Phase 3c: Code review
--- Phase 1 ---
[Mark 1a in_progress, read phase_01.md]
→ Contains 2 tasks: project setup, config files
[Mark 1a complete, 1b in_progress]
[Dispatch task-implementor-fast for Task 1]
→ Created package.json, tsconfig.json.
[Dispatch task-implementor-fast for Task 2]
→ Created config files. Build succeeds.
[Mark 1b complete, 1c in_progress]
[Use requesting-code-review skill for phase 1]
→ Zero issues.
[Mark 1c complete]
--- Phase 2 ---
[Mark 2a in_progress, read phase_02.md]
→ Contains 3 tasks: types, service, tests
[Mark 2a complete, 2b in_progress]
[Execute all 3 tasks...]
[Mark 2b complete, 2c in_progress]
[Use requesting-code-review skill for phase 2]
→ Important: 1, Minor: 1
→ Dispatch bug-fixer, re-review
→ Zero issues.
[Mark 2c complete]
--- Phase 3 ---
[Similar pattern...]
--- Finalize ---
[Invoke project-claude-librarian subagent]
→ Updated CLAUDE.md.
[Use requesting-code-review skill for final review]
→ All requirements met.
[Transitioning to finishing-a-development-branch]你:我正在使用`executing-an-implementation-plan`技能。
[发现阶段:phase_01.md, phase_02.md, phase_03.md]
[读取每个文件的前3行获取标题]
[使用TaskCreate创建任务:]
- [ ] 阶段1a:读取/path/to/phase_01.md — 项目设置
- [ ] 阶段1b:执行任务
- [ ] 阶段1c:代码审核
- [ ] 阶段2a:读取/path/to/phase_02.md — 令牌服务
- [ ] 阶段2b:执行任务
- [ ] 阶段2c:代码审核
- [ ] 阶段3a:读取/path/to/phase_03.md — API中间件
- [ ] 阶段3b:执行任务
- [ ] 阶段3c:代码审核
--- 阶段1 ---
[标记1a为in_progress,读取phase_01.md]
→ 包含2个任务:项目设置、配置文件
[标记1a为已完成,1b为in_progress]
[分配task-implementor-fast执行任务1]
→ 创建了package.json、tsconfig.json。
[分配task-implementor-fast执行任务2]
→ 创建了配置文件。构建成功。
[标记1b为已完成,1c为in_progress]
[使用requesting-code-review技能进行阶段1审核]
→ 无问题。
[标记1c为已完成]
--- 阶段2 ---
[标记2a为in_progress,读取phase_02.md]
→ 包含3个任务:类型定义、服务、测试
[标记2a为已完成,2b为in_progress]
[执行所有3个任务...]
[标记2b为已完成,2c为in_progress]
[使用requesting-code-review技能进行阶段2审核]
→ 重要问题:1,次要问题:1
→ 分配bug-fixer,重新审核
→ 无问题。
[标记2c为已完成]
--- 阶段3 ---
[类似流程...]
--- 最终完成 ---
[调用project-claude-librarian Subagent]
→ 更新了CLAUDE.md。
[使用requesting-code-review技能进行最终审核]
→ 所有要求均已满足。
[过渡到finishing-a-development-branch]Common Rationalizations - STOP
常见错误理由 - 切勿这样做
| Excuse | Reality |
|---|---|
| "I'll read all phases upfront to understand the full picture" | No. Read one phase at a time. Context limits are real. |
| "I'll skip the read step, I remember what's in the file" | No. Always read just-in-time. Context may have been compacted. |
| "I'll review after each task to catch issues early" | No. Review once per phase. Task-level review wastes context. |
| "Context error on review, I'll skip the review" | No. Chunk the review into halves. Never skip review. |
| "Minor issues can wait" | No. Fix ALL issues including Minor. |
| 借口 | 实际情况 |
|---|---|
| “我提前读取所有阶段以了解全局” | 不行。一次读取一个阶段。上下文限制是真实存在的。 |
| “我跳过读取步骤,我记得文件内容” | 不行。始终按需读取。上下文可能已被压缩。 |
| “我在每个任务后进行审核以尽早发现问题” | 不行。每个阶段审核一次。任务级审核会浪费上下文。 |
| “审核时出现上下文错误,我跳过审核” | 不行。将审核拆分为两部分。永远不要跳过审核。 |
| “次要问题可以以后再处理” | 不行。修复所有问题包括次要问题。 |