do-in-steps

Name: do-in-steps
Author: neolabhq

github.com/neolabhqAgent 工作流1.8k1.2k 次安装9 周前更新

代码仓库

关于 do-in-steps

用于将复杂任务拆分为有序子任务并协调子 Agent 执行的技能，面向需要逐步交付和独立验证的工作。它为每个步骤并行安排实现与评审，并依据评审反馈重试。

主要功能

01拆分任务并传递步骤上下文
02按子任务选择模型等级
03并行执行实现与评审标准制定
04使用独立评审验证每一步
05依据反馈重试失败步骤

适用场景

01按步骤完成复杂重构
02协调依赖前序结果的多阶段工作
03对每项阶段成果进行独立检查

安装

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

$npx skills add https://github.com/neolabhq/context-engineering-kit --skill do-in-steps

安装后在 Claude Code 中输入/do-in-steps确认已加载。

详细介绍

do-in-steps

通过将复杂任务拆解为按顺序执行的子任务，并协调子 Agent 依次完成每个步骤，来执行该任务。自动分析任务以识别依赖关系，为每个子任务选择合适规模的模型，将已完成步骤中的相关上下文传递给后续步骤，并使用元评审评估规范，通过独立评审者验证每个步骤后再继续。此命令实现了用于按顺序执行任务、传递上下文的 **Supervisor/Orchestrator 模式**，并结合 **元评审 → LLM 作为评审者验证**。你（编排器）负责分析复杂任务并将其拆解为有序的子任务，然后对每个步骤并行派发一个元评审 Agent 和一个实现 Agent。元评审会生成针对当前步骤的评估标准，同时实现工作也会并行进行。每个子 Agent 都会获得： - **隔离的上下文** - 为其特定子任务提供干净的上下文窗口 - **合适规模的模型** - 根据[模型选择策略](#model-selection-policy)为每个步骤选择：默认使用 `sonnet`/`haiku`，只有达到条件时才使用 `opus` - **前序步骤上下文** - 来自前序步骤的相关输出摘要 - **结构化推理** - 用于系统化思考的零样本 CoT 前缀 - **自我评估** - 提交前进行内部验证 - **结构化评估** - 元评审会在评审开始前，为每个步骤生成量身定制的评分细则和检查清单 - **外部评审** - 使用元评审规范进行 LLM 作为评审者验证，并包含迭代循环 - **并行提速** - 每个步骤中的元评审和实现 Agent 并行运行；同一步骤中的重试会复用元评审规范

参数

参数	格式	默认值	描述
`task`	自由格式文本	必填	要拆解并执行的任务描述
`--strict`	`--strict`	`false`	禁用迭代裁量规则——只有当 `score >= 4.0` 时步骤才算通过，否则重试，直至达到最大重试次数。
`--model`	`haiku\|sonnet\|opus`	按步骤自动选择	用户明确指定的选项，适用于每个步骤中的所有子 Agent：实现 Agent、元评审 Agent 和评审 Agent。若未提供，必须根据模型选择策略为每个步骤选择模型等级——没有固定的默认等级。若用户提供了选项，则每个子 Agent 都优先使用用户的选择，而非策略规定的选择——有关显式指定模型与升级规则之间的关系，请参阅升级规则。

示例：/do-in-steps Refactor UserService class and update all consumers --strict

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

分析并拆解任务
根据模型选择策略为每个子任务选择模型等级和 Agent——默认使用 sonnet/haiku，只有达到条件时才使用 opus
对每个步骤：并行派发元评审 Agent 和实现 Agent（派发顺序为元评审优先）
等待两者都完成，然后将元评审的规范传递给评审 Agent
若评审未通过，则迭代该步骤（最多重试 3 次），并复用相同的元评审规范
汇总输出并向后续步骤传递上下文
报告最终结果

危险信号——绝对不要做这些

绝对不要：

阅读实现文件来了解代码细节（交给子 Agent 处理）
编写代码或直接修改源文件
跳过分解步骤，直接开始实现
为了“节省时间”而亲自执行多个步骤
详细阅读步骤输出，导致上下文溢出
完整阅读评审报告（只解析结构化标题）
跳过评审验证，直接进入下一步
以任何形式向评审 Agent 提供分数阈值

务必：

使用 Task 工具分派子 Agent 完成所有实现工作
每个步骤都要并行分派元评审 Agent 和实现 Agent（分派顺序中元评审 Agent 必须优先）
等待元评审 Agent 和实现 Agent 都完成后，再分派评审 Agent
将该步骤的元评审评估规范传递给评审 Agent
在发给元评审 Agent 和评审 Agent 的提示词中包含 CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}
在同一步骤的重试期间重复使用相同的元评审规范（重试时绝不要重新运行元评审）
每个新步骤都要分派一个新的元评审 Agent（每个步骤都要使用针对该步骤定制的规范）
使用 Task 工具分派独立的评审 Agent来验证步骤
只传递必要的上下文摘要，不要传递完整文件内容
通过评审验证后再进入下一步
如果验证失败，根据评审反馈迭代（最多重试 3 次）
将迭代裁量规则应用于每个步骤的判定，除非提供了 --strict

任何偏离编排流程的行为（试图亲自实现子任务、阅读实现文件、阅读完整评审报告或直接修改内容）都会导致上下文污染并最终失败，结果就是你会被解雇！

模型选择策略

选择模型是影响最大的单一决策——它的影响超过任何提示词措辞，决定了步骤能否正确完成以及整个流程需要多久。绝不能把它当成走过场：分派每个步骤之前，都必须指出模型层级并给出一句话的理由。因为不愿思考而直接选最强模型，不是谨慎，而是失败。

默认层级：sonnet 和 haiku 为默认选项。opus 仅保留供特殊情况使用，且必须由下表中的触发条件证明其必要性，绝不能因为拿不准就选择它。

**逐步骤选择，而非每次运行统一选择：**必须根据每个步骤自身的范围、复杂度和风险，独立选择该步骤的层级。一次分解中可以合理地混用层级——例如，契约变更使用 opus，机械性的后续工作使用 haiku。某一步骤使用的层级（包括通过升级采用的层级）不得沿用到下一步。

选择规则

任务类型	层级	示例
修正文档／文本中的单个文件——不涉及代码或跨文件推理	`haiku`	修正拼写错误、更新链接、纠正 README 中过时的命令
范围局限于单个文件、行数较少（约 10 行或更少）的机械式代码修改	`haiku`	更新常量、添加保护子句、重命名局部变量、修改配置值
编写代码——新增函数、组件或测试，单模块修改，沿用既有模式	`sonnet`	添加端点、编写服务方法及测试、重构一个模块
多文件重构（约 3 个或更多文件，或任何文件数量下的共享契约变更），或关键操作（身份验证、支付／账单、数据完整性、不可逆迁移、公共 API 破坏），或复杂逻辑（并发、非平凡算法、架构决策）	`opus`	跨模块重构、身份验证或支付逻辑、架构迁移、新算法设计

优先级（必须遵守）：评估每一行规则，而非只看第一个匹配项。如果匹配多行，采用最高的匹配层级——关键性和复杂度始终优先于规模。安全关键的身份验证处理程序中，即使只有四行空值检查，也同时匹配 haiku 和 opus 的规则，因此应归为 opus。关键操作列表是穷尽性的，而非示例：发布到生产环境、涉及真实用户或添加公共 API 都不是触发条件，因此，在单个服务文件中添加带验证的新端点仍归为 sonnet。机械式多文件修改例外：仅涉及多个文件并不代表复杂。对于纯机械式修改——依据规则在多个文件中重复相同的编辑，不涉及逻辑，也不改变契约——仅多文件触发条件不适用；关键操作和复杂逻辑触发条件仍然适用。你必须根据单次修改的内容进行分级，将其视作只修改一个文件；因此，在 40 个文件中机械式重命名符号属于 haiku，但如果将相同的重命名限制在 src/auth/ 中，则属于 opus——无论修改范围多广，单次修改都会触发关键操作条件。这一例外不适用于共享契约变更（上述规则已将其列为 opus 的触发条件），因此，跨文件提取共享接口仍属于 opus。

