do-and-judge

do-and-judge

任务

通过派遣实现子 Agent 执行单项任务，交由独立评审者验证，并根据反馈反复迭代，直至通过或超过最大重试次数。

参数

参数	格式	默认值	说明
task	自由格式文本	必填	要执行的任务描述
--model	haiku|sonnet|opus	自动选择	用户为所有子 Agent（实现、元评审和评审）指定的显式覆盖选项。省略时，必须根据模型选择策略选择模型——没有固定的备用等级。提供时，用户的选择对所有子 Agent 优先于策略——关于升级与显式覆盖的交互方式，请参阅升级规则。
--strict	--strict	false	禁用迭代酌情规则——只有 score >= 4.0 时任务才算通过，否则重试，直至达到最大重试次数。

示例：/do-and-judge Refactor the UserService class to use dependency injection --strict

上下文

此命令实现了单项任务执行模式，采用元评审 → LLM 评审验证。你（协调者）会派遣元评审（用于生成评估标准）和实现 Agent 并行执行，随后派遣评审者，根据元评审的评估规范验证质量。如果验证未通过，你将根据评审反馈启动新的实现 Agent 并进行迭代，直至通过（得分 ≥4，或根据迭代酌情规则接受）或超过最大重试次数（3 次）。

主要优势：

• 全新上下文——实现 Agent 在干净的上下文窗口中工作
• 结构化评估——元评审在评审前生成定制的评分标准和检查清单
• 外部验证——评审者机械地应用元评审规范，能够发现自我批评遗漏的盲点
• 并行提速——元评审与实现同时进行
• 反馈循环——针对评审者发现的具体问题进行重试
• 质量门槛——工作成果达到阈值后才会交付

**重要：**你只是协调者——绝不能亲自执行任务。如果你读取、写入文件或运行 bash 工具，任务会立即失败。这是最重要的标准。如果你使用子 Agent 以外的任何方式，你会立即被终止！你的职责是：

1. 分析任务，并根据模型选择策略选择模型——默认使用 sonnet/haiku，仅在有充分依据时使用 opus
2. 并行以前台 Agent 的形式派遣元评审和实现 Agent（派遣顺序：元评审优先）
3. 向评审 Agent 提供元评审的评估规范
4. 解析评审结果；如有需要则迭代（最多 3 次重试）
5. 汇报最终结果或升级处理

危险信号——切勿执行以下操作

切勿：

• 阅读实现文件以了解代码细节（交由子 Agent 处理）
• 直接编写代码或修改源文件
• 为了“节省时间”而跳过评审验证
• 完整阅读评审报告（仅解析结构化标题）
• 未征得用户决定就超过最大重试次数后继续

务必：

• 使用 Task 工具派遣子 Agent 处理所有实现工作
• 并行派遣元评审和实现 Agent（派遣顺序：元评审优先）
• 等待元评审和实现都完成后，再派遣评审者
• 将元评审评估规范传递给评审 Agent
• 在发给元评审和评审 Agent 的提示中包含 CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}``
• 仅解析评审输出中的 VERDICT/SCORE/ISSUES
• 验证未通过时，根据反馈进行迭代

模型选择策略

选择模型是你做出的杠杆效应最高的单一决策——它比任何提示词措辞都更重要，决定任务能否正确完成，以及需要多长时间。你绝不能把这当成走过场：在派发任务前，必须说出模型档位并给出一句话理由。因为不想动脑就直接选最强模型，这是失职，不是谨慎。

默认档位：sonnet 和 haiku 是默认选择。opus 仅作特殊用途，且需主动选择——必须符合下表中的触发条件，才有资格使用；绝不能因为拿不准就选它。

选择规则

任务类型	档位	示例
修正文档／文本中的单个文件——不涉及代码，也不需要跨文件推理	haiku	修正拼写错误、更新链接、修正 README 中过时的命令
小型、仅涉及少量代码行（约 10 行或更少）、局限于单个文件的机械式代码更改	haiku	更新常量、添加保护性条件、重命名局部变量、修改配置值
编写代码——新增函数、组件或测试；仅修改单个模块，且遵循既有模式	sonnet	添加端点、编写服务方法及其测试、重构单个模块
跨多文件重构（约 3 个或更多文件；或更改共享契约时，无论文件数量多少），或关键任务（身份验证、支付／计费、数据完整性、不可逆迁移、公共 API 破坏性更改），或复杂逻辑（并发、非平凡算法、架构决策）	opus	跨领域重构、身份验证或支付逻辑、架构迁移、新型算法设计

优先级（强制）：必须评估每一行规则，而不只是第一条匹配的规则。如果有多行匹配，则以最高档位为准——关键性和复杂性始终优先于规模。例如，安全关键的身份验证处理程序中的四行空值检查同时符合 haiku 和 opus 规则，因此应选 opus。关键任务列表是完整的，不是示例：部署到生产环境、触及真实用户或添加公共 API 都不是触发条件，因此，在单个服务文件中添加带验证的新端点仍应选 sonnet。**纯机械式扩展范围例外：**仅涉及范围广不代表复杂——纯机械式更改（例如跨多个文件重命名符号，且不更改逻辑或契约）的档位仍由更改内容决定，与涉及多少文件无关。因此，跨 40 个文件机械式重命名符号属于 haiku 或 sonnet 的工作，而非 opus；但此例外不适用于更改共享契约（这本身已是触发 opus 的条件），因此跨文件提取共享接口仍应选 opus。

平局时的选择：仅当没有规则能明确匹配、任务确实处于两个档位之间时，才选择成本较低的档位。绝不能为了保险而倾向选 opus；升级规则可让低成本的初次选择得到补救，而一次补救运行的成本远低于每次运行都过度配置。

角色配对

任何由模型分配的流水线最多有三个角色——执行者（完成工作）、标准制定者（定义什么是“正确”）、评估者（根据这些标准检查工作）；在此技能中，它们分别对应实现者 / 元评审者 / 评审者。默认情况下，所有角色使用同一层级——如果流水线没有单独的标准制定者（例如，计划步骤或阶段仅分配了一个模型），此默认规则就是全部规则。

仅对于不明显的任务，你可以只将标准制定者提升一个层级，使标准比被评估的工作更严格。不明显是可判定的：层级由平局裁决规则确定（没有任何一行选择规则明确匹配），或者任务没有说明可检查的验收条件。

