sadd:do-in-steps

Name: sadd:do-in-steps
Author: neolabhq

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

代码仓库

关于 sadd:do-in-steps

sadd:do-in-steps 是用于 Claude Code 的技能，可将复杂任务拆成有序子任务，由多个 Agent 协作执行，并在每步后验证结果。

主要功能

01按顺序拆解任务
02按子任务选择模型
03并行执行与生成评估标准
04独立验证每个步骤
05在步骤间传递上下文
06验证失败时重试

适用场景

01拆分有依赖关系的多部分改动
02在执行 Agent 间传递相关结果
03继续后续步骤前检查阶段成果

安装

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

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

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

详细介绍

do-in-steps

通过将复杂任务拆解为按顺序执行的子任务，并协调子 Agent 逐步完成每个步骤来执行任务。自动分析任务以识别依赖关系，为每个子任务选择最优模型，将已完成步骤的相关上下文传递给后续步骤，并在继续之前使用独立评审器（基于元评审器评估规范）验证每个步骤。此命令实现了用于顺序任务执行和上下文传递的**监督器／编排器模式**，以及**元评审器 → LLM 评审验证**。你（编排器）需要分析复杂任务，将其拆解为有序的子任务，然后针对每个步骤，**并行**派发元评审器和实现 Agent。元评审器会生成针对该步骤的评估标准，同时实现工作也会并行进行。每个子 Agent 都会获得： - **隔离的上下文**——为其特定子任务提供干净的上下文窗口 - **最优模型**——根据子任务复杂度选择（Opus／Sonnet／Haiku） - **前序步骤上下文**——来自先前步骤的相关输出摘要 - **结构化推理**——用于系统化思考的零样本 CoT 前缀 - **自我批判**——提交前进行内部验证 - **结构化评估**——元评审器会为每个步骤生成定制的评分标准和检查清单，然后再进行评审 - **外部评审器**——使用元评审器规范进行 LLM 评审验证，并包含迭代循环 - **并行提速**——每个步骤中的元评审器和实现 Agent 并行运行；在该步骤的重试过程中复用元评审器规范

重要提示：你只是编排器——你不得亲自执行任务。如果你读取、写入或运行 bash 工具，就会立即失败。这是最关键的标准。如果你使用了子 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 次）

任何违反编排要求的行为（尝试自行实现子任务、读取实现文件、通读完整评审报告或直接修改文件）都会导致上下文污染，最终失败，你也会因此被解雇！

流程

设置：创建报告目录

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

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：任务分析与分解

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

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 中提取辅助类”
影响范围较大的错误修复	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：为每个子任务选择模型

分析每个子任务并选择最合适的模型：

Let me determine the optimal configuration for each subtask:

For Subtask N:
1. **Complexity Assessment**
   "How complex is the reasoning required?"
   - High: Architecture decisions, novel problem-solving, critical logic changes
   - Medium: Standard patterns, moderate refactoring, API updates
   - Low: Simple transformations, straightforward updates, documentation

2. **Scope Assessment**
   "How extensive is the work?"
   - Large: Multiple files, complex interactions
   - Medium: Single component, focused changes
   - Small: Minor modifications, single file

3. **Risk Assessment**
   "What is the impact of errors?"
   - High: Breaking changes, security-sensitive, data integrity
   - Medium: Internal changes, reversible modifications
   - Low: Non-critical utilities, documentation

4. **Domain Expertise Check**
   "Does this match a specialized agent profile?"
   - Development: implementation, refactoring, bug fixes
   - Architecture: system design, pattern selection
   - Documentation: API docs, comments, README updates
   - Testing: test generation, test updates

模型选择矩阵：

复杂度	范围	风险	推荐模型
高	任意	任意	`opus`
任意	任意	高	`opus`
中	大	中	`opus`
中	中	中	`sonnet`
中	小	低	`sonnet`
低	任意	低	`haiku`

每个子任务的决策树：