平局时的选择：只有在没有任何规则能明确匹配——任务确实介于两个层级之间时，才选择成本较低的层级。你不得为了稳妥而倾向选择 opus；升级规则允许以较低成本恢复错误的初始判断，而一次纠正所需的成本远低于每次任务都配置过高。

角色配对

任何由模型分配的流水线最多有三个角色——执行者（负责完成工作）、标准制定者（定义什么才算“正确”）、评估者（根据这些标准检查工作）；在此技能中，它们会在每个步骤中分别对应实现、元评审者和评审者。默认：该步骤的三个角色都使用相同层级。

仅对于不明显的步骤，你可以单独将标准制定者提高一个层级，使其制定的标准比接受评估的工作更严格。不明显是可验证的：层级由平局处理规则决定（没有任何一行选择规则能明确匹配），或者该步骤没有说明任何可检查的验收条件。

模式	标准制定者（元评审者）	执行者 + 评估者（实现 + 评审者）	适用情况
强化俳句	`sonnet`	`haiku`	工作很简单，但正确标准并不明确
强化 Sonnet	`opus`	`sonnet`	验收标准含糊或后果重大，且代码工作本身并未触发 `opus` 条件

执行者和评估者可以使用不同层级。如果标准制定者给出的标准列表看起来过于复杂，你可以单独提高评估者的层级，但不得将标准制定者设为低于执行者的层级。**明确指定的 --model 覆盖会取代本节的全部规则：**用户传入 --model 时，每个步骤中的所有角色都使用该层级，角色配对不得将元评审者的层级提高到该层级之上。

升级规则

当以下任一触发条件成立时，在下一次尝试时将生成方和评估方都提升一个档位（即失败步骤的实现模型和评判模型）：

首次尝试质量较低——得分较低，或问题表明模型误解了该步骤，而不只是遗漏了细节。
用户抱怨质量太差或结果有误——无论何时，包括报告 PASS 之后。

档位顺序：haiku → sonnet → opus。opus 是上限，没有更高档位。如果 opus 档的工作仍然失败，就升级给用户处理，绝不要循环重试。

唯一例外——保持档位（对此规则唯一的说明，仅适用于触发条件 (1)）：当触发条件 (1) 成立，但评判方指出的问题是具体、可修复的缺陷，而非能力差距（问题范围窄、描述精准，且模型显然已经理解），你可以保持档位，并在相同档位下根据评判方的确切反馈重试，而不是提升档位。这是触发条件 (1) 下唯一可以不强制提升档位的情况；其他所有情况下，触发条件 (1) 都必须提升档位。触发条件 (2)（用户抱怨）没有此类例外——按照下方的例外条款，必须立即提升档位。
**显式 --model 例外条款（对此规则唯一的说明）：**显式指定 --model 是用户覆盖设置，因此触发条件 (1) 绝不能悄然覆盖此设置——继续使用覆盖指定的模型迭代，直到达到最大重试次数。如果最终仍未达到目标，应指出发现的问题，并建议用户批准提升档位。触发条件 (2) 即代表该批准，因此必须立即提升档位。
**仅适用于失败步骤。**升级只会调整该步骤的重试档位，不会调整整个链中的档位：每个后续步骤都必须根据选择规则独立评估，并重新从 sonnet/haiku 默认档位开始。
升级只调整实现模型和评判模型。该步骤的元评判模型不会重新运行，也不会调整档位——其规范会在该步骤的重试中继续使用；在步骤中途更改标准会使各次尝试之间的比较失效。
升级是对真正根因修复的补充，绝不能取而代之。你仍然必须将评判方的具体反馈传递给重试；禁止在更高档位上重新分派相同提示词并寄希望于结果改善。
升级与得分阈值、迭代裁量规则及每个步骤最多重试 3 次的预算互不影响——它只改变下一次尝试由哪个模型运行，绝不改变是否有必要进行尝试。
报告 PASS 后重新进入（对此规则唯一的说明）：报告 PASS 不代表工作已结束。如果用户之后表示某个步骤的结果有误或质量太差，则根据触发条件 (2) 重新进入该步骤的重试流程，且该步骤的重试预算重置——即使先前的重试周期已耗尽，这次抱怨也会开启一个最多包含 3 次重试的新周期。

跨提供商等效关系

当此技能运行于 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` 类，以及任何优势在于更长时间推理而非吞吐量的模型

映射依据是能力档位，而非名称——随着供应商发布新模型，确切名称会变化。以上所有规则都以档位表述，因此在其他提供商处，应先将档位映射到同类模型，再原样应用选择、配对和升级规则。

流程

设置：创建报告目录

开始前，请确保报告目录已存在：

mkdir -p .specs/reports

报告命名约定： .specs/reports/{task-name}-step-{N}-{YYYY-MM-DD}.md

其中：

{task-name} - 根据任务描述得出（例如，user-dto-refactor）
{N} - 步骤编号
{YYYY-MM-DD} - 当前日期

注意： 实现输出应放在指定位置；只有评审验证报告放在 .specs/reports/

阶段 1：任务分析与分解

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

使用零样本思维链推理系统地分析任务：

Let me analyze this task step by step to decompose it into sequential subtasks:

1. **Task Understanding**
   "What is the overall objective?"
   - What is being asked?
   - What is the expected final outcome?
   - What constraints exist?

2. **Identify Natural Boundaries**
   "Where does the work naturally divide?"
   - Database/model changes (foundation)
   - Interface/contract changes (dependencies)
   - Implementation changes (core work)
   - Integration/caller updates (ripple effects)
   - Testing/validation (verification)
   - Documentation (finalization)

3. **Dependency Identification**
   "What must happen before what?"
   - "If I do B before A, will B break or use stale information?"
   - "Does B need any output from A as input?"
   - "Would doing B first require redoing work after A?"
   - What is the minimal viable ordering?

4. **Define Clear Boundaries**
   "What exactly does each subtask encompass?"
   - Input: What does this step receive?
   - Action: What transformation/change does it make?
   - Output: What does this step produce?
   - Verification: How do we know it succeeded?

分解指南：

模式	分解策略	示例
接口变更	1. 更新接口，2. 更新实现，3. 更新调用方	“更改 getUser 的返回类型”
功能新增	1. 添加核心逻辑，2. 添加集成点，3. 添加 API 层	“为 UserService 添加缓存”
重构	1. 提取/修改核心，2. 更新内部引用，3. 更新外部引用	“从 Service 中提取辅助类”
产生影响的 Bug 修复	1. 修复根本原因，2. 修复相关问题，3. 更新测试	“修复影响报告的计算错误”
多层变更	1. 数据层，2. 业务层，3. API 层，4. 客户端层	“为 User 实体添加新字段”

分解输出格式：

## Task Decomposition

### Original Task
{task_description}

### Subtasks (Sequential Order)

| Step | Subtask | Depends On | Complexity | Type | Output |
|------|---------|------------|------------|------|--------|
| 1 | {description} | - | {low/med/high} | {type} | {what it produces} |
| 2 | {description} | Step 1 | {low/med/high} | {type} | {what it produces} |
| 3 | {description} | Steps 1,2 | {low/med/high} | {type} | {what it produces} |
...

### Dependency Graph
Step 1 ─→ Step 2 ─→ Step 3 ─→ ...

阶段 2：为每个子任务选择模型

根据以下三个维度评估每个子任务，然后直接从选择规则表中确定其层级——层级按步骤选择，绝不是为整个执行过程统一选择。

范围 — 一个文件、一个组件，还是多个文件？
复杂度 — 机械式编辑、成熟模式，还是新颖/复杂的逻辑？
风险 — 隔离且可逆、内部，还是选择规则中 opus 行所列的关键风险？

对于每个步骤，在分派前说明这三个维度的评估结果、所选层级，以及一句话的理由。然后应用角色配对——包括其 --model 覆盖规则——以确定该步骤的元评审层级。

领域专业知识检查：“此子任务是否适合某个专业 Agent 配置？”

开发：实现、重构、Bug 修复
架构：系统设计、模式选择
文档：API 文档、注释、README 更新
测试：测试生成、测试更新

专业 Agent： 专业 Agent 列表取决于项目和已加载的插件。sdd 插件中的常见 Agent 包括：sdd:developer、sdd:researcher、sdd:software-architect、sdd:tech-lead、sdd:business-analyst、sdd:code-explorer、sdd:code-reviewer、sdd:tech-writer。如果没有合适的专业 Agent，则使用不带专业化配置的通用 Agent。

决策： 当子任务明显受益于领域专业知识，且复杂度足以值得投入额外开销时，使用专业 Agent（haiku 层级的步骤除外）。

选择输出格式：

## Model/Agent Selection

| Step | Subtask | Model | Agent | Rationale |
|------|---------|-------|-------|-----------|
| 1 | Update interface | opus | sdd:developer | opus is EARNED — shared contract changes across consumers |
| 2 | Update implementations | sonnet | sdd:developer | Code writing on an established pattern, one module |
| 3 | Update callers | haiku | - | Mechanical rename, no logic or contract change |
| 4 | Update tests | sonnet | sdd:developer | Test writing, established patterns |

阶段 3：顺序执行，并行进行元评审与评审验证

逐个执行子任务。对于每个步骤，并行分派元评审和实现 Agent，然后使用元评审的规范，由独立评审 Agent 进行验证。如有需要则迭代，之后传递上下文。

每个步骤的执行流程：

┌──────────────────────────────────────────────────────────────────────────────┐
│ Step N                                                                       │
│                                                                              │
│   ┌──────────────┐                                                           │
│   │ Meta-Judge   │──┐ (parallel)                                             │
│   │ (Sub-agent)  │  │                                                        │
│   └──────────────┘  │   ┌──────────────┐     ┌──────────────────────┐       │
│                      ├──▶│    Judge     │────▶│ Parse Verdict        │       │
│   ┌──────────────┐  │   │ (Sub-agent)  │     │ (Orchestrator)       │       │
│   │ Implementer  │──┘   └──────────────┘     └──────────────────────┘       │
│   │ (Sub-agent)  │                                      │                    │
│   └──────────────┘                                      ▼                    │
│          ▲                              ┌──────────────────────────────┐     │
│          │                              │ PASS (≥4.0)?                 │     │
│          │                              │ ├─ YES → Next Step           │     │
│          │                              │ ├─ ≥3.0 → Rule 3.6           │     │
│          │                              │ └─ NO  → Retry?              │     │
│          │                              │     ├─ <3 retries → Retry    │     │
│          │                              │     └─ ≥3 retries → Escalate │     │
│          │                              └──────────────────────────────┘     │
│          │                                            │                      │
│          └────────────── feedback ────────────────────┘                      │
│          (retries reuse same meta-judge spec, no new meta-judge)             │
└──────────────────────────────────────────────────────────────────────────────┘

3.1 上下文传递协议

每个子任务完成后，提取与后续步骤相关的上下文：

需要传递的上下文：

已修改的文件（仅路径，不含内容）
所做的关键更改（摘要）
新增的接口/API
会影响后续步骤的决策
后续步骤需要注意的警告或事项

上下文筛选：

仅传递与剩余子任务相关的信息
不要传递不会影响后续步骤的实现细节
上下文摘要应保持简洁（每个步骤最多 200 个单词）

**上下文大小指南：**如果累计上下文超过约 500 个单词，应更积极地概述较早步骤的内容。子 Agent 需要详情时可直接读取文件。

上下文累积示例（具体示例）：

## Completed Steps Summary

### Step 1: Define UserRepository Interface
- **What was done:** Created `src/repositories/UserRepository.ts` with interface definition
- **Key outputs:**
  - Interface: `IUserRepository` with methods: `findById`, `findByEmail`, `create`, `update`, `delete`
  - Types: `UserCreateInput`, `UserUpdateInput` in `src/types/user.ts`
- **Relevant for next steps:**
  - Implementation must fulfill `IUserRepository` interface
  - Use the defined input types for method signatures

### Step 2: Implement UserRepository
- **What was done:** Created `src/repositories/UserRepositoryImpl.ts` implementing `IUserRepository`
- **Key outputs:**
  - Class: `UserRepositoryImpl` with all interface methods implemented
  - Uses existing database connection from `src/db/connection.ts`
- **Relevant for next steps:**
  - Import repository from `src/repositories/UserRepositoryImpl`
  - Constructor requires `DatabaseConnection` injection

3.2 子 Agent 提示词构建

对于每个子任务，构建的提示词必须包含以下部分：

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

## Reasoning Approach

Before taking any action, think through this subtask systematically.

Let's approach this step by step:

1. "Let me understand what was done in previous steps..."
   - What context am I building on?
   - What interfaces/patterns were established?
   - What constraints did previous steps introduce?

2. "Let me understand what this step requires..."
   - What is the specific objective?
   - What are the boundaries of this step?
   - What must I NOT change (preserve from previous steps)?

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 consistent with previous steps' changes?
   - Is there a simpler way?

Work through each step explicitly before implementing.

3.2.2 任务正文

<task>
{Subtask description}
</task>

<subtask_context>
Step {N} of {total_steps}: {subtask_name}
</subtask_context>

<previous_steps_context>
{Summary of relevant outputs from previous steps - ONLY if this is not the first step}
- Step 1: {what was done, key files modified, relevant decisions}
- Step 2: {what was done, key files modified, relevant decisions}
...
</previous_steps_context>

<constraints>
- Focus ONLY on this specific subtask
- Build upon (do not undo) changes from previous steps
- Follow existing code patterns and conventions
- Produce output that subsequent steps can build upon
- 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.

</constraints>

<input>
{What this subtask receives - files, context, dependencies}
</input>

<output>
{Expected deliverable - modified files, new files, summary of changes}

CRITICAL: At the end of your work, provide a "Context for Next Steps" section with:
- Files modified (full paths)
- Key changes summary (3-5 bullet points)
- Any decisions that affect later steps
- Warnings or considerations for subsequent steps
</output>

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

## Self-Critique Verification (MANDATORY)

Before completing, verify your work integrates properly with previous steps. Do not submit unverified changes.

### Verification Questions

Generate verification questions based on the subtask description and the previous steps context. Examples:

| # | Question | Evidence Required |
|---|----------|-------------------|
| 1 | Does my work build correctly on previous step outputs? | [Specific evidence] |
| 2 | Did I maintain consistency with established patterns/interfaces? | [Specific evidence] |
| 3 | Does my solution address ALL requirements for this step? | [Specific evidence] |
| 4 | Did I stay within my scope (not modifying unrelated code)? | [List any out-of-scope changes] |
| 5 | Is my output ready for the next step to build upon? | [Check against dependency graph] |

### Answer Each Question with Evidence

Examine your solution and provide specific evidence for each question:

[Q1] Previous Step Integration:
- Previous step output: [relevant context received]
- How I built upon it: [specific integration]
- Any conflicts: [resolved or flagged]

[Q2] Pattern Consistency:
- Patterns established: [list]
- How I followed them: [evidence]
- Any deviations: [justified or fixed]

[Q3] Requirement Completeness:
- Required: [what was asked]
- Delivered: [what you did]
- Gap analysis: [any gaps]

[Q4] Scope Adherence:
- In-scope changes: [list]
- Out-of-scope changes: [none, or justified]

[Q5] Output Readiness:
- What later steps need: [based on decomposition]
- What I provided: [specific outputs]
- Completeness: [HIGH/MEDIUM/LOW]

### 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 "Context for Next Steps" section

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

3.3 并行分发元评审者

**关键：**对于每个步骤，在同一条消息中通过两次 Task 工具调用，并行分发元评审者和实现 Agent。元评审者必须是消息中的第一次工具调用，以便在实现 Agent 修改产物之前检查它们。

两个 Agent 均作为前台 Agent 运行。等待两者都完成后，再继续进行评审者分发。

元评审者提示词（每个步骤）：

## Task

Generate an evaluation specification yaml for the following step. 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}

## Step Being Evaluated
Step {N}/{total}: {subtask_name}
{subtask_description}
- Input: {what this step receives}
- Expected output: {what this step should produce}

## Previous Steps Context
{Summary of what previous steps accomplished}

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

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

分发示例

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

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

  Tool call 2 (implementation):
    - description: "Step {N}/{total}: {subtask_name}"
    - model: {implementation model — the user's `--model` if one was passed; otherwise the model selected for this step}
    - subagent_type: "{selected agent type}"

等待两者都返回后，再继续进行评审者分发。

3.4 评审者验证协议

元评审者和实现 Agent 都完成后，分发一名独立评审者，使用元评审者评估规范来验证该步骤。

关键：向评审者提供元评审者的评估规范 YAML 原文，不得跳过、添加或以任何方式修改，也不得缩短或总结其中的任何文本！

3.4.1 分析预先存在的更改部分

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

何时包含：

同一次 SAME do-in-steps 运行中前面步骤的更改（评审步骤 N 时的步骤 1..N-1）——这是顺序执行中最常见的情况。运行步骤 N 时，评审器 MUST 将步骤 1..N-1 的更改视为预先存在的更改。每个已完成步骤的输出（创建/修改的文件、关键更改）都会成为后续步骤评审器的预先存在上下文。
同一会话中更早完成的 do-in-steps 或 do-and-judge 任务运行
调用此技能前用户手动进行的修改（可从对话上下文或 git 中查看）
此任务运行前其他工具或 Agent 进行的更改

何时省略：

这是步骤 1，且没有已知的先前更改（没有更早的会话任务，也没有用户修改）——完全省略此部分
在 SAME 步骤内重试时，DO NOT 将实现 Agent 自己之前的尝试列为“预先存在的更改”——这些属于当前步骤的迭代周期

内容指南：

使用高层次摘要：任务描述、受影响的文件/模块列表、更改的大致性质（创建、修改、删除）
DO NOT 包含代码块、差异或逐行细节——保持简洁
清楚标注每个来源：“步骤 1：{描述}”、“步骤 2：{描述}”、“用户修改（当前任务之前）”等
如果存在多个预先存在的更改来源，请为每个来源使用单独的小节（每个已完成步骤一个，外加任何外部来源）
利用上下文传递协议输出（第 3.1 节）——“已完成步骤摘要”已记录每个步骤产生的内容

关键：避免读取完整代码库或 git 历史，只需使用高层次的 git diff/status 来确定哪些文件发生了更改，或使用对话上下文和已完成步骤摘要来确定预先存在的更改。

步骤评审器提示词模板：

You are evaluating Step {N}/{total}: {subtask_name} against an evaluation specification produced by the meta judge.

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## Original Task
{overall_task_description}

## Step Requirements
{subtask_description}
- Input: {what this step receives}
- Expected output: {what this step should produce}

## Previous Steps Context
{Summary of what previous steps accomplished}

{IF pre-existing changes are known (previous steps, prior tasks, or user modifications), include the following section — otherwise omit entirely}

## Pre-existing Changes (Context Only)

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

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

### {Additional source if applicable}
{High-level summary}

{END conditional section}

## Evaluation Specification

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

实现输出

{实现 Agent 修改的文件路径} {实现 Agent 提供的“后续步骤上下文”部分}

说明

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

输出

重要：你必须在回复开头使用 YAML，严格按照以下结构化评估报告格式作答！


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

**Dispatch:**

使用 Task 工具：

description: "评审步骤 {N}/{total}：{subtask_name}"
prompt: {包含精确元评审规范 YAML 的评审验证提示词，以及适用时的“现有更改”部分}
model: {评审模型——如果用户传入了 --model，则使用该模型；否则必须与此步骤当前的实现模型一致，包括升级后}
subagent_type: "sadd:judge"


#### 3.5 Dispatch, Verify, and Iterate

For each subtask in sequence:

并行派发元评审器和实现 Agent（单条消息，2 次工具调用）：工具调用 1（元评审器——必须先调用）：使用 Task 工具： - description: "元评审步骤 {N}/{total}：{subtask_name}" - prompt: {包含步骤要求和上下文的元评审提示词} - model: {元评审模型——如果用户传入了 --model，则使用该模型；否则与此步骤的实现模型处于相同层级，或根据角色配对规则高出一个层级} - subagent_type: "sadd:meta-judge"

工具调用 2（实现）：使用 Task 工具： - description: "步骤 {N}/{total}：{subtask_name}" - prompt: {构造的提示词，包含思维链 + 任务 + 先前上下文 + 自我批判} - model: {实现模型——如果用户传入了 --model，则使用该模型；否则使用为此步骤选择的模型} - subagent_type: "{选定的 Agent 类型}"
等待两者完成。收集输出：
- 从元评审器输出中提取评估规范 YAML
- 从实现输出中解析“后续步骤的上下文”部分，并记录已修改的文件
派发评审子 Agent（使用此步骤的元评审规范）：使用 Task 工具：
- description: "评审步骤 {N}/{total}：{subtask_name}"
- prompt: {包含步骤要求、实现输出和元评审规范 YAML 的评审验证提示词}
- model: {评审模型——如果用户传入了 --model，则使用该模型；否则必须与此步骤当前的实现模型一致}
- subagent_type: "sadd:judge"
解析评审结果（不要阅读完整报告）：从评审回复中提取：
- VERDICT：PASS 或 FAIL
- SCORE：X.X/5.0
- ISSUES：问题列表（如有）
- IMPROVEMENTS：改进建议列表（如有）
根据评审结果作出决定：

如果分数 ≥4.0： → VERDICT：PASS → 进入下一步骤，并带上累积的上下文 → 将 IMPROVEMENTS 作为可选增强项纳入上下文

如果 3.0 ≤ 分数 <4.0，且不是 STRICT_MODE： → 应用迭代酌情处理规则（3.6） → 接受 → VERDICT：PASS（报告未解决的问题并继续） → 不接受 → VERDICT：FAIL → 转到下面的“检查重试次数”

其他情况（分数 <3.0，或 STRICT_MODE 下分数 <4.0）： → VERDICT：FAIL → 检查此步骤的重试次数

如果重试次数 <3： → 根据“3.5.1 重试时的模型升级”确定此步骤的重试层级（遵循升级规则——两者都升级，除非适用唯一的保留例外） → 在该层级派发重试实现 Agent，并提供： - 原始步骤要求 - 评审的 ISSUES 列表作为反馈 - 评审报告路径，以供查看详情 - 修复具体问题的指示 → 使用此步骤相同的元评审规范，返回评审验证环节；在重试层级派发评审器（评审器始终与实现层级一致） → 不要重新运行元评审器，也不要调整其层级

如果重试次数 ≥3： → 升级给用户处理（参见错误处理） → 不要进入下一步骤
进入下一个子任务，并带上累积的上下文 → 为下一步骤并行派发新的元评审器和实现 Agent


##### 3.5.1 Model Escalation on Retry

Before dispatching any retry you MUST decide this step's tier explicitly per the [Escalation Rule](#escalation-rule) — which governs in full, including its sole hold exception — and state the decision in your step report. Retry-specific anchors on top of it:

- **Trigger (1) is anchored at `score < 3.0`** here (or issues showing the model misunderstood the step rather than merely missing details).
- The retry's judge MUST be dispatched at the same tier as the retry implementation; the step's meta-judge is neither re-run nor re-tiered.
- The escalated tier applies to **this step's remaining attempts only** — the next step is re-assessed from scratch per [Phase 2](#phase-2-model-selection-for-each-subtask).
- If `opus` still fails, escalate to the user per [Error Handling](#if-step-fails-after-max-retries).

**Retry prompt template for implementation agent:**

```markdown
## Retry Required: Step {N}/{total}

Your previous implementation did not pass judge verification.

<original_requirements>
{subtask_description}
</original_requirements>

<judge_feedback>
VERDICT: FAIL
SCORE: {score}/5.0
ISSUES:
{list of issues from judge}

Full report available at: {path_to_judge_report}
</judge_feedback>

<your_previous_output>
{files modified in previous attempt}
</your_previous_output>

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

1. First, 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 "Context for Next Steps" section

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

3.6 迭代裁量规则

你的主要任务是在达到目标质量的同时完成任务，迭代投入 MUST 与每个步骤的规模相称。两种失败模式都确实存在：

在细枝末节上反复重试、耗费上下文，导致整体任务始终无法完成 → 任务失败。
接受质量确实差到无法视为完成的步骤 → 更严重的失败。

对每个评审分数应用以下规则：

score < 3.0 → 无条件 FAIL。不得酌情处理。 根据评审反馈重试，直到步骤通过或达到最大重试次数。
3.0 <= score < 4.0 → 裁量区间。 只有在此区间内，才 MAY 决定接受低于 4.0 目标的步骤。固定的 4.0 目标使实际下限为 3.0，因此无需单独设置有界降级检查。
在此区间内，如果遗留问题仅为低/中优先级（存在任何 High 或 Critical 发现时，裁量权将完全取消），且这些问题都没有违反步骤的目标要求或造成实质性缺陷（即只是吹毛求疵），那么在发起重试之前，MUST FIRST 评估再次尝试是否值得投入时间和上下文成本。
最多进行一次由细枝末节问题驱动的重试，且计入重试预算。如果重试后发现的仍只是细枝末节问题，MUST 将步骤标记为 PASS（ACCEPTED），将未解决的问题纳入累积上下文，在最终摘要中报告，并继续下一步骤。如果返回的分数低于 3.0，则适用无条件 FAIL 规则。
MUST 保持批判性，NOT 宽松处理。决定不达到目标就停止，必须是有意为之，并以不存在真正违反要求的问题为依据——后续步骤将以此步骤为基础。如果确实存在阻塞问题，导致步骤在最大重试次数内无法完成，则 MUST 将其升级为失败，绝不可粉饰太平。
如果 STRICT_MODE 为 true，则整条规则 DISABLED：只有在 score >= 4.0 或达到最大重试次数时才停止。--strict 不会改变其他任何事项——4.0 目标、最大重试次数限制、< 3.0 无条件 FAIL 规则以及元评审/评审调用均不受影响。

第 4 阶段：最终摘要和报告

所有子任务完成并通过验证后，请回复一份完整报告：

## Sequential Execution Summary

**Overall Task:** {original task description}
**Total Steps:** {count}
**Total Agents:** {meta_judges(one per step) + implementation_agents + judge_agents + retry_agents}
**Strict Mode:** {STRICT_MODE}

### Step-by-Step Results

| Step | Subtask | Model | Judge Score | Retries | Status |
|------|---------|-------|-------------|---------|--------|
| 1 | {name} | {model} | {X.X}/5.0 | {0-3} | PASS |
| 2 | {name} | {model} | {X.X}/5.0 | {0-3} | PASS |
| ... | ... | ... | ... | ... | ... |

Status is `PASS` (score >= 4.0), `ACCEPTED` (below target per the [Iteration Discretion Rule](#36-iteration-discretion-rule) — list the outstanding nitpicks under Follow-up Recommendations), or `FAILED`.

**Model** is the tier the step finished at; when [escalation](#351-model-escalation-on-retry) fired, record it as `{starting tier} → {final tier}`.

### Files Modified (All Steps)
- {file1}: {what changed, which step}
- {file2}: {what changed, which step}
...

### Key Decisions Made
- Step 1: {decision and rationale}
- Step 2: {decision and rationale}
...

### Integration Points
{How the steps connected and built upon each other}

### Judge Verification Summary
| Step | Initial Score | Final Score | Issues Fixed |
|------|---------------|-------------|--------------|
| 1 | {X.X} | {X.X} | {count or "None"} |
| 2 | {X.X} | {X.X} | {count or "None"} |

### Meta-Judge Specifications
One evaluation specification generated per step (in parallel with implementation), reused across retries within each step.


### Follow-up Recommendations
{Any improvements suggested by judges, tests to run, or manual verification needed}

错误处理

如果评审验证失败（分数 <4.0）

经过评审验证的迭代循环会自动处理大多数失败（只有在迭代裁量规则拒绝接受 3.0..4.0 的分数后，该分数才算 FAIL）：

Judge FAIL (Retry Available):
  1. Parse ISSUES from judge verdict
  2. Dispatch retry implementation agent with feedback
  3. Re-verify with judge (using same step's meta-judge specification — do NOT re-run meta-judge)
  4. Repeat until PASS or max retries (3)

如果步骤在达到最大重试次数后仍失败

如果某个步骤在三次评审验证中均未通过：

停止 - 不要继续基于有缺陷的基础推进
报告 - 提供失败分析：
- 原始步骤要求
- 所有评审结论和分数
- 多次重试中持续存在的问题
升级处理 - 向用户提供选项：
- 提供更多上下文/指导后重试
- 在下一个更高模型层级重新运行此步骤（如果该步骤已达到 opus，则省略此选项）
- 修改步骤要求
- 跳过此步骤（如果为可选项）
- 中止并报告部分进展
等待 - 未经用户决定，不得继续

升级报告格式：

## Step {N} Failed Verification (Max Retries Exceeded)

### Step Requirements
{subtask_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} |
| 4 | {X.X}/5.0 | {issues} |

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

### Judge Reports
- .specs/reports/{task-name}-step-{N}-attempt-1.md
- .specs/reports/{task-name}-step-{N}-attempt-2.md
- .specs/reports/{task-name}-step-{N}-attempt-3.md
- .specs/reports/{task-name}-step-{N}-attempt-4.md

### Options
1. **Provide guidance** - Give additional context for another retry
2. **Escalate the tier** - Re-run this step's implementation and judge one tier up (omit this option if the step already reached `opus`)
3. **Modify requirements** - Simplify or clarify step requirements
4. **Skip step** - Mark as skipped and continue (if non-critical)
5. **Abort** - Stop execution and preserve partial progress

Awaiting your decision...

绝不可：

在步骤达到最大重试次数后仍失败的情况下继续推进
为了“节省时间”而跳过评审验证
忽略多次重试中持续存在的问题
猜测哪些做法可能有效

如果缺少上下文

不要猜测之前步骤的产出
重新检查之前步骤的输出，查找缺失信息
检查评审报告——其中可能指出了缺失要素
如有需要，调用澄清子 Agent，以提取缺失的上下文
更新上下文传递方式，以用于今后类似任务

步骤冲突时

在冲突点停止执行
**分析：**分解是否有误？这些步骤是否确实存在依赖关系？
检查评审反馈——评审者可能已指出集成问题
可选方案：
- 如果遗漏了依赖关系，重新排列步骤
- 将冲突步骤合并为一个步骤
- 在冲突步骤之间添加协调步骤

示例

示例 1：相互依赖的顺序步骤（前序步骤产生的已有更改）

输入：

/do-in-steps implement user management feature

阶段 1 - 分解：

步骤	子任务	依赖项	复杂度	类型	输出
1	创建 User 模型和数据库架构	-	中	实现	User 模型、迁移文件
2	为用户添加 CRUD 端点	步骤 1	中	实现	REST API 路由、控制器
3	添加身份验证集成	步骤 1、2	高	实现	身份验证中间件、JWT 处理

阶段 2 - 模型选择：

步骤	子任务	模型	理由
1	创建 User 模型和架构	sonnet	遵循既定模式编写代码；全新创建的 `users` 表可逆，因此不会触发不可逆迁移条件
2	添加 CRUD 端点	sonnet	在单个模块中编写代码；“添加到公共 API”不在详尽的关键项列表中
3	添加身份验证集成	opus	opus 当之无愧——身份验证（JWT 签发和路由保护）触发了关键条件

阶段 3 - 累积已有更改并执行：

Step 1: Create User model and database schema
  Parallel dispatch: Meta-judge + Implementation
  Judge Verification (with step 1 meta-judge spec):
    NOTE: No pre-existing changes — this is step 1 with no prior session tasks.
    The "Pre-existing Changes" section is OMITTED from the judge prompt.

    Judge prompt sent:
    ┌─────────────────────────────────────────────────────────
    │ You are evaluating Step 1/3: Create User model and
    │ database schema against an evaluation specification
    │ produced by the meta judge.
    │
    │ CLAUDE_PLUGIN_ROOT=...
    │
    │ ## Original Task
    │ Implement user management feature
    │
    │ ## Step Requirements
    │ Create User model and database schema with proper
    │ fields and relationships.
    │
    │ ## Previous Steps Context
    │ None (first step)
    │
    │ ## Evaluation Specification
    │ ```yaml
    │ {meta-judge's evaluation specification YAML}
    │ ```
    │
    │ ## Implementation Output
    │ Files: src/models/User.ts (new), migrations/001_create_users.ts (new)
    │ Key changes: Created User model with id, email, name, passwordHash...
    │
    │ ## Instructions
    │ Follow your full judge process...
    └─────────────────────────────────────────────────────────

  → Judge (Sonnet — same tier as implementation): PASS, SCORE: 4.2/5.0
  → Context passed forward: User model fields, migration file paths

Step 2: Add CRUD endpoints for users
  Parallel dispatch: Meta-judge + Implementation (both Sonnet)
  Judge Verification (with step 2 meta-judge spec):
    NOTE: Pre-existing changes detected — Step 1 created the User model.
    Include "Pre-existing Changes" section so the judge does not confuse
    Step 1's files with Step 2's implementation work.

    Judge prompt sent:
    ┌─────────────────────────────────────────────────────────
    │ You are evaluating Step 2/3: Add CRUD endpoints for
    │ users against an evaluation specification produced by
    │ the meta judge.
    │
    │ CLAUDE_PLUGIN_ROOT=...
    │
    │ ## Original Task
    │ Implement user management feature
    │
    │ ## Step Requirements
    │ Add CRUD endpoints (create, read, update, delete) for
    │ user management with proper validation and error handling.
    │
    │ ## Previous Steps Context
    │ Step 1 created User model with fields: id, email, name,
    │ passwordHash, createdAt, updatedAt.
    │
    │ ## Pre-existing Changes (Context Only)
    │
    │ The following changes were made BEFORE the current
    │ step's implementation agent started working. They are
    │ NOT part of the current step's output. Focus your
    │ evaluation on the current step's changes. Only verify
    │ pre-existing changed files/logic if they directly
    │ relate to the current step's requirements.
    │
    │ ### Step 1: "Create User model and database schema"
    │ The following files were created as part of Step 1:
    │ - src/models/User.ts (new) - User model with fields:
    │   id, email, name, passwordHash, createdAt, updatedAt
    │ - migrations/001_create_users.ts (new) - Database
    │   migration for users table
    │
    │ These files exist in the codebase and may be referenced
    │ by the current step, but evaluate only the changes made
    │ by Step 2's implementation agent.
    │
    │ ## Evaluation Specification
    │ ```yaml
    │ {meta-judge's evaluation specification YAML}
    │ ```
    │
    │ ## Implementation Output
    │ Files: src/controllers/UserController.ts (new),
    │        src/routes/users.ts (new), src/app.ts (modified)
    │ Key changes: Added REST endpoints for user CRUD...
    │
    │ ## Instructions
    │ Follow your full judge process...
    └─────────────────────────────────────────────────────────

  → Judge (Sonnet — same tier as implementation): PASS, SCORE: 4.4/5.0
  → Context passed forward: API routes, controller patterns

Step 3: Add authentication integration
  Parallel dispatch: Meta-judge + Implementation (both Opus — critical trigger)
  Judge Verification (with step 3 meta-judge spec):
    NOTE: Pre-existing changes include BOTH Step 1 AND Step 2.
    The judge needs to know about all prior steps' output.

    Judge prompt sent:
    ┌─────────────────────────────────────────────────────────
    │ You are evaluating Step 3/3: Add authentication
    │ integration against an evaluation specification
    │ produced by the meta judge.
    │
    │ CLAUDE_PLUGIN_ROOT=...
    │
    │ ## Original Task
    │ Implement user management feature
    │
    │ ## Step Requirements
    │ Add JWT-based authentication with login/register
    │ endpoints and middleware for protecting user routes.
    │
    │ ## Previous Steps Context
    │ Step 1 created User model. Step 2 added CRUD endpoints
    │ at /api/users with UserController.
    │
    │ ## Pre-existing Changes (Context Only)
    │
    │ The following changes were made BEFORE the current
    │ step's implementation agent started working. They are
    │ NOT part of the current step's output. Focus your
    │ evaluation on the current step's changes. Only verify
    │ pre-existing changed files/logic if they directly
    │ relate to the current step's requirements.
    │
    │ ### Step 1: "Create User model and database schema"
    │ - src/models/User.ts (new) - User model with fields:
    │   id, email, name, passwordHash, createdAt, updatedAt
    │ - migrations/001_create_users.ts (new) - Database
    │   migration for users table
    │
    │ ### Step 2: "Add CRUD endpoints for users"
    │ - src/controllers/UserController.ts (new) - REST
    │   controller with create, read, update, delete handlers
    │ - src/routes/users.ts (new) - Express router for
    │   /api/users endpoints
    │ - src/app.ts (modified) - Registered user routes
    │
    │ These files exist in the codebase and may be modified
    │ by the current step, but evaluate only the changes made
    │ by Step 3's implementation agent.
    │
    │ ## Evaluation Specification
    │ ```yaml
    │ {meta-judge's evaluation specification YAML}
    │ ```
    │
    │ ## Implementation Output
    │ Files: src/auth/AuthMiddleware.ts (new),
    │        src/routes/auth.ts (new), src/app.ts (modified),
    │        src/routes/users.ts (modified)
    │ Key changes: Added JWT auth with login/register...
    │
    │ ## Instructions
    │ Follow your full judge process...
    └─────────────────────────────────────────────────────────

  → Judge (Opus — same tier as implementation): PASS, SCORE: 4.1/5.0

最终摘要：

Agent 总数：10（3 个元评审者 + 3 个实现者 + 0 次重试 + 3 个评审者）
已有更改的累积情况：
- 步骤 1 评审者：无
- 步骤 2 评审者：步骤 1 的输出（2 个文件）
- 步骤 3 评审者：步骤 1 和 2 的输出（5 个文件）
所有评审分数：4.2、4.4、4.1

示例 2：用户修改过的代码库 + 顺序步骤（已有更改来源混合）

场景：

用户在对话期间一直在处理支付处理模块。他们在调用 do-in-steps 之前修改了几个文件（添加了新的 PaymentGateway 接口、更新了配置）。

输入：

/do-in-steps fix and improve payment processing

阶段 1 - 分解：

步骤	子任务	依赖项	复杂度	类型	输出
1	修复支付验证错误	-	中	Bug 修复	已更正的验证逻辑
2	为失败的支付添加重试逻辑	步骤 1	高	实现	带退避机制的重试机制

阶段 2 - 模型选择：

步骤	子任务	模型	理由
1	修复支付验证错误	opus	opus 当之无愧——范围虽小，但优先级意味着关键性高于规模：支付属于关键项
2	为失败的支付添加重试逻辑	opus	opus 当之无愧——支付（关键项）加上围绕资金流转的重试／退避排序（复杂逻辑）

两个步骤都使用 opus，是因为其领域值得使用，而不是因为此次运行本身——有关混合不同层级的链式示例，请参见示例 3。

阶段 3 - 执行并混合已有更改：

Step 1: Fix payment validation bugs
  Parallel dispatch: Meta-judge + Implementation (both Opus — critical trigger)
  Judge Verification (Opus, with step 1 meta-judge spec):
    NOTE: Pre-existing changes detected from USER modifications.
    The user modified payment files before this task — include those
    so the judge focuses only on the bug fix, not the user's prior work.

    Judge prompt sent:
    ┌─────────────────────────────────────────────────────────
    │ You are evaluating Step 1/2: Fix payment validation
    │ bugs against an evaluation specification produced by
    │ the meta judge.
    │
    │ CLAUDE_PLUGIN_ROOT=...
    │
    │ ## Original Task
    │ Fix and improve payment processing
    │
    │ ## Step Requirements
    │ Fix validation bugs in payment amount and currency
    │ checks that allow invalid transactions to proceed.
    │
    │ ## Previous Steps Context
    │ None (first step)
    │
    │ ## Pre-existing Changes (Context Only)
    │
    │ The following changes were made BEFORE the current
    │ step's implementation agent started working. They are
    │ NOT part of the current step's output. Focus your
    │ evaluation on the current step's changes. Only verify
    │ pre-existing changed files/logic if they directly
    │ relate to the current step's requirements.
    │
    │ ### User modifications (before current task)
    │ The user made changes to the following files/modules
    │ before this task was started:
    │ - src/payments/PaymentGateway.ts (new) - Payment
    │   gateway interface definition
    │ - src/payments/StripeAdapter.ts (modified) - Updated
    │   to implement new PaymentGateway interface
    │ - src/config/payment.config.ts (modified) - Added
    │   gateway configuration settings
    │
    │ The current task focuses on fixing validation bugs.
    │ Pre-existing changes to payment files may overlap with
    │ the current step's scope — evaluate whether the
    │ implementation agent's changes correctly fix the bugs
    │ without breaking the pre-existing modifications.
    │
    │ ## Evaluation Specification
    │ ```yaml
    │ {meta-judge's evaluation specification YAML}
    │ ```
    │
    │ ## Implementation Output
    │ Files: src/payments/PaymentValidator.ts (modified),
    │        tests/payments/PaymentValidator.test.ts (modified)
    │ Key changes: Fixed amount validation to reject negative
    │ values, added currency code format check...
    │
    │ ## Instructions
    │ Follow your full judge process...
    └─────────────────────────────────────────────────────────

  → VERDICT: PASS, SCORE: 4.3/5.0
  → Context passed forward: Validation fixes, affected files

Step 2: Add retry logic for failed payments
  Parallel dispatch: Meta-judge + Implementation (both Opus — critical trigger)
  Judge Verification (Opus, with step 2 meta-judge spec):
    NOTE: Pre-existing changes now include BOTH the user's modifications
    AND Step 1's output. The judge needs both sources to correctly
    attribute changes.

    Judge prompt sent:
    ┌─────────────────────────────────────────────────────────
    │ You are evaluating Step 2/2: Add retry logic for failed
    │ payments against an evaluation specification produced by
    │ the meta judge.
    │
    │ CLAUDE_PLUGIN_ROOT=...
    │
    │ ## Original Task
    │ Fix and improve payment processing
    │
    │ ## Step Requirements
    │ Add retry mechanism with exponential backoff for failed
    │ payment transactions, with configurable max retries.
    │
    │ ## Previous Steps Context
    │ Step 1 fixed payment validation bugs in
    │ PaymentValidator.ts (amount and currency checks).
    │
    │ ## Pre-existing Changes (Context Only)
    │
    │ The following changes were made BEFORE the current
    │ step's implementation agent started working. They are
    │ NOT part of the current step's output. Focus your
    │ evaluation on the current step's changes. Only verify
    │ pre-existing changed files/logic if they directly
    │ relate to the current step's requirements.
    │
    │ ### User modifications (before current task)
    │ - src/payments/PaymentGateway.ts (new) - Payment
    │   gateway interface definition
    │ - src/payments/StripeAdapter.ts (modified) - Updated
    │   to implement new PaymentGateway interface
    │ - src/config/payment.config.ts (modified) - Added
    │   gateway configuration settings
    │
    │ ### Step 1: "Fix payment validation bugs"
    │ - src/payments/PaymentValidator.ts (modified) - Fixed
    │   amount validation and currency code format checks
    │ - tests/payments/PaymentValidator.test.ts (modified) -
    │   Added regression tests for validation fixes
    │
    │ These files exist in the codebase and may be modified
    │ by the current step, but evaluate only the changes made
    │ by Step 2's implementation agent.
    │
    │ ## Evaluation Specification
    │ ```yaml
    │ {meta-judge's evaluation specification YAML}
    │ ```
    │
    │ ## Implementation Output
    │ Files: src/payments/PaymentRetryService.ts (new),
    │        src/payments/StripeAdapter.ts (modified),
    │        src/config/payment.config.ts (modified),
    │        tests/payments/PaymentRetryService.test.ts (new)
    │ Key changes: Added PaymentRetryService with exponential
    │ backoff, integrated into StripeAdapter...
    │
    │ ## Instructions
    │ Follow your full judge process...
    └─────────────────────────────────────────────────────────

  → VERDICT: PASS, SCORE: 4.5/5.0

最终摘要：

Agent 总数：7（2 个元评审者 + 2 个实现者 + 0 次重试 + 2 个评审者）
已有更改的累积情况：
- 步骤 1 评审者：用户修改（3 个文件）
- 步骤 2 评审者：用户修改（3 个文件）+ 步骤 1 的输出（2 个文件）
所有评审分数：4.3、4.5

示例 3：通过升级处理多文件重构

输入：

/do-in-steps Rename 'userId' to 'accountId' across the codebase - this affects interfaces, implementations, and callers

阶段 1 - 分解：

步骤	子任务	依赖项	复杂度	类型	输出
1	更新接口定义	-	高	重构	更新后的接口
2	更新这些接口的实现	步骤 1	低	重构	更新后的实现
3	更新调用方和使用方	步骤 2	低	重构	更新后的调用方文件
4	更新测试	步骤 3	低	测试	更新后的测试文件
5	更新文档	步骤 4	低	文档	更新后的文档

阶段 2 - 模型选择：

步骤	子任务	模型	理由
1	更新接口	opus	opus 是应得的选择——共享契约发生变化，无论文件数量多少，这都是触发使用 `opus` 的条件
2	更新实现	haiku	机械性广度的例外情况：每个文件重复执行一个由规则驱动的重命名操作，按单次出现进行分级
3	更新调用方	haiku	同样适用该例外情况——机械性重命名，不涉及逻辑或契约变更
4	更新测试	haiku	与重命名对应的机械性测试修复
5	更新文档	haiku	单一用途的文本修正，不涉及代码

阶段 3 - 带升级的执行（每个步骤都有并行的元评审器和实现）：

Step 1: Update interfaces
  Parallel dispatch: Meta-judge + Implementation (both Opus — shared contract change)
  → Judge (Opus, sadd:judge, with step 1 meta-judge spec): PASS, 4.3/5.0

Step 2: Update implementations
  Parallel dispatch: Meta-judge + Implementation (both Haiku)
    NOTE: Step 1's opus tier does NOT carry forward — Step 2 is tiered on
    its own merits (mechanical rename).
  → Judge (Haiku, sadd:judge, with step 2 meta-judge spec): PASS, 4.0/5.0

Step 3: Update callers (Problem Detected — model escalation within the step)
  Parallel dispatch: Meta-judge (Haiku) + Implementation (Haiku)
  Attempt 1 (Haiku impl + Haiku judge): Judge FAIL, 2.5/5.0
    → ISSUES: Missed 12 occurrences in legacy module
    → score < 3.0 → trigger (1) fires. Missed occurrences read as a capability
      gap, not a narrow fixable defect, so the sole hold exception does not
      apply → mandatory bump: haiku → sonnet.
      Meta-judge NOT re-run, NOT re-tiered — same spec reused.
  Attempt 2 (Sonnet impl + Sonnet judge, same step 3 meta-judge spec): FAIL, 2.8/5.0
    → ISSUES: Still missing 4 occurrences, found new deprecated API usage
    → still < 3.0 → still a capability gap, not a narrow fixable defect →
      mandatory bump again: sonnet → opus
  Attempt 3 (Opus impl + Opus judge, same spec): FAIL, 3.2/5.0
    → ISSUES: 2 occurrences in dynamically generated code
    → at the `opus` ceiling — no bump available regardless of the hold
      exception; retry at `opus` with exact feedback.
  Attempt 4 (Opus impl + Opus judge, same spec): FAIL, 3.3/5.0
    → ISSUES: Dynamic code generation still not fully addressed

  ESCALATION TO USER:
  "Step 3 failed after 4 attempts (haiku → sonnet → opus). Persistent issue:
   Dynamic code generation in LegacyAdapter.ts generates 'userId' at runtime.
   Options: 1) Provide guidance, 2) Modify requirements, 3) Skip, 4) Abort"
  (Tier escalation is NOT offered as an option — already at the opus ceiling.)

  User response: "Update LegacyAdapter to use string template with accountId"

  Attempt 5 (with user guidance, Opus, same step 3 meta-judge spec): Judge PASS, 4.1/5.0

Step 4-5: Each with parallel meta-judge + implementation, complete without issues
  NOTE: Step 3's escalation to opus is scoped to Step 3. Steps 4 and 5 are
  re-assessed from scratch and both run at Haiku.

Agent 总数：20（5 个元评审器 + 5 个实现 + 5 次重试 + 5 个评审器）

最佳实践

任务分解

明确具体： 每个子任务都应有清晰、可验证的结果
定义验证点： 评审器应检查每个步骤的哪些内容？
尽量减少步骤： 合并相关工作；不要过度拆分
验证依赖关系： 确保每个步骤都能获得前序步骤提供的所需内容
规划上下文： 确定哪些上下文需要在步骤间传递

模型选择

规则见模型选择策略；以下习惯有助于落实这些规则：

逐步明确说明理由 - 派发每个步骤前，说明其范围、复杂度和风险，以及由此得出的模型级别；这是整个执行过程中影响最大的决策
opus 应得而用，绝非权宜之选 - 根据选择规则中的优先级和决胜规则解决所有重叠与平局，绝不凭直觉决定
依据每个步骤自身的情况确定模型级别 - 一个工作链中可以混用不同级别；相邻步骤的级别（或已升级的级别）不能作为当前步骤的依据
各角色使用相同级别 - 只提高规则制定者（元评审器）的级别，且仅限不明显的步骤（角色配对）
基于证据升级 - 仅当尝试明显使用了过低级别的模型，或用户对质量提出意见时才升级（升级规则），且升级范围仅限失败的步骤

上下文传递指南

场景	传递内容	省略内容
步骤 1 中定义的接口	完整的接口定义	实现细节
步骤 2 中的实现	关键模式、文件位置	内部逻辑
步骤 3 中的集成	使用模式、入口点	步骤 2 的内部细节
重试时的评审反馈	ISSUES 列表、报告路径	完整报告内容

让上下文聚焦：

传递后续步骤构建工作所需的内容
省略不会影响后续步骤的内部细节
突出需要保持一致的模式和约定
将评审器的 IMPROVEMENTS 作为可选增强项
跟踪已有变更 - 向评审器传递此前修改的上下文（包括前序步骤），避免归因混淆

元评审 + 评审验证

绝不跳过元评审 — 针对任务定制的评估标准比通用标准能做出更好的判断
每个步骤配备一个元评审 — 每个步骤都会获得专属元评审，并与实现工作并行派发
在同一步骤的重试中复用元评审规范 — 重试时，复用该步骤的元评审规范；不要重新运行元评审
每个新步骤都使用新的元评审 — 不同步骤的要求不同，因此每个步骤都需要新的元评审
并行派发时优先调用元评审 — 始终将其作为消息中的第一个工具调用
只解析评审回复中的标题 — 不要阅读完整报告，以避免上下文污染
包含 CLAUDE_PLUGIN_ROOT — 元评审和评审都需要已解析的插件根路径
元评审 YAML — 只将元评审 YAML 传给评审，不要添加任何额外文字或注释！
自我批评后： 评审会检查已通过内部验证的工作
独立验证： 评审与实现者是不同的 Agent
结构化输出： 始终从回复中解析 VERDICT/SCORE，而不是完整报告
最多重试次数： 升级给用户前最多尝试 3 次
反馈循环： 将评审的 ISSUES 传给重试实现 Agent
重试时，使用同一步骤的元评审规范返回评审验证

质量保证

双层验证： 自我批评（内部）+ 评审（外部）
先进行自我批评： 实现 Agent 在提交前验证自己的工作
再进行外部评审： 独立评审能发现自我批评遗漏的盲点
迭代循环： 根据反馈重试，直到通过或达到最大重试次数
适度迭代： 应用迭代裁量规则 — 最多进行一次由小问题驱动的重试，评分绝不低于 3.0，使用 --strict 时禁用
链式验证： 评审会检查与先前步骤的集成情况
升级处理： 不要继续推进未通过的步骤，应征求用户意见
最终集成测试： 所有步骤完成后，验证完整变更能否协同工作

上下文格式参考

实现 Agent 输出格式

## Context for Next Steps

### Files Modified
- `src/dto/UserDTO.ts` (new file)
- `src/services/UserService.ts` (modified)

### Key Changes Summary
- Created UserDTO with fields: id (string), name (string), email (string), createdAt (Date)
- UserDTO includes static `fromUser(user: User): UserDTO` factory method
- Added `toDTO()` method to User class for convenience

### Decisions That Affect Later Steps
- Used class-based DTO (not interface) to enable transformation methods
- Opted for explicit mapping over automatic serialization for better control

### Warnings for Subsequent Steps
- UserDTO does NOT include password field - ensure no downstream code expects it
- The `createdAt` field is formatted as ISO string in JSON serialization

### Verification Points
- TypeScript compiles without errors
- UserDTO.fromUser() correctly maps all User properties
- Existing service tests still pass

评审判定格式（结构化标题）

---
VERDICT: PASS
SCORE: 4.2/5.0
ISSUES:
  - None
IMPROVEMENTS:
  - Consider adding input validation to fromUser() method
  - Add JSDoc comments for better IDE support
---

## Detailed Evaluation
[Evidence and analysis following meta-judge specification rubrics...]

评审判定格式（FAIL 示例）

---
VERDICT: FAIL
SCORE: 2.8/5.0
ISSUES:
  - Missing User->UserDTO mapping logic in getUser() method
  - Return type annotation changed but actual return value still returns User object
  - No null handling for optional User fields
IMPROVEMENTS:
  - Add static fromUser() factory method to UserDTO
  - Implement toDTO() as instance method on User class
---

关键要点： 有依赖关系的复杂任务适合按顺序执行，每个步骤都在全新上下文中运行，同时只接收来自先前步骤的相关输出。针对每个步骤的元评审评估规范能确保评估标准符合各步骤的具体要求，同时与实现工作并行运行以提高速度。外部评审验证能发现自我批评遗漏的盲点，而迭代循环（复用同一步骤的元评审规范）则能确保质量达标后再继续。这既能避免上下文污染，也能防止错误传播。

支持 Markdown

登录后评论

基本信息

作者: neolabhq
仓库: neolabhq/context-engineering-kit
分类: Agent 工作流
安装次数: 1,239
GitHub Stars: 1,792

报告问题