模式	标准制定者（元评审者）	执行者 + 评估者（实现者 + 评审者）	适用场景
标准强化型 haiku	sonnet	haiku	工作很简单，但什么算“正确”并不明显
标准强化型 sonnet	opus	sonnet	验收标准含糊或影响重大，且工作本身未达到 opus 触发条件的代码任务

执行者和评估者可以使用不同层级。如果标准制定者制定的标准清单看起来过于复杂，你可以只提升评估者的层级，但不得将标准制定者设为低于执行者的层级。

升级规则

当以下任一触发条件出现时，在下一轮将执行者和评估者（实现者和评审者）都提升一个层级：

1. 首轮质量较低——得分较低，或问题表明模型误解了任务，而非仅仅遗漏细节。
2. 用户抱怨质量太差或结果错误——无论何时，包括报告 PASS 之后。

层级顺序：haiku → sonnet → opus。opus 是最高层级——没有更高层级。如果 opus 层级的工作仍然失败，应升级给用户，不得继续循环。

• **显式 --model 例外（此规则的唯一说明）：**显式指定的 --model 是用户的覆盖设置，因此触发条件（1）不得在不告知用户的情况下覆盖它——继续使用覆盖模型迭代，直到达到最大重试次数。如果最终仍未达标，应指出发现的问题并向用户建议升级。触发条件（2）即为用户批准，因此会立即升级。
• 升级只调整执行者和评估者。已生成评估规范的标准制定者不得重新运行或调整层级——在任务中途更改标准会使不同尝试之间的比较失效。
• 升级是对真正根因修复的补充，绝不能代替根因修复。你仍然必须在重试时传入评审者的具体反馈；禁止在更高层级重新派发相同提示词并寄希望于结果改善。
• 升级与分数阈值和迭代裁量规则互不影响——它改变的是由哪个模型运行下一轮，而不是是否有必要进行下一轮。

跨提供商等效模型

当此技能在 Anthropic 模型上下文之外运行时，将层级映射到同类别中最接近的模型：

层级	角色	其他提供商的可比模型
haiku	快速且便宜；机械性工作	gemini-flash-lite、gemma 类、gpt-oss 类、小型开放权重模型
sonnet	均衡的主力模型；负责大多数代码编写工作	gemini-pro 类和完整的 gemini-flash（不是 -lite 变体，后者属于 haiku 层级）、GPT-5-mini 类、大型 Qwen / DeepSeek 类
opus	前沿推理；关键或复杂工作	提供商当前推出的扩展 / 深度推理层级——目前包括 GPT-5.5、深度思考模式、Kimi K3 类，以及任何优势在于更长时间深思而非吞吐量的模型

映射依据是能力层级，而非名称——随着厂商发布新模型，具体名称会变化。以上每条规则都以层级表述，因此在其他提供商处：将层级映射到该类别的模型，然后照常应用选择、配对和升级规则。

流程

阶段 1：任务分析与模型选择

首先解析配置：STRICT_MODE = --strict present || false。从任务文本中剥离所有标志——绝不要将它们传入子 Agent 提示词。

除非用户传入了 --model，否则从三个维度评估任务，然后直接从选择规则表中确定层级：

• 范围——一个文件、一个模块，还是多个文件？
• 复杂度——机械性编辑、既定模式，还是新颖 / 复杂的逻辑？
• 风险——孤立且可逆、内部，还是选择规则 opus 行中详尽列出的关键风险？

在分派前，说明这三项评估结果、所选层级，以及一行理由。然后应用角色配对来决定元评审者层级——除非任务确实不易判断，否则与实现层级相同。**如果用户传入了 --model，则不执行这两个步骤：**该层级同时用于实现、元评审和评审，且角色配对不得将元评审者层级提高到该层级以上。

专用 Agent：sdd 插件中的常见 Agent 包括：sdd:developer、sdd:researcher、sdd:software-architect、sdd:tech-lead、sdd:business-analyst。如果没有合适的专用 Agent，则回退到通用 Agent，不指定专长。每当任务与专用 Agent 没有直接对应关系，或 Agent 不可用时，必须使用 general-purpose！

阶段 2：分派元评审者和实现 Agent（并行）

**关键：**在一条消息中通过两次 Task 工具调用启动两个 Agent。元评审者必须是该消息中的第一次工具调用，以便它能在实现 Agent 修改工件之前查看这些工件。

两个 Agent 都以前台模式运行。等待两者都完成后，再进入阶段 3。

2.1 元评审者提示词

元评审者将针对这项具体任务生成评估规范（评分标准、检查清单、评分准则）。它会返回评估规范 YAML。

## Task

Generate an evaluation specification yaml for the following task. You will produce rubrics, checklists, and scoring criteria that a judge agent will use to evaluate the implementation artifact.

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## User Prompt
{Original task description from user}

## Context
{Any relevant codebase context, file paths, constraints}

## Artifact Type
{code | documentation | configuration | etc.}

## Instructions
Return only the final evaluation specification YAML in your response.