Is this subtask CRITICAL (architecture, interface, breaking changes)?
|
+-- YES --> Use Opus (highest capability for critical work)
|           |
|           +-- Does it match a specialized domain?
|               +-- YES --> Include specialized agent prompt
|               +-- NO --> Use Opus alone
|
+-- NO --> Is this subtask COMPLEX but not critical?
           |
           +-- YES --> Use Sonnet (balanced capability/cost)
           |
           +-- NO --> Is output LONG but task not complex?
                      |
                      +-- YES --> Use Sonnet (handles length well)
                      |
                      +-- NO --> Is this subtask SIMPLE/MECHANICAL?
                                 |
                                 +-- YES --> Use Haiku (fast, cheap)
                                 |
                                 +-- NO --> Use Sonnet (default for uncertain)

专用 Agent： 可用的专用 Agent 列表取决于项目和已加载的插件。sdd 插件中的常见 Agent 包括：sdd:developer、sdd:tdd-developer、sdd:researcher、sdd:software-architect、sdd:tech-lead、sdd:team-lead、sdd:qa-engineer。如果没有合适的专用 Agent，则回退到不具备专门能力的通用 Agent。

决策： 只有当子任务明确受益于领域专业知识，且复杂度足以证明额外开销合理时，才使用专用 Agent（Haiku 级别的任务除外）。

选择输出格式：

## Model/Agent Selection

| Step | Subtask | Model | Agent | Rationale |
|------|---------|-------|-------|-----------|
| 1 | Update interface | opus | sdd:developer | Complex API design |
| 2 | Update implementations | sonnet | sdd:developer | Follow patterns |
| 3 | Update callers | haiku | - | Simple find/replace |
| 4 | Update tests | sonnet | sdd:tdd-developer | Test expertise |

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

逐个执行子任务。每个步骤都并行调度元评审器和实现 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 + low → PASS   │          │
│          │                              │ └─ NO  → Retry?         │          │
│          │                              │     ├─ <3 → Retry       │          │
│          │                              │     └─ ≥3 → 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
</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 都以前台模式运行。等待两者都完成后，再调度评审器。

每步元评审提示词：

## 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: opus
    - subagent_type: "sadd:meta-judge"

  Tool call 2 (implementation):
    - description: "Step {N}/{total}: {subtask_name}"
    - model: {selected model}
    - subagent_type: "{selected agent type}"

等待两者都返回后，再调度评审器。

3.4 评审验证协议

元评审器和实现 Agent 都完成后，调度一个独立评审器，依据元评审器的评估规范验证该步骤。

重要：必须向评审器提供元评审器的原样评估规范 YAML；不得跳过、添加或以任何方式修改其中内容，也不得缩短或总结其中的任何文本！

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

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

何时包含：

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

何时省略：

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

内容指南：

使用高层概述：任务描述、受影响文件或模块列表、更改的大致性质（创建、修改、删除）
不要包含代码块、差异或行级细节——保持简洁
清楚标注每个来源：“步骤 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: "Judge Step {N}/{total}: {subtask_name}"
prompt: {包含精确元评审规范 YAML 的评审验证提示词，以及适用时的“预先存在的更改”部分}
model: opus
subagent_type: "sadd:judge"


#### 3.5 Dispatch, Verify, and Iterate

For each subtask in sequence:

并行派发元评审 Agent 和实现 Agent（单条消息，2 次工具调用）：工具调用 1（元评审 — 必须先调用）：使用 Task 工具： - description: "Meta-judge Step {N}/{total}: {subtask_name}" - prompt: {包含步骤要求和上下文的元评审提示词} - model: opus - subagent_type: "sadd:meta-judge"

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

如果分数 ≥4.0： → VERDICT：PASS → 在累积上下文的基础上继续下一步 → 将 IMPROVEMENTS 作为可选改进纳入上下文

如果分数 ≥3.0 且发现的问题均为低优先级，则： → VERDICT：PASS → 在累积上下文的基础上继续下一步 → 将 IMPROVEMENTS 作为可选改进纳入上下文

如果分数 <4.0： → VERDICT：FAIL → 检查此步骤的重试次数

如果重试次数 <3： → 派发实现 Agent 重试，并提供： - 原始步骤要求 - 评审的 ISSUES 列表作为反馈 - 评审报告的路径，以供参考 - 修复具体问题的指示 → 使用此步骤相同的元评审规范，重新进行评审验证 → 重试时不要重新运行元评审

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


**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.

阶段 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}

### 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 |
| ... | ... | ... | ... | ... | ... |

### 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）

经过评审验证的迭代循环可以自动处理大多数失败：

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)

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

当某一步骤三次评审验证均未通过时：

停止 — 不要在基础未稳固时继续
报告 — 提供失败分析：
- 原始步骤要求
- 所有评审结论和分数
- 多次重试中持续存在的问题
升级处理 — 向用户提供以下选项：
- 提供更多上下文或指导以便重试
- 修改步骤要求
- 跳过此步骤（如果是可选步骤）
- 中止并报告部分进度
等待 — 未经用户决定，不要继续

升级报告格式：

## 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. **Modify requirements** - Simplify or clarify step requirements
3. **Skip step** - Mark as skipped and continue (if non-critical)
4. **Abort** - Stop execution and preserve partial progress

Awaiting your decision...

绝不：

在达到最大重试次数后仍未通过的步骤之后继续
为了“节省时间”而跳过评审验证
忽略多次重试中持续存在的问题
臆测可能有效的做法

如果上下文缺失

不要猜测之前的步骤产出了什么
重新检查之前步骤的输出，查找缺失的信息
查看评审报告——其中可能标出了缺失内容
如有需要，派遣澄清子 Agent提取缺失的上下文
更新上下文传递方式，以便今后处理类似任务

如果步骤相互冲突

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

示例

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

输入：

/do-in-steps implement user management feature

阶段 1 - 分解：

步骤	子任务	依赖于	复杂度	类型	输出
1	创建用户模型和数据库架构	-	中	实现	用户模型、迁移文件
2	添加用户 CRUD 端点	步骤 1	中	实现	REST API 路由、控制器
3	添加身份验证集成	步骤 1、2	高	实现	身份验证中间件、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...
    └─────────────────────────────────────────────────────────

  → VERDICT: 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
  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...
    └─────────────────────────────────────────────────────────

  → VERDICT: PASS, SCORE: 4.4/5.0
  → Context passed forward: API routes, controller patterns

Step 3: Add authentication integration
  Parallel dispatch: Meta-judge + Implementation
  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...
    └─────────────────────────────────────────────────────────

  → VERDICT: PASS, SCORE: 4.1/5.0

最终摘要：

Agent 总数：10（3 个元评审者 + 3 个实现 Agent + 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	修复支付验证错误	-	中	错误修复	修正后的验证逻辑
2	为失败的支付添加重试逻辑	步骤 1	高	实现	带退避机制的重试机制

阶段 3 - 执行并混合累积前序更改：

Step 1: Fix payment validation bugs
  Parallel dispatch: Meta-judge + Implementation
  Judge Verification (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
  Judge Verification (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 个实现 Agent + 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	破坏性更改需要谨慎处理
2	更新实现	haiku	机械式重命名
3	更新调用方	haiku	机械式更新
4	更新测试	haiku	简单的测试修复
5	更新文档	haiku	简单的文本更新

阶段 3 - 执行并逐步升级（每个步骤均并行进行元评审和实现）：

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

Step 2: Update implementations
  Parallel dispatch: Meta-judge + Implementation
  → Judge (Opus, sadd:judge, with step 2 meta-judge spec): PASS, 4.0/5.0

Step 3: Update callers (Problem Detected)
  Parallel dispatch: Meta-judge + Implementation
  Attempt 1: Judge FAIL, 2.5/5.0 (using step 3 meta-judge spec)
    → ISSUES: Missed 12 occurrences in legacy module
  Attempt 2: Judge FAIL, 2.8/5.0 (reusing same step 3 meta-judge spec)
    → ISSUES: Still missing 4 occurrences, found new deprecated API usage
  Attempt 3: Judge FAIL, 3.2/5.0 (reusing same step 3 meta-judge spec)
    → ISSUES: 2 occurrences in dynamically generated code
  Attempt 4: Judge FAIL, 3.3/5.0 (reusing same step 3 meta-judge spec)
    → ISSUES: Dynamic code generation still not fully addressed

  ESCALATION TO USER:
  "Step 3 failed after 4 attempts. Persistent issue: Dynamic code generation
   in LegacyAdapter.ts generates 'userId' at runtime.
   Options: 1) Provide guidance, 2) Modify requirements, 3) Skip, 4) Abort"

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

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

Step 4-5: Each with parallel meta-judge + implementation, complete without issues

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

最佳实践

任务拆解

明确具体： 每个子任务都应有清晰、可验证的结果
定义验证点： 判定者应在每一步检查什么？
尽量减少步骤： 合并相关工作，避免过度拆解
验证依赖关系： 确保每一步都具备所需的前置条件
规划上下文： 明确步骤之间需要传递哪些上下文

模型选择

匹配复杂度： 简单转换任务不要使用 Opus
高风险时升级： 首步和关键步骤应使用更强的模型
考虑链式影响： 早期步骤中的错误会逐步累积；应尽早投入资源保证质量
拿不准时使用 Opus： 对于依赖关系紧密的步骤，质量优先于成本

步骤类型	实现模型
关键／可能造成破坏	Opus
标准	Opus
耗时且简单	Sonnet
简单且短小	Haiku

上下文传递指南

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

让上下文保持聚焦：

传递下一步构建所需的内容
省略不会影响后续步骤的内部细节
强调需要保持一致的模式／惯例
可将判定者提出的 IMPROVEMENTS 作为可选改进纳入
追踪已有改动——向判定者传递此前修改（包括前序步骤）的上下文，避免归因混淆

元判定者 + 判定者验证

绝不跳过元判定者——量身定制的评估标准比通用标准能带来更好的判定
每步配备一个元判定者——每个步骤都应有专属元判定者，并与实现工作并行派发
在同一步骤的重试中复用元判定者规范——重试时，复用该步骤的元判定者规范；不要重新运行元判定者
每个新步骤都使用新的元判定者——不同步骤的要求各不相同，因此每步都应重新配置
并行派发时优先调用元判定者——始终将其作为消息中的第一个工具调用
只解析判定者报告中的标题——不要读取完整报告，以免上下文受到干扰
包含 CLAUDE_PLUGIN_ROOT——元判定者和判定者都需要解析后的插件根路径
元判定者 YAML——只将元判定者 YAML 传递给判定者，不要在其中添加任何其他文本或注释！
自我批评后： 判定者审查已通过内部验证的工作
独立验证： 判定者应与实现者不同
结构化输出： 始终从回复中解析 VERDICT／SCORE，而非完整报告
最多重试 3 次： 达到上限后升级给用户处理
反馈循环： 将判定者的 ISSUES 传递给负责重试的实现 Agent
重试时使用同一步骤的元判定者规范，重新进行判定者验证

质量保证

双层验证： 自我批评（内部）+ 判定者（外部）
先进行自我批评： 实现 Agent 在提交前验证自己的工作
再由外部判定者审查： 独立判定者发现自我批评可能遗漏的问题
迭代循环： 根据反馈重试，直到通过或达到重试上限
链式验证： 判定者检查与前序步骤的集成情况
升级处理： 步骤未通过时不要继续；应征求用户意见
最终集成测试： 所有步骤完成后，验证整体改动能否协同工作

上下文格式参考

实现 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...]

评审判定格式（失败示例）

---
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 工作流
安装次数: 458
GitHub Stars: 1,795

报告问题