sdd:implement

实现任务并进行验证

你的工作是使用任务规范和子代理，以最佳质量实现解决方案。除非确实有必要停止或任务已完成，否则绝不能停止！除非确实有必要，否则不要提问！启动实现代理和评审代理，反复迭代，直到问题修复，然后再进入下一步！

使用自动化质量验证执行任务实现步骤，并使用 LLM 作为评审者检查关键产物。

用户输入

$ARGUMENTS

---

命令参数

从 $ARGUMENTS 解析以下参数：

参数定义

参数	格式	默认值	说明
task-file	路径或文件名	自动检测	任务文件名或路径（例如 add-validation.feature.md）
--continue	--continue	无	从上次完成的步骤继续实现。先启动评审者验证当前状态，然后与实现代理迭代。
--refine	--refine	false	增量优化模式——检测与 Git 的差异，并仅重新实现受影响的步骤（从修改的步骤开始）。
--human-in-the-loop	--human-in-the-loop [step1,step2,...]	无	在指定步骤之后暂停，以便人工验证。如果未指定步骤，则在每一步之后暂停。
--target-quality	--target-quality X.X 或 --target-quality X.X,Y.Y	4.0（标准）/ 4.5（关键）	目标阈值（满分为 5.0）。单个值会同时设置标准和关键阈值。两个以逗号分隔的值分别设置标准阈值和关键阈值。
--max-iterations	--max-iterations N	3	每个步骤最多进行的修复→验证循环次数。默认值为 3 次迭代。设为 unlimited 表示不设限制。
--skip-judges	--skip-judges	false	跳过所有评审验证检查——各步骤不经过质量门槛即可继续。

配置解析

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

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

# Parse --target-quality (supports single value or two comma-separated values)
if --target-quality has single value X.X:
    THRESHOLD_FOR_STANDARD_COMPONENTS = X.X
    THRESHOLD_FOR_CRITICAL_COMPONENTS = X.X
elif --target-quality has two values X.X,Y.Y:
    THRESHOLD_FOR_STANDARD_COMPONENTS = X.X
    THRESHOLD_FOR_CRITICAL_COMPONENTS = Y.Y
else:
    THRESHOLD_FOR_STANDARD_COMPONENTS = 4.0  # default
    THRESHOLD_FOR_CRITICAL_COMPONENTS = 4.5  # default

# Initialize other defaults
MAX_ITERATIONS = --max-iterations || 3  # default is 3 iterations 
HUMAN_IN_THE_LOOP_STEPS = --human-in-the-loop || [] (empty = none, "*" = all)
SKIP_JUDGES = --skip-judges || false
REFINE_MODE = --refine || false
CONTINUE_MODE = --continue || false

# Special handling for --human-in-the-loop without step list
if --human-in-the-loop present without step numbers:
    HUMAN_IN_THE_LOOP_STEPS = "*" (all steps)

--continue 的上下文解析

使用 --continue 时：

1. 步骤解析：

   • 解析任务文件，查找步骤标题上的 [DONE] 标记
   • 找出最后一个未完成的步骤
   • 启动评审者，验证最后一个未完成步骤的产物
   • 如果评审通过：将该步骤标记为已完成，并从下一步继续
   • 如果评审未通过：重新实现该步骤并反复迭代，直到通过

2. 状态恢复：

   • 检查任务文件位置（in-progress/、todo/、done/）
   • 如果文件位于 todo/，继续之前将其移至 in-progress/
   • 根据现有产物预先填入已捕获的值

优化模式行为（--refine）

使用 --refine 时，它会检测项目文件（而非任务文件）的更改，并将其映射到实现步骤，以确定哪些内容需要重新验证。

1. 检测已更改的项目文件：

   首先，根据 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 针对最新的进行中工作执行

2. 将更改映射到实现步骤：

   • 读取任务文件，获取实现步骤列表
   • 对于每个已更改的文件，确定由哪个步骤创建或修改：
     • 检查步骤的“预期输出”部分，查看其中的文件路径
     • 检查步骤的子任务，查看其中的文件引用
     • 检查 #### Verification 部分中的步骤产物
   • 构建映射：{changed_file → step_number}

3. 确定受影响的步骤：

   • 找出所有关联了已更改文件的步骤
   • 最早受影响的步骤是起始步骤
   • 从该步骤开始，之后的所有步骤都需要重新验证
   • 更早且未受影响的步骤保持原样

4. 优化执行：

   • 按顺序处理每个受影响的步骤：
     • 启动评审 Agent，验证该步骤的产物（包括用户的更改）
     • 如果评审 PASS：将步骤标记为已完成，然后继续下一步
     • 如果评审 FAIL：启动实现 Agent，将用户的更改作为上下文，然后重新验证
   • 保留用户的手动修复——实现 Agent 应在其基础上继续，而不是覆盖它们

5. 示例：

   # User manually fixed src/validation/validation.service.ts
   # (This file was created in Step 2)
   
   /implement my-task.feature.md --refine
   
   # Detects: src/validation/validation.service.ts modified
   # Maps to: Step 2 (Create ValidationService)
   # Action: Launch judge for Step 2
   #   - If PASS: User's fix is good, proceed to Step 3
   #   - If FAIL: Implementation agent align rest of the code with user changes, without overwriting user's changes
   # Continues: Step 3, Step 4... (re-verify all subsequent steps)
   

6. 更改了多个文件：

   # User edited files from Step 2 AND Step 4
   
   /implement my-task.feature.md --refine
   
   # Detects: Files from Step 2 and Step 4 modified
   # Earliest affected: Step 2
   # Re-verifies: Step 2, Step 3, Step 4, Step 5...
   # (Step 3 re-verified even though no direct changes, because it depends on Step 2)
   

7. 已暂存与未暂存的更改：

   # 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
   # Staged changes are preserved, not re-verified
   
   # --
   
   # 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
   # validation.service.ts changes are verified
   

人在回路中的行为

以下情况会触发人工验证检查点：

1. 触发条件：

   • HUMAN_IN_THE_LOOP_STEPS 中某个步骤的实现和评审验证均为 PASS 后
   • 实现、评审和实现重试后（下一次评审重试前）
   • 如果 HUMAN_IN_THE_LOOP_STEPS 为 "*"，则每个步骤后都会触发

2. 在检查点：

   • 显示当前步骤结果摘要
   • 显示生成的产物及其路径
   • 显示评审评分和反馈
   • 询问用户：“查看步骤输出。继续？[Y/n/反馈]”
   • 如果用户提供反馈，则将其纳入下一轮迭代或步骤
   • 如果用户回复“n”，则暂停工作流

3. 检查点消息格式：

   ---
   ## 🔍 Human Review Checkpoint - Step X
   
   **Step:** {step title}
   **Step Type:** {standard/critical}
   **Judge Score:** {score}/{threshold for step type} threshold
   **Status:** ✅ PASS / 🔄 ITERATING (attempt {n})
   
   **Artifacts Created/Modified:**
   - {artifact_path_1}
   - {artifact_path_2}
   
   **Judge Feedback:**
   {feedback summary}
   
   **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/ - 已完成的任务

状态转换

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

---

关键：你只能担任协调者

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

务必为子 Agent 正确构建上下文！

关键：对于每个子 Agent（实现和评估），你都需要提供：

• 任务文件路径
• 步骤编号
• 条目编号（如适用）
• 产物路径（如适用）
• ${CLAUDE_PLUGIN_ROOT} 的值，以便 Agent 能解析 @${CLAUDE_PLUGIN_ROOT}/scripts/create-scratchpad.sh 等路径

你要做的事

• 只读取一次任务文件（仅限阶段 1）
• 通过 Task 工具启动子 Agent
• 接收子 Agent 的报告
• 获得评审确认后，将阶段标记为完成
• 汇总结果并向用户报告

你绝不能做的事

禁止操作	原因	应改为
读取实现输出	上下文膨胀 → 丢失命令	由子 Agent 报告其创建的内容
读取参考文件	理解模式是子 Agent 的工作	在子 Agent 提示词中加入路径
读取产物进行“检查”	上下文膨胀 → 忘记验证	启动评审 Agent
自行评估代码质量	这不是你的工作，会导致遗漏	启动评审 Agent
因为“很简单”而跳过验证	所有验证都是强制的	仍然启动评审 Agent

避免自我辩解的规则

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

如果你想：“我快速检查一下，看起来是否正确” → 停下。 启动评审 Agent。这不是你的工作。

如果你想：“这太简单了，不需要验证” → 停下。 如果任务指定了验证，就启动评审 Agent。没有例外。

如果你想：“我需要读取参考文件，才能写出好的提示词” → 停下。 在子 Agent 提示词中写明参考文件路径。由子 Agent 读取。

为什么这很重要

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

编排者“快速检查” = 跳过评审 Agent = 质量崩塌 = 产物不合格。

你的上下文窗口很宝贵。好好保护。把一切都交给 Agent。

---

重要提示

配置规则

• 标准步骤使用 THRESHOLD_FOR_STANDARD_COMPONENTS（默认值为 4.0）！
• 任务文件中标记为关键的步骤使用 THRESHOLD_FOR_CRITICAL_COMPONENTS（默认值为 4.5）！
• 默认迭代次数为 3 次——经过 3 轮修复→验证后停止，并继续下一步（同时发出警告）！
• 如果 MAX_ITERATIONS 设置为 unlimited：迭代至达到质量阈值（不限次数）
• 仅在 HUMAN_IN_THE_LOOP_STEPS 中指定的步骤之后（或设置为 "*" 时的所有步骤之后）触发人工介入检查点！
• 如果 SKIP_JUDGES 为 true：跳过所有评审验证——每个实现完成后直接继续下一步！
• 如果 CONTINUE_MODE 为 true：跳转到 RESUME_FROM_STEP——不要重新实现已完成的步骤！
• 如果 REFINE_MODE 为 true：检测已更改的项目文件，将其映射到对应步骤，并从 REFINE_FROM_STEP 开始重新验证——保留用户的修复！

执行与评估规则

• 仅使用前台 Agent：不要使用后台 Agent。尽可能并行启动 Agent。后台 Agent 经常遇到权限问题和其他错误。

重新启动评审，直到获得有效结果，或发生以下情况：

• 拒绝冗长报告：如果 Agent 返回非常长的报告，而没有按要求使用暂存区，则拒绝该结果。这表明 Agent 未遵循“使用暂存区”的指示。
• 评审评分为 5.0 是幻觉：如果评审返回 5.0/5.0，将其视为幻觉或敷衍评估。拒绝该结果并重新运行评审。如此严格的框架中，满分几乎不可能。
• 拒绝缺少评分的报告：如果评审报告缺少数字评分，则拒绝该报告。这表明评审未能阅读或遵循评分标准。

---

概览

此命令通过以下方式编排多步骤任务的实施：

1. 顺序执行，遵循步骤依赖关系
2. 并行执行，适用于依赖关系允许的情况
3. 使用评审 Agent 对关键步骤进行自动验证
4. 对高风险产物使用多 LLM 小组（PoLL）
5. 通过消除位置偏差进行汇总投票
6. 阶段跟踪，每次评审通过后进行确认

---

完整工作流概览

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/
    │
    ▼
Phase 1: Load Task
    │
    ▼
Phase 2: Execute Steps
    │
    ├─── For each step in dependency order:
    │    │
    │    ▼
    │    ┌─────────────────────────────────────────────────┐
    │    │ Launch sdd:developer agent                          │
    │    │ (implementation)                                │
    │    └─────────────────┬───────────────────────────────┘
    │                      │
    │                      ▼
    │    ┌─────────────────────────────────────────────────┐
    │    │ Launch judge agent(s)                           │
    │    │ (verification per #### Verification section)    │
    │    └─────────────────┬───────────────────────────────┘
    │                      │
    │                      ▼
    │    ┌─────────────────────────────────────────────────┐
    │    │ Judge PASS? → Mark step complete in task file   │
    │    │ Judge FAIL? → Fix and re-verify (max 2 retries) │
    │    └─────────────────────────────────────────────────┘
    │
    ▼
Phase 3: Final Verification
    │
    ├─── Verify all Definition of Done items
    │    │
    │    ▼
    │    ┌─────────────────────────────────────────────────┐
    │    │ Launch judge agent                              │
    │    │ (verify all DoD items)                          │
    │    └─────────────────┬───────────────────────────────┘
    │                      │
    │                      ▼
    │    ┌─────────────────────────────────────────────────┐
    │    │ All PASS? → Proceed to Phase 4                  │
    │    │ Any FAIL? → Fix and re-verify (iterate)         │
    │    └─────────────────────────────────────────────────┘
    │
    ▼
Phase 4: Move Task to Done
    │
    ├─── Move task: in-progress/ → done/
    │
    ▼
Phase 5: Final Report

---

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

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

步骤 0.1：解析任务文件

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

1. 先检查进行中的文件夹：

   ls .specs/tasks/in-progress/*.md 2>/dev/null
   

   • 如果恰好有 1 个文件 → 将 $TASK_FILE 设为该文件，将 $TASK_FOLDER 设为 in-progress
   • 如果有多个文件 → 列出这些文件并询问用户：“有多个进行中的任务。要继续哪一个？”
   • 如果没有文件 → 继续执行步骤 2

2. 检查待办文件夹：

   ls .specs/tasks/todo/*.md 2>/dev/null
   

   • 如果恰好有 1 个文件 → 将 $TASK_FILE 设为该文件，将 $TASK_FOLDER 设为 todo
   • 如果有多个文件 → 列出这些文件并询问用户：“待办中有多个任务。要实现哪一个？”
   • 如果没有文件 → 报告“没有可用任务。请先使用 /add-task 创建一个。”并停止

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

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

步骤 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

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

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

### Configuration

| Setting | Value |
|---------|-------|
| **Task File** | {TASK_PATH} |
| **Standard Components Threshold** | {THRESHOLD_FOR_STANDARD_COMPONENTS}/5.0 |
| **Critical Components Threshold** | {THRESHOLD_FOR_CRITICAL_COMPONENTS}/5.0 |
| **Max Iterations** | {MAX_ITERATIONS or "3"} |
| **Human Checkpoints** | {HUMAN_IN_THE_LOOP_STEPS as comma-separated or "All steps" or "None"} |
| **Skip Judges** | {SKIP_JUDGES} |
| **Continue Mode** | {CONTINUE_MODE} |
| **Refine Mode** | {REFINE_MODE} |

步骤 0.4：处理继续模式

如果 CONTINUE_MODE 为 true：

1. 识别最后完成的步骤：

   • 检查任务文件中步骤标题上的 [DONE] 标记
   • 找出标记为 [DONE] 的最高步骤编号
   • 将 LAST_COMPLETED_STEP 设为该编号（如果没有则设为 0）

2. 验证最后完成的步骤（如有）：

   • 如果 LAST_COMPLETED_STEP > 0：
     • 启动 judge agent，验证该步骤的产物
     • 如果 judge 通过：将 RESUME_FROM_STEP 设为 LAST_COMPLETED_STEP + 1
     • 如果 judge 未通过：将 RESUME_FROM_STEP 设为 LAST_COMPLETED_STEP（重新实现）

3. 跳至恢复点：

   • 在阶段 2 中，跳过 RESUME_FROM_STEP 之前的所有步骤
   • 从 RESUME_FROM_STEP 开始继续执行

步骤 0.5：处理优化模式

如果 REFINE_MODE 为 true：

1. 检测发生变更的项目文件：

   # 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
   

2. 加载任务文件并提取步骤→文件映射：

   • 读取任务文件以获取实现步骤
   • 对于每个步骤，从以下内容中提取其创建或修改的文件：
     • “预期输出”部分
     • 提及文件路径的子任务说明
     • #### Verification 中的产物路径
   • 构建映射：STEP_FILE_MAP = {step_number → [file_paths]}

3. 将变更文件映射到步骤：

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

   • 如果没有匹配的步骤：“变更文件无法映射到任何实现步骤。请手动验证。”

4. 确定优化范围：

   • REFINE_FROM_STEP = min(AFFECTED_STEPS) # 最早受影响的步骤
   • 从 REFINE_FROM_STEP 开始及之后的所有步骤都需要重新验证
   • 保留 REFINE_FROM_STEP 之前的步骤，不作更改

5. 保存变更文件上下文：

   • CHANGED_FILES = 变更文件路径列表
   • USER_CHANGES_CONTEXT = 受影响文件的 git diff 输出
   • 将此上下文传递给 judge 和实现 Agent
   • Agent 应在用户修复的基础上继续，而不是覆盖这些修复

阶段 1：加载并分析任务

这是唯一可以读取文件的阶段。

步骤 1.1：加载任务详情

只读取一次任务文件：

Read $TASK_PATH

读取完成后，执行的其余部分不得读取任何其他文件。

步骤 1.2：确定实现步骤

解析 ## Implementation Process 部分：

• 列出所有步骤及其依赖关系
• 确定哪些步骤带有 Parallel with: 注释
• 根据 #### Verification 部分，对每个步骤的验证需求进行分类：

验证级别	使用时机	评审配置
无	简单操作（mkdir、delete）	跳过验证
单个评审者	非关键产物	1 名评审者，阈值 4.0/5.0
2 名评审者组成的评审小组	关键产物	2 名评审者，按中位数投票，阈值 4.5/5.0
每项单独评审	多个相似项目	每项 1 名评审者，并行评审

步骤 1.3：创建待办列表

使用 TodoWrite 创建包含所有实现步骤的待办列表，并标记验证要求：

{
  "todos": [
    {"content": "Step 1: [Title] - [Verification Level]", "status": "pending", "activeForm": "Implementing Step 1"},
    {"content": "Step 2: [Title] - [Verification Level]", "status": "pending", "activeForm": "Implementing Step 2"}
  ]
}

---

阶段 2：执行实现步骤

按依赖顺序执行每个步骤：

模式 A：简单步骤（无需验证）

1. 启动开发者 Agent：

使用 Task 工具，并设置：

• Agent 类型：sdd:developer
• 模型：按步骤指定，或默认使用 opus
• 描述："Implement Step [N]: [Title]"
• 提示词：

Implement Step [N]: [Step Title]

Task File: $TASK_PATH
Step Number: [N]

Your task:
- Execute ONLY Step [N]: [Step Title]
- Do NOT execute any other steps
- Follow the Expected Output and Success Criteria exactly

When complete, report:
1. What files were created/modified (paths)
2. Confirmation that success criteria are met
3. Any issues encountered

2. 使用 Agent 的报告（无需验证）

• Agent 报告创建了什么 → 使用此信息
• 不要自行读取创建的文件
• 此模式无需验证（适用于简单操作）

3. 将步骤标记为已完成

• 更新任务文件：
  • 在步骤标题中标记 [DONE]（例如，### Step 1: Setup [DONE]）
  • 将步骤的子任务标记为 [X]，表示已完成
• 将待办事项更新为 completed

---

模式 B：关键步骤（由 2 名评审者进行评估）

1. 启动开发者 Agent：

使用 Task 工具，并设置：

• Agent 类型：sdd:developer
• 模型：按步骤指定，或默认使用 opus
• 描述："Implement Step [N]: [Title]"
• 提示词：

Implement Step [N]: [Step Title]

Task File: $TASK_PATH
Step Number: [N]

Your task:
- Execute ONLY Step [N]: [Step Title]
- Do NOT execute any other steps
- Follow the Expected Output and Success Criteria exactly

When complete, report:
1. What files were created/modified (paths)
2. Confirmation of completion
3. Self-critique summary

2. 等待完成

• 接收 Agent 的报告
• 记录报告中的产物路径
• 不要自行读取产物

3. 并行启动 2 个评估 Agent（必须）：

⚠️ 必须：此模式要求启动评估 Agent。必须启动这些评估，不得跳过，也不得自行验证。

评估时使用 sdd:developer Agent 类型

评估 1 和 2（使用相同的提示词结构并行启动）：

CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

Read @${CLAUDE_PLUGIN_ROOT}/prompts/judge.md for evaluation methodology.

Evaluate artifact at: [artifact_path from implementation agent report]

**Chain-of-Thought Requirement:** Justification MUST be provided BEFORE score for each criterion.

Rubric:
[paste rubric table from #### Verification section]

Context:
- Read $TASK_PATH
- Verify Step [N] ONLY: [Step Title]
- Threshold: [from #### Verification section]
- Reference pattern: [if specified in #### Verification section]

You can verify the artifact works - run tests, check imports, validate syntax.

Return: scores per criterion with evidence, overall weighted score, PASS/FAIL, improvements if FAIL.

4. 汇总结果：

• 计算各项评审标准的中位数得分
• 标记方差较大的评审标准（std > 1.0）
• 若总体中位数 ≥ 阈值，则通过

5. 确定阈值：

• 检查任务文件中是否将该步骤标记为关键步骤（在 #### Verification 部分或步骤元数据中）
• 如果是关键步骤：使用 THRESHOLD_FOR_CRITICAL_COMPONENTS
• 如果是标准步骤：使用 THRESHOLD_FOR_STANDARD_COMPONENTS

6. 未通过时：迭代直至通过（默认最多 3 次）

• 将评审者的反馈和问题提供给实现 Agent
• 根据评审反馈重新实现（使代码符合要求；若处于完善模式，则保留用户的更改）
• 由评审者重新验证
• 持续迭代直至通过——继续修复 → 验证的循环，直到达到质量阈值或达到最大迭代次数
• 如果达到 MAX_ITERATIONS（默认值为 3）：
  • 记录警告："Step [N] did not pass after {MAX_ITERATIONS} iterations"
  • 继续下一步骤（不要无限期阻塞）

7. 通过时：将步骤标记为已完成

• 更新任务文件：
  • 在步骤标题中标记 [DONE]（例如，### Step 2: Create Service [DONE]）
  • 将步骤的子任务标记为 [X]，表示已完成
• 将待办事项更新为 completed
• 在跟踪记录中记录评审者的得分

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

仅当步骤通过后，且步骤编号包含在 HUMAN_IN_THE_LOOP_STEPS 中（或 HUMAN_IN_THE_LOOP_STEPS == "*"）时：

---
## 🔍 Human Review Checkpoint - Step [N]

**Step:** [Step Title]
**Judge Score:** [score]/[threshold for step type] threshold
**Status:** ✅ PASS

**Artifacts Created/Modified:**
- [artifact_path_1]
- [artifact_path_2]

**Judge Feedback:**
[feedback summary from judges]

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

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

• 如果用户提供反馈：保存反馈，以供下一步骤使用；或根据反馈重新实现当前步骤
• 如果用户回复 "n"：暂停工作流并报告当前进度
• 如果用户回复 "Y" 或继续：进入下一步骤

---

模式 C：多条目步骤（逐项评估）

对于会创建多个相似条目的步骤：

1. 并行启动开发 Agent（每项一个）：

对每个条目使用 Task 工具（全部并行启动）：

• Agent 类型：sdd:developer
• 模型：按指定值，或默认使用 opus
• 描述："Implement Step [N], Item: [Name]"
• 提示词：

Implement Step [N], Item: [Item Name]

Task File: $TASK_PATH
Step Number: [N]
Item: [Item Name]

Your task:
- Create ONLY [item_name] from Step [N]
- Do NOT create other items or steps
- Follow the Expected Output and Success Criteria exactly

When complete, report:
1. File path created
2. Confirmation of completion
3. Self-critique summary

2. 等待全部完成

• 收集所有 Agent 报告
• 记录所有产物路径
• 不要自行读取任何已创建的文件

3. 并行启动评估 Agent（每项一个）

⚠️ 必须：启动评估 Agent。不要跳过。不要自行验证。

评估时使用 sdd:developer Agent 类型

对每个条目：

CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

Read @${CLAUDE_PLUGIN_ROOT}/prompts/judge.md for evaluation methodology.

Evaluate artifact at: [item_path from implementation agent report]

**Chain-of-Thought Requirement:** Justification MUST be provided BEFORE score for each criterion.

Rubric:
[paste rubric from #### Verification section]

Context:
- Read $TASK_PATH
- Verify Step [N]: [Step Title]
- Verify ONLY this Item: [Item Name]
- Threshold: [from #### Verification section]

You can verify the artifact works - run tests, check syntax, confirm dependencies.

Return: scores with evidence, overall score, PASS/FAIL, improvements if FAIL.

4. 收集所有结果

5. 汇总报告：

• 通过的条目：X/Y
• 需要修改的条目：[列出具体问题]

6. 确定阈值：

• 检查任务文件中是否将此步骤标记为关键步骤（在 #### Verification 部分或步骤元数据中）
• 如果是关键步骤：使用 THRESHOLD_FOR_CRITICAL_COMPONENTS
• 如果是常规步骤：使用 THRESHOLD_FOR_STANDARD_COMPONENTS

7. 如果有任何 FAIL：迭代，直到全部 PASS

• 向实现 Agent 提供失败条目及评审反馈
• 仅重新实现失败条目，并纳入反馈（在 refine 模式下保留用户的更改）
• 使用评审重新验证失败条目
• 迭代，直到全部 PASS——持续进行修复 → 验证循环，直到所有条目达到质量阈值或达到最大迭代次数
• 如果达到 MAX_ITERATIONS（默认值为 3）：
  • 记录警告："Step [N] has {X} items that did not pass after {MAX_ITERATIONS} iterations"
  • 继续下一步（不要无限期阻塞）

8. 全部 PASS 后：标记步骤已完成

• 更新任务文件：
  • 在步骤标题后标记 [DONE]（例如：### Step 3: Create Items [DONE]）
  • 将该步骤的子任务标记为 [X] 已完成
• 将待办事项更新为 completed
• 在跟踪记录中记录通过率

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

仅在所有条目 PASS 后，如果步骤编号位于 HUMAN_IN_THE_LOOP_STEPS 中（或 HUMAN_IN_THE_LOOP_STEPS == "*"）：

---
## 🔍 Human Review Checkpoint - Step [N]

**Step:** [Step Title]
**Items Passed:** X/Y
**Status:** ✅ ALL PASS

**Artifacts Created:**
- [item_1_path]
- [item_2_path]
- ...

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

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

• 如果用户提供反馈：保存反馈以供下一步使用，或根据反馈重新实现条目
• 如果用户回复 "n"：暂停工作流并报告当前进度
• 如果用户回复 "Y" 或继续：进入下一步

---

⚠️ 检查点：继续最终验证前

进入最终验证前，请确认你遵守了以下规则：

• 是否为所有实现启动了 sdd:developer Agent？
• 是否为所有验证启动了评估 Agent？
• 是否仅在评审 PASS 后才将步骤标记为已完成？
• 是否避免自行读取任何产物文件？

如果你读取了任务文件以外的文件，说明操作有误。停止并重新开始。

---

阶段 3：最终验证

所有实现步骤完成后，验证任务是否符合所有完成定义标准。

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

使用 Task 工具并提供：

• Agent 类型：sdd:developer
• 模型：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 "## Definition of Done (Task Level)" section
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 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

Be thorough - check everything the task requires.

步骤 3.2：查看验证结果

• 接收验证报告
• 记录哪些条目 PASS，哪些 FAIL
• 如果评审报告显示所有条目均 PASS，你必须读取任务文件末尾，确认所有 DoD 条目都已标记为 [X]

步骤 3.3：修复失败条目（如有）

如果任何完成定义条目 FAIL：

1. 为每个失败条目启动开发 Agent：

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：将任务移至 Done

所有完成定义条目均 PASS 后，将任务移至 done 文件夹。

步骤 4.1：确认完成情况

确认任务文件中的所有完成定义条目都已标记为已完成。

步骤 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/

---

阶段 5：聚合与报告

评审组投票算法

使用 2 次或更多次评估时，请按照以下手动计算步骤操作：

• 分步思考，分别输出每一步的结果！
• 不要跳过步骤！

步骤 1：收集各项标准的分数

创建一个表格，列出每项标准及所有评估的分数：

标准	评估 1	评估 2	中位数	差值
[名称 1]	X.X	X.X	?	?
[名称 2]	X.X	X.X	?	?

步骤 2：计算每项标准的中位数

对于 2 次评估：中位数 =（分数 1 + 分数 2）/ 2

对于 3 次或更多评估：将分数排序，取中间值（若数量为偶数，则取中间两个值的平均值）

步骤 3：检查是否存在高方差

高方差 = 评估者存在显著分歧（差值 > 2.0 分）

公式：|Eval1 - Eval2| > 2.0 → 标记为高方差

步骤 4：计算加权总分

将每项标准的中位数乘以其权重，然后求和：

Overall = (Criterion1_Median × Weight1) + (Criterion2_Median × Weight2) + ...

步骤 5：确定通过/未通过

将总分与阈值进行比较：

• Overall ≥ Threshold → 通过 ✅
• Overall < Threshold → 未通过 ❌

---

处理意见分歧

如果评估之间存在显著分歧（任意标准的差值 > 2.0）：

1. 标记该标准
2. 呈现两位评估者的推理
3. 询问用户：“评估者对 [标准] 存在分歧。是否手动审核？”
4. 如果是：呈现证据，获取用户决定
5. 如果否：使用中位数（保守做法）

最终报告

所有步骤完成且 DoD 验证通过后：

## Implementation Summary

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

### Configuration Used

| Setting | Value |
|---------|-------|
| **Standard Components Threshold** | {THRESHOLD_FOR_STANDARD_COMPONENTS}/5.0 |
| **Critical Components Threshold** | {THRESHOLD_FOR_CRITICAL_COMPONENTS}/5.0 |
| **Max Iterations** | {MAX_ITERATIONS or "3"} |
| **Human Checkpoints** | {HUMAN_IN_THE_LOOP_STEPS or "None"} |
| **Skip Judges** | {SKIP_JUDGES} |
| **Continue Mode** | {CONTINUE_MODE} |
| **Refine Mode** | {REFINE_MODE} |

### Steps Completed

| Step | Title | Status | Verification | Score | Iterations | Judge Confirmed |
|------|-------|--------|--------------|-------|------------|-----------------|
| 1    | [Title] | ✅ | Skipped | N/A | 1 | - |
| 2    | [Title] | ✅ | Panel (2) | 4.5/5 | 1 | ✅ |
| 3    | [Title] | ✅ | Per-Item | 5/5 passed | 2 | ✅ |
| 4    | [Title] | ✅ | Single | 4.2/5 | 3 | ✅ |

**Legend:**
- ✅ PASS - Score >= threshold for step type
- ⚠️ MAX_ITER - Did not pass but MAX_ITERATIONS reached, proceeded anyway
- ⏭️ SKIPPED - Step skipped (continue/refine mode)

### Verification Summary

- Total steps: X
- Steps with verification: Y
- Passed on first try: Z
- Required iteration: W
- Total iterations across all steps: 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]

### High-Variance Criteria (Evaluators Disagreed)

- [Criterion] in [Step]: Eval 1 scored X, Eval 2 scored Y

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

| Step | Checkpoint | User Action | Feedback Incorporated |
|------|------------|-------------|----------------------|
| 2    | After PASS | Continued | - |
| 4    | After iteration 2 | Feedback | "Improve error messages" |
| 6    | After PASS | Continued | - |

### Task File Updated

- Task moved from `in-progress/` to `done/` folder
- All step titles marked `[DONE]`
- All step subtasks marked `[X]`
- All Definition of Done items marked `[X]`

### Recommendations

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

---

执行流程图

┌──────────────────────────────────────────────────────────────┐
│                IMPLEMENT TASK WITH VERIFICATION               │
├──────────────────────────────────────────────────────────────┤
│                                                               │
│  Phase 0: Select Task                                         │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │ Use provided name or auto-select from todo/ (if 1 task) │  │
│  │ → Move task from todo/ to in-progress/                  │  │
│  └─────────────────────────────────────────────────────────┘  │
│                           │                                   │
│                           ▼                                   │
│  Phase 1: Load Task                                           │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │ Read $TASK_PATH → Parse steps                           │  │
│  │ → Extract #### Verification specs → Create TodoWrite    │  │
│  └─────────────────────────────────────────────────────────┘  │
│                           │                                   │
│                           ▼                                   │
│  Phase 2: Execute Steps (Respecting Dependencies)             │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │                                                          │  │
│  │  For each step:                                          │  │
│  │                                                          │  │
│  │  ┌──────────────┐    ┌───────────────┐    ┌───────────┐ │  │
│  │  │ developer    │───▶│ Judge Agent   │───▶│ PASS?     │ │  │
│  │  │ Agent        │    │ (verify)      │    │           │ │  │
│  │  └──────────────┘    └───────────────┘    └───────────┘ │  │
│  │                                                │   │     │  │
│  │                                               Yes  No    │  │
│  │                                                │   │     │  │
│  │                                                ▼   ▼     │  │
│  │                                    ┌────────┐  Fix & │   │  │
│  │                                    │ Mark   │  Retry │   │  │
│  │                                    │Complete│  ↺     │   │  │
│  │                                    └────────┘        │   │  │
│  └─────────────────────────────────────────────────────────┘  │
│                           │                                   │
│                           ▼                                   │
│  Phase 3: Final Verification                                  │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │                                                         │  │
│  │  ┌──────────────┐    ┌───────────────┐    ┌───────────┐ │  │
│  │  │ Judge Agent  │───▶│ All DoD       │───▶│ All PASS? │ │  │
│  │  │ (verify DoD) │    │ items checked │    │           │ │  │
│  │  └──────────────┘    └───────────────┘    └───────────┘ │  │
│  │                                                │   │    │  │
│  │                                               Yes  No   │  │
│  │                                                │   │    │  │
│  │                                                ▼   ▼    │  │
│  │                                                Fix &    │  │
│  │                                                Retry    │  │
│  │                                                ↺        │  │
│  │                                                         │  │
│  └─────────────────────────────────────────────────────────┘  │
│                           │                                   │
│                           ▼                                   │
│  Phase 4: Move Task to Done                                   │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │ mv in-progress/$TASK → done/$TASK                       │  │
│  └─────────────────────────────────────────────────────────┘  │
│                           │                                   │
│                           ▼                                   │
│  Phase 5: Aggregate & Report                                  │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │ Collect all verification 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 last completed step
/implement add-validation.feature.md --continue

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

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

# Human review after specific steps only
/implement add-validation.feature.md --human-in-the-loop 2,4,6

# Higher quality threshold (stricter) - sets both standard and critical to 4.5
/implement add-validation.feature.md --target-quality 4.5

# Different thresholds for standard (3.5) and critical (4.5) components
/implement add-validation.feature.md --target-quality 3.5,4.5

# Lower quality threshold for both (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 judge verifications (fast but no quality gates)
/implement add-validation.feature.md --skip-judges

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

示例 1：实现功能

User: /implement add-validation.feature.md

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

Phase 1: Loading task...
Task: "Add form validation service"
Steps identified: 4 steps

Verification plan (from #### Verification sections):
- Step 1: No verification (directory creation)
- Step 2: Panel of 2 evaluations (ValidationService)
- Step 3: Per-item evaluations (3 validators)
- Step 4: Single evaluation (integration)

Phase 2: Executing...

Step 1: Launching sdd:developer agent...
  Agent: "Implement Step 1: Create Directory Structure..."
  Result: ✅ Directories created
  Verification: Skipped (simple operation)
  Status: ✅ COMPLETE

Step 2: Launching sdd:developer agent...
  Agent: "Implement Step 2: Create ValidationService..."
  Result: Files created, tests passing

  Launching 2 judge agents in parallel...
  Judge 1: 4.3/5.0 - PASS
  Judge 2: 4.5/5.0 - PASS
  Panel Result: 4.4/5.0 ✅
  Status: ✅ COMPLETE (Judge Confirmed)

[Continue for all steps...]

Phase 3: Final Verification...
Launching DoD verification agent...
  Agent: "Verify all Definition of Done items..."
  Result: 4/4 items PASS ✅

Phase 4: Moving task to done...
  mv .specs/tasks/in-progress/add-validation.feature.md .specs/tasks/done/

Phase 5: Final Report
Implementation complete.
- 4/4 steps completed
- 6 artifacts verified
- All passed first try
- Definition of Done: 4/4 PASS
- Task location: .specs/tasks/done/add-validation.feature.md ✅

示例 2：处理 DoD 项失败

[All steps complete...]

Phase 3: Final Verification...
Launching DoD verification agent...
  Agent: "Verify all Definition of Done items..."
  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...
  Agent: "Fix ESLint errors..."
  Result: Fixed 356 errors, 0 warnings ✅

Re-launching DoD verification agent...
  Agent: "Re-verify all Definition of Done items..."
  Result: 4/4 items PASS ✅

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

Phase 5: Final Report
Task verification complete.
- All DoD items now PASS
- 1 issue fixed (ESLint errors)
- Task location: .specs/tasks/done/ ✅

示例 3：处理验证失败

Step 3 Implementation complete.
Launching judge agents...

Judge 1: 3.5/5.0 - FAIL (threshold 4.0)
Judge 2: 3.2/5.0 - FAIL

Issues found:
- Test Coverage: 2.5/5
  Evidence: "Missing edge case tests for empty input"
  Justification: "Success criteria requires edge case coverage"
- Pattern Adherence: 3.0/5
  Evidence: "Uses custom Result type instead of project standard"
  Justification: "Should use existing Result<T, E> from src/types"

Should I attempt to fix these issues? [Y/n]

User: Y

Launching sdd:developer agent with feedback...
Agent: "Fix Step 3: Address judge feedback..."
Result: Issues fixed, tests added

Re-launching judge agents...
Judge 1: 4.2/5.0 - PASS
Judge 2: 4.4/5.0 - PASS
Panel Result: 4.3/5.0 ✅
Status: ✅ COMPLETE (Judge Confirmed)

示例 4：从中断处继续

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

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

Scanning task file for completed steps...
Found: Step 1 [DONE], Step 2 [DONE]
Last completed: Step 2

Verifying Step 2 artifacts...
Launching judge agent for Step 3...
Judge: 4.3/5.0 - PASS ✅
Marking step as complete in task file...

Resuming from Step 4...

Step 3: Launching sdd:developer agent...
[continues normally from Step 4]

示例 5：根据用户修复进行优化

# User manually fixed src/validation/validation.service.ts
# (This file was created in Step 2: Create ValidationService)

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

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

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

Mapping files to implementation steps...
- src/validation/validation.service.ts → Step 2 (Create ValidationService)

Earliest affected step: Step 2
Preserving: Step 1 (unchanged)
Re-verifying from: Step 2 onwards

Step 2: Launching judge to verify rest of logic with user's changes...
Judge: 4.3/5.0 - PASS ✅
Rest of logic is not affected, proceeding...

Step 3: Launching judge to verify...
Judge: typescript error detected in file
Launching imeplementation agent to fix the error, and align logic with user's changes...

Launching judge to verify fixed logic...
Judge: 4.5/5.0 - PASS ✅

[continues verifying remaining steps...]

All steps verified with user's changes incorporated ✅

示例 6：人在回路审核

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

Configuration:
- Human Checkpoints: All steps

Step 1: Launching sdd:developer agent...
Result: Directories created ✅

---
## 🔍 Human Review Checkpoint - Step 1

**Step:** Create Directory Structure
**Judge Score:** N/A (no verification)
**Status:** ✅ COMPLETE

**Artifacts Created:**
- src/validation/
- src/validation/tests/

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

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

Step 2: Launching sdd:developer agent...
Result: ValidationService created ✅

Launching judge agents...
Judge 1: 4.5/5.0 - PASS
Judge 2: 4.3/5.0 - PASS
Panel Result: 4.4/5.0 ✅

---
## 🔍 Human Review Checkpoint - Step 2

**Step:** Create ValidationService
**Judge Score:** 4.4/5.0 (threshold: 4.0)
**Status:** ✅ PASS

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

**Judge Feedback:**
- All criteria met
- Test coverage comprehensive

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

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

Incorporating feedback: "error messages could be more descriptive"
Re-launching sdd:developer agent with feedback...
[iteration continues]

示例 7：严格的质量阈值

User: /implement critical-api.feature.md --target-quality 4.5

Configuration:
- Target Quality: 4.5/5.0

Step 2: Implementing critical API endpoint...
Result: Endpoint created

Launching judge agents...
Judge 1: 4.2/5.0 - FAIL (threshold: 4.5)
Judge 2: 4.3/5.0 - FAIL

Iteration 1: Re-implementing with feedback...
[fixes applied]

Launching judge agents...
Judge 1: 4.4/5.0 - FAIL
Judge 2: 4.5/5.0 - PASS

Iteration 2: Re-implementing with feedback...
[more fixes applied]

Launching judge agents...
Judge 1: 4.6/5.0 - PASS
Judge 2: 4.5/5.0 - PASS
Panel Result: 4.55/5.0 ✅

Status: ✅ COMPLETE (passed on iteration 2)

---

错误处理

实现失败

如果 sdd:developer agent 报告失败：

1. 向用户展示失败详情
2. 提出有助于解决问题的澄清问题
3. 根据澄清内容再次启动 sdd:developer agent

评审者意见分歧

如果评审者存在显著分歧（差值 > 2.0）：

1. 提供双方观点及证据
2. 请用户作出决定：“评审者存在分歧。由您决定？”
3. 根据用户的决定继续

优化模式：未检测到变更

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

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

优化模式：变更无法对应到步骤

如果 --refine 模式发现了变更文件，但这些文件都无法对应到实现步骤：

1. 报告：“变更文件与任何实现步骤的预期输出都不匹配。”
2. 列出检测到的变更文件
3. 建议：“手动验证，或不使用 --refine 运行，以重新验证所有步骤。”

---

检查清单

完成实现前：

配置处理

• 正确解析了 $ARGUMENTS 中的所有标志
• 对标准步骤使用了 THRESHOLD_FOR_STANDARD_COMPONENTS
• 对关键步骤使用了 THRESHOLD_FOR_CRITICAL_COMPONENTS
• 持续迭代，直到达到质量阈值（或达到 MAX_ITERATIONS，默认值为 3）
• 仅对 HUMAN_IN_THE_LOOP_STEPS 中的步骤触发人在回路检查点
• 如果 SKIP_JUDGES 为 true：跳过所有评审验证
• 如果 CONTINUE_MODE 为 true：验证最后一步并正确恢复执行
• 如果 REFINE_MODE 为 true：检测变更的项目文件，将其对应到步骤，并从最早受影响的步骤开始重新验证

上下文保护（关键）

• 仅阅读任务文件（.specs/tasks/in-progress/ 中的 $TASK_PATH）——不读取其他文件
• 未读取实现输出、参考文件或工件
• 使用子 Agent 报告了解状态——未通过读取文件进行“检查”

委派

• 所有实现均由 sdd:developer Agent 通过 Task 工具完成
• 所有评估均由 sdd:developer Agent 通过 Task 工具完成
• 未自行执行任何验证
• 未跳过任何验证步骤（除非 SKIP_JUDGES 为 true）

阶段跟踪

• 仅在评审通过后（或 SKIP_JUDGES 时立即）将每个步骤标记为完成
• 每个步骤完成后更新任务文件：
  • 步骤标题标记为 [DONE]
  • 子任务标记为 [X]
• 每个步骤完成后更新待办列表

执行质量

• 按依赖顺序执行所有步骤
• 同时启动并行步骤（而非依次执行）
• 每个 sdd:developer Agent 都收到明确指定步骤的聚焦提示
• 所有关键工件均由评审者评估（除非 SKIP_JUDGES）
• 对高风险工件采用评审小组投票
• 所有评估提示均包含思维链要求
• 评估失败后持续迭代，直至达到质量门槛
• 生成包含评审确认状态的最终报告
• 将评估者之间的分歧告知用户

人机协作（如已启用）

• 在 HUMAN_IN_THE_LOOP_STEPS 中的每个步骤之后显示检查点
• 将用户反馈纳入后续迭代或步骤
• 用户要求暂停时暂停工作流

最终验证与完成

• 启动定义完成（DoD）验证 Agent
• 验证所有 DoD 项目（状态为 PASS/FAIL/BLOCKED）
• 通过 sdd:developer Agent 修复未通过的 DoD 项目
• 修复后重新验证
• 将任务从 in-progress/ 移至 done/ 文件夹
• 将任务文件中的所有 DoD 复选框标记为 [X]
• 向用户展示最终验证报告

---

附录 A：验证规范参考

本附录说明如何在任务文件中指定验证要求。在第 2 阶段（执行步骤）中，请参考这些规范，了解如何验证每项工件。

任务文件如何定义验证要求

任务文件在每个实现步骤的 #### Verification 部分中定义验证要求。这些部分指定了：

必需元素

1. 级别：验证复杂度

   • None——简单操作（mkdir、delete）——跳过验证
   • Single Judge——非关键工件——1 位评审者，门槛为 4.0/5.0
   • Panel of 2 Judges——关键工件——2 位评审者，采用中位数投票，门槛为 4.0/5.0 或 4.5/5.0
   • Per-Item Judges——多个相似项目——每项由 1 位评审者评审，并行执行

2. 工件：待验证文件的路径

   • 示例：src/decision/decision.service.ts、src/decision/tests/decision.service.spec.ts

3. 门槛：最低通过分数

   • 标准质量通常为 4.0/5.0
   • 关键组件有时为 4.5/5.0

4. 评分标准：加权标准表（见下方格式）

5. 参考模式（可选）：优质实现示例的路径

   • 示例：src/app.service.ts，用于参考 NestJS 服务模式

评分标准格式

任务文件中的评分标准使用以下 Markdown 表格格式：

| Criterion | Weight | Description |
|-----------|--------|-------------|
| [Name 1]  | 0.XX   | [What to evaluate] |
| [Name 2]  | 0.XX   | [What to evaluate] |
| ...       | ...    | ...         |

要求：

• 权重之和必须为 1.0
• 每项标准都有明确且可衡量的描述
• 每份评分标准通常包含 3–6 项标准

示例：

| Criterion | Weight | Description |
|-----------|--------|-------------|
| Type Correctness | 0.35 | Types match specification exactly |
| API Contract Alignment | 0.25 | Aligns with documented API contract |
| Export Structure | 0.20 | Barrel exports correctly expose all types |
| Code Quality | 0.20 | Follows project TypeScript conventions |

评分标准

评审者评估产物时，会针对每项标准使用以下 5 分制：

• 1（差）：不符合要求

  • 缺少关键要素
  • 从根本上误解了要求

• 2（低于平均水平）：存在多个问题，部分符合要求

  • 有些要素正确，但存在明显缺漏
  • 需要大幅返工

• 3（合格）：符合基本要求

  • 可用，但较为简单
  • 质量或完整性仍有提升空间

• 4（良好）：符合所有要求，仅有少量小问题

  • 实现扎实
  • 稍加润色即可有所提升

• 5（优秀）：超出要求

  • 质量出众
  • 做到了超出所要求的内容
  • 可作为参考实现

执行期间使用验证规范

在阶段 2（执行步骤）期间：

1. sdd:developer Agent 完成实现后
2. 阅读任务文件中该步骤的 #### Verification 部分
3. 提取：Level、Artifact paths、Threshold、Rubric、Reference Pattern
4. 根据 Level 启动适当的评审 Agent
5. 向评审者提供：Artifact path、Rubric、Threshold、Reference Pattern
6. 汇总评审结果并判定 PASS/FAIL
7. 如果为 FAIL，则启动 sdd:developer Agent 修复问题并重新验证

任务文件中的验证部分示例：

#### Verification

**Level:** Panel of 2 Judges with Aggregated Voting
**Artifact:** `src/decision/decision.service.ts`, `src/decision/tests/decision.service.spec.ts`

**Rubric:**

| Criterion | Weight | Description |
|-----------|--------|-------------|
| Routing Logic | 0.20 | Correctly routes by customerType |
| Drip Feed Implementation | 0.25 | 2% random approval for rejected New customers only |
| Response Formatting | 0.20 | Correct decision outcome, triggeredRules preserved, ISO 8601 timestamp |
| Testability | 0.15 | Injectable randomGenerator enables deterministic testing |
| Test Coverage | 0.20 | Unit tests cover approval, rejection, drip feed, routing, timestamp |

**Reference Pattern:** NestJS service patterns, ZenEngineService API

此规范要求你：

• 并行启动 2 个评审 Agent
• 让他们评估服务文件和测试文件
• 使用指定权重的 5 项标准评分表
• 不要将 threshold 提供给评审者，只用它与评审者的平均分进行比较
• 参照现有的 NestJS 模式进行比较