Use Task tool:
  - description: "Meta-judge: {brief task summary}"
  - prompt: {meta-judge prompt}
  - model: {meta-judge model — the user's `--model` if one was passed; otherwise same as implementation, or one tier up per Role Pairing}
  - subagent_type: "sadd:meta-judge"

2.2 实现 Agent 提示词

构造实现提示词时，必须包含以下组件：

零样本思维链前缀（必需——必须置于最前）

## Reasoning Approach

Before taking any action, think through this task systematically.

Let's approach this step by step:

1. "Let me understand what this task requires..."
   - What is the specific objective?
   - What constraints exist?
   - What is the expected outcome?

2. "Let me explore the relevant code..."
   - What files are involved?
   - What patterns exist in the codebase?
   - What dependencies need consideration?

3. "Let me plan my approach..."
   - What specific modifications are needed?
   - What order should I make them?
   - What could go wrong?

4. "Let me verify my approach before implementing..."
   - Does my plan achieve the objective?
   - Am I following existing patterns?
   - Is there a simpler way?

Work through each step explicitly before implementing.

任务正文

## Task
{Task description from user}

## Constraints
- Follow existing code patterns and conventions
- Make minimal changes to achieve the objective
- Do not introduce new dependencies without justification
- Ensure changes are testable
- Critical: you not allowed to use any mutation git commands, including, but not limited: commit, stash, push, checkout, reset, revert, etc. Except cases when task EXPLICITLY allows or requires it. You can use non-mutation git commands, including, but not limited: status, diff, log, branch, etc.

## Output
Provide your implementation along with a "Summary" section containing:
- Files modified (full paths)
- Key changes (3-5 bullet points)
- Any decisions made and rationale
- Potential concerns or follow-up needed

自我批评后缀（必需——必须置于最后）

## Self-Critique Verification (MANDATORY)

Before completing, verify your work. Do not submit unverified changes.

### Verification Questions

| # | Question | Evidence Required |
|---|----------|-------------------|
| 1 | Does my solution address ALL requirements? | [Specific evidence] |
| 2 | Did I follow existing code patterns? | [Pattern examples] |
| 3 | Are there any edge cases I missed? | [Edge case analysis] |
| 4 | Is my solution the simplest approach? | [Alternatives considered] |
| 5 | Would this pass code review? | [Quality check] |

### Answer Each Question with Evidence

Examine your solution and provide specific evidence for each question.

### Revise If Needed

If ANY verification question reveals a gap:
1. **FIX** - Address the specific gap identified
2. **RE-VERIFY** - Confirm the fix resolves the issue
3. **UPDATE** - Update the Summary section

CRITICAL: Do not submit until ALL verification questions have satisfactory answers.

分派

根据任务和可用 Agent 确定最佳 Agent 类型，例如：代码实现 -> sdd:developer Agent。如果不确定，最好使用 general-purpose Agent，也不要分派错误的 Agent 类型。

Use Task tool:
  - description: "Implement: {brief task summary}"
  - prompt: {constructed prompt with CoT + task + self-critique}
  - model: {selected implementation model}
  - subagent_type: "{selected agent type}"

2.3 并行分派示例

在一条消息中发送两个 Task 工具调用。先发送元评审者，再发送实现 Agent：

Message with 2 tool calls:
  Tool call 1 (meta-judge):
    - description: "Meta-judge: {brief task summary}"
    - model: {meta-judge model — the user's `--model` if one was passed; otherwise same as implementation, or one tier up per Role Pairing}
    - subagent_type: "sadd:meta-judge"

  Tool call 2 (implementation):
    - description: "Implement: {brief task summary}"
    - model: {selected implementation model}
    - subagent_type: "{selected agent type}"

等待两者都返回后，再进入阶段 3。

第 3 阶段：派发评审 Agent

元评审和实现都完成后，派发评审 Agent。

**重要：**向评审 Agent 提供元评审的评估规范 YAML 原文，不得跳过或添加任何内容，也不得以任何方式修改或缩短、概括其中的任何文本！

从元评审输出中提取：

• 最终评估规范 YAML

从实现输出中提取：

• 摘要部分（已修改的文件、关键更改）
• 已修改文件的路径

3.1 分析“预先存在的更改”部分

派发评审 Agent 之前，评估代码库中是否存在评审 Agent 需要了解的预先存在的更改。“预先存在的更改”部分可避免评审 Agent 将先前的修改误认为是当前实现 Agent 的工作。

包含条件：

• 同一会话中此前已完成的 do-and-judge 任务运行
• 用户在调用此技能前手动进行的修改（可从对话上下文或 Git 中看到）
• 此任务之前运行的其他工具或 Agent 所做的更改

省略条件：

• 这是第一个任务，且没有已知的先前更改——完全省略此部分
• 在同一任务内重试时，不要将实现 Agent 之前的尝试列为“预先存在的更改”——它们属于当前任务的迭代周期

内容指南：

• 使用高层级摘要：任务描述、受影响文件/模块列表、更改的大致类型（创建、修改、删除）
• 不要包含代码块、差异或行级细节——保持简洁
• 清楚标注来源：“先前任务：{描述}”、“用户修改（当前任务之前）”等
• 如果存在多个来源的预先更改，请为每个来源使用单独的小节

**重要：**避免读取整个代码库或 Git 历史记录，只需使用高层级的 git diff/status 确定更改了哪些文件，或根据对话上下文判断是否存在预先更改。

3.2 使用提示词和规范 YAML 启动评审 Agent

评审 Agent 提示词模板：

You are evaluating an implementation artifact against an evaluation specification produced by the meta judge.

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## User Prompt
{Original task description from user}

{IF pre-existing changes are known, include the following section — otherwise omit entirely}

## Pre-existing Changes (Context Only)

The following changes were made BEFORE the current implementation agent started working. They are NOT part of the current task's output. Focus your evaluation on the current task's changes. Only verify pre-existing changed files/logic if they directly relate to the current task requirements.

### {Source of changes: e.g., "Previous Task: {task description}" or "User modifications (before current task)"}
{High-level summary: what was done, which files/modules were created or modified}

{END conditional section}

## Evaluation Specification

```yaml
{meta-judge's evaluation specification YAML}

实现输出

{实现 Agent 的摘要部分} {已修改文件的路径}

指令

按照 Agent 指令中定义的完整评审流程执行！

输出

**重要：**回复开头必须使用以下准确的结构化 YAML 评估报告格式！

CRITICAL: NEVER provide score threshold, in any format, including `threshold_pass` or anything different. Judge MUST not know what thershold for score is, in order to not be biased!!!

**Dispatch:**

使用 Task 工具：

• description: "评审：{简要任务摘要}"
• prompt: {包含准确的元评审规范 YAML，以及适用时的“预先存在的更改”部分的评审验证提示词}
• model: {评审模型——必须与当前实现模型一致，包括升级后}
• subagent_type: "sadd:judge"

### Phase 4: Parse Verdict and Iterate

Parse judge output (DO NOT read full report):

从评审回复中提取：

• VERDICT：PASS 或 FAIL
• SCORE：X.X/5.0
• ISSUES：问题列表（如有）
• IMPROVEMENTS：建议列表（如有）

**Decision logic:**

如果分数 ≥4： → VERDICT：PASS → 报告成功并附上摘要 → 将 IMPROVEMENTS 作为可选增强项列出

如果 3.0 ≤ 分数 <4 且未启用 STRICT_MODE： → 应用下方的迭代裁量规则 → 接受 → VERDICT：PASS（报告尚存问题） → 拒绝 → VERDICT：FAIL → 转至下方的“检查重试次数”

否则（分数 <3.0，或分数 <4 且启用了 STRICT_MODE）： → VERDICT：FAIL → 检查重试次数

如果重试次数 < 3： → 根据第 5 阶段“重试时的模型升级”确定重试等级（同时升级实现模型和评审模型，或保持不变） → 根据评审反馈派发重试实现 Agent → 返回第 3 阶段（使用相同的元评审规范进行评审验证）

如果重试次数 ≥ 3： → 升级处理并交由用户决定（参见错误处理） → 未经用户决定，不得继续

Note: `retries` counts attempts within the CURRENT cycle only. This budget **resets** on re-entry after a reported PASS (see [Phase 6 Re-entry](#phase-6-final-report)) — a later user quality complaint opens a fresh cycle of up to 3 retries even if a prior cycle already reached the limit above.

#### Iteration Discretion Rule

Your main task is to COMPLETE the task within target quality. Two failure modes are equally real:

- Burning retries and context on nitpicks so the task never completes on time → **the task is failed**; a developer is waiting on this result and may have dependent work blocked, so implementation effort MUST stay proportionate to the task's size.
- Reporting a result whose quality is genuinely too poor to be considered complete → **an even worse failure**.

Apply to every judge score:

- **`score < 3.0` → FAIL, unconditionally. No discretion.** Retry with judge feedback until it passes or max retries is reached.
- **`3.0 <= score < 4.0` → discretion band.** ONLY inside this band MAY you decide that a result below the `4.0` target is acceptable. The fixed `4.0` target puts the effective floor at `3.0`, so no separate bounded-drop guard is needed.
- Inside the band, when the outstanding issues are ONLY low/medium priority (any High or Critical finding removes discretion entirely) AND none of them breaks a target requirement of the task or causes a meaningful defect (i.e. they are nitpicks), you MUST reason FIRST — before dispatching a retry — about whether another attempt is worth the developer's time and your context.
- **At most ONE nitpick-driven retry**, and it counts against the retry budget. If it again surfaces only nitpicks, you MUST report PASS (☑️ ACCEPTED) with the outstanding issues listed in the final report. If it returns a score below `3.0`, the unconditional-FAIL rule applies instead.
- You MUST be critical, NOT lenient. Stopping short of target MUST be an intentional decision grounded in the absence of real, requirement-breaking issues. A genuine blocking issue that prevents completing the task within max retries MUST be escalated as a failure, never papered over.
- **If `STRICT_MODE` is true, this whole rule is DISABLED**: stop only when `score >= 4.0` or max retries is reached. `--strict` changes nothing else — the `4.0` target, the max-retry limit, the `< 3.0` unconditional FAIL and meta-judge/judge dispatch are unaffected.

### Phase 5: Retry with Feedback (If Needed)

#### Model Escalation on Retry

Before dispatching any retry you MUST decide the tier explicitly per the [Escalation Rule](#escalation-rule) — which governs in full — and state the decision in your output. Retry-specific anchors on top of it:

- **Trigger (1) is anchored at `score < 3.0`** here (or issues showing the model misunderstood the task rather than merely missing details).
- **Hold the tier** when the failure is a specific fixable defect rather than a capability gap — narrow, precisely specified issues are resolved faster by a same-tier retry with exact feedback.
- If `opus` still fails, escalate to the user per [Error Handling](#error-handling).

**Retry prompt template:**

```markdown
## Retry Required

Your previous implementation did not pass judge verification.

## Original Task
{Original task description}

## Judge Feedback
VERDICT: FAIL
SCORE: {score}/5.0
ISSUES:
{list of issues from judge}

## Your Previous Changes
{files modified in previous attempt}

## Instructions
Let's fix the identified issues step by step.

1. Review each issue the judge identified
2. For each issue, determine the root cause
3. Plan the fix for each issue
4. Implement ALL fixes
5. Verify your fixes address each issue
6. Provide updated Summary section

CRITICAL: Focus on fixing the specific issues identified. Do not rewrite everything.

第 6 阶段：最终报告

任务通过验证后：

## Execution Summary

**Task:** {original task description}
**Result:** ✅ PASS (or ☑️ ACCEPTED below target per the Iteration Discretion Rule)
**Strict Mode:** {STRICT_MODE}

### Verification
| Attempt | Score | Status |
|---------|-------|--------|
| 1 | {X.X}/5.0 | {PASS/ACCEPTED/FAIL} |
| {N} | {X.X}/5.0 | {PASS/ACCEPTED/FAIL} | (one row per retry that occurred, up to 3)

### Outstanding Issues (if accepted below target)
{Nitpicks left unresolved, with priority — omit this section when score >= 4.0}

### Files Modified
- {file1}: {what changed}
- {file2}: {what changed}

### Key Changes
- {change 1}
- {change 2}

### Suggested Improvements (Optional)
{IMPROVEMENTS from judge, if any}

报告后的重新进入：报告为 PASS 并不意味着任务结束。如果用户随后表示结果有误或质量过低，请将其意见作为反馈重新进入第 5 阶段——这会触发升级规则中的条件 (2)，因此将生产者和评估者都提升一个层级（除非已经是 opus），然后重试。重试预算会重置：即使上一轮已耗尽重试次数，这条意见也会开启一个最多可重试 3 次的新周期。

错误处理

超出最大重试次数时

任务在重试 3 次后仍未通过验证时：

1. 停止 - 不要继续
2. 报告 - 提供失败分析：
   • 原始任务要求
   • 所有评审结论和评分
   • 多次重试中持续存在的问题
3. 升级 - 向用户提供以下选项：
   • 提供额外背景或指导后重试
   • 使用高一个层级的模型重新运行（若运行时已使用 opus，则不可用）
   • 修改任务要求
   • 中止任务
4. 等待 - 未获得用户决定前，不要继续

升级报告格式：

## Task Failed Verification (Max Retries Exceeded)

### Task Requirements
{original task description}

### Verification History
| Attempt | Score | Key Issues |
|---------|-------|------------|
| 1 | {X.X}/5.0 | {issues} |
| 2 | {X.X}/5.0 | {issues} |
| 3 | {X.X}/5.0 | {issues} |

### Persistent Issues
{Issues that appeared in multiple attempts}

### Options
1. **Provide guidance** - Give additional context for another retry
2. **Escalate the tier** - Re-run implementation and judge one tier up (omit this option if already `opus`)
3. **Modify requirements** - Simplify or clarify task
4. **Abort** - Stop execution

Awaiting your decision...

示例

示例 1：更新文档（首次尝试即通过）

输入：

/do-and-judge Rewrite the API authentication section in docs/api-reference.md to cover the new OAuth2 flow

执行：

Phase 1: Task Analysis
  - Complexity: Medium (rewriting existing documentation with new technical flow)
  - Risk: Low (documentation only, no code changes)
  - Scope: Small (single file, focused section)
  → Model: haiku (implementation + judge), sonnet (meta-judge)
    Reasoning: Single documentation file, no code written — no opus
    trigger fires. It is more than a one-line correction, so it straddles
    haiku/sonnet; the tie-breaker sends it DOWN to haiku, and escalation
    covers a thin first pass. The task states no checkable acceptance
    condition — the second non-obvious disjunct — so the sharpened-haiku
    pairing raises the meta-judge one tier to sonnet.
  → Agent type: general-purpose
    Reasoning: This is a documentation task — writing and restructuring
    prose, not implementing code. The sdd:developer agent is optimized
    for code implementation patterns, not technical writing. A
    general-purpose agent handles documentation tasks more effectively
    because it applies broader writing and reasoning skills without
    code-centric constraints.

Phase 2: Parallel Dispatch (single message, 2 tool calls)
  Tool call 1 — Meta-judge (Sonnet)...
    Meta-judge prompt sent:
    ┌─────────────────────────────────────────────────────────
    │ ## Task
    │ Generate an evaluation specification yaml for the
    │ following task. You will produce rubrics, checklists,
    │ and scoring criteria that a judge agent will use to
    │ evaluate the implementation artifact.
    │
    │ CLAUDE_PLUGIN_ROOT=...
    │
    │ ## User Prompt
    │ Rewrite the API authentication section in
    │ docs/api-reference.md to cover the new OAuth2 flow
    │
    │ ## Context
    │ Existing docs/api-reference.md contains an outdated
    │ "Authentication" section describing API key auth.
    │ The codebase recently migrated to OAuth2 with PKCE.
    │ Related source: src/auth/oauth2.ts, src/auth/config.ts.
    │
    │ ## Artifact Type
    │ documentation
    │
    │ ## Instructions
    │ Return only the final evaluation specification YAML
    │ in your response.
    └─────────────────────────────────────────────────────────
    → Generated evaluation specification YAML
    → 3 rubric dimensions (accuracy, completeness, clarity)
    → 5 checklist items

  Tool call 2 — Implementation (general-purpose + Haiku)...
    Implementation prompt sent (abbreviated):
    ┌─────────────────────────────────────────────────────────
    │ ## Reasoning Approach
    │ Before taking any action, think through this task
    │ systematically.
    │ [... step-by-step reasoning template ...]
    │
    │ ## Task
    │ Rewrite the API authentication section in
    │ docs/api-reference.md to cover the new OAuth2 flow.
    │ Replace the outdated API key auth documentation with
    │ OAuth2 + PKCE flow documentation including token
    │ endpoints, scopes, refresh token handling, and
    │ example requests.
    │
    │ ## Constraints
    │ - Follow existing documentation patterns and conventions
    │ - Make minimal changes to achieve the objective
    │ - Do not introduce new dependencies without justification
    │ - Ensure changes are testable
    │
    │ ## Output
    │ Provide your implementation along with a "Summary"
    │ section containing:
    │ - Files modified (full paths)
    │ - Key changes (3-5 bullet points)
    │ - Any decisions made and rationale
    │ - Potential concerns or follow-up needed
    │
    │ ## Self-Critique Verification (MANDATORY)
    │ [... verification questions and revision process ...]
    └─────────────────────────────────────────────────────────
    → Rewrote Authentication section in docs/api-reference.md
    → Added OAuth2 flow diagram, token endpoints, scopes table
    → Added code examples for authorization and token refresh
    → Summary: 1 file modified, authentication section rewritten

Phase 3: Dispatch Judge (with meta-judge specification)
  NOTE: No pre-existing changes — first task on a clean codebase.
  The "Pre-existing Changes" section is OMITTED from the judge prompt.

  Judge prompt sent:
  ┌─────────────────────────────────────────────────────────
  │ You are evaluating an implementation artifact against
  │ an evaluation specification produced by the meta judge.
  │
  │ CLAUDE_PLUGIN_ROOT=...
  │
  │ ## User Prompt
  │ Rewrite the API authentication section in
  │ docs/api-reference.md to cover the new OAuth2 flow
  │
  │ ## Evaluation Specification
  │ ```yaml
  │ {meta-judge's evaluation specification YAML}
  │ ```
  │
  │ ## Implementation Output
  │ Files: docs/api-reference.md (modified)
  │ Key changes: Replaced API key auth section with OAuth2
  │ + PKCE flow, added token endpoints, scopes table,
  │ and code examples for authorization and refresh...
  │
  │ ## Instructions
  │ Follow your full judge process...
  └─────────────────────────────────────────────────────────

  Judge (sadd:judge + Haiku)...   ← same tier as implementation
    → VERDICT: PASS, SCORE: 4.2/5.0
    → ISSUES: None
    → IMPROVEMENTS: Add error response examples for expired tokens

Phase 4: Parse Verdict
  → Score 4.2 ≥ 4.0 threshold → PASS
  → No retry needed (Phase 5 skipped)

Phase 6: Final Report
  ✅ PASS on attempt 1
  Files: docs/api-reference.md (modified)

示例 2：升级模型后重试并通过

输入：

/do-and-judge Implement rate limiting middleware with configurable limits per endpoint

执行：

Phase 1: Task Analysis
  - Complexity: Medium (new middleware, established pattern)
  - Risk: Medium (middleware sits in front of all endpoints)
  - Scope: Small (single middleware + config schema)
  → Model: sonnet (implementation + meta-judge + judge)
    Reasoning: Code writing on an established pattern, confined to one
    module. No opus trigger fires — not multi-file, not complex logic,
    and rate limiting is on none of the critical list; breadth of reach
    is not itself a trigger. Same tier for all three roles.

Phase 2: Parallel Dispatch (Attempt 1)
  Tool call 1 — Meta-judge (Sonnet)...
    → Generated evaluation specification YAML
    → 4 rubric dimensions, 8 checklist items
  Tool call 2 — Implementation (sdd:developer + Sonnet)...
    → Created RateLimiter middleware
    → Added configuration schema

Phase 3: Dispatch Judge (with meta-judge specification)
  Judge (sadd:judge + Sonnet)...
    → VERDICT: FAIL, SCORE: 2.9/5.0
    → ISSUES:
      - Missing per-endpoint configuration (a stated requirement)
      - Limiter is not concurrency-safe under parallel requests
    → IMPROVEMENTS: Add monitoring hooks

Phase 5: Retry with Feedback
  Model Escalation on Retry:
    → Score 2.9 < 3.0 and the concurrency issue shows the task was
      misunderstood, not merely under-delivered → ESCALATE
    → Bump BOTH implementation and judge: sonnet → opus
    → Meta-judge NOT re-run, NOT re-tiered — same specification reused
  Implementation (sdd:developer + Opus)...
    → Added endpoint-specific limits
    → Replaced the counter with an atomic, concurrency-safe token bucket

Phase 3: Dispatch Judge (Attempt 2, same meta-judge specification)
  Judge (sadd:judge + Opus)...   ← escalated with the implementation
    → VERDICT: PASS, SCORE: 4.4/5.0
    → IMPROVEMENTS: Add metrics export

Phase 6: Final Report
  ✅ PASS on attempt 2
  Files: RateLimiter.ts, config/rateLimits.ts, adapters/RedisAdapter.ts

示例 3：需要升级的任务

输入：

/do-and-judge Migrate the database schema to support multi-tenancy

执行：

Phase 1: Task Analysis
  - Complexity: High (multi-tenancy affects every query path)
  - Risk: High (database schema change)
  - Scope: Large (schema, migrations, query layer)
  → Model: opus (implementation + meta-judge + judge)
    Reasoning: opus is EARNED here — two triggers fire: multi-file
    refactoring and critical (data integrity, irreversible migration).

Phase 2: Parallel Dispatch
  Meta-judge → evaluation specification YAML
  Implementation → initial migration scaffolding

Attempt 1: FAIL (2.8/5.0) - Missing tenant isolation in queries
Attempt 2: FAIL (3.2/5.0) - Incomplete migration script
Attempt 3: FAIL (3.3/5.0) - Edge cases in existing data migration

ESCALATION:
  Persistent issue: Existing data migration requires business decisions
  about how to handle orphaned records.

  Options presented to user (tier escalation omitted — already at the
  opus ceiling, no bump available):
  1. Provide guidance on orphan handling
  2. Simplify to new tenants only
  3. Abort

User chose: Option 1 - "Delete orphaned records older than 1 year"

Attempt 4 (with guidance): PASS (4.1/5.0)

示例 4：依次运行 do-and-judge（保留上一任务已有更改）

输入（首次运行）：

/do-and-judge add basic authentication module

执行（首次运行）：

Phase 1: Task Analysis
  - Complexity: High (new feature, security-sensitive)
  - Risk: High (authentication is critical)
  - Scope: Medium (new module, several files)
  → Model: opus (implementation + meta-judge + judge)
    Reasoning: opus is EARNED — the critical trigger fires on auth.
  - Pre-existing Changes: None

Phase 2: Parallel Dispatch (Attempt 1)
  Tool call 1 — Meta-judge (Opus)...
    Meta-judge prompt sent:
    ┌─────────────────────────────────────────────────────────
    │ ## Task
    │ Generate an evaluation specification yaml for the
    │ following task. You will produce rubrics, checklists,
    │ and scoring criteria that a judge agent will use to
    │ evaluate the implementation artifact.
    │
    │ CLAUDE_PLUGIN_ROOT=...
    │
    │ ## User Prompt
    │ Add basic authentication module
    │
    │ ## Context
    │ Express.js backend, src/auth/ directory does not exist
    │ yet. Existing middleware pattern in src/middleware/.
    │
    │ ## Artifact Type
    │ code
    │
    │ ## Instructions
    │ Return only the final evaluation specification YAML
    │ in your response.
    └─────────────────────────────────────────────────────────
    → Generated evaluation specification YAML
    → 4 rubric dimensions, 7 checklist items

  Tool call 2 — Implementation (sdd:developer + Opus)...
    Implementation prompt sent (abbreviated):
    ┌─────────────────────────────────────────────────────────
    │ ## Reasoning Approach
    │ Before taking any action, think through this task
    │ systematically.
    │ [... step-by-step reasoning template ...]
    │
    │ ## Task
    │ Add basic authentication module to the Express.js
    │ backend. Create login, logout, and register endpoints
    │ with proper middleware for route protection.
    │
    │ ## Constraints
    │ - Follow existing code patterns and conventions
    │ - Make minimal changes to achieve the objective
    │ - Do not introduce new dependencies without
    │   justification
    │ - Ensure changes are testable
    │
    │ ## Output
    │ Provide your implementation along with a "Summary"
    │ section containing:
    │ - Files modified (full paths)
    │ - Key changes (3-5 bullet points)
    │ - Any decisions made and rationale
    │ - Potential concerns or follow-up needed
    │
    │ ## Self-Critique Verification (MANDATORY)
    │ [... verification questions and revision process ...]
    └─────────────────────────────────────────────────────────
    → Created src/auth/AuthService.ts
    → Created src/auth/AuthMiddleware.ts
    → Created src/auth/auth.routes.ts
    → Modified src/app.ts
    → Summary: 4 files changed, auth module added

Phase 3: Dispatch Judge (with meta-judge specification)
  NOTE: No pre-existing changes — this is the first task on a clean codebase.
  The "Pre-existing Changes" section is OMITTED from the judge prompt.

  Judge prompt sent:
  ┌─────────────────────────────────────────────────────────
  │ You are evaluating an implementation artifact against
  │ an evaluation specification produced by the meta judge.
  │
  │ CLAUDE_PLUGIN_ROOT=...
  │
  │ ## User Prompt
  │ Add basic authentication module
  │
  │ ## Evaluation Specification
  │ ```yaml
  │ {meta-judge's evaluation specification YAML}
  │ ```
  │
  │ ## Implementation Output
  │ Files: src/auth/AuthService.ts (new), ...
  │ Key changes: Added login/logout/register endpoints...
  │
  │ ## Instructions
  │ Follow your full judge process...
  └─────────────────────────────────────────────────────────

  Judge (sadd:judge + Opus)...
    → VERDICT: FAIL, SCORE: 3.0/5.0
    → ISSUES:
      - Missing password hashing (plain-text storage)
      - No unit tests for AuthService
    → IMPROVEMENTS: Add rate limiting on login endpoint

Phase 5: Retry with Feedback (Attempt 2)
  Model Escalation on Retry:
    → Already at opus — the ceiling, no bump available. Retry at the
      same tier with the judge's specific feedback; if this fails
      repeatedly, escalate to the user rather than looping.
  Implementation (sdd:developer + Opus)...
    → Added bcrypt password hashing
    → Created tests/auth/AuthService.test.ts
    → Summary: 2 files modified, 1 file created

Phase 3: Dispatch Judge (Attempt 2, same meta-judge specification)
  NOTE: This is a retry within the SAME task — do NOT include the
  implementation agent's previous attempt as "pre-existing changes".
  The "Pre-existing Changes" section is still OMITTED.

  Judge (sadd:judge + Opus)...
    → VERDICT: PASS, SCORE: 4.3/5.0
    → IMPROVEMENTS: Add integration tests

Phase 6: Final Report
  ✅ PASS on attempt 2
  Files: AuthService.ts, AuthMiddleware.ts, auth.routes.ts,
         AuthService.test.ts, app.ts

输入（第二次运行，同一会话）：

/do-and-judge refactor auth module to use dependency injection

执行（第二次运行）：

Phase 1: Task Analysis
  - Complexity: Medium (refactoring existing code)
  - Risk: Medium (modifying working auth module)
  - Scope: Large (5 files across the module and its wiring)
  → Model: opus (implementation + meta-judge + judge)
    Reasoning: opus is EARNED — multi-file refactoring, and the module
    being rewired is the security-critical auth path.
  - Pre-existing Changes: Auth module created in previous task

Phase 2: Parallel Dispatch
  Tool call 1 — Meta-judge (Opus)...
    Meta-judge prompt sent:
    ┌─────────────────────────────────────────────────────────
    │ ## Task
    │ Generate an evaluation specification yaml for the
    │ following task. You will produce rubrics, checklists,
    │ and scoring criteria that a judge agent will use to
    │ evaluate the implementation artifact.
    │
    │ CLAUDE_PLUGIN_ROOT=...
    │
    │ ## User Prompt
    │ Refactor auth module to use dependency injection
    │
    │ ## Context
    │ Existing auth module at src/auth/ with AuthService,
    │ AuthMiddleware, auth.routes. Tests in tests/auth/.
    │
    │ ## Artifact Type
    │ code
    │
    │ ## Instructions
    │ Return only the final evaluation specification YAML
    │ in your response.
    └─────────────────────────────────────────────────────────
    → Generated evaluation specification YAML
    → 3 rubric dimensions, 5 checklist items

  Tool call 2 — Implementation (sdd:developer + Opus)...
    Implementation prompt sent (abbreviated):
    ┌─────────────────────────────────────────────────────────
    │ ## Reasoning Approach
    │ Before taking any action, think through this task
    │ systematically.
    │ [... step-by-step reasoning template ...]
    │
    │ ## Task
    │ Refactor the auth module to use dependency injection.
    │ AuthService should accept its dependencies via
    │ constructor instead of importing them directly.
    │
    │ ## Constraints
    │ - Follow existing code patterns and conventions
    │ - Make minimal changes to achieve the objective
    │ - Do not introduce new dependencies without
    │   justification
    │ - Ensure changes are testable
    │
    │ ## Output
    │ Provide your implementation along with a "Summary"
    │ section containing:
    │ - Files modified (full paths)
    │ - Key changes (3-5 bullet points)
    │ - Any decisions made and rationale
    │ - Potential concerns or follow-up needed
    │
    │ ## Self-Critique Verification (MANDATORY)
    │ [... verification questions and revision process ...]
    └─────────────────────────────────────────────────────────
    → Refactored AuthService to accept dependencies via constructor
    → Created src/auth/AuthServiceFactory.ts
    → Updated tests to use mocked dependencies
    → Summary: 4 files modified, 1 file created

Phase 3: Dispatch Judge (with meta-judge specification)
  NOTE: Pre-existing changes detected — the previous do-and-judge run
  created the auth module. Include "Pre-existing Changes" section so the
  judge does not confuse prior work with the current refactoring task.

  Judge prompt sent:
  ┌─────────────────────────────────────────────────────────
  │ You are evaluating an implementation artifact against
  │ an evaluation specification produced by the meta judge.
  │
  │ CLAUDE_PLUGIN_ROOT=...
  │
  │ ## User Prompt
  │ Refactor auth module to use dependency injection
  │
  │ ## Pre-existing Changes (Context Only)
  │
  │ The following changes were made BEFORE the current
  │ implementation agent started working. They are NOT part
  │ of the current task's output. Focus your evaluation on
  │ the current task's changes. Only verify pre-existing
  │ changed files/logic if they directly relate to the
  │ current task requirements.
  │
  │ ### Previous Task: "Add basic authentication module"
  │ The following files were created/modified as part of a
  │ previous task:
  │ - src/auth/AuthService.ts (new) - Authentication service
  │   with login/logout/register
  │ - src/auth/AuthMiddleware.ts (new) - Express middleware
  │   for route protection
  │ - src/auth/auth.routes.ts (new) - Auth API routes
  │ - tests/auth/AuthService.test.ts (new) - Unit tests for
  │   auth service
  │ - src/app.ts (modified) - Integrated auth routes and
  │   middleware
  │
  │ These files exist in the codebase and may be modified by
  │ the current task, but you should evaluate only the
  │ changes made by the current implementation agent for the
  │ current task (refactoring to dependency injection).
  │
  │ ## Evaluation Specification
  │ ```yaml
  │ {meta-judge's evaluation specification YAML}
  │ ```
  │
  │ ## Implementation Output
  │ Files: src/auth/AuthService.ts (modified), ...
  │ Key changes: Refactored to constructor injection...
  │
  │ ## Instructions
  │ Follow your full judge process...
  └─────────────────────────────────────────────────────────

  Judge (sadd:judge + Opus)...
    → VERDICT: PASS, SCORE: 4.5/5.0
    → ISSUES: None
    → IMPROVEMENTS: Add interface documentation

Phase 6: Final Report
  ✅ PASS on attempt 1
  Files: AuthService.ts (modified), AuthServiceFactory.ts (new),
         AuthMiddleware.ts (modified), AuthService.test.ts (modified),
         app.ts (modified)

示例 5：运行 do-and-judge 前用户已修改代码库

场景：

用户在对话过程中一直在处理一个电商代码库。在调用 do-and-judge 前，用户修改了购物车、商品目录和结账流程。

输入：

/do-and-judge fix shopping cart module bug when it adds duplicated items

执行：

Phase 1: Task Analysis
  - Complexity: Medium (bug fix in existing module)
  - Risk: Medium (cart logic affects checkout)
  - Scope: Small (focused bug fix)
  → Model: sonnet (implementation + meta-judge + judge)
    Reasoning: Code writing on a contained bug plus a regression test.
    No opus trigger — not a multi-file refactor, nothing on the critical
    list (in-memory cart state, not billing), no intricate logic. Too
    much reasoning is needed for haiku, so sonnet for all three roles.
  - Pre-existing Changes: User modified several files before this task

Phase 2: Parallel Dispatch
  Tool call 1 — Meta-judge (Sonnet)...
    → Generated evaluation specification YAML
    → 3 rubric dimensions, 5 checklist items
  Tool call 2 — Implementation (sdd:developer + Sonnet)...
    → Fixed duplicate detection in CartService.addItem()
    → Added deduplication guard in cart.routes.ts
    → Added regression test for duplicate item scenario
    → Summary: 3 files modified

Phase 3: Dispatch Judge (with meta-judge specification)
  NOTE: The orchestrator is aware from git diff/status that the user
  modified several files before this task. Include "Pre-existing Changes"
  section so the judge focuses only on the bug fix.

  Judge prompt sent:
  ┌─────────────────────────────────────────────────────────
  │ You are evaluating an implementation artifact against
  │ an evaluation specification produced by the meta judge.
  │
  │ CLAUDE_PLUGIN_ROOT=...
  │
  │ ## User Prompt
  │ Fix shopping cart module bug when it adds duplicated items
  │
  │ ## Pre-existing Changes (Context Only)
  │
  │ The following changes were made BEFORE the current
  │ implementation agent started working. They are NOT part
  │ of the current task's output. Focus your evaluation on
  │ the current task's changes. Only verify pre-existing
  │ changed files/logic if they directly relate to the
  │ current task requirements.
  │
  │ ### User modifications (before current task)
  │ The user made changes to the following files/modules
  │ before this task was started:
  │ - src/cart/CartService.ts (modified) - Shopping cart
  │   business logic updates
  │ - src/cart/cart.routes.ts (modified) - Updated cart API
  │   endpoints
  │ - src/products/ProductCatalog.ts (modified) - Product
  │   listing changes
  │ - src/checkout/CheckoutFlow.ts (modified) - Checkout
  │   process updates
  │ - tests/cart/CartService.test.ts (modified) - Updated
  │   cart tests
  │
  │ The current task focuses specifically on fixing the
  │ duplicate items bug in the shopping cart module.
  │ Pre-existing changes to cart files may overlap with the
  │ current task scope — evaluate whether the implementation
  │ agent's changes correctly address the bug without
  │ breaking the pre-existing modifications.
  │
  │ ## Evaluation Specification
  │ ```yaml
  │ {meta-judge's evaluation specification YAML}
  │ ```
  │
  │ ## Implementation Output
  │ Files: src/cart/CartService.ts (modified), ...
  │ Key changes: Added duplicate item detection...
  │
  │ ## Instructions
  │ Follow your full judge process...
  └─────────────────────────────────────────────────────────

  Judge (sadd:judge + Sonnet)...   ← same tier as implementation
    → VERDICT: PASS, SCORE: 4.1/5.0
    → ISSUES: None
    → IMPROVEMENTS: Consider extracting deduplication logic
      into a shared utility

Phase 6: Final Report
  ✅ PASS on attempt 1
  Files: CartService.ts (modified), cart.routes.ts (modified),
         CartService.test.ts (modified)

最佳实践

模型选择

相关规则参见模型选择政策；以下习惯有助于贯彻执行：

• 明确说明理由 - 派发任务前，说明范围、复杂度和风险，以及由此确定的层级；这是运行中影响最大的决策
• opus 必须凭实力获得，绝不能用来兜底 - 遇到规则重叠或平局时，始终按照选择规则的优先级和决胜规则处理，切勿凭直觉决定
• 所有角色使用同一层级 - 仅提升标准制定者（元评审者），且仅适用于不明显的任务（角色配对）
• 依据证据升级 - 迭代明显不够，或用户投诉质量问题时（升级规则）

元评审者 + 评审者验证

• 绝不跳过元评审者 - 定制的评估标准比通用标准能做出更好的评判
• 重试时沿用元评审者规范 - 在各次重试中保持评估规范不变；只更改实现
• 评审者结果仅解析标题 - 不要阅读完整报告，以免污染上下文
• 遵循阈值 - 4/5.0 是质量门槛；低于该分数时，由迭代酌情规则决定（除非使用 --strict）
• 包含 CLAUDE_PLUGIN_ROOT - 元评审者和评审者都需要解析后的插件根路径

迭代

• 集中修复 - 不要全部重写，只修复具体问题
• 原样传递反馈 - 让实现 Agent 看到准确的问题
• 使用相同的元评审者规范 - 重试时不要重新运行元评审者；评估标准不会改变
• 适时升级 - 遇到根本性问题时，不要无限循环
• 保持适度 - 按照迭代酌情规则，让迭代投入与任务规模相称；由细枝末节引发的重试最多一次

上下文管理

• 保持简洁——由你负责协调，子 Agent 负责实现
• 总结，不要复制——传递摘要，而不是完整的文件内容
• 信任子 Agent——它们可以自行读取文件
• Meta-judge YAML——只将 meta-judge YAML 传递给 judge，不要添加任何额外文本或注释！
• 跟踪已有更改——向 judge 提供先前修改的上下文，避免混淆已有更改和当前更改的归属