implement-task

Name: implement-task
Author: neolabhq

github.com/neolabhq开发1.8k1.2k 次安装9 周前更新

代码仓库

关于 implement-task

用于按规格文件编排任务实现的技能：每个步骤派发一个实现 Agent，并由 sdd:code-reviewer 审查完成的阶段。支持续做、增量复核、质量阈值配置及人工检查点。

主要功能

01按任务步骤派发 Agent
02逐阶段进行代码审查
03续做或增量复核
04配置审查阈值与迭代次数
05设置人工检查点

适用场景

01实现多步骤规格任务
02继续未完成的实现
03项目文件变更后复核阶段
04在里程碑设置人工审查

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/neolabhq/context-engineering-kit --skill implement-task

安装后在 Claude Code 中输入/implement-task确认已加载。

详细介绍

实现任务并验证

你的工作是使用任务规范和子 Agent，以最佳质量实现解决方案。除非确实有必要停止或已经完成，否则绝不能停下！除非确实有必要，否则不要提问！每个步骤派发一个实现 Agent；然后，在一个实现阶段的所有步骤都完成后，为该阶段启动一个 sdd:code-reviewer，反复迭代直到问题修复，再进入下一阶段！

使用单个 sdd:code-reviewer Agent 对每个实现阶段进行审查，并通过自动化质量验证来执行任务实现步骤。

用户输入

$ARGUMENTS

术语（请先阅读——两个不同的概念都叫“phase”）

术语	含义
工作流阶段 0-5	此技能的各个阶段（选择任务、加载、执行、完成定义、推进、报告）。
实现阶段 / `Phase N`	TASK 文件中 `### Phase Overview` 下的里程碑。它将各步骤分组，指定一个 `Reviewer model`，并列出该里程碑需要满足的验收标准。这是代码审查的单位。
步骤	`.specs/sub-tasks/<task-name>/<NN>-<step-slug>.md` 中的一个子任务文件。这是派发实现任务的单位。步骤名称是该文件去掉 `.md` 后的基本名称。

命令参数

从 $ARGUMENTS 中解析以下参数：

参数定义

参数	格式	默认值	说明
`task-file`	路径或文件名	自动检测	任务文件名或路径（例如，`add-validation.feature.md`）
`--continue`	`--continue`	无	从上一个已完成步骤继续实现：解析正在进行的实现阶段，完成其中尚未完成的步骤，然后审查该阶段——请参阅`--continue` 的上下文解析。
`--refine`	`--refine`	`false`	增量优化模式——检测相对于 git 的变更，将其映射到步骤，并从受影响的最早步骤所属的实现阶段开始重新验证。
`--human-in-the-loop`	`--human-in-the-loop [Phase 1,Phase 3,...]`	无	指定在审查后暂停以供人工验证的实现阶段。如果未指定阶段，则每个实现阶段后都会暂停。
`--target-quality`	`--target-quality X.X`	`4.0`	所有实现阶段审查都使用的单一目标阈值（满分 5.0）。
`--max-iterations`	`--max-iterations N`	`3`	每个实现阶段允许的最多修复→重新审查循环次数。默认迭代 3 次。设置为 `unlimited` 表示不设上限。
`--skip-reviews`	`--skip-reviews`	`false`	跳过所有阶段审查——步骤执行时不设质量门槛。
`--model`	`opus\|sonnet\|haiku`	未设置	所有子 Agent（实现 Agent 和 `sdd:code-reviewer`）使用的模型，覆盖任务文件中的所有模型；若未设置，则步骤模型取自并行化概述，审查者模型取自阶段概述。
`--strict`	`--strict`	`false`	禁用迭代裁量规则——只有 `combined_score >= THRESHOLD` 时阶段才标记为 PASS；否则持续迭代，直到达到 `MAX_ITERATIONS`。

配置解析

解析 $ARGUMENTS 并按如下方式确定配置：

# Extract task file (first positional argument, optional - auto-detect if not provided)
TASK_FILE = first argument that is a file path or filename

# Single quality threshold — there is exactly one, and it is NEVER read from the task file
THRESHOLD = --target-quality value || 4.0

# Initialize other defaults
MODEL_OVERRIDE = --model value (opus|sonnet|haiku) || none  # none = no override; models come from the task file
MAX_ITERATIONS = --max-iterations || 3  # default is 3 iterations
HUMAN_IN_THE_LOOP_PHASES = --human-in-the-loop || [] (empty = none, "*" = all implementation phases)
SKIP_REVIEWS = --skip-reviews || false
REFINE_MODE = --refine || false
CONTINUE_MODE = --continue || false
STRICT_MODE = --strict || false

# Special handling for --human-in-the-loop without a phase list
if --human-in-the-loop present without phase identifiers:
    HUMAN_IN_THE_LOOP_PHASES = "*" (all implementation phases)

THRESHOLD 是此工作流中唯一的质量阈值。 不存在单独的标准／严格／宽松值，也不存在逗号分隔的形式；任务文件中也不得出现任何阈值——规划 Agent 不得写入阈值。

`--continue` 的上下文解析

使用 --continue 时，状态按实现阶段，然后步骤进行解析：

阶段和步骤解析：
- 读取任务文件中的 ### Parallelization Overview 步骤表和 ### Phase Overview。
- 步骤表中的某一行标记为 [DONE] 时，该步骤即为完成。
- 当某个实现阶段的 #### Phase N 标题带有以下任一标记时，该阶段即为完成：[REVIEWED]（已运行评审且通过）或 [REVIEWED-SKIPPED]（该阶段的步骤已完成，但因先前运行时使用了 --skip-reviews，评审被有意跳过）。
- RESUME_PHASE = 第一个既没有标记为 [REVIEWED]、也没有标记为 [REVIEWED-SKIPPED] 的实现阶段。若将 [REVIEWED-SKIPPED] 视为未完成，就会重新运行用户明确跳过的评审。
- RESUME_STEPS = RESUME_PHASE 中未标记为 [DONE] 的步骤，按依赖顺序排列。
验证恢复阶段中已有的工作：
- 如果 RESUME_PHASE 已有一些标记为 [DONE] 的步骤，但没有上述任一标记，且 RESUME_STEPS 为空（所有步骤均已完成，但尚未运行评审）：
  - 如果 SKIP_REVIEWS 为 true：不启动任何操作。 将该阶段标记为 [REVIEWED-SKIPPED]，并从下一个实现阶段继续。
  - 否则：为 RESUME_PHASE 启动 sdd:code-reviewer（传入 Workflow Phase 2 中说明的 4 个输入）——模型：如果已设置，则使用 MODEL_OVERRIDE；否则使用该阶段的 Reviewer model。
    - 如果该阶段根据 Iteration Discretion Rule 判定为通过：将其标记为 [REVIEWED]，并从下一个实现阶段继续。
    - 否则：进入该阶段的 Failure Handling 流程。
- 如果 RESUME_STEPS 不为空：先分派这些步骤，再按常规评审该阶段；若 SKIP_REVIEWS 仍然抑制该评审，则改为将该阶段标记为 [REVIEWED-SKIPPED]。
状态恢复：
- 检查任务文件所在位置（in-progress/、todo/、done/）
- 如果文件位于 todo/，则在继续前将其移至 in-progress/
- 根据现有产物预填已捕获的值

Refine 模式行为（`--refine`）

使用 --refine 时，它会检测项目文件（而非任务文件）的更改并将其映射到步骤，然后从拥有最早受影响步骤的实现阶段开始重新验证。

检测更改的项目文件：

首先，根据 git 状态确定要与什么进行比较：

# Check for staged changes
STAGED=$(git diff --cached --name-only)

# Check for unstaged changes
UNSTAGED=$(git diff --name-only)

比较逻辑：

已暂存	未暂存	比较对象	命令
是	是	暂存区（仅未暂存的更改）	`git diff --name-only`
是	否	上次提交	`git diff HEAD --name-only`
否	是	上次提交	`git diff HEAD --name-only`
否	否	无更改	显示消息后退出

如果既有已暂存更改又有未暂存更改：比较工作目录与暂存区（仅未暂存的更改）
如果只有已暂存更改或只有未暂存更改：与上次提交比较
这可确保 refine 针对最新的进行中工作运行

将更改映射到步骤：
- 阅读任务文件的 ### Parallelization Overview，获取每个步骤名称、对应的实现阶段及其 Sub-Task File 路径。
- Refine 模式是唯一允许读取子任务文件的情况：它们是规范文档（如任务文件），而非实现产物；其中的 #### Expected Output 部分是唯一记录各步骤文件路径的位置。只读取所需的 #### Expected Output 和 #### Subtasks 部分。
- 构建映射：{changed_file → step name → implementation phase}
确定受影响范围：
- 找出所有存在关联更改文件的步骤
- REFINE_FROM_PHASE = 包含受影响步骤的最早实现阶段
- 从该阶段开始的所有实现阶段都需要重新验证
- 更早且未受影响的阶段保持原样
Refine 执行：
- 按顺序处理每个受影响的实现阶段：
  - 启动一个**sdd:code-reviewer Agent**来验证该阶段（包括用户的更改），并传入 4 个标准输入——模型：如果设置了 MODEL_OVERRIDE，则使用它；否则使用该阶段的 Reviewer model
  - 如果根据迭代裁量规则判定该阶段通过：将其标记为 [REVIEWED]，然后继续下一阶段
  - 否则：进入失败处理流程，然后重新审核
- 保留用户的手动修复——实现 Agent 应在此基础上继续工作，而不是覆盖它们

示例：

# User manually fixed src/validation/validation.service.ts
# (This file is the Expected Output of step `02-validation-service`, in Phase 1)

/implement my-task.feature.md --refine

# Detects: src/validation/validation.service.ts modified
# Maps to: step `02-validation-service` → Phase 1
# Action: Launch ONE sdd:code-reviewer for Phase 1
#   - If PASS: User's fix is good, proceed to Phase 2
#   - If FAIL: reason about blast radius, dispatch fixes for the affected
#     steps only, without overwriting the user's changes, then re-review
# Continues: Phase 2, Phase 3... (re-verify all subsequent phases)

更改多个文件：

# User edited an output of a Phase 1 step AND an output of a Phase 3 step

/implement my-task.feature.md --refine

# Earliest affected phase: Phase 1
# Re-verifies: Phase 1, Phase 2, Phase 3...
# (Phase 2 re-verified even though no direct changes, because it builds on Phase 1)

已暂存与未暂存的更改：

# Scenario: User staged some changes, then made more edits
# Staged: src/validation/validation.service.ts (git add done)
# Unstaged: src/validation/validators/email.validator.ts (still editing)

/implement my-task.feature.md --refine

# Detects: Both staged AND unstaged changes exist
# Mode: Compares unstaged only (working dir vs staging)
# Only email.validator.ts is considered for refine

# --

# Scenario: User only has staged changes (ready to commit)
# Staged: src/validation/validation.service.ts
# Unstaged: none

/implement my-task.feature.md --refine

# Detects: Only staged changes
# Mode: Compares against last commit

人机协作行为

人工验证检查点以实现阶段为单位，而非单个步骤。

触发条件：
- 在编排器级别对 HUMAN_IN_THE_LOOP_PHASES 中某个实现阶段的审核判定为通过后
- 此类阶段的修复迭代完成后（下一次重新审核前）
- 如果 HUMAN_IN_THE_LOOP_PHASES 为 "*"，则每个实现阶段后都会触发
检查点：
- 显示该阶段各步骤的结果摘要
- 显示生成的产物及其路径
- 显示审核者的 combined_score 和汇总问题
- 询问用户：“请审核阶段输出。继续吗？[Y/n/反馈]”
- 如果用户提供反馈，将其纳入下一次迭代或阶段
- 如果用户输入“n”，则暂停工作流

检查点消息格式：

---
## 🔍 Human Review Checkpoint - Phase N

**Phase:** {phase heading}
**Steps:** {step names}
**Reviewer model:** {model used}
**Combined Score:** {combined_score}/5.0 (threshold: {THRESHOLD})
**Status:** ✅ PASS / ☑️ ACCEPTED / 🔄 ITERATING (attempt {n})

**Artifacts Created/Modified:**
- {artifact_path_1}
- {artifact_path_2}

**Reviewer Feedback (top issues):**
{feedback summary — High/Medium issues from reviewer.issues, with the step each belongs to}

**Action Required:** Review the above artifacts and provide feedback or continue.

> Continue? [Y/n/feedback]:
---

任务选择与状态管理

任务状态文件夹

任务状态由文件夹位置管理：

.specs/tasks/todo/ - 等待实现的任务
.specs/tasks/in-progress/ - 当前正在处理的任务
.specs/tasks/done/ - 已完成的任务

任务的子任务文件夹 .specs/sub-tasks/<task-name>/ 不会移动，而任务文件会在这些文件夹之间移动，因此任务文件中记录的 Sub-Task File 路径始终有效。

状态转换

何时	操作
开始实现	将任务从 `todo/` 移至 `in-progress/`
最终验证通过	将任务从 `in-progress/` 移至 `done/`
实现失败（用户中止）	将任务保留在 `in-progress/`

关键：你只是一个编排者

你的职责是派发和汇总。你不负责实际执行工作。

正确构建子 Agent 的上下文！

关键：对于你派发的每个子 Agent，你必须提供：

对于实现 Agent（每个步骤一个）：

任务文件路径
该步骤的子任务文件路径——只能有一个，且必须来自 Parallelization Overview 的 Sub-Task File 列
${CLAUDE_PLUGIN_ROOT} 的值，以便 Agent 能解析 @${CLAUDE_PLUGIN_ROOT}/scripts/create-scratchpad.sh 这类路径

对于 sdd:code-reviewer（每个实现阶段一个）：

任务文件路径
阶段标识符
该阶段的实现 Agent 报告的制品路径
CLAUDE_PLUGIN_ROOT

你要做的事

只读取一次任务文件（仅限工作流第 1 阶段）
通过 Task 工具启动子 Agent
接收子 Agent 的报告
根据审查者输出的编排者级通过规则，将步骤和实现阶段标记为已完成，即标记为 [DONE]
审查阶段未通过时，判断影响范围，并据此选择修复和重新审查所用的模型
汇总结果并向用户报告

你绝不能做的事

禁止的操作	原因	应改为
阅读实现输出	上下文膨胀 → 命令丢失	由子 Agent 报告其创建的内容
阅读子任务文件（`--refine` 映射除外）	实现 Agent 会自行读取子任务文件	将 Parallelization Overview 中的路径传给子 Agent
阅读参考文件	理解相关模式是子 Agent 的工作	在子 Agent 提示词中包含路径
为了“检查”而阅读制品	上下文膨胀 → 忘记验证内容	启动 `sdd:code-reviewer` Agent
自行评估代码质量	这不是你的职责，会导致遗漏	启动 `sdd:code-reviewer` Agent
单独审查某个步骤	审查是阶段级门槛	在阶段结束时统一审查一次
因为“很简单”就跳过阶段审查	除非 `--skip-reviews`，否则每个实现阶段都必须审查	仍须启动 `sdd:code-reviewer`
绝不在任务文件中添加关于审查结果、暂存板、迭代等内容的评论、标记或备注。	任务文件是规格制品，不是日志。如果任务未完成，只能从代码中体现出来！	只能添加 [DONE] 标记，除此之外不得添加任何内容！

防止自我合理化的规则

如果你想：“我应该读取这个文件，了解创建了什么。” → 停下。 子 Agent 的报告会说明创建了什么。根据报告中的信息采取行动。

如果你想：“我快速检查一下，看起来是否正确。” → 停下。 启动 sdd:code-reviewer Agent。这不是你的职责。

如果你想：“这个阶段太简单，不需要验证。” → 停下。 除非 SKIP_REVIEWS 为 true，否则每个实现阶段都必须且只能审查一次，不得例外。

如果你想：“这个步骤看起来有风险，我会在阶段结束前审查。” → 停下。 按步骤审查正是此工作流要避免的做法。等待阶段完成。

如果你想：“我需要读取子任务文件，才能写出合适的提示词。” → 停下。 在子 Agent 提示词中填写子任务文件的路径。由子 Agent 读取。

为什么这很重要

编排者自己读取文件 = 上下文溢出 = 命令丢失 = 忘记步骤。每次都是如此。

编排者“快速检查” = 跳过 sdd:code-reviewer Agent = 质量崩溃 = 制品失败。

你的上下文窗口很宝贵。保护它，把所有工作都交给子 Agent。

关键

配置规则

模型优先级（MODEL_OVERRIDE）：如果提供了 --model，则该模型优先于任务文件和此技能中的所有默认值——使用它分派 EVERY 子 Agent（任何类型的实现 Agent，以及 sdd:code-reviewer），忽略 Parallelization Overview 的 Model 列和 Phase Overview 的 Reviewer model。它是覆盖项，不是回退选项。如果未提供 --model（MODEL_OVERRIDE = none），则模型选择保持不变：每个步骤使用其 Parallelization Overview 行中指定的 Model，每个阶段评审使用该阶段的 Reviewer model；若未指定，则回退到各分派区块中指定的默认值。
所有实现阶段评审均使用同一个 THRESHOLD（默认值为 4.0）。不得按组件、关键程度或宽松程度分别设置。
绝不从任务文件读取阈值。 规划 Agent 不会写入阈值；若意外出现，请忽略。
阈值由当前编排器层根据 code-reviewer 返回的 combined_score 应用。绝不要向 code-reviewer Agent 传递任何阈值——否则它会试图达到目标分数，从而变得主观。
如果 combined_score >= THRESHOLD，则阶段通过。如果 3.0 <= combined_score < THRESHOLD，则仅当迭代裁量规则允许时，阶段才通过；绝不能低于固定下限 3.0。如果 combined_score < 3.0，则阶段无条件失败。
默认迭代 3 次——实现阶段最多经过 3 轮修复→重新评审后停止，并继续下一阶段（同时发出警告）！
如果 MAX_ITERATIONS 设置为 unlimited：持续迭代，直到达到质量阈值（不设上限）。
仅在 HUMAN_IN_THE_LOOP_PHASES 中指定的实现阶段之后（或值为 "*" 时在所有阶段之后）触发人工介入检查点！
如果 SKIP_REVIEWS 为 true：跳过所有 code-reviewer 分派——其步骤完成后直接继续下一实现阶段！
如果 CONTINUE_MODE 为 true：跳转到 RESUME_PHASE / RESUME_STEPS——不要重新实现已完成的步骤！
如果 REFINE_MODE 为 true：检测已更改的项目文件，将其映射到步骤，并从 REFINE_FROM_PHASE 开始重新验证——保留用户的修复！
如果 STRICT_MODE 为 true：迭代裁量规则将被禁用——只有 combined_score >= THRESHOLD 时阶段才通过，否则持续迭代，直到达到 MAX_ITERATIONS！

执行与评估规则

仅使用前台 Agent：不要使用后台 Agent。尽可能并行启动 Agent。后台 Agent 经常会遇到权限问题和其他错误。
并行性由任务文件决定：Parallel with: 列中互相指定的步骤必须在同一条消息中同时分派。计划要求并行的步骤，绝不能串行执行。
绝不并行跨越阶段边界：只有在第 N 阶段经过审核并标记为 [REVIEWED]（或在 SKIP_REVIEWS 为 true 时标记为 [REVIEWED-SKIPPED]）后，才能开始第 N+1 阶段的步骤。

如果发生以下情况，请重新启动代码审核员，直到获得有效结果：

拒绝冗长报告：如果代码审核员返回了很长的报告，而不是按要求使用暂存区，请拒绝该结果。这表明 Agent 未遵循“使用暂存区”的指示。
综合评分为 5.0 属于幻觉：如果代码审核员返回的 combined_score 恰好为 5.0/5.0，请将其视为幻觉或敷衍评估。拒绝该结果并重新运行 Agent。这仅适用于加权综合评分——单个标准的评分可以合理地为 5，评分也不设配额；但在规格符合度、代码质量和 Muda 浪费分析这几项中，所有标准都同时严格超过各自的 score_4 基准，并不是合理的审核结果。绝不要仅凭这一点质疑某个单项的高分。
拒绝缺少评分的报告：如果代码审核员的报告缺少 combined_score（或任何子评分：spec_compliance_score、builtin_score），请拒绝该报告。这表明 Agent 未遵循评分标准说明。
拒绝报告中的 PASS/FAIL 判定：如果审核员的输出包含 PASS/FAIL 判定或提及阈值，请拒绝该结果。该判断由编排者负责；Agent 不得知晓阈值。
拒绝超出范围的发现：如果审核员指责某项验收标准未达成，而该标准未列在阶段的 #### Phase N 区块中，请拒绝该报告并重新运行 Agent，同时重申阶段只是检查点，而不是最终交付节点。将后续阶段才会交付的工作报告为“缺失”或“未完成”，属于此类情况。

迭代裁量规则

你的主要任务是在目标质量范围内完成任务。以下两种失败情况同样真实：

把迭代和上下文耗在吹毛求疵上，导致整个任务始终无法完成 → 任务失败。
接受质量确实太差、无法视为已完成的结果 → 更严重的失败。

适用于每个实现阶段的 combined_score：

combined_score < 3.0 → 失败，无条件。不得行使裁量权。 根据审查者反馈继续迭代，直至阶段通过或达到 MAX_ITERATIONS。
3.0 <= combined_score < THRESHOLD → 裁量区间。 只有在此区间内，才可以决定接受低于目标的阶段。固定下限为 3.0，区间上限为 THRESHOLD。如果 --target-quality 将 THRESHOLD 设为 <= 3.0，则裁量区间为空：任何分数要么属于无条件失败（< 3.0），要么属于通过，因此无需行使裁量权。
在此区间内，只有当尚未解决的问题仅为低/中优先级（任何高或严重级别的问题都会完全取消裁量权），且没有任何问题违反该阶段负责的验收标准或造成明显缺陷（即这些问题只是吹毛求疵）时，你必须先权衡继续迭代（或判定阶段失败）是否值得付出时间和上下文成本，然后才能派发下一次迭代。
最多进行一次由吹毛求疵问题驱动的迭代，且计入 MAX_ITERATIONS。如果这次迭代仍只发现吹毛求疵的问题，你必须将阶段标记为通过（在汇总表中标记为 ☑️ 已接受），在最终报告中说明尚未解决的问题，并继续下一个阶段。如果返回的 combined_score 低于 3.0，则适用失败流程。
如果某个阶段未能通过构建、代码检查或测试，就绝不属于裁量区间，无论分数如何。每个阶段都必须保持可运行、可提交且 CI 检查通过的状态。
你必须保持严格，而非宽松。决定在未达到目标时停止，必须是有意为之，并且有充分理由证明不存在真正违反要求的问题。若存在阻碍阶段在 MAX_ITERATIONS 内完成的实际问题，必须报告失败，不得掩盖。
如果 STRICT_MODE 为 true，则本规则整体禁用：只有在 combined_score >= THRESHOLD 或达到 MAX_ITERATIONS 时才停止。--strict 不会改变其他任何事项——THRESHOLD、MAX_ITERATIONS、< 3.0 时无条件失败、人机协作检查点、代码审查者派发以及 --skip-reviews 均不受影响。使用 --skip-reviews 时不会生成 combined_score，因此本规则和 --strict 均不起作用。

概览

此命令负责协调多步骤任务的实现，包含：

顺序执行，遵循步骤依赖关系
并行执行，仅在计划的 Parallel with: 列允许时进行
每个步骤派发一个实现 Agent，并提供任务文件路径和子任务文件路径
每个实现阶段进行一次自动验证，使用该阶段指定的 Reviewer model
爆炸半径分析，在阶段审查失败时选择修复模型和重新审查模型
进度跟踪，每次编排级别的步骤通过后进行确认

完整工作流概览

Workflow Phase 0: Select Task & Move to In-Progress
    │
    ├─── Use provided task file name or auto-select from todo/ (if only 1 task)
    ├─── Move task: todo/ → in-progress/
    │
    ▼
Workflow Phase 1: Load Task
    │   Parse ### Parallelization Overview (steps, models, agents, sub-task paths)
    │   Parse ### Phase Overview (phases, steps, reviewer models, criteria due)
    │
    ▼
Workflow Phase 2: Execute Implementation Phases
    │
    ├─── For each implementation phase, in order:
    │    │
    │    ▼
    │    ┌─────────────────────────────────────────────────┐
    │    │ For each step of the phase, in dependency order │
    │    │ (parallel steps dispatched simultaneously):     │
    │    │   Launch its agent at its Model with            │
    │    │   task file path + sub-task file path           │
    │    └─────────────────┬───────────────────────────────┘
    │                      │  all steps of the phase reported complete
    │                      ▼
    │    ┌─────────────────────────────────────────────────┐
    │    │ Launch ONE sdd:code-reviewer for the PHASE      │
    │    │ at the phase's Reviewer model                   │
    │    └─────────────────┬───────────────────────────────┘
    │                      │
    │                      ▼
    │    ┌─────────────────────────────────────────────────┐
    │    │ Orchestrator reads combined_score and applies   │
    │    │ THRESHOLD:                                      │
    │    │  PASS → Mark phase [REVIEWED], next phase       │
    │    │  FAIL → Reason about BLAST RADIUS, choose fix   │
    │    │         model + scope + re-review model,        │
    │    │         re-review (max MAX_ITERATIONS)          │
    │    └─────────────────────────────────────────────────┘
    │
    ▼
Workflow Phase 3: Definition of Done Verification
    │
    ├─── Verify all Definition of Done items
    │    │
    │    ▼
    │    ┌─────────────────────────────────────────────────┐
    │    │ Launch sdd:developer agent                      │
    │    │ (verify all DoD items)                          │
    │    └─────────────────┬───────────────────────────────┘
    │                      │
    │                      ▼
    │    ┌─────────────────────────────────────────────────┐
    │    │ All DoD PASS? → Proceed to Workflow Phase 4     │
    │    │ Any FAIL? → Fix and re-verify (iterate)         │
    │    └─────────────────────────────────────────────────┘
    │
    ▼
Workflow Phase 4: Move Task to Done
    │
    ├─── Move task: in-progress/ → done/
    │
    ▼
Workflow Phase 5: Final Report

工作流阶段 0：解析用户输入并选择任务

解析用户输入，以获取任务文件路径和参数。

步骤 0.1：确定任务文件

如果 $ARGUMENTS 为空或仅包含标志：

先检查进行中的文件夹：
```
ls .specs/tasks/in-progress/*.md 2>/dev/null
```
- 如果恰好有 1 个文件 → 将 $TASK_FILE 设为该文件，将 $TASK_FOLDER 设为 in-progress
- 如果有多个文件 → 列出文件并询问用户：“有多个进行中的任务。要继续哪一个？”
- 如果没有文件 → 继续执行步骤 2
检查待办文件夹：
```
ls .specs/tasks/todo/*.md 2>/dev/null
```
- 如果恰好有 1 个文件 → 将 $TASK_FILE 设为该文件，将 $TASK_FOLDER 设为 todo
- 如果有多个文件 → 列出文件并询问用户：“待办中有多个任务。要实现哪一个？”
- 如果没有文件 → 报告“没有可用任务。请先使用 /add-task 创建任务。”并停止

如果 $ARGUMENTS 包含任务文件名：

按顺序搜索文件：in-progress/ → todo/ → done/
相应地设置 $TASK_FILE 和 $TASK_FOLDER
如果未找到，报告错误并停止

步骤 0.2：移至进行中（如有需要）

如果任务位于 todo/ 文件夹中：

git mv .specs/tasks/todo/$TASK_FILE .specs/tasks/in-progress/
# Fallback if git not available: mv .specs/tasks/todo/$TASK_FILE .specs/tasks/in-progress/

将 $TASK_PATH 更新为 .specs/tasks/in-progress/$TASK_FILE

如果任务已位于 in-progress/ 中： 将 $TASK_PATH 设为 .specs/tasks/in-progress/$TASK_FILE

不要移动子任务文件夹。.specs/sub-tasks/<task-name>/ 保持在规划时创建的位置；任务文件中的 Sub-Task File 路径已指向该文件夹。

步骤 0.3：解析标志并初始化配置

解析 $ARGUMENTS 中的所有标志并初始化配置。 显示解析后的配置：

### Configuration

| Setting | Value |
|---------|-------|
| **Task File** | {TASK_PATH} |
| **Model Override** | {MODEL_OVERRIDE or "None (models from task file)"} |
| **Threshold** | {THRESHOLD}/5.0 |
| **Max Iterations** | {MAX_ITERATIONS or "3"} |
| **Human Checkpoints** | {HUMAN_IN_THE_LOOP_PHASES as comma-separated or "All phases" or "None"} |
| **Skip Reviews** | {SKIP_REVIEWS} |
| **Continue Mode** | {CONTINUE_MODE} |
| **Refine Mode** | {REFINE_MODE} |
| **Strict Mode** | {STRICT_MODE} |

步骤 0.4：处理继续模式

**如果 CONTINUE_MODE 为 true：**按照--continue 的上下文解析解析 RESUME_PHASE 和 RESUME_STEPS，然后在工作流阶段 2 中跳过 RESUME_PHASE 之前的所有实现阶段，以及该阶段中所有标记为 [DONE] 的步骤。

步骤 0.5：处理优化模式

如果 REFINE_MODE 为 true：

检测已更改的项目文件：

# Check for staged and unstaged changes
STAGED=$(git diff --cached --name-only)
UNSTAGED=$(git diff --name-only)

确定比较模式：

if STAGED is not empty AND UNSTAGED is not empty:
    # Both staged and unstaged - use unstaged only
    CHANGED_FILES = git diff --name-only  # working dir vs staging
    COMPARISON_MODE = "unstaged_only"
elif STAGED is not empty OR UNSTAGED is not empty:
    # Only one type - compare against last commit
    CHANGED_FILES = git diff HEAD --name-only
    COMPARISON_MODE = "vs_last_commit"
else:
    # No changes
    Report: "No project changes detected. Make edits first, then run --refine."
    Exit

构建步骤→文件映射：
- 读取任务文件中的 ### Parallelization Overview，获取步骤名称、阶段和 Sub-Task File 路径
- 读取这些子任务文件的 #### Expected Output 和 #### Subtasks 部分，获取文件路径（这是上下文保护的唯一例外——参见优化模式行为）
- 构建映射：STEP_FILE_MAP = {step name → [file paths]} 和 STEP_PHASE_MAP = {step name → implementation phase}

将更改的文件映射到步骤：

AFFECTED_STEPS = []
for each changed_file:
    for step_name, file_list in STEP_FILE_MAP:
        if changed_file matches any path in file_list:
            AFFECTED_STEPS.append(step_name)

如果没有匹配的步骤：“更改的文件与任何步骤的 Expected Output 都不对应。请手动验证。”

确定优化范围：
- REFINE_FROM_PHASE = STEP_PHASE_MAP[AFFECTED_STEPS] 中最早的实现阶段
- 从 REFINE_FROM_PHASE 开始及之后的所有实现阶段都需要重新验证
- REFINE_FROM_PHASE 之前的阶段按原样保留
存储更改文件的上下文：
- CHANGED_FILES = 更改文件路径的列表
- USER_CHANGES_CONTEXT = 受影响文件的 git diff 输出
- 将此上下文传递给你派发来修复问题的实现 Agent
- Agent 应基于用户的修复继续工作，而不是覆盖这些修复

工作流阶段 1：加载并分析任务

这是执行过程中唯一可以读取文件的阶段（--refine 模式下的子任务 #### Expected Output 部分除外）。

步骤 1.1：加载任务详情

仅读取一次任务文件：

Read $TASK_PATH

读取后，执行余下流程时不得读取任何其他文件。

步骤 1.2：解析实施流程

将 ## Implementation Process 部分解析为两个工作结构。

字段	来源	用途
步骤名称	`Step` 列（以反引号括起的子任务基本文件名）	在所有其他列表中的标识
实施阶段	`Phase` 列	所属的审核关卡
模型	`Model` 列	调度时使用的 `model`（除非设置了 `MODEL_OVERRIDE`）
Agent	`Agent` 列	要调度的 `sdd:` Agent 类型
依赖项	`Depends on` 列	排序
并行步骤	`Parallel with` 列	在同一条消息中调度哪些步骤
子任务文件	`Sub-Task File` 列	传递给 Agent 的路径

从 ### Phase Overview 中获取——对于每个 #### Phase N 块，记录 Steps:、Reviewer model:、Checklist items: 列表和 Rubrics: 列表。使用 Reviewer model: 调度审核；审核标准由审核者负责处理，不属于你的工作——不要将它们粘贴到任何提示词中。

任务文件中没有阈值、验证级别或评审者数量。不要查找这些内容。

步骤 1.3：创建待办列表

使用 TodoWrite 创建待办列表，每个步骤对应一条，每个实施阶段审核也对应一条：

{
  "todos": [
    {"content": "Phase 1 / Step 01-foundation [haiku]", "status": "pending", "activeForm": "Implementing 01-foundation"},
    {"content": "Phase 1 / Step 02a-service [sonnet]", "status": "pending", "activeForm": "Implementing 02a-service"},
    {"content": "Phase 1 review [reviewer: sonnet]", "status": "pending", "activeForm": "Reviewing Phase 1"},
    {"content": "Phase 2 / Step 03-integration [sonnet]", "status": "pending", "activeForm": "Implementing 03-integration"},
    {"content": "Phase 2 review [reviewer: opus]", "status": "pending", "activeForm": "Reviewing Phase 2"}
  ]
}

工作流阶段 2：执行实施阶段

按顺序处理实施阶段。在每个阶段内，按依赖顺序处理步骤，并同时调度 Parallel with: 分组中的步骤。当该阶段的所有步骤都报告完成后，运行一次阶段审核。

所有实施阶段都适用同一种且唯一的调度模式，无一例外。

阶段审核模式

for each implementation phase P, in order:
    for each dependency-ordered group G of steps in P:
        dispatch every step of G in ONE message (parallel), each with:
            agent type   = its Agent column
            model        = MODEL_OVERRIDE if set, else its Model column
            prompt       = task file path + its sub-task file path
        collect each agent's reported artifact paths

    if SKIP_REVIEWS:
        mark P [REVIEWED-SKIPPED]; continue to the next phase

    dispatch ONE sdd:code-reviewer for P with the 4 inputs
        model = MODEL_OVERRIDE if set, else P's `Reviewer model`

    apply THRESHOLD to combined_score
        PASS      → mark P [REVIEWED]; human checkpoint if due; next phase
        FAIL      → Failure Handling (blast radius) → re-review; up to MAX_ITERATIONS

调度步骤（每个步骤调度一个实施 Agent）

使用 Task 工具，每个步骤调用一次（Parallel with: 分组中的所有步骤在同一条消息中调用）：

Agent 类型：步骤的 Agent 列，前缀为 sdd:（例如 sdd:developer、sdd:tech-writer）
模型：如果已设置，则使用 MODEL_OVERRIDE；否则使用步骤的 Model 列；如果两者均未设置，则使用 sonnet
描述："Implement step [step-name]"
提示词：

CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

Implement step `[step-name]`.

Task File: $TASK_PATH
Sub-Task File: [the Sub-Task File path from the Parallelization Overview]

Your task:
- Read the sub-task file first — it IS your step
- Read the task file for Description, Acceptance Criteria (including the Test Strategy) and Architecture Overview
- Execute ONLY this step. Do NOT execute any other step, even one you can see in the Parallelization Overview
- Follow the sub-task file's Expected Output, Success Criteria and Subtasks exactly
- Your phase is a checkpoint, not the finish line: implement what this step delivers, and do not pull later phases' work forward
- Leave the tree building, linting and testing green

When complete, report:
1. What files were created/modified (paths)
2. Confirmation that the sub-task's success criteria are met
3. Self-critique summary
4. Any issues encountered

不要将步骤的目标、预期输出、成功标准或子任务粘贴到提示词中。Agent 会读取其子任务文件。传递路径就是约定；粘贴内容只会造成上下文臃肿和偏移。

收集每份报告中的产物路径。不要读取产物。

Code-Reviewer 输入约定（不可协商）

每次调度 sdd:code-reviewer 时，必须且只能包含以下 4 项输入，不得包含任何类似阈值或通过/失败预期的内容（Task 工具的 model 参数是调度设置，不是提示词输入——参见 MODEL_OVERRIDE）：

任务文件路径：$TASK_PATH
阶段标识符：正在审核的阶段，必须与 ### Phase Overview 中的写法完全一致（例如 Phase 2）
产物路径：该阶段实施 Agent 报告创建或修改的每个文件路径
CLAUDE_PLUGIN_ROOT：插件根路径

调度提示词：

CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

Apply your full evaluation process (Stages 0-12) and return a single combined report.

Inputs:

1. Task file path:
   $TASK_PATH

2. Phase identifier:
   [e.g. Phase 2]

3. Artifact path(s):
   [every file path reported by this phase's implementation agents]

4. CLAUDE_PLUGIN_ROOT: ${CLAUDE_PLUGIN_ROOT}

不得向 code-reviewer 传递以下内容：

任何分数阈值、目标质量或通过线数值
任何 PASS/FAIL 预期
你自行编写的任何评分细则或检查清单（只有任务文件的 ## Acceptance Criteria（按 Phase Overview 缩小范围后）具有权威性）
子任务文件路径——审核者会根据 Phase Overview 的 Steps: 行和 Parallelization Overview 的 Sub-Task File 列自行解析
任务描述或验收标准文本——Agent 会自行读取任务文件

阈值应用（仅限编排器层级）

收到代码审查者的报告后，编排器（此技能）会应用阈值：

combined_score = reviewer.combined_score
all_issues     = reviewer.issues          # each carries the step it belongs to
blast_radius   = reviewer.blast_radius

# PASS rule (orchestrator decides):
if combined_score >= THRESHOLD:
    PASS
elif 3.0 <= combined_score < THRESHOLD and not STRICT_MODE:
    apply the Iteration Discretion Rule → accepted: PASS | declined: FAIL → fix
else:
    FAIL → fix

combined_score 已包含 spec_compliance + code_quality + Muda 浪费分析（审查者会根据其 STAGE 9 在内部汇总这些分数）。编排器无需重新汇总子分数；只有 combined_score、issues 和 blast_radius 与门禁判定有关。

失败处理：判断影响范围（你最关键的判断）

这是你在此工作流中做出的最重要判断。分派任何任务前，都要仔细思考。

这里没有规则表，你也不得自行编制。只有一条原则：

应根据审查结果的影响范围，选择修复该阶段的 Agent，以及重新审查修复结果的 Agent；不要依据最初构建该阶段时使用的模型。

分派任何修复任务前，都要明确并书面地考虑以下几点：

范围——审查结果涉及哪些步骤？使用 issues[].step 和 blast_radius.affected_steps。哪些步骤有明确证据表明没有问题？
深度——这是某个步骤中的局部缺陷，还是整个阶段在结构上就不正确（blast_radius.requires_phase_rework）？
耦合——修复受影响的步骤是否会迫使你重写未受影响的步骤？如果会，修复单位就是整个阶段，而不是单个步骤。
严重程度——是破坏了该阶段负责的验收标准的高危／严重问题，还是低／中危的细枝末节？
能力上限——这次失败是否表明负责实现的模型能力不足？如果模型已经因同一问题失败过一次，那么在相同层级再次分派它也会失败。应升级模型。

然后决定三件事：

修复模型——可以高于或低于最初构建该步骤时使用的模型，也可以因步骤而异。
修复范围——需要重新分派哪些子任务文件。绝不要重新分派已完成得好的步骤，否则就会毁掉已有的成果。
重新审查模型——至少应达到该阶段的 Reviewer model。如果因为阶段在结构上不正确而升级修复模型，也要升级重新审查的模型：让导致缺陷漏过的层级来审查，不算真正的检查。

示例（典型情况）。 一个阶段包含三个步骤，均由 haiku 构建，审查者为 sonnet，但审查未通过。相同的失败结论，仅因影响范围不同，就可能需要两种截然不同的修复：

情况 A——整个阶段都失败了。 审查者在全部三个步骤中都报告了高危问题，requires_phase_rework: true，而且该阶段的共享抽象设计有误。影响范围 = 整个阶段；深度 = 结构性；耦合 = 全部耦合；能力上限 = haiku 显然无法胜任此设计。**决定：**将整个阶段的步骤重新分派给 sonnet（如果抽象设计确实很难，则交给 opus），并由 opus 而不是该阶段的 sonnet 重新审查——正是 sonnet 的审查让这个有缺陷的结构通过了。
情况 B——只有一个步骤失败了。 审查者报告了一个高危问题，affected_steps: [02b-token-service]，requires_phase_rework: false，另外两个步骤没有问题。影响范围 = 一个步骤；深度 = 局部；耦合 = 无；能力上限 = 尚未达到，缺陷是遗漏了边界情况，而非设计失败。**决定：**仍由 haiku 仅重新处理 02b-token-service，并提供审查者针对该步骤提出的问题；另外两个步骤保持不变；由该阶段的 sonnet 重新审查。

其余情况都应从该原则推导，而不是预先列举。 使用混合模型的阶段、仅因测试失败的阶段、第二次失败的阶段、五个步骤中有两个相互耦合的阶段——这些情况都没有预设答案。按范围 → 深度 → 耦合 → 严重程度 → 能力上限的顺序逐一判断，写下推理过程并作出选择。不要套用决策矩阵；情况千差万别，矩阵只会让你在最需要思考的地方停止思考。

在最终报告中记录推理过程和选择，让用户了解为什么为每项修复选择了相应的模型。

重试反馈构建

对于你决定重新派发的每个步骤，构建此提示词（每个步骤一个；步骤之间相互独立时并行处理）：

CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

Fix step `[step-name]` — Phase [N] review iteration [K] of [MAX_ITERATIONS]

Task File: $TASK_PATH
Sub-Task File: [that step's Sub-Task File path]

The phase this step belongs to failed its quality review. Reviewer combined_score: [X.XX] / threshold [THRESHOLD]

Issues attributed to THIS step:
[paste the reviewer.issues entries whose `step` is this step (plus any `phase-wide` entries), verbatim: source, priority, description, evidence (file:line), impact, suggestion]

Full reviewer report (for additional context, do NOT skim — use the issues list as your primary work list):
[path to reviewer's scratchpad report file under .specs/scratchpad/<hex>.md]

Your task:
- Address every High priority issue attributed to this step
- Address every Medium priority issue attributed to this step
- Do NOT introduce functionality beyond your sub-task file's Expected Output
- Do NOT modify files owned by steps that were NOT re-dispatched
- Re-run tests/lint/build to ensure no regressions

When complete, report:
1. Files changed (paths)
2. Per-issue resolution status (Fixed / Partially Fixed / Skipped with justification)
3. Any new concerns introduced by the fix

每个重新派发的步骤都报告完成后，再次为同一阶段派发 code-reviewer，并提供相同的 4 项输入（产物列表可能有所增加——传入并集）。重复此过程，直到获得 PASS 或达到 MAX_ITERATIONS。

如果达到 MAX_ITERATIONS：

记录警告："Phase [N] did not pass after {MAX_ITERATIONS} iterations (final combined_score: X.XX, threshold: {THRESHOLD})"
继续进入下一个实现阶段（不要无限期阻塞）

PASS 时：标记阶段完成

更新任务文件：
- 在 ### Parallelization Overview 表格中每个已完成步骤的名称旁标记 [DONE]
- 将阶段标题标记为 [REVIEWED]（例如 #### Phase 1: Foundation [REVIEWED]）；如果 SKIP_REVIEWS 为 true，则标记为 [REVIEWED-SKIPPED]
将待办事项更新为 completed
在跟踪记录中记录 combined_score

步骤自身的 #### Subtasks 和 #### Success Criteria 复选框由实现 Agent 在其子任务文件中标记，不由你标记。

人机协同检查点（如适用）

仅当实现阶段通过后，且阶段标识符位于 HUMAN_IN_THE_LOOP_PHASES 中（或 HUMAN_IN_THE_LOOP_PHASES == "*"）时，才显示 Human-in-the-Loop Behavior 中的检查点。

如果用户提供反馈：保存起来，供下一阶段使用，或根据反馈重新派发受影响的步骤
如果用户回复 "n"：暂停工作流并报告当前进度
如果用户回复 "Y" 或继续操作：进入下一个实现阶段

⚠️ 检查点：进行 DoD 验证前

开始 DoD 验证前，请确认你遵循了以下规则：

是否为每个步骤派发了一个实现 Agent，并提供任务文件路径和子任务文件路径？
是否按照 Parallelization Overview 表格中每个步骤对应的模型派发了所有步骤（除非设置了 MODEL_OVERRIDE）？
是否在每个实现阶段结束时恰好启动了一个 sdd:code-reviewer（除非设置了 SKIP_REVIEWS），并使用该阶段的 Reviewer model？
是否避免审查任何单独的步骤？
是否自行根据 combined_score 应用 THRESHOLD，且没有向审查者传递阈值？
是否在确定每次修复和重新审查所用的模型前，以文字形式分析了影响范围？
是否仅在满足编排器层面的 PASS 规则后，才将阶段标记为 [REVIEWED]？
是否避免自行读取任何产物文件？

如果你读取了任务文件（以及 --refine 中的子任务 Expected Outputs）之外的文件，那就是错误的。立即停止并重新开始。

工作流阶段 3：完成定义验证

所有实现阶段完成后，验证任务是否满足所有完成定义标准。

步骤 3.1：启动完成定义验证

使用 Task 工具，并设置：

Agent 类型：sdd:developer
模型：如果已设置 MODEL_OVERRIDE，则使用该值；否则使用 opus
描述："Verify Definition of Done"
提示词：

CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

Verify all Definition of Done items in the task file.

Task File: $TASK_PATH

Your task:
1. Read the task file and locate the `## Acceptance Criteria` section, then its `**Definition of Done:**` sub-block
2. Go through each checkbox item one by one
3. For each item, verify if it passes by:
   - Running appropriate tests (unit tests, E2E tests)
   - Checking build/compilation status
   - Verifying file existence and correctness
   - Checking code patterns and linting
4. You MUST mark each item in the task file that passed verification with `[X]`
5. Return a structured report:
- List ALL Definition of Done items
- Status for each:
   - ✅ PASS - if the item is complete and verified
   - ❌ FAIL - if the item fails verification, with specific reason why
   - ⚠️ BLOCKED - if the item cannot be verified due to a blocker
- Evidence for each status
- Specific issues for any failures
- Overall pass rate

This is the TASK-LEVEL check, run once, after every implementation phase is done. Unlike a phase review, nothing here is "not yet due" — every Definition of Done item must hold now.

Be thorough - check everything the task requires.

步骤 3.2：审查验证结果

接收完成定义验证报告
记录哪些 DoD 项目通过（PASS），哪些未通过（FAIL）
如果验证 Agent 报告所有 DoD 项目均通过（PASS），则必须在任务文件末尾确认所有 DoD 项目都已标记为 [X]

步骤 3.3：修复未通过的 DoD 项目（如有）

如果任何完成定义项目未通过（FAIL）：

1. 为每个未通过的项目启动一个实现 Agent——模型：如果已设置 MODEL_OVERRIDE，则使用该值；否则使用 opus：

Fix Definition of Done item: [Item Description]

Task File: $TASK_PATH

Current Status:
[paste failure details from verification report]

Your task:
1. Fix the specific issue identified
2. Verify the fix resolves the problem
3. Ensure no regressions (all tests still pass)

Return:
- What was fixed
- Confirmation the item now passes
- Any related changes made

2. 修复后重新验证：

再次启动验证 Agent（步骤 3.1），确认所有项目现在均已通过（PASS）。

3. 如有需要，重复执行：

重复“修复 → 验证”循环，直到所有完成定义项目均通过（PASS）。

工作流阶段 4：将任务移至已完成目录

所有完成定义项目都通过（PASS）后，将任务移至已完成目录。

第 4.1 步：确认完成情况

确认任务文件中的所有完成定义（DoD）项目均已标记为完成。

第 4.2 步：移动任务

# Extract just the filename from $TASK_PATH
TASK_FILENAME=$(basename $TASK_PATH)

# Move from in-progress to done
git mv .specs/tasks/in-progress/$TASK_FILENAME .specs/tasks/done/
# Fallback if git not available: mv .specs/tasks/in-progress/$TASK_FILENAME .specs/tasks/done/

**请勿移动 .specs/sub-tasks/<task-name>/。**该目录保持原位；任务文件中记录的路径必须继续有效。

工作流阶段 5：汇总与报告

最终报告

所有实施阶段完成且 DoD 验证通过后：

## Implementation Summary

### Task Status
- Task Status: `done` ✅
- All Definition of Done items: X/X PASS (100%)

### Configuration Used

| Setting | Value |
|---------|-------|
| **Model Override** | {MODEL_OVERRIDE or "None (models from task file)"} |
| **Threshold** | {THRESHOLD}/5.0 |
| **Max Iterations** | {MAX_ITERATIONS or "3"} |
| **Human Checkpoints** | {HUMAN_IN_THE_LOOP_PHASES or "None"} |
| **Skip Reviews** | {SKIP_REVIEWS} |
| **Continue Mode** | {CONTINUE_MODE} |
| **Refine Mode** | {REFINE_MODE} |
| **Strict Mode** | {STRICT_MODE} |

### Steps Completed

| Step | Phase | Model Used | Status |
|------|-------|------------|--------|
| `01-foundation` | Phase 1 | haiku | ✅ |
| `02a-service` | Phase 1 | sonnet | ✅ |
| `03-integration` | Phase 2 | sonnet | ✅ (re-dispatched at opus in iteration 1) |

### Phase Reviews

| Phase | Steps | Reviewer Model | Combined Score | Iterations | Status |
|-------|-------|----------------|----------------|------------|--------|
| Phase 1 | 2 | sonnet | 4.3/5 | 1 | ✅ |
| Phase 2 | 1 | opus | 3.6/5 | 2 | ☑️ |

**Legend:**
- ✅ PASS - `combined_score >= THRESHOLD`
- ☑️ ACCEPTED - Score in discretion band `3.0 <= combined_score < THRESHOLD` accepted per the [Iteration Discretion Rule](#iteration-discretion-rule) (outstanding nitpicks listed under Recommendations)
- ⚠️ MAX_ITER - Did not pass but MAX_ITERATIONS reached, proceeded anyway
- ⏭️ SKIPPED - Review skipped (`--skip-reviews`, continue or refine mode); the phase heading carries `[REVIEWED-SKIPPED]`, not `[REVIEWED]`

### Fix Decisions (blast-radius reasoning)

| Phase | Iteration | Findings scope | Fix model chosen | Re-review model | Reasoning |
|-------|-----------|----------------|------------------|-----------------|-----------|
| Phase 2 | 1 | 1 of 1 step, structural | opus (was sonnet) | opus (was opus) | Shared abstraction wrong; sonnet had already failed on it |

### Review Summary

- Total implementation phases: X
- Phases reviewed: Y
- Passed on first review: Z
- Accepted below target per Iteration Discretion Rule: U (outstanding nitpicks listed under Recommendations)
- Required fix iterations: W
- Total iterations across all phases: V
- Final pass rate: 100%

### Definition of Done Verification

| Item | Status | Evidence |
|------|--------|----------|
| [DoD Item 1] | ✅ PASS | [Brief evidence] |
| [DoD Item 2] | ✅ PASS | [Brief evidence] |
| ... | ... | ... |

**Issues Fixed During Verification:**
1. [Issue]: [How it was fixed]
2. [Issue]: [How it was fixed]

### Human Review Summary (if --human-in-the-loop used)

| Phase | Checkpoint | User Action | Feedback Incorporated |
|-------|------------|-------------|----------------------|
| Phase 1 | After PASS | Continued | - |
| Phase 2 | After iteration 1 | Feedback | "Improve error messages" |

### Task File Updated

- Task moved from `in-progress/` to `done/` folder
- All step rows marked `[DONE]` in the Parallelization Overview
- All phase headings marked `[REVIEWED]` in the Phase Overview — or `[REVIEWED-SKIPPED]` for phases whose review `--skip-reviews` suppressed
- All Definition of Done items marked `[X]`
- Sub-task files' subtasks marked `[X]` by their implementation agents

### Recommendations

1. [Any follow-up actions]
2. [Suggested improvements]

执行流程图

┌──────────────────────────────────────────────────────────────┐
│                IMPLEMENT TASK WITH VERIFICATION               │
├──────────────────────────────────────────────────────────────┤
│                                                               │
│  Workflow Phase 0: Select Task                                │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │ Use provided name or auto-select from todo/ (if 1 task) │  │
│  │ → Move task from todo/ to in-progress/                  │  │
│  └─────────────────────────────────────────────────────────┘  │
│                           │                                   │
│                           ▼                                   │
│  Workflow Phase 1: Load Task                                  │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │ Read $TASK_PATH → Parse Parallelization Overview        │  │
│  │ (steps, models, agents, sub-task paths) + Phase         │  │
│  │ Overview (phases, reviewer models) → TodoWrite          │  │
│  └─────────────────────────────────────────────────────────┘  │
│                           │                                   │
│                           ▼                                   │
│  Workflow Phase 2: Execute Implementation Phases              │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │                                                          │  │
│  │  For each implementation phase:                          │  │
│  │                                                          │  │
│  │  ┌──────────────┐                                        │  │
│  │  │ step agent   │─┐                                      │  │
│  │  ├──────────────┤ │ (parallel where the plan says so)    │  │
│  │  │ step agent   │─┤                                      │  │
│  │  ├──────────────┤ │                                      │  │
│  │  │ step agent   │─┘                                      │  │
│  │  └──────────────┘ │                                      │  │
│  │                   ▼                                      │  │
│  │        ┌─────────────────────┐    ┌───────────┐          │  │
│  │        │ ONE code-reviewer   │───▶│ PASS?     │          │  │
│  │        │ for the whole phase │    │           │          │  │
│  │        └─────────────────────┘    └───────────┘          │  │
│  │                                     │      │             │  │
│  │                                   PASS   FAIL            │  │
│  │                                     │      │             │  │
│  │                                     ▼      ▼             │  │
│  │                            ┌──────────┐  Blast-radius    │  │
│  │                            │ Mark     │  reasoning →     │  │
│  │                            │[REVIEWED]│  fix model +     │  │
│  │                            └──────────┘  scope + re-     │  │
│  │                                          review model ↺  │  │
│  └─────────────────────────────────────────────────────────┘  │
│                           │                                   │
│                           ▼                                   │
│  Workflow Phase 3: Definition of Done Verification            │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │                                                         │  │
│  │  ┌──────────────┐    ┌───────────────┐    ┌───────────┐ │  │
│  │  │ DoD Verifier │───▶│ All DoD       │───▶│ All PASS? │ │  │
│  │  │ Agent        │    │ items checked │    │           │ │  │
│  │  └──────────────┘    └───────────────┘    └───────────┘ │  │
│  │                                                │   │    │  │
│  │                                               Yes  No   │  │
│  │                                                │   │    │  │
│  │                                                ▼   ▼    │  │
│  │                                                Fix &    │  │
│  │                                                Retry    │  │
│  │                                                ↺        │  │
│  │                                                         │  │
│  └─────────────────────────────────────────────────────────┘  │
│                           │                                   │
│                           ▼                                   │
│  Workflow Phase 4: Move Task to Done                          │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │ mv in-progress/$TASK → done/$TASK                       │  │
│  └─────────────────────────────────────────────────────────┘  │
│                           │                                   │
│                           ▼                                   │
│  Workflow Phase 5: Aggregate & Report                         │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │ Collect all phase review results                        │  │
│  │ → Calculate aggregate metrics                           │  │
│  │ → Generate final report                                 │  │
│  │ → Present to user                                       │  │
│  └─────────────────────────────────────────────────────────┘  │
│                                                               │
└──────────────────────────────────────────────────────────────┘

使用示例

基本用法

# Implement a specific task
/implement add-validation.feature.md

# Auto-select task from todo/ or in-progress/ (if only 1 task)
/implement

# Continue from the last completed step
/implement add-validation.feature.md --continue

# Refine after user fixes project files (detects changes, re-verifies affected phases)
/implement add-validation.feature.md --refine

# Human review after every implementation phase
/implement add-validation.feature.md --human-in-the-loop

# Human review after specific phases only
/implement add-validation.feature.md --human-in-the-loop "Phase 1,Phase 3"

# Higher quality threshold (stricter)
/implement add-validation.feature.md --target-quality 4.5

# Lower quality threshold (faster convergence)
/implement add-validation.feature.md --target-quality 3.5

# Unlimited iterations (default is 3)
/implement add-validation.feature.md --max-iterations unlimited

# Skip all phase reviews (fast but no quality gates)
/implement add-validation.feature.md --skip-reviews

# Strict mode: never accept a phase below target - iterate until threshold or MAX_ITERATIONS
/implement add-validation.feature.md --strict

# Force ALL sub-agents (implementers + code-reviewer) onto one model, overriding the task file
/implement add-validation.feature.md --model sonnet

# Combined: continue with human review
/implement add-validation.feature.md --continue --human-in-the-loop

示例 1：实现一项功能

User: /implement add-validation.feature.md

Workflow Phase 0: Task Selection...
Found task in: .specs/tasks/todo/add-validation.feature.md
Moving to in-progress: .specs/tasks/in-progress/add-validation.feature.md

Workflow Phase 1: Loading task...
Task: "Add form validation service"
Parallelization Overview: 4 steps
Phase Overview: 2 implementation phases
- Phase 1: 01-validation-types, 02-validation-service — reviewer sonnet
- Phase 2: 03a-email-validator, 03b-phone-validator — reviewer opus
Threshold: 4.0/5.0

Workflow Phase 2: Executing...

Phase 1 / step 01-validation-types [haiku]
  Prompt: task file + .specs/sub-tasks/add-validation/01-validation-types.md
  Result: ✅ src/validation/types.ts

Phase 1 / step 02-validation-service [sonnet]
  Prompt: task file + .specs/sub-tasks/add-validation/02-validation-service.md
  Result: ✅ src/validation/validation.service.ts + spec

  Launching 1 sdd:code-reviewer for Phase 1 (model: sonnet)...
  Inputs: task file path, "Phase 1", 3 artifact paths, CLAUDE_PLUGIN_ROOT
  combined_score 4.3/5.0 ≥ threshold 4.0 → PASS ✅
  Marking Phase 1 [REVIEWED]

Phase 2 / steps 03a-email-validator, 03b-phone-validator [haiku, haiku] — dispatched in parallel
  Result: ✅ 2 validators + specs

  Launching 1 sdd:code-reviewer for Phase 2 (model: opus)...
  combined_score 4.5/5.0 ≥ threshold 4.0 → PASS ✅

Workflow Phase 3: Definition of Done Verification...
  Result: 4/4 items PASS ✅

Workflow Phase 4: Moving task to done...

Workflow Phase 5: Final Report
Implementation complete.
- 4/4 steps completed, 2/2 phases reviewed
- All passed first review
- Definition of Done: 4/4 PASS
- Task location: .specs/tasks/done/add-validation.feature.md ✅

示例 2：处理 DoD 项目失败

[All implementation phases complete and reviewed...]

Workflow Phase 3: Definition of Done Verification...
Launching DoD verification agent...
  Result: 3/4 items PASS, 1 FAIL ❌

Failing item:
- "Code follows ESLint rules": 356 errors found

Should I attempt to fix this issue? [Y/n]

User: Y

Launching sdd:developer agent...
  Result: Fixed 356 errors, 0 warnings ✅

Re-launching DoD verification agent...
  Result: 4/4 items PASS ✅

Workflow Phase 4: Moving task to done...
All DoD checkboxes marked complete ✅

以下示例 3 和 4 是失败处理中同一个锚点案例的两个部分，以会话日志的形式展示了完整过程。它们不是情形目录——其他所有失败情况都应依据原则进行推理，而不是查阅目录。

示例 3：阶段审核失败——锚点示例的案例 A，会话日志形式

Phase 2 complete: steps 03a, 03b, 03c — all built by haiku.
Launching 1 sdd:code-reviewer for Phase 2 (model: sonnet)...

combined_score 2.1/5.0 — below threshold 4.0 and below the 3.0 floor → FAIL (no discretion)

Reviewer blast_radius:
  affected_steps: [03a-parser, 03b-evaluator, 03c-formatter]
  unaffected_steps: []
  requires_phase_rework: true

Blast-radius reasoning:
- Scope: all 3 steps carry High findings
- Depth: structural — the shared Rule interface the three steps agreed on is wrong
- Coupling: total — fixing one forces rewriting the other two
- Severity: 4 High findings, 2 of them break CK-3 and CK-4, which Phase 2 owns
- Ceiling: haiku produced three mutually inconsistent takes on the same interface
→ Fix model: sonnet for all three steps (was haiku)
→ Fix scope: whole phase
→ Re-review model: opus (was sonnet) — the sonnet review is what let this shape through

Iteration 1/3: re-dispatching 03a, 03b, 03c at sonnet with their per-step issues...
Re-launching sdd:code-reviewer for Phase 2 at opus...
combined_score 4.4/5.0 ≥ threshold 4.0 → PASS ✅
Marking Phase 2 [REVIEWED]

示例 4：阶段审核失败——锚点示例的案例 B，会话日志形式

Phase 1 complete: steps 01a, 01b, 01c — all built by haiku.
Launching 1 sdd:code-reviewer for Phase 1 (model: sonnet)...

combined_score 3.4/5.0 — below threshold 4.0, inside discretion band → but a High finding removes discretion → FAIL

Reviewer blast_radius:
  affected_steps: [01b-token-service]
  unaffected_steps: [01a-user-model, 01c-config]
  requires_phase_rework: false

Blast-radius reasoning:
- Scope: 1 of 3 steps
- Depth: local — a missed expiry edge case, not a design failure
- Coupling: none — 01a and 01c do not touch the token path
- Severity: 1 High, breaks CK-2 which Phase 1 owns
- Ceiling: not reached — the step's design is right, one branch is missing
→ Fix model: haiku (unchanged)
→ Fix scope: 01b-token-service ONLY — 01a and 01c are not re-dispatched
→ Re-review model: sonnet (the phase's Reviewer model, unchanged)

Iteration 1/3: re-dispatching 01b-token-service at haiku...
Re-launching sdd:code-reviewer for Phase 1 at sonnet...
combined_score 4.2/5.0 ≥ threshold 4.0 → PASS ✅

示例 5：从中断处继续

User: /implement add-validation.feature.md --continue

Workflow Phase 0: Parsing flags...
Configuration:
- Continue Mode: true
- Threshold: 4.0/5.0 (default)

Scanning task file...
Parallelization Overview: 01-... [DONE], 02-... [DONE], 03-..., 04-...
Phase Overview: Phase 1 [REVIEWED], Phase 2 (not reviewed)
RESUME_PHASE = Phase 2
RESUME_STEPS = 03-..., 04-...

Resuming: dispatching 03-... and 04-... (parallel per the plan)...
[both complete]

Launching 1 sdd:code-reviewer for Phase 2 (model: opus)...
combined_score 4.3/5.0 ≥ threshold 4.0 → PASS ✅

示例 6：用户修复后进行完善

# User manually fixed src/validation/validation.service.ts
# (Expected Output of step 02-validation-service, in Phase 1)

User: /implement add-validation.feature.md --refine

Workflow Phase 0: Parsing flags...
Configuration:
- Refine Mode: true

Detecting changed project files...
- src/validation/validation.service.ts (modified)

Mapping files to steps (reading sub-task Expected Output sections)...
- src/validation/validation.service.ts → 02-validation-service → Phase 1

Earliest affected phase: Phase 1
Preserving: nothing earlier
Re-verifying from: Phase 1 onwards

Launching 1 sdd:code-reviewer for Phase 1...
combined_score 4.3/5.0 ≥ threshold 4.0 → PASS ✅

Launching 1 sdd:code-reviewer for Phase 2...
combined_score 2.8/5.0 — High finding "typescript error in src/validation/index.ts" → FAIL
Blast radius: 1 step (04-barrel-exports), local, no coupling, ceiling not reached
→ re-dispatch 04-barrel-exports at its original model with the user's diff as context

Re-launching sdd:code-reviewer for Phase 2...
combined_score 4.5/5.0 → PASS ✅

All phases verified with user's changes incorporated ✅

示例 7：人在回路审核

User: /implement add-validation.feature.md --human-in-the-loop

Configuration:
- Human Checkpoints: All phases

Phase 1 / steps 01-..., 02-... dispatched...
Result: ✅ complete

Launching 1 sdd:code-reviewer for Phase 1 (model: sonnet)...
combined_score 4.4/5.0 ≥ threshold 4.0 → PASS ✅

---
## 🔍 Human Review Checkpoint - Phase 1

**Phase:** Phase 1: Validation Core
**Steps:** `01-validation-types`, `02-validation-service`
**Reviewer model:** sonnet
**Combined Score:** 4.4/5.0 (threshold: 4.0)
**Status:** ✅ PASS

**Artifacts Created/Modified:**
- src/validation/types.ts
- src/validation/validation.service.ts
- src/validation/tests/validation.service.spec.ts

**Reviewer Feedback (top issues):**
- [Low] `02-validation-service` — Error messages could be more descriptive

**Action Required:** Review the above artifacts and provide feedback or continue.

> Continue? [Y/n/feedback]: The error messages could be more descriptive
---

Incorporating feedback: re-dispatching 02-validation-service with the feedback...
[iteration continues]

示例 8：严格的质量门槛

User: /implement add-validation.feature.md --strict

Configuration:
- Strict Mode: true (Iteration Discretion Rule DISABLED)
- Threshold: 4.0/5.0 (default)
- Max Iterations: 3 (default)

Phase 1 / steps 01-..., 02-... dispatched...

Launching 1 sdd:code-reviewer for Phase 1 (model: sonnet)...
combined_score 3.6/5.0 — outstanding issues are 2 Low nitpicks only
Without --strict this would sit in the discretion band (3.0 <= 3.6 < 4.0) and be ☑️ ACCEPTED.
--strict disables that discretion → FAIL, iterate.

Blast radius: 1 step (02-validation-service), local → re-dispatch it with the reviewer feedback
Re-launching sdd:code-reviewer for Phase 1 (iteration 2)...
combined_score 4.2/5.0 ≥ threshold 4.0 → PASS ✅
Marking Phase 1 [REVIEWED]

错误处理

实施失败

如果实施 Agent 报告失败：

向用户说明失败详情
提出有助于解决问题的澄清问题
根据澄清结果，重新派发该步骤的 Agent
步骤失败会推迟该阶段的审核，但绝不会跳过审核。阶段中的所有步骤均报告完成后，阶段审核会按正常流程运行（除非设置了 SKIP_REVIEWS）。

审核者返回无效报告

如果 sdd:code-reviewer 返回的报告违反了执行与评估规则中的任一规则——combined_score 为 5.0、缺少 combined_score、给出 PASS/FAIL 判定，或针对该阶段不负责的验收标准提出问题——则拒绝该报告，并使用相同的 4 项输入重新运行 Agent。切勿自行修正其报告。

完善模式：未检测到更改

如果 --refine 模式未在项目中发现 Git 更改：

报告：“自上次提交以来，未检测到项目文件更改。”
建议：“先修改项目文件，然后再次运行 --refine。”
或者建议：“不使用 --refine 运行，以重新实施所有步骤。”

完善模式：更改无法映射到步骤

如果 --refine 模式发现了已更改文件，但没有文件能映射到某个步骤的预期输出：

报告：“已更改文件与任何步骤的预期输出均不匹配。”
列出检测到的已更改文件
建议：“请手动验证，或不使用 --refine 运行，以重新验证所有阶段。”

缺少子任务文件

如果并行化概览中的 Sub-Task File 路径不存在：

尝试 .specs/sub-tasks/<task-file-basename-without-extension>/<step-name>.md——该文件夹从不移动，因此过时的路径通常可以恢复
如果仍然缺失，请向用户报告并停止。切勿臆造该步骤的内容，也切勿只向 Agent 派发任务文件。

检查清单

完成实施之前：

配置处理

上下文保护（关键）

只读取任务文件（.specs/tasks/in-progress/ 中的 $TASK_PATH）——以及 --refine 模式下子任务中的 #### Expected Output 部分；不读取其他内容
未读取实现输出、参考文件或制品
使用子 Agent 的报告了解状态——未读取文件进行“检查”

委派

每个步骤都通过 Task 工具交由各自的子 Agent 实现，并提供任务文件路径和子任务文件路径
除非指定了 MODEL_OVERRIDE，否则每个步骤均按其 Parallelization Overview 对应行指定的模型和 Agent 类型进行调度
每个实现阶段恰好调度一个 sdd:code-reviewer，并使用该阶段指定的 Reviewer model（除非设置了 SKIP_REVIEWS）
未审查任何单独的步骤
未自行执行任何验证

进度跟踪

每个步骤的 Agent 报告完成后，在 Parallelization Overview 中将其对应行标记为 [DONE]
只有在编排器级别的 PASS 后才将阶段标题标记为 [REVIEWED]（如果设置了 SKIP_REVIEWS，则标记为 [REVIEWED-SKIPPED]）
每个步骤完成后以及每次阶段审查后更新待办列表

执行质量

按依赖顺序执行所有步骤
在同一条消息中同时启动 Parallel with: 组（不得顺序启动）
上一阶段尚未完成审查时，不启动后续阶段的任何步骤
在为每次修复选择模型、修复范围和重新审查模型之前，先写明影响范围分析
只重新调度受影响的步骤——未受影响的步骤保持不变
根据审查者提供的 issues（按步骤归属）进行失败后的迭代，直至达到编排器级别的 PASS
生成最终报告，包含阶段审查结果和修复决策

人在环（如果已启用）

在 HUMAN_IN_THE_LOOP_PHASES 中的每个实现阶段后显示检查点
在后续迭代和阶段中纳入用户反馈
用户要求暂停时暂停工作流

最终验证与完成

启动 Definition of Done 验证 Agent，使其读取 ## Acceptance Criteria → **Definition of Done:**
验证所有 DoD 条目（状态为 PASS/FAIL/BLOCKED）
通过实现 Agent 修复失败的 DoD 条目
修复后执行重新验证
将任务从 in-progress/ 文件夹移至 done/ 文件夹（保留子任务文件夹）
在任务文件中将所有 DoD 复选框标记为 [X]
向用户提交最终验证报告

附录 A：任务文件和子任务文件提供的内容

本附录说明此技能使用的产物。这是一份阅读指南，并非要求阅读工作流阶段 1 允许范围之外的更多文件。

任务文件结构

计划任务文件恰好包含以下部分：

部分	编写者	此技能如何使用
`# Description`	`sdd:business-analyst`	不直接使用——子 Agent 会读取
`## Acceptance Criteria`	`sdd:business-analyst`	仅在工作流阶段 3 使用其 `Definition of Done:` 子区块
`## Architecture Overview`	`sdd:software-architect`	不直接使用——子 Agent 会读取
`## Implementation Process`	`sdd:tech-lead`	全部使用：分派、模型、阶段、评审关卡

## Acceptance Criteria 按顺序恰好包含六个子区块：**Checklist:**、**Regular Checks:**、**Rubric:**、**Rubric Score Definitions:**、**Test Strategy:**、**Definition of Done:**。前五项是评审者的输入，并按阶段缩小范围——你绝不会解析或转发它们。

任务文件不包含任何评分配置——没有阈值、评审者数量或逐步评审元数据。评分配置仅由编排器提供。如果任务文件包含上表未列出的任何部分，则说明它是旧计划中的过期产物；请忽略它，并在最终报告中注明。

`## Implementation Process`

## Implementation Process

[sub-agent execution directive: launch one agent per step; verify at PHASE level]

### Parallelization Overview

[ASCII dependency diagram]

| Step | Phase | Model | Agent | Depends on | Parallel with | Sub-Task File |
|------|-------|-------|-------|------------|---------------|---------------|
| `01-foundation` | Phase 1 | haiku | developer | None | None | `.specs/sub-tasks/<task-name>/01-foundation.md` |
| `02a-service` | Phase 1 | sonnet | developer | `01-foundation` | `02b-docs` | `.specs/sub-tasks/<task-name>/02a-service.md` |

### Phase Overview

#### Phase 1

Steps: `01-foundation`, `02a-service`
Reviewer model: `sonnet`
Acceptance Criteria that should be fulfiled:
Checklist items:
- `CK-1` — ...
- `CK-2` — ...

Rubrics:
- `Contract Correctness`

阶段标识符为 Phase N（后面可以跟标题：#### Phase 1: Foundation）。这是你传给评审者的准确标识符。
Reviewer model: 的值为 haiku、sonnet 或 opus 之一。它是该阶段唯一一次评审分派所用的模型。
Checklist items: 和 Rubrics: 列表限定了评审者的评分范围。它们是评审者的输入，不是你的输入——评审者会直接从任务文件中读取。绝不要将它们粘贴到提示词中。

子任务文件

每个步骤一个，路径为 .specs/sub-tasks/<task-name>/<NN>-<step-slug>.md，其中 <task-name> 是去掉扩展名后的任务文件名。文件夹位置不会改变。

# Step NN: [Title]

**Task File:** `.specs/tasks/todo/<task-name>.md`
**Phase:** Phase N
**Model:** haiku | sonnet | opus
**Agent:** [agent type]
**Depends on:** [step names or None]
**Parallel with:** [step names or None]
**Note:** [or None]

**Goal:** ...

[step description]

#### Expected Output
#### Success Criteria
#### Subtasks
#### Blockers & Risks

步骤名称是去掉 .md 后缀后的文件基本名。它是 Steps:、Depends on:、Parallel with: 以及评审者逐项问题归因中使用的标识。

评分标准

sdd:code-reviewer 会根据其自身 ## Scoring Scale 部分定义的 1-5 整数刻度为每项标准评分。该部分是唯一的定义，此处有意不重复——评分由评审者负责；你不进行评分，只将 combined_score 与 THRESHOLD 比较。绝不要在任何提示词或报告中重述该刻度，或提供你自己的版本。

**对你唯一的影响：**应用迭代裁量规则时，将分数视为一个等级位置，绝不要凭直觉把它理解为“满分 5 分中的几分”，也不要用“尚可”或“优秀”之类的词来判断。

在执行期间使用这些产物

工作流阶段 2 期间：

使用任务文件路径和子任务文件路径，在其 Model 指定的模型上分派每个步骤的 Agent
等待实现阶段的每个步骤都报告完成
在该阶段的 Reviewer model 上启动一个 sdd:code-reviewer——Model：若已设置 MODEL_OVERRIDE，则使用它；否则使用该阶段的 Reviewer model；再否则使用 opus
只传入恰好 4 项输入（任务文件路径、阶段标识符、产物路径、CLAUDE_PLUGIN_ROOT）——绝不传入阈值，绝不传入子任务路径
接收评审者的综合报告
在此层将 THRESHOLD 与 combined_score 比较
若为 FAIL，分析影响范围，仅为受影响的步骤分派修复，然后重新评审该阶段

支持 Markdown

登录后评论

基本信息

作者: neolabhq
仓库: neolabhq/context-engineering-kit
分类: 开发
安装次数: 1,248
GitHub Stars: 1,792

报告问题