do-in-parallel

do-in-parallel

并行启动多个子 Agent，在不同文件或目标上执行任务。分析任务，为每个目标选择合适规模的模型层级，进行需求分组分析（可重复、共享或独立），生成注重质量的提示词，并要求进行自我批评；然后根据分组情况分派元评审员（每组一名，或每个独立任务一名），并行分派所有元评审员；接着为每项任务并行分派实施者；每项任务完成后，使用适合其分组的评估规范，通过 LLM-as-a-judge 进行验证。 此命令实现了**主管／编排器模式**，具备并行调度、**需求分组**以及**元评审 → LLM-as-a-judge 验证**。其主要优势在于**并行执行**——多个独立任务同时运行，而非依次执行，大幅缩短批量操作的总耗时。需求分组分析通过让相关任务共享元评审员和评审员，减少 Agent 总数：可重复组（在多个目标上执行同一任务）共享一份元评审规范；共享组（相互依赖的任务）使用一份组合评审规范。

主要优势：

• 并行执行——多个任务同时运行
• 需求分组——识别可重复和共享的任务模式，减少元评审员和评审员的数量
• 选择合适规模的模型——根据模型选择策略为每个目标选择模型：默认使用 sonnet／haiku，只有在确有需要时才使用 opus
• 全新上下文——每个子 Agent 都在干净的上下文窗口中工作
• 针对任务的评估——每位元评审员都会为其特定任务或任务组制定定制化的评分标准和检查清单
• 外部验证——评审员机械地应用针对目标的元评审规范，发现自我批评遗漏的盲点
• 反馈循环——根据评审员指出的具体问题重试
• 质量门槛——达到标准后才会交付成果

常见用例：

• 在多个文件中应用相同的重构
• 同时对多个模块进行代码分析
• 为多个组件生成文档
• 并行执行相互独立的转换

参数

参数	格式	默认值	描述
task	自由文本	必填	要在各目标上执行的任务描述
--files	"file1,file2,..."	无	以逗号分隔的目标文件路径列表
--targets	"target1,target2,..."	无	以逗号分隔的具名目标列表
--model	haiku|sonnet|opus	根据任务自动选择	用户为所有任务中的所有子 Agent（实现、元评审和评审）指定的显式覆盖选项。省略时，必须根据模型选择策略为每项任务选择一个级别——没有固定的回退级别，并且不会执行第 3 阶段的级别评估步骤。提供此选项时，所有子 Agent 都以用户的选择为准——有关升级规则如何与显式覆盖选项交互，请参阅升级规则。
--output	路径	无	结果的输出目录路径
--strict	--strict	false	禁用迭代裁量规则——目标只有在 score >= 4.0 时才算通过，否则会重试，直到达到最大重试次数。

示例：/do-in-parallel Refactor error handling --files "src/a.ts,src/b.ts" --strict

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

1. 分析任务，执行需求分组分析，并根据模型选择策略为每项任务选择模型级别
2. 根据分组并行分派元评审
3. 每个元评审完成后，为该组的目标分派实现子 Agent，并提供结构化提示词
4. 实现者完成后，根据分组分派评审
5. 解析评审结果，并在需要时迭代（每个目标最多重试 3 次；对于共享组，仅重试失败的任务）
6. 收集结果并汇报最终摘要

红线——绝不能做这些事

绝不要：

• 为了了解代码细节而阅读实现文件（交给子 Agent 处理）
• 直接编写代码或修改源文件
• 为了“节省时间”而跳过评审验证
• 通篇阅读评审报告（只解析结构化标头）
• 未经用户决定就在达到最大重试次数后继续
• 等待一个 Agent 完成后再启动另一个
• 在重试时重新运行元评审
• 等待所有元评审完成后才启动实现 Agent
• 为属于同一可重复组或共享组的任务分别启动元评审
• 仅有部分实现 Agent 失败时，重新启动共享组中的所有实现 Agent

务必：

• 使用 Task 工具，将所有实现工作分派给子 Agent
• 在分派任何元评审之前，先进行需求分组分析
• 根据分组分派元评审——在同一条回复中并行分派全部任务
• 元评审完成后立即分派实现 Agent，不要等到所有元评审都完成后才分派
• 每个任务的元评审一完成，就立即为该任务启动实现 Agent。如果所有元评审均已完成，则在同一条回复中启动所有实现 Agent
• 向每个评审 Agent 提供对应目标的具体元评审评估规范
• 对于共享组，只分派一个评审 Agent，一并审查所有相关更改
• 在给元评审 Agent 和评审 Agent 的提示词中加入 CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}
• 使用 Task 工具分派独立的评审 Agent 进行验证
• 每项实现完成后，再分派对应的评审 Agent
• 只解析评审输出中的 VERDICT/SCORE/ISSUES
• 如果验证失败，则根据反馈迭代（每个目标最多重试 3 次）
• 除非提供了 --strict，否则对每个目标的评审结论应用迭代酌情规则
• 共享组重试时，只重新启动具体失败的实现 Agent，不要重新启动整个组
• 重试时复用同一份元评审规范（绝不要重新运行元评审）

模型选择策略

选择模型是你能做的最具影响力的单项决策——它比提示词的措辞更重要，决定了目标能否正确完成，以及整个批次需要多长时间。你绝不能把这当成走过场：在分派每个目标之前，必须说明所选级别并给出一句理由。因为不愿动脑就选择最强模型，这不是谨慎，而是失职。

默认级别：sonnet 和 haiku 为默认选项。opus 仅作保留选项，需主动选择——必须由下表中的触发条件证明其合理性，不能因为拿不准就选它。

按任务选择，而非按运行选择：必须根据每个任务本身的范围、复杂度和风险，独立选择模型级别——不再要求一个批次中的所有并行 Agent 使用“相同配置”。独立任务应各自按实际情况选择级别。可重复组的共享元评审会生成一份可复用规范，但这并不意味着该组的所有任务都必须使用相同级别：根据下方的选择规则，每个任务仍分别选择实现和评审级别，因此，即使某个目标属于原本只需机械处理的组，只要涉及关键领域，也仍可使用 opus，而同组中的其他任务则可以使用成本更低的模型。共享组的同一个评审 Agent 会一并审查组内所有任务，因此其级别应与其中当前最高的实现级别相同（见角色配对）。某个任务使用的级别（包括升级后使用的级别）不得套用到同组的其他任务或下一个批次。

选择规则

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

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

平局时的选择：仅当没有任何规则明确匹配、任务确实介于两个层级之间时，才选择成本较低的层级。你绝不能为了规避风险而倾向于选择 opus；升级规则能让低成本的初步判断得到补救，而补救一个任务的成本远低于给每个任务都配置过高资源。

角色配对

任何由模型分配的流水线最多包含三个角色——生产者（负责完成工作）、标准制定者（定义什么才算“正确”）和评估者（依据这些标准检查工作）；在此技能中，这三个角色分别对应每个并行任务的实现者／元评审者／评审者——可重复组中的所有任务共用一位元评审者，而共享组中的所有任务还会共用一位评审者。默认：该任务的三个角色都使用同一层级。

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

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

生产者和评估者 MUST 始终使用同一层级——对于评审多个任务的可重复组或共享组的评审者，“使用同一层级”是指使用其所服务任务中当前最高的实现层级，以确保绝不会要求其评审高于自身层级的工作（参见 重试时的模型升级）。你 MUST NOT 只提高评估者的层级，也 MUST NOT 将标准制定者设定为低于生产者的层级。**显式的 --model 覆盖优先于本节的所有规则：**当用户传入 --model 时，每个任务的每个角色都使用该层级运行，且角色配对 MUST NOT 将元评审者的层级提高到该层级之上。

升级规则

当以下任一触发条件出现时，下一次尝试时将生产者和评估器都提升一个等级（即失败任务的实现和评判者）：

1. 首次尝试质量较低 — 分数较低，或问题表明模型误解了任务，而不只是遗漏了细节。
2. 用户抱怨质量太差或结果错误 — 无论何时，包括报告 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 类，以及任何优势在于更长时间推理而非吞吐量的模型

映射依据是能力层级，而非名称——随着厂商发布新模型，具体名称会不断变化。以上规则均以层级表示，因此在其他提供商处：先将层级映射到对应类别的模型，再原样应用选择、配对和升级规则。

流程

阶段 1：解析输入并识别目标

从命令参数中提取目标：

Input patterns:
1. --files "src/a.ts,src/b.ts,src/c.ts"    --> File-based targets
2. --targets "UserService,OrderService"    --> Named targets
3. Infer from task description             --> Parse file paths from task

解析规则：

• 如果提供了 --files：按逗号拆分，并验证每个路径都存在
• 如果提供了 --targets：按逗号拆分，并按原样使用
• 如果两者都未提供：尝试从任务描述中提取文件路径或目标名称
• STRICT_MODE = --strict present || false - 禁用迭代裁量规则；此时目标只有在 score >= 4.0 时才算通过，否则会重试，直至达到最大重试次数
• 在构建子 Agent 提示词之前，从任务文本中移除所有标志——绝不要将它们传入子 Agent 提示词

示例：/do-in-parallel Simplify error handling --files "src/a.ts,src/b.ts" --strict

阶段 2：使用零样本 CoT 分析任务

分派之前，请系统地分析任务：

Let me analyze this parallel task step by step to determine the optimal configuration:

1. **Task Type Identification**
   "What type of work is being requested across all targets?"
   - Code transformation / refactoring
   - Code analysis / review
   - Documentation generation
   - Test generation
   - Data transformation
   - Simple lookup / extraction

2. **Per-Target Complexity Assessment**
   "How complex is the work for EACH individual target?"
   - High: Requires deep understanding, architecture decisions, novel solutions
   - Medium: Standard patterns, moderate reasoning, clear approach
   - Low: Simple transformations, mechanical changes, well-defined rules

3. **Per-Target Output Size**
   "How extensive is each target's expected output?"
   - Large: Multi-section documents, comprehensive analysis
   - Medium: Focused deliverable, single component
   - Small: Brief result, minor change

4. **Independence Check**
   "Are the targets truly independent?"
   - Yes: No shared state, no cross-dependencies, order doesn't matter
   - Partial: Some shared context needed, but can run in parallel
   - No: Dependencies exist --> Use sequential execution instead

独立性验证（并行分派前必须完成）

继续之前，请确认任务确实彼此独立：

检查项	问题	如果答案为“否”
文件独立性	目标是否共用文件？	无法并行处理——文件冲突
状态独立性	任务是否会修改共享状态？	无法并行处理——存在竞态条件
顺序独立性	执行顺序是否重要？	无法并行处理——需要按顺序执行
输出独立性	是否有目标会读取另一个目标的输出？	无法并行处理——存在数据依赖

独立性检查清单：

• 没有目标会读取另一个目标的输出
• 没有目标会修改另一个目标要读取的文件
• 完成顺序无关紧要
• 不存在共享的可变状态
• 不存在跨越多个目标的数据库事务

如果任意一项检查未通过：请停止并告知用户并行处理为何不安全。建议使用 /launch-sub-agent 按顺序执行。

需求分组分析（派发 Meta-Judge 前必须完成）

识别各项任务并确认其独立性后，分析任务是否可以共用 Meta-Judge 和／或 Judge。这样可以在不影响质量的前提下，减少派发的 Agent 总数。

三种分组类型（可在同一用户提示词中组合使用）：

分组类型	适用场景	Meta-Judge	实现 Agent	Judge
可重复型	将相同的任务模式应用于多个文件／模块（例如，“为全部 3 个模块添加测试”）	整个组共用一个 Meta-Judge	每项任务各派一个（始终隔离）	每项任务各派一个，且都使用同一份共享规范
共享型	任务彼此依赖，应一起审查／验证（例如，“实现 S3 适配器并将其集成到分析功能中”）	整个组共用一个 Meta-Judge	每项任务各派一个（始终隔离）	整个组共用一个 Judge，一起审查所有更改
独立型	任务完全独立，没有分组的好处	每项任务各派一个	每项任务各派一个（始终隔离）	每项任务各派一个

决策流程：

For each pair of tasks, ask:

1. "Is this the SAME task applied to different targets?"
   +-- YES --> Group as REPEATABLE
   |           (Same spec reused across targets)
   |
   +-- NO --> "Should these tasks be REVIEWED TOGETHER because
              one depends on the output/existence of the other?"
              |
              +-- YES --> Group as SHARED
              |           (Combined spec, single judge reviews all)
              |
              +-- NO --> Mark as INDEPENDENT
                         (Separate meta-judge and judge per task)

重要：

• 如有疑问，默认采用独立型。如果无法确定任务是否确实属于可重复型或共享型，就将其视为独立任务。过度分组可能导致评估规范有误，而独立任务始终能获得针对各自任务的正确评估。多使用几个 Agent，也好过产出错误的验证标准。
• 实现 Agent 始终必须隔离——每项任务各派一个，绝不共用。只有 Meta-Judge 和 Judge 可以共用／分组。分组分析在任务分析阶段进行，也就是在启动任何 Agent 之前。

Meta-Judge 指引：

• 可重复型组：派发可重复型组的 Meta-Judge 时，明确要求其制定可复用的验证规范。
• 共享型组：派发共享型组的 Meta-Judge 时，明确要求其制定综合验证规范。

共享型组的重试逻辑：

如果共享型组的 Judge 发现问题，应分析具体是哪些实现 Agent 产出了未通过检查的更改。只重新启动其更改未通过检查的实现 Agent——只有确有必要时才重新启动组内所有 Agent。针对性重试后，重新启动共享的 Judge，再次审查所有更改（包括已通过检查的 Agent 所完成且未改动的工作）。

第 3 阶段：模型与 Agent 选择

根据第 2 阶段的分析，依照模型选择策略，为每项任务选择模型级别和专用 Agent——默认使用 sonnet／haiku，只有符合条件时才使用 opus。如果传入了 --model，则直接跳转到3.2：根据角色配对中的覆盖条款，每项任务的所有子 Agent 都使用用户指定的级别。

3.1 按任务选择模型层级

针对以下三个维度评估每项任务，然后直接从选择规则表中确定其层级——按任务选择层级，绝不为整个批次统一选择：

• 范围 — 一个文件、一个组件，还是多个文件？
• 复杂度 — 机械式编辑、已有模式，还是新颖／复杂的逻辑？
• 风险 — 独立且可撤销、内部，还是选择规则中 opus 行详尽列表所定义的关键风险？

按分组类型：

• 独立任务 — 根据每项任务自身的情况确定层级；每项任务都有自己的元评审者和该层级的评审者。
• 可重复分组 — 共享的元评审者生成一份可复用的规范，但每项任务的实现和评审者仍需单独确定层级：对每个目标严格按照选择规则进行评估，就像它是独立任务一样。分组内的关键领域目标（例如，某个文件恰好是身份验证代码）可以使用 opus，而同组其他目标仍使用 sonnet 或 haiku，即使它们共用一份规范。
• 共享分组 — 首先根据每项任务的内容单独确定层级，然后将该组唯一的共享评审者设为这些层级中的最高层级（根据角色配对），确保评审者永远不会被要求评审超出自身层级的工作。

对于每项任务，在分派前说明三个维度的评估结果、所选层级以及一行理由。然后应用角色配对——完整遵循其所有规定，包括 --model 覆盖项——以确定该任务（或分组）的元评审者层级。

3.2 选择专用 Agent（可选）

如果任务符合某个专门领域，则在所有并行 Agent 中加入相关的 Agent 提示词。专用 Agent 提供领域特定的最佳实践，可提升输出质量。

专用 Agent： 专用 Agent 列表取决于项目和已加载的插件。

决策： 在以下情况下使用专用 Agent：

• 任务明显能从领域专业知识中受益
• 所有并行 Agent 之间保持一致性很重要
• 任务并非简单任务（对于简单任务，额外开销并不值得）

在以下情况下跳过专用 Agent：

• 任务简单／机械（Haiku 层级）
• 没有明确匹配的领域
• 通用执行已足够

阶段 3.5：分组并行分派元评审者

在分派实现 Agent 之前，根据阶段 2 的需求分组分析结果分派元评审者。元评审者的数量取决于分组情况：每个可重复分组一个、每个共享分组一个、每项独立任务一个。无论分组类型如何，所有元评审者都要并行启动。每个元评审者都会生成评分标准、检查清单和评分准则。每份规范仅供其关联任务的所有重试复用。

重要：遵循上下文隔离原则——仅向每个 Agent 提供与其特定目标或分组相关的上下文。

3.5.1 按分组类型划分的元评审者提示词模板

独立元评审者提示词：

## Task

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

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## User Prompt as Context
{Original user prompt}

## Target
{Specific target for this meta-judge: task description, file path, component name, etc. extracted from User Prompt}

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

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

## Instructions
User prompt is provided as context, you should use it only as reference of changes that can occur in the project by other agents. Generate evaluation specification ONLY on the for the your specific target, generated from User Prompt. Your report will be used to verify only this particular task, not the all tasks in the user prompt.
Return only the final evaluation specification YAML in your response.

可重复分组元评审者提示词（每组一个）：

## Task

Generate a REUSABLE evaluation specification yaml that can be applied to ANY of the following targets performing the same task. You will produce rubrics, checklists, and scoring criteria that individual judge agents will each use independently to evaluate one target's implementation artifact.

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## User Prompt as Context
{Original user prompt}

## Task Being Repeated
{The common task description shared by all targets in this group}

## Targets in This Group
{List of all targets: file paths, component names, etc.}

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

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

## Instructions
CRITICAL: You are generating a REUSABLE spec that will be applied to EACH target independently by separate judges.
- Use generic language: "target file should align with criteria" instead of "all files should align"
- Do NOT include file-specific requirements (e.g., NOT "file should have only authentication logic") if the same spec will be applied to another target which logically cannot fulfill this criteria (e.g. "cart.ts" or "payments.ts" cannot have authentication logic)
- The spec must be applicable to ANY target in this group without modification
- Each judge will receive this same spec and evaluate only its own target against it
User prompt is provided as context, you should use it only as reference of changes that can occur in the project by other agents.
Return only the final evaluation specification YAML in your response.

共享分组元评审者提示词（每组一个）：

## Task

Generate a COMBINED evaluation specification yaml that covers ALL of the following related tasks. These tasks are interdependent and will be reviewed TOGETHER by a single judge. You will produce rubrics, checklists, and scoring criteria that account for cross-task dependencies and integration points.

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## User Prompt as Context
{Original user prompt}

## Tasks in This Shared Group
{List of all tasks with their targets:
- Task 1: {description} -> {target}
- Task 2: {description} -> {target}
}

## Context
{Any relevant codebase context, file paths, constraints, integration points between tasks}

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

## Instructions
CRITICAL: You are generating a COMBINED spec for tasks that will be reviewed TOGETHER by ONE judge.
- Include evaluation criteria for EACH individual task
- Include cross-task verification criteria (e.g., "adapter implementation matches the interface consumed by the integration module")
- Organize the spec so the judge can identify which criteria apply to which task's changes
- The judge will review ALL changes from ALL tasks in this group in a single evaluation
User prompt is provided as context, you should use it only as reference of changes that can occur in the project by other agents.
Return only the final evaluation specification YAML in your response.

3.5.2 分派模式

在单次响应中分派所有元评审者（无论分组类型如何）：

Use Task tool (one per group/independent task, all in same message):

[Meta-judge for Repeatable Group: "add tests"]
  - description: "Meta-judge (repeatable): reusable spec for adding tests across 3 modules"
  - prompt: {repeatable group meta-judge prompt}
  - model: {meta-judge model — the user's `--model` if one was passed; otherwise the HIGHEST current implementation tier among the group's tasks, or one tier up per Role Pairing}
  - subagent_type: "sadd:meta-judge"

[Meta-judge for Shared Group: "S3 adapter + integration"]
  - description: "Meta-judge (shared): combined spec for S3 adapter implementation and integration"
  - prompt: {shared group meta-judge prompt}
  - model: {meta-judge model — the user's `--model` if one was passed; otherwise the HIGHEST current implementation tier among the group's tasks, or one tier up per Role Pairing}
  - subagent_type: "sadd:meta-judge"

[Meta-judge for Independent Task: "update CI pipeline"]
  - description: "Meta-judge: update CI pipeline"
  - prompt: {independent meta-judge prompt}
  - model: {meta-judge model — the user's `--model` if one was passed; otherwise this task's implementation tier, or one tier up per Role Pairing}
  - subagent_type: "sadd:meta-judge"

[All meta-judges launched simultaneously]

关键： 不要等到所有元评审者都完成后才进入阶段 4。每当一个元评审者完成，就立即启动实现 Agent。如果所有元评审者均已完成，则在单次响应中启动所有实现 Agent。

阶段 4：构建每个目标的提示词

为每个目标构建相同的提示词结构，仅根据目标特定细节进行定制：

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

## Reasoning Approach

Let's think step by step.

Before taking any action, think through the problem systematically:

1. "Let me first understand what is being asked for this specific target..."
   - What is the core objective?
   - What are the explicit requirements?
   - What constraints must I respect?

2. "Let me analyze this specific target..."
   - What is the current state?
   - What patterns or conventions exist?
   - What context is relevant?

3. "Let me plan my approach..."
   - What are the concrete steps?
   - What could go wrong?
   - Is there a simpler approach?

Work through each step explicitly before implementing.

4.2 任务正文（按目标定制）

<task>
{Task description from $ARGUMENTS}
</task>

<target>
{Specific target for this agent: file path, component name, etc.}
</target>

<constraints>
- Work ONLY on the specified target
- Do NOT modify other files unless explicitly required
- Follow existing patterns in the target
- {Any additional constraints from context}
- 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>

<output>
{Expected deliverable location and format}

CRITICAL: At the end of your work, provide 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
</output>

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

## Self-Critique Verification (MANDATORY)

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

### 1. Generate Verification Questions

Create questions specific to your task and target. There examples of questions:

| # | Question | Why It Matters |
|---|----------|----------------|
| 1 | Did I achieve the stated objective for this target? | Incomplete work = failed task |
| 2 | Are my changes consistent with patterns in this file/codebase? | Inconsistency creates technical debt |
| 3 | Did I introduce any regressions or break existing functionality? | Breaking changes are unacceptable |
| 4 | Are edge cases and error scenarios handled appropriately? | Edge cases cause production issues |
| 5 | Is my output clear, well-formatted, and ready for review? | Unclear output reduces value |

### 2. Answer Each Question with Evidence

For each question, provide specific evidence from your work:

[Q1] Objective Achievement:
- Required: [what was asked]
- Delivered: [what you did]
- Gap analysis: [any gaps]

[Q2] Pattern Consistency:
- Existing pattern: [observed pattern]
- My implementation: [how I followed it]
- Deviations: [any intentional deviations and why]

[Q3] Regression Check:
- Functions affected: [list]
- Tests that would catch issues: [if known]
- Confidence level: [HIGH/MEDIUM/LOW]

[Q4] Edge Cases:
- Edge case 1: [scenario] - [HANDLED/NOTED]
- Edge case 2: [scenario] - [HANDLED/NOTED]

[Q5] Output Quality:
- Well-organized: [YES/NO]
- Self-documenting: [YES/NO]
- Ready for PR: [YES/NO]

### 3. Fix Issues Before Submitting

If ANY verification reveals a gap:
1. **FIX** - Address the specific issue
2. **RE-VERIFY** - Confirm the fix resolves the issue
3. **DOCUMENT** - Note what was changed and why

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

阶段 5：并行派发实现任务并由评审者验证

元评审者完成后，同时启动所有实现子 Agent，然后根据分组类型进行评审者验证。

5.1 执行流程

独立／可重复流程（每项任务对应一名评审者）：

┌─────────────────────────────────────────────────────────────────────────┐
│                                                                         │
│   Phase 3.5: Meta-Judge Dispatch (ALL in parallel)                      │
│                                                                         │
│   Independent:            Repeatable Group:                             │
│   ┌──────────────┐        ┌─────────────────────┐                       │
│   │ Meta-Judge A  │        │ Meta-Judge (shared)  │                       │
│   │ (tier)        │        │ (tier)               │                       │
│   │ → Spec YAML A │        │ → Reusable Spec YAML │                       │
│   └──────┬───────┘        └──────────┬──────────┘                       │
│          │                     ┌─────┴─────┐                            │
│          ▼                     ▼           ▼                            │
│   Phase 5: Implementation (ALL in parallel, one per task)               │
│                                                                         │
│   ┌──────────────┐   ┌──────────────┐   ┌──────────────┐               │
│   │ Implementer A │   │ Implementer B │   │ Implementer C │              │
│   └──────┬───────┘   └──────┬───────┘   └──────┬───────┘               │
│          │                  │                  │                        │
│          ▼                  ▼                  ▼                        │
│   Phase 5.2: Judge per task (after ALL implementors complete)           │
│                                                                         │
│   ┌──────────────┐   ┌──────────────┐   ┌──────────────┐               │
│   │  Judge A      │   │  Judge B      │   │  Judge C      │              │
│   │ +Spec YAML A  │   │ +Reusable Spec│   │ +Reusable Spec│              │
│   └──────┬───────┘   └──────┬───────┘   └──────┬───────┘               │
│          ▼                  ▼                  ▼                        │
│   Parse Verdict (per target) → PASS/FAIL → Retry if needed             │
└─────────────────────────────────────────────────────────────────────────┘

共享流程（整个组对应一名评审者）：

┌─────────────────────────────────────────────────────────────────────────┐
│                                                                         │
│   Phase 3.5: Meta-Judge for Shared Group                                │
│   ┌──────────────────────┐                                              │
│   │ Meta-Judge (combined) │                                              │
│   │ (tier)                │                                              │
│   │ → Combined Spec YAML  │                                              │
│   └──────────┬───────────┘                                              │
│         ┌────┴────┐                                                     │
│         ▼         ▼                                                     │
│   Phase 5: Implementation (one per task, in parallel)                   │
│   ┌──────────────┐   ┌──────────────┐                                   │
│   │ Implementer X │   │ Implementer Y │                                  │
│   └──────┬───────┘   └──────┬───────┘                                   │
│          │                  │                                           │
│          └────────┬─────────┘                                           │
│                   ▼                                                     │
│   Phase 5.2: ONE Judge for entire group                                 │
│   ┌────────────────────────────────┐                                    │
│   │  Judge (shared)                 │                                    │
│   │ +Combined Spec YAML             │                                    │
│   │ +ALL implementation outputs     │                                    │
│   └──────────────┬─────────────────┘                                    │
│                  ▼                                                      │
│   Parse per-task verdicts → Retry ONLY failing task(s) if needed        │
└─────────────────────────────────────────────────────────────────────────┘

关键：并行派发模式

在同一条响应中启动所有实现 Agent。不要等一名 Agent 完成后再启动另一名：

## Dispatching 3 parallel tasks

[Task 1]
Use Task tool:
  description: "Parallel: simplify error handling in src/services/user.ts"
  prompt: [CoT prefix + task body for user.ts + critique suffix]
  model: sonnet

[Task 2]
Use Task tool:
  description: "Parallel: simplify error handling in src/services/order.ts"
  prompt: [CoT prefix + task body for order.ts + critique suffix]
  model: sonnet

[Task 3]
Use Task tool:
  description: "Parallel: simplify error handling in src/services/payment.ts"
  prompt: [CoT prefix + task body for payment.ts + critique suffix]
  model: sonnet

[All 3 tasks launched simultaneously - results collected when all complete]

并行化指南：

• 在同一批次（同一条响应）中启动所有独立任务
• 不要等一项任务完成后再启动另一项
• 不要依次调用 Task 工具
• Task 工具会自动处理并行化
• 全部完成后再收集结果

上下文隔离（重要）：

• 只传递与各个特定目标相关的上下文
• 不要向每个 Agent 传递所有目标的完整列表
• 让子 Agent 通过读取文件来发现本地模式
• 每个 Agent 都在干净的上下文中工作，避免累积混淆

5.2 评审者验证协议

所有实现 Agent 完成后，根据阶段 2 确定的需求分组派发评审者。派发模式因分组类型而异：

分组类型	评审者派发方式	使用的规范
独立	每项任务对应一名评审者	任务专属的元评审者规范
可重复	每项任务对应一名评审者	使用该组元评审者提供的同一份共享可复用规范
共享	整个组仅派发一名评审者	使用该组元评审者提供的组合规范

关键：向评审者提供准确无误的元评审者评估规范 YAML，不要跳过或添加任何内容，也不要以任何方式修改，不要缩短或概述其中的任何文本！对于可重复组，每个目标的评审者都应收到同一份可复用规范。对于共享组，唯一的评审者应收到涵盖所有任务的组合规范。

5.2.1 分析已有或预期的并行更改部分

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

何时包含：

• 本次会话中较早完成了先前的 do-in-parallel 运行（即先前批次中的所有目标）
• 用户在调用此技能之前进行了手动修改（可从对话上下文或 git 中看到）
• 其他工具或 Agent 在此次并行派发之前运行并产生了更改
• 同一批次中的其他并行 Agent 预期会产生更改（例如，其他 Agent 预计会在并行开发期间修改仓库中的其他文件）

何时省略：

• 这是首次运行，且没有已知的先前更改——完全省略此部分
• 在同一目标内重试时，不要将实现 Agent 自身之前的尝试列为“已有更改”——这些尝试属于当前目标的迭代周期

内容指南：

• 使用高层次摘要：任务描述、受影响文件／模块列表、更改的大致性质（新建、修改、删除）
• 不要包含代码块、差异或行级细节——保持简洁
• 明确标注来源：“先前的 do-in-parallel：{描述}”、“用户修改（当前任务开始前）”等
• 如果存在多个更改来源，请分别使用不同的小节

关键：不要读取完整代码库或 git 历史，只需通过高层次的 git diff/status 确定哪些文件发生了更改，或根据对话上下文判断是否存在任何已有更改。

5.2.2 使用提示词和目标专属规范 YAML 启动评审者

评审者提示词模板：

You are evaluating an implementation artifact for target {target_name} against an evaluation specification produced by the meta judge.

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## User Prompt
{Original task description from user}

## Target
{Specific target: file path or component name}

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

## Pre-existing or Expected Parallel Changes (Context Only)

The following changes were made before or expected to be done by other parallel agents in the same batch now. They are NOT part of the current implementation agent's output. Focus your evaluation on the current agent's changes to its specific target. Only verify other changed files/logic if they directly relate to the current target's task requirements.

### {Source of changes: e.g., "Previous do-in-parallel: {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 可能对项目进行的更改。仅根据用户提示中的任务进行评估。你的工作是仅验证目标中的这一特定部分，而不是用户提示中的所有任务。 请遵循 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!!!

##### 5.2.3 Shared Group Judge Prompt Template

For shared groups where ONE judge reviews ALL related changes together:

```markdown
You are evaluating implementation artifacts for a group of related tasks against a combined evaluation specification produced by the meta judge. These tasks are interdependent and must be reviewed together.

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## User Prompt
{Original task description from user}

## Tasks in This Shared Group
{List of all tasks with their targets:
- Task 1: {description} -> {target}
- Task 2: {description} -> {target}
}

{IF pre-existing changes are known, include the "Pre-existing or Expected Parallel Changes (Context Only)" section — otherwise omit entirely}

## Evaluation Specification

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

实现输出

{组中的每项任务：}

任务：{任务描述} -> {目标}

{该任务实现 Agent 提供的摘要} {已修改文件的路径}

说明

用户提示作为上下文提供，你应仅将其用作参考，了解其他 Agent 可能进行的更改。请一起评估此共享组中的所有任务。验证跨任务集成点（例如，适配器是否符合集成模块使用的接口）。 重要：对于每项任务，请分别指出其是否通过或失败，以便仅重试失败的任务。 请遵循 Agent 指令中定义的完整评审流程！

输出

重要：你必须在回复开头严格使用以下 YAML 格式的评估报告！报告中须包含每项任务的判定结果。

##### 5.2.4 Dispatch Judges by Grouping Type

**Independent and Repeatable targets -- one judge per task:**

使用 Task 工具：

• description: "Judge: {target name}"
• prompt: {judge verification prompt with exact meta-judge specification YAML, and Pre-existing or Expected Parallel Changes section if applicable}
• model: {judge model — the user's --model if one was passed; otherwise MUST equal this task's current implementation tier, including after escalation}
• subagent_type: "sadd:judge"

For repeatable groups, each judge receives the SAME shared reusable spec from the group's single meta-judge, but its **model** is still that task's own current implementation tier — repeatable tasks can diverge in tier even though they share one spec. The judge prompt template from 5.2.2 is used as-is; only the target and implementation output differ between judges.

**Shared group -- ONE judge for the entire group:**

使用 Task 工具：

• description: "Judge (shared): {group description}"
• prompt: {shared group judge prompt from 5.2.3 with combined meta-judge specification YAML and ALL implementation outputs}
• model: {judge model — the user's --model if one was passed; otherwise MUST equal the HIGHEST current implementation tier among this group's tasks, including after any of them escalates}
• subagent_type: "sadd:judge"

**Launch ALL judges in parallel** (independent, repeatable, and shared judges all dispatched in same response).

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!!!

#### 5.3 Parse Verdict and Iterate

Parse judge output for each target (DO NOT read full report):

从评审回复中提取：

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

**Decision logic per target:**

如果评分 >= 4： -> VERDICT：PASS -> 将目标标记为已完成 -> 将 IMPROVEMENTS 作为可选增强项列出

如果 3.0 <= 评分 < 4 且 NOT STRICT_MODE： -> 应用迭代酌情处理规则（5.5） -> 接受 -> VERDICT：PASS（将目标标记为已完成，报告未解决的问题） -> 拒绝 -> VERDICT：FAIL -> 转到下方的“检查重试次数”

否则（评分 < 3.0，或评分 < 4 且为 STRICT_MODE）： -> VERDICT：FAIL -> 检查此目标的重试次数

如果重试次数 < 3： -> 根据下文“5.3.1 重试时的模型升级”确定此目标的重试层级 （根据升级规则——同时提升实现和评审模型，除非仅适用其例外情况） -> 在该层级启动重试实现 Agent，并提供评审反馈 -> 返回评审验证环节，并使用相同的目标专用元评审规范， 在重试层级启动评审（评审模型始终与实现模型一致）

如果重试次数 >= 3： -> 将目标标记为失败（与其他目标隔离） -> 未经用户决定，不得继续重试

**IMPORTANT: Failures are isolated**
- One target failing does NOT affect other targets
- Other parallel tasks continue independently
- Only the failed target is retried

**Shared group verdict parsing:**

For shared groups, the judge produces per-task verdicts within a single report. Parse each task's verdict individually:

从共享评审回复中提取：

• 各任务判定结果：
  • 任务 1（{target}）：VERDICT：PASS/FAIL，SCORE：X.X/5.0，ISSUES：[...]
  • 任务 2（{target}）：VERDICT：PASS/FAIL，SCORE：X.X/5.0，ISSUES：[...]
• 总体评分：X.X/5.0
• 跨任务问题：集成问题列表（如有）

**Shared group retry logic:**

如果共享评审发现失败：

1. 根据各任务判定结果，确定具体失败的任务
2. 仅重新启动失败任务的实现 Agent -- 不要重新启动已通过任务的 Agent
3. 重试实现完成后，重新启动共享评审， 再次评审所有更改（已通过的更改 + 重试后的更改） -- 共享评审仍使用相同的组合元评审规范
4. 重复此过程，直到所有任务通过，或任一任务达到最大重试次数

重要：仅重试具体失败任务的实现 Agent。 不得重新实现已通过的任务。共享评审每轮都会一并评审完整任务组。

##### 5.3.1 Model Escalation on Retry

Before dispatching any retry you MUST decide the failing task's tier explicitly per the [Escalation Rule](#escalation-rule) — which governs in full, including its sole hold exception — and record the decision in the target's row of the Results table. 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).
- **Scope:** per the [Escalation Rule](#escalation-rule).
- **Independent and repeatable-group judges:** the retry's judge MUST be dispatched at the same tier as the retry implementation.
- **Shared-group judge:** because ONE judge reviews every task in the group together, its retry tier MUST equal the HIGHEST current implementation tier among the group's tasks — so an escalated task's judge coverage never falls below its own tier, even while unescalated siblings stay at their original tier.
- The task's meta-judge (or the group's, for repeatable/shared groups) is neither re-run nor re-tiered; its specification is reused across every retry.
- The escalated tier applies to **this task's remaining attempts only** — every other target keeps the tier it was assigned in [Phase 3](#phase-3-model-and-agent-selection).
- If `opus` still fails, escalate to the user per [Error Handling](#error-handling).

#### 5.4 Retry with Feedback (If Needed)

**Retry prompt template:**

```markdown
## Retry Required for Target: {target_name}

Your previous implementation did not pass judge verification.

## Original Task
{Original task description}

## Target
{Specific target}

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

5.5 迭代裁量规则

你的主要任务是在达到目标质量的前提下完成任务，迭代投入 MUST 与各目标的规模相称。以下两种失败模式同样真实：

• 把重试次数和上下文耗在细枝末节上，导致整个批次始终无法完成 → 任务失败。
• 接受质量确实差到无法视为完成的目标 → 更严重的失败。

对每个评审分数都应用以下规则（对于共享组，按组内每项任务的判定分别应用）：

• score < 3.0 → 无条件判定失败。不得酌情处理。 根据评审反馈重试，直到目标通过或达到最大重试次数。
• 3.0 <= score < 4.0 → 酌情处理区间。 只有在此区间内，才可以决定接受低于 4.0 目标分数的目标。固定的 4.0 目标使有效下限为 3.0，因此无需单独设置有界降分保护。
• 在此区间内，若待处理的问题仅为低 / 中优先级（任何高优先级或严重问题都会完全取消酌情处理权），并且都不违反目标要求或造成实质性缺陷（即仅为细枝末节），则在派发重试之前，你 MUST 先判断再次尝试是否值得付出时间和上下文成本。
• 由细枝末节驱动的重试最多一次，且计入重试预算。如果再次评审仍只发现细枝末节，你 MUST 将目标标记为已完成（ACCEPTED），在最终摘要中报告尚未解决的问题，然后继续处理。如果分数低于 3.0，则适用无条件判定失败的规则。
• 你 MUST 保持严格，而非宽容。未达到目标就停止，必须是基于不存在真正违反要求的问题而做出的审慎决定。如果存在真实的阻塞问题，导致目标在最大重试次数内无法完成，则 MUST 报告目标失败，不得掩盖问题。
• 如果 STRICT_MODE 为 true，则本规则完全禁用：只有在 score >= 4.0 或达到最大重试次数时才停止。--strict 不会改变其他内容——4.0 目标分数、最大重试次数限制、< 3.0 无条件判定失败，以及元评审 / 评审派发均不受影响。

阶段 6：收集并总结结果

所有 Agent 完成后（按需进行重试），汇总结果：

## Parallel Execution Summary

### Configuration
- **Task:** {task description}
- **Models Used:** {tiers seen across all targets, e.g. "sonnet (3), opus (1), haiku (1)" — or `--model` override if the user passed one; see Results table for per-target detail}
- **Targets:** {count} items
- **Strict Mode:** {STRICT_MODE}

### Results

| Target | Grouping | Model | Judge Score | Retries | Status | Summary |
|--------|----------|-------|-------------|---------|--------|---------|
| {target_1} | {Repeatable/Shared/Independent} | {model} | {X.X}/5.0 | {0-3} | SUCCESS | {brief outcome} |
| {target_2} | {Repeatable/Shared/Independent} | {model} | {X.X}/5.0 | {0-3} | SUCCESS | {brief outcome} |
| {target_3} | {Repeatable/Shared/Independent} | {model} | {X.X}/5.0 | {3} | FAILED | {failure reason} |
| ... | ... | ... | ... | ... | ... | ... |

Status is `SUCCESS` (score >= 4.0), `ACCEPTED` (below target per the [Iteration Discretion Rule](#55-iteration-discretion-rule) — list the outstanding nitpicks in the Verification Summary), or `FAILED`.

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

### Overall Assessment
- **Completed:** {X}/{total}
- **Failed:** {Y}/{total}
- **Total Retries:** {sum of all retries}
- **Common patterns:** {any patterns across results}

### Verification Summary
{Aggregate judge verification results - any common issues?}

### Files Modified
- {list of all modified files}

### Failed Targets (If Any)
{For each failed target after max retries}
- **Target:** {name}
- **Final Score:** {X.X}/5.0
- **Persistent Issues:** {issues that weren't resolved}
- **Options:** Retry with guidance / Skip / Manual fix

### Next Steps
{If any failures, suggest remediation}

失败处理：

• 清楚报告失败的任务及错误详情
• 失败不会影响成功的任务
• 达到最大重试次数后，隔离失败的目标
• 提供选项：给出指导、跳过或手动修复

示例

示例 1：需求分组 —— 可重复 + 独立混合（含前一批次留下的更改）

场景：

一个团队先后运行两个并行批次。第一批更新 3 个端点文件中的 API 文档（src/api/users.ts、src/api/orders.ts、src/api/products.ts）。第二批为 src 文件夹中的全部 3 个模块添加测试，并在 GitHub Actions 中添加一个测试步骤。第二批中每个 Agent 的评审器都需要了解第一批的文档更改，以及同一批次中其他并行 Agent 预期进行的更改。

输入（第二批——第一批已在本次会话的较早阶段完成）：

/do-in-parallel add tests to all 3 modules in src folder and add tests step to github actions

编排器分析：

Phase 2: Task Analysis + Requirement Grouping

1. Task Identification:
   - Task A: "Add tests to src/modules/auth.ts"
   - Task B: "Add tests to src/modules/cart.ts"
   - Task C: "Add tests to src/modules/payments.ts"
   - Task D: "Add tests step to GitHub Actions CI pipeline"

2. Requirement Grouping:
   - Tasks A, B, C: REPEATABLE — same task ("add tests") applied to 3 different modules
     → ONE shared meta-judge producing a reusable spec
   - Task D: INDEPENDENT — different task type (CI configuration)
     → Separate meta-judge

3. Pre-existing and Expected Parallel Changes Assessment:
   - Pre-existing (from prior batch): API documentation updated across
     src/api/users.ts, src/api/orders.ts, src/api/products.ts
   - Expected parallel: Each agent should be aware that other agents in this
     batch are adding tests to other modules and updating GH Actions simultaneously

4. Agent Count:
   - Meta-judges: 2 (1 repeatable for tests + 1 independent for GH Actions)
   - Implementation agents: 4 (one per task, always isolated)
   - Judges: 4 (3 using shared test spec + 1 for GH Actions)
   - Total: 10 agents (vs. 12 without grouping)

阶段 3：模型选择

目标	分组	级别	原因
src/modules/auth.ts	可重复	opus	opus 当之无愧——即使任务本身“只是”添加测试，关键触发条件仍会因 auth 领域而触发；错误的测试可能掩盖真正的 auth 缺陷
src/modules/cart.ts	可重复	sonnet	按既有模式编写代码（生成测试）；cart.ts 不会触发关键领域条件
src/modules/payments.ts	可重复	opus	opus 当之无愧——关键触发条件因 payments 领域而触发
.github/workflows/ci.yml	独立	haiku	遵循现有流水线惯例，小幅、机械地添加一个 CI 步骤

尽管可重复组中的任务共用一份元评审器规范，但它们的级别并不相同：auth.ts 和 payments.ts 各自独立触发关键条件，而 cart.ts 不会。共享的元评审器本身以三项任务中的最高级别 opus 运行。

阶段 3.5：元评审器派发（2 个元评审器并行）：

[Meta-judge 1: Repeatable group — test generation]
Use Task tool:
  - description: "Meta-judge (repeatable): reusable spec for adding tests across 3 modules"
  - prompt:
    ## Task

    Generate a REUSABLE evaluation specification yaml that can be applied to
    ANY of the following targets performing the same task. You will produce
    rubrics, checklists, and scoring criteria that individual judge agents
    will each use independently to evaluate one target's implementation artifact.

    CLAUDE_PLUGIN_ROOT={CLAUDE_PLUGIN_ROOT}

    ## User Prompt as Context
    add tests to all 3 modules in src folder and add tests step to github actions

    ## Task Being Repeated
    Add comprehensive unit tests to a source module

    ## Targets in This Group
    - src/modules/auth.ts
    - src/modules/cart.ts
    - src/modules/payments.ts

    ## Context
    Project uses Jest for testing. Test files should be co-located as
    *.test.ts files. Existing test patterns available in src/modules/__tests__/.

    ## Artifact Type
    code

    ## Instructions
    CRITICAL: You are generating a REUSABLE spec that will be applied to
    EACH target independently by separate judges.
    - Use generic language: "target file should align with criteria" instead
      of "all files should align"
    - Do NOT include file-specific requirements (e.g., NOT "auth.ts should
      test only authentication logic") since this same spec will be applied
      to different files
    - The spec must be applicable to ANY target in this group without modification
    - Each judge will receive this same spec and evaluate only its own target
      against it
    User prompt is provided as context, you should use it only as reference
    of changes that can occur in the project by other agents.
    Return only the final evaluation specification YAML in your response.
  - model: opus
  - subagent_type: "sadd:meta-judge"

[Meta-judge 2: Independent — GitHub Actions]
Use Task tool:
  - description: "Meta-judge: add tests step to GitHub Actions"
  - prompt:
    ## Task

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

    CLAUDE_PLUGIN_ROOT={CLAUDE_PLUGIN_ROOT}

    ## User Prompt as Context
    add tests to all 3 modules in src folder and add tests step to github actions

    ## Target
    Add a test execution step to the GitHub Actions CI pipeline
    (.github/workflows/ci.yml or similar)

    ## Context
    Project uses Jest for testing. The CI pipeline should run tests after
    build step. Existing workflow file may need a new job or step.

    ## Artifact Type
    configuration

    ## Instructions
    User prompt is provided as context, you should use it only as reference
    of changes that can occur in the project by other agents. Generate
    evaluation specification ONLY for adding the tests step to GitHub Actions.
    Your report will be used to verify only this particular task, not the
    all tasks in the user prompt.
    Return only the final evaluation specification YAML in your response.
  - model: haiku
  - subagent_type: "sadd:meta-judge"

[Both meta-judges launched simultaneously]

阶段 5：实现派发（全部元评审器完成后，4 个 Agent 并行）：

[Implementation 1: auth module tests]
Use Task tool:
  - description: "Parallel: add tests to src/modules/auth.ts"
  - prompt:
    ## Reasoning Approach
    Let's think step by step.
    Before taking any action, think through the problem systematically:
    1. "Let me first understand what is being asked for this specific target..."
    2. "Let me analyze this specific target..."
    3. "Let me plan my approach..."
    Work through each step explicitly before implementing.

    <task>Add comprehensive unit tests</task>
    <target>src/modules/auth.ts</target>
    <constraints>
    - Work ONLY on the specified target
    - Do NOT modify other files unless explicitly required
    - Follow existing test patterns in the project
    </constraints>
    <output>
    Create test file for the auth module.
    CRITICAL: At the end of your work, provide a "Summary" section containing:
    - Files modified (full paths)
    - Key changes (3-5 bullet points)
    - Any decisions made and rationale
    </output>

    ## Self-Critique Verification (MANDATORY)
    [standard self-critique suffix]
  - model: opus  # opus is EARNED — critical trigger: auth.ts implements authentication logic

[Implementation 2: cart module tests]
Use Task tool:
  - description: "Parallel: add tests to src/modules/cart.ts"
  - prompt:
    ## Reasoning Approach
    Let's think step by step.
    Before taking any action, think through the problem systematically:
    1. "Let me first understand what is being asked for this specific target..."
    2. "Let me analyze this specific target..."
    3. "Let me plan my approach..."
    Work through each step explicitly before implementing.

    <task>Add comprehensive unit tests</task>
    <target>src/modules/cart.ts</target>
    <constraints>
    - Work ONLY on the specified target
    - Do NOT modify other files unless explicitly required
    - Follow existing test patterns in the project
    </constraints>
    <output>
    Create test file for the cart module.
    CRITICAL: At the end of your work, provide a "Summary" section containing:
    - Files modified (full paths)
    - Key changes (3-5 bullet points)
    - Any decisions made and rationale
    </output>

    ## Self-Critique Verification (MANDATORY)
    Before submitting, verify your work:
    1. Re-read the original task and confirm every requirement is addressed
    2. Check that all tests follow existing patterns in the project
    3. Verify no unrelated files were modified
    4. Confirm the Summary section is complete and accurate
  - model: sonnet

[Implementation 3: payments module tests]
Use Task tool:
  - description: "Parallel: add tests to src/modules/payments.ts"
  - prompt: [Same CoT prefix + task body for payments.ts + critique suffix]
  - model: opus  # opus is EARNED — critical trigger: payments.ts is the payments/billing domain

[Implementation 4: GitHub Actions test step]
Use Task tool:
  - description: "Parallel: add tests step to GitHub Actions CI"
  - prompt:
    ## Reasoning Approach
    Let's think step by step.
    Before taking any action, think through the problem systematically:
    1. "Let me first understand what is being asked for this specific target..."
    2. "Let me analyze this specific target..."
    3. "Let me plan my approach..."
    Work through each step explicitly before implementing.

    <task>Add a test execution step to the GitHub Actions CI pipeline</task>
    <target>.github/workflows/ci.yml</target>
    <constraints>
    - Work ONLY on the CI workflow file
    - Add a step that runs the test suite after the build step
    - Do NOT modify other workflow files or steps beyond what is necessary
    - Follow existing workflow patterns and conventions
    </constraints>
    <output>
    Update the CI workflow with a test execution step.
    CRITICAL: At the end of your work, provide a "Summary" section containing:
    - Files modified (full paths)
    - Key changes (3-5 bullet points)
    - Any decisions made and rationale
    </output>

    ## Self-Critique Verification (MANDATORY)
    Before submitting, verify your work:
    1. Re-read the original task and confirm every requirement is addressed
    2. Check that the workflow YAML is valid and well-structured
    3. Verify no unrelated workflow steps were modified
    4. Confirm the Summary section is complete and accurate
  - model: haiku

[All 4 launched simultaneously]

阶段 5.2：评审器派发（全部实现者完成后，4 个评审器并行）：

[Judge 1: auth module — uses SHARED reusable spec from repeatable meta-judge]
Use Task tool:
  - description: "Judge: src/modules/auth.ts"
  - prompt:
    You are evaluating an implementation artifact for target
    src/modules/auth.ts against an evaluation specification produced
    by the meta judge.

    CLAUDE_PLUGIN_ROOT={CLAUDE_PLUGIN_ROOT}

    ## User Prompt
    add tests to all 3 modules in src folder and add tests step to github actions

    ## Target
    src/modules/auth.ts

    ## Pre-existing and expected parallel changes (Context Only)

    The following changes were made before or expected to be done by
    other parallel agents in the same batch now. They are NOT part of
    the current implementation agent's output. Focus your evaluation
    on the current agent's changes to its specific target. Only verify
    other changed files/logic if they directly relate to the current
    target's task requirements.

    ### Previous do-in-parallel: "Update API documentation for all endpoints"
    The following files were modified as part of a previous parallel batch:
    - src/api/users.ts (modified) - Added JSDoc to public methods,
      updated module header
    - src/api/orders.ts (modified) - Added JSDoc to public methods,
      added @example tags
    - src/api/products.ts (modified) - Added JSDoc to public methods,
      updated type annotations

    ### Expected parallel changes (current batch)
    Other agents in this batch are simultaneously:
    - Adding tests to src/modules/cart.ts and src/modules/payments.ts
      (repeatable group — same task on other modules)
    - Adding a tests step to .github/workflows/ci.yml (independent task)

    ## Evaluation Specification
    ```yaml
    {EXACT reusable spec YAML from repeatable meta-judge — same for all 3 module judges}
    ```

    ## Implementation Output
    {Summary from auth implementation agent}

    ## Instructions
    User prompt is provided as context, you should use it only as reference
    of changes that can occur in the project by other agents. Evaluate ONLY
    the test generation for auth.ts.
    Follow your full judge process as defined in your agent instructions!

    ## Output
    CRITICAL: You must reply with this exact structured evaluation report
    format in YAML at the START of your response!
  - model: opus  # matches auth.ts's own implementation tier, not the group's shared meta-judge tier
  - subagent_type: "sadd:judge"

[Judge 2: cart module — uses SAME shared reusable spec]
Use Task tool:
  - description: "Judge: src/modules/cart.ts"
  - prompt: [Same judge template, same reusable spec YAML, cart implementation output.
    Pre-existing and expected parallel changes section: same prior batch info,
    expected parallel changes list auth.ts, payments.ts, and GH Actions instead]
  - model: sonnet  # matches cart.ts's own implementation tier
  - subagent_type: "sadd:judge"

[Judge 3: payments module — uses SAME shared reusable spec]
Use Task tool:
  - description: "Judge: src/modules/payments.ts"
  - prompt: [Same judge template, same reusable spec YAML, payments implementation output.
    Pre-existing and expected parallel changes section: same prior batch info,
    expected parallel changes list auth.ts, cart.ts, and GH Actions instead]
  - model: opus  # matches payments.ts's own implementation tier
  - subagent_type: "sadd:judge"

[Judge 4: GitHub Actions — uses INDEPENDENT spec from GH Actions meta-judge]
Use Task tool:
  - description: "Judge: GitHub Actions CI"
  - prompt:
    You are evaluating an implementation artifact for target
    .github/workflows/ci.yml against an evaluation specification produced
    by the meta judge.

    CLAUDE_PLUGIN_ROOT={CLAUDE_PLUGIN_ROOT}

    ## User Prompt
    add tests to all 3 modules in src folder and add tests step to github actions

    ## Target
    .github/workflows/ci.yml

    ## Pre-existing and expected parallel changes (Context Only)

    The following changes were made before or expected to be done by
    other parallel agents in the same batch now. They are NOT part of
    the current implementation agent's output. Focus your evaluation
    on the current agent's changes to its specific target. Only verify
    other changed files/logic if they directly relate to the current
    target's task requirements.

    ### Previous do-in-parallel: "Update API documentation for all endpoints"
    The following files were modified as part of a previous parallel batch:
    - src/api/users.ts (modified) - Added JSDoc to public methods,
      updated module header
    - src/api/orders.ts (modified) - Added JSDoc to public methods,
      added @example tags
    - src/api/products.ts (modified) - Added JSDoc to public methods,
      updated type annotations

    ### Expected parallel changes (current batch)
    Other agents in this batch are simultaneously:
    - Adding tests to src/modules/auth.ts, src/modules/cart.ts,
      and src/modules/payments.ts (repeatable group — test generation)

    ## Evaluation Specification
    ```yaml
    {EXACT spec YAML from independent GH Actions meta-judge}
    ```

    ## Implementation Output
    {Summary from GH Actions implementation agent}

    ## Instructions
    User prompt is provided as context, you should use it only as reference
    of changes that can occur in the project by other agents. Evaluate ONLY
    the GitHub Actions test step.
    Follow your full judge process as defined in your agent instructions!

    ## Output
    CRITICAL: You must reply with this exact structured evaluation report
    format in YAML at the START of your response!
  - model: haiku  # matches ci.yml's own implementation tier
  - subagent_type: "sadd:judge"

[All 4 judges launched simultaneously]

结果：

目标	分组	模型	评审分数	重试次数	状态
src/modules/auth.ts	可重复	opus	4.2/5.0	0	成功
src/modules/cart.ts	可重复	sonnet	4.0/5.0	0	成功
src/modules/payments.ts	可重复	opus	4.1/5.0	0	成功
.github/workflows/ci.yml	独立	haiku	4.3/5.0	0	成功

**总计：**4/4 项已完成。Agent 总数：10（2 个元评审器 + 4 个实现 Agent + 4 个评审器）

---

示例 2：需求分组——共享组 + 可重复组组合（存在用户预先修改）

场景：

开发者在对话期间一直在处理 Node.js 后端。他们重构了数据库连接层，并手动更新了多个服务模块，包括添加 S3 类接口。随后，他们调用 do-in-parallel 来实现和集成 S3 接口，并重构购物车模块。每个 Agent 的评审器都需要了解用户先前的修改，以及同一批次中其他并行 Agent 预期进行的更改。

输入：

/do-in-parallel I wrote class interface for S3 service in s3.adapter.ts, please do 2 tasks: implement s3 adapter with tests and integrate s3 adapter to analytics module. Also refactor and simplify all files in cart module

编排器分析：

Phase 2: Task Analysis + Requirement Grouping

1. Task Identification:
   - Task A: "Implement S3 adapter with tests in src/adapters/s3.adapter.ts"
   - Task B: "Integrate S3 adapter into src/modules/analytics.module.ts"
   - Task C: "Refactor and simplify src/modules/cart/cart.service.ts"
   - Task D: "Refactor and simplify src/modules/cart/cart.repository.ts"
   - Task E: "Refactor and simplify src/modules/cart/cart.controller.ts"

2. Requirement Grouping:
   - Tasks A, B: SHARED — interdependent (adapter must match interface consumed
     by analytics integration; should be reviewed together)
     → ONE combined meta-judge, ONE shared judge
   - Tasks C, D, E: REPEATABLE — same task ("refactor and simplify") applied
     to 3 different files in cart module
     → ONE reusable meta-judge

3. Pre-existing and Expected Parallel Changes Assessment:
   - Pre-existing (user modifications): Refactored database connection layer
     (src/db/connection.ts, src/db/queries.ts), updated service modules,
     and added S3 class interface in src/adapters/s3.adapter.ts
   - Expected parallel: S3 adapter implementation and analytics integration
     run in parallel (shared group); cart refactoring agents run in parallel
     (repeatable group); both groups run simultaneously

4. Agent Count:
   - Meta-judges: 2 (1 shared for S3 work + 1 repeatable for cart refactoring)
   - Implementation agents: 5 (one per task, always isolated)
   - Judges: 4 (1 shared for S3 group + 3 individual for cart)
   - Total: 11 agents (vs. 15 without grouping)

阶段 3：模型选择

目标	分组	层级	原因
src/adapters/s3.adapter.ts	共享组	opus	共享契约触发条件——其公共接口是任务 B 集成所依赖的契约
src/modules/analytics.module.ts	共享组	opus	共享契约触发条件——依赖配对任务中定义的适配器公共接口进行集成
src/modules/cart/cart.service.ts	可重复组	sonnet	重构仅限于单个文件，不更改契约
src/modules/cart/cart.repository.ts	可重复组	sonnet	重构仅限于单个文件，不更改契约
src/modules/cart/cart.controller.ts	可重复组	sonnet	重构仅限于单个文件，不更改契约

共享组使用 opus，因为任务 A 和任务 B 共用一个契约——分析集成所使用的 S3 适配器公共接口；选择规则 将其列为 opus 触发条件：“共享契约发生变化时，不受文件数量限制。”可重复组使用 sonnet，因为每个购物车文件都是独立重构的，没有契约变更。共享组的元评审器及其唯一评审器也使用 opus——角色配对的默认规则是，同一任务的三个角色使用相同层级；共享评审器的层级则为其负责的任务中当前实现层级的最高值（两个任务都使用 opus，因此一致）。

阶段 3.5：元评审器调度（2 个元评审器并行）：

[Meta-judge 1: Shared group — S3 adapter + integration]
Use Task tool:
  - description: "Meta-judge (shared): combined spec for S3 adapter and analytics integration"
  - prompt:
    ## Task

    Generate a COMBINED evaluation specification yaml that covers ALL of the
    following related tasks. These tasks are interdependent and will be
    reviewed TOGETHER by a single judge. You will produce rubrics, checklists,
    and scoring criteria that account for cross-task dependencies and
    integration points.

    CLAUDE_PLUGIN_ROOT={CLAUDE_PLUGIN_ROOT}

    ## User Prompt as Context
    I wrote class interface for S3 service in s3.adapter.ts, please do 2 tasks:
    implement s3 adapter with tests and integrate s3 adapter to analytics module.
    Also refactor and simplify all files in cart module

    ## Tasks in This Shared Group
    - Task A: Implement S3 adapter with tests -> src/adapters/s3.adapter.ts
    - Task B: Integrate S3 adapter into analytics module -> src/modules/analytics.module.ts

    ## Context
    The user has already written the class interface in s3.adapter.ts. Task A
    implements the interface methods and adds unit tests. Task B integrates the
    adapter into the analytics module. The adapter's public API from Task A must
    match what Task B consumes.

    ## Artifact Type
    code

    ## Instructions
    CRITICAL: You are generating a COMBINED spec for tasks that will be
    reviewed TOGETHER by ONE judge.
    - Include evaluation criteria for EACH individual task
    - Include cross-task verification criteria (e.g., "S3 adapter's public
      methods match the calls made by the analytics integration")
    - Organize the spec so the judge can identify which criteria apply to
      which task's changes
    - The judge will review ALL changes from ALL tasks in this group in a
      single evaluation
    User prompt is provided as context, you should use it only as reference
    of changes that can occur in the project by other agents.
    Return only the final evaluation specification YAML in your response.
  - model: opus
  - subagent_type: "sadd:meta-judge"

[Meta-judge 2: Repeatable group — cart refactoring]
Use Task tool:
  - description: "Meta-judge (repeatable): reusable spec for refactoring cart module files"
  - prompt:
    ## Task

    Generate a REUSABLE evaluation specification yaml that can be applied to
    ANY of the following targets performing the same task. You will produce
    rubrics, checklists, and scoring criteria that individual judge agents
    will each use independently to evaluate one target's implementation artifact.

    CLAUDE_PLUGIN_ROOT={CLAUDE_PLUGIN_ROOT}

    ## User Prompt as Context
    I wrote class interface for S3 service in s3.adapter.ts, please do 2 tasks:
    implement s3 adapter with tests and integrate s3 adapter to analytics module.
    Also refactor and simplify all files in cart module

    ## Task Being Repeated
    Refactor and simplify a source file in the cart module

    ## Targets in This Group
    - src/modules/cart/cart.service.ts
    - src/modules/cart/cart.repository.ts
    - src/modules/cart/cart.controller.ts

    ## Context
    All three files are in the cart module. Refactoring should simplify logic,
    reduce complexity, improve readability while preserving existing behavior.

    ## Artifact Type
    code

    ## Instructions
    CRITICAL: You are generating a REUSABLE spec that will be applied to
    EACH target independently by separate judges.
    - Use generic language: "target file should align with criteria" instead
      of "all files should align"
    - Do NOT include file-specific requirements since this same spec will be
      applied to different files
    - The spec must be applicable to ANY target in this group without modification
    User prompt is provided as context, you should use it only as reference
    of changes that can occur in the project by other agents.
    Return only the final evaluation specification YAML in your response.
  - model: sonnet
  - subagent_type: "sadd:meta-judge"

[Both meta-judges launched simultaneously]

阶段 5：实现调度（元评审器完成后，5 个 Agent 并行）：

[Implementation 1: S3 adapter]
Use Task tool:
  - description: "Parallel: implement S3 adapter with tests"
  - prompt:
    ## Reasoning Approach
    Let's think step by step.
    Before taking any action, think through the problem systematically:
    1. "Let me first understand what is being asked for this specific target..."
    2. "Let me analyze this specific target..."
    3. "Let me plan my approach..."
    Work through each step explicitly before implementing.

    <task>Implement S3 adapter with tests based on the existing class interface</task>
    <target>src/adapters/s3.adapter.ts</target>
    <constraints>
    - Work ONLY on the specified target
    - Implement all methods defined in the existing class interface
    - Add comprehensive unit tests
    - Do NOT modify the analytics module
    </constraints>
    <output>
    Implement the S3 adapter and create tests.
    CRITICAL: At the end of your work, provide a "Summary" section containing:
    - Files modified (full paths)
    - Key changes (3-5 bullet points)
    - Any decisions made and rationale
    </output>

    ## Self-Critique Verification (MANDATORY)
    Before submitting, verify your work:
    1. Re-read the original task and confirm every requirement is addressed
    2. Check that the adapter implements all interface methods correctly
    3. Verify no unrelated files were modified
    4. Confirm the Summary section is complete and accurate
  - model: opus

[Implementation 2: Analytics integration]
Use Task tool:
  - description: "Parallel: integrate S3 adapter into analytics module"
  - prompt:
    ## Reasoning Approach
    [standard CoT prefix]

    <task>Integrate S3 adapter into the analytics module</task>
    <target>src/modules/analytics.module.ts</target>
    <constraints>
    - Work ONLY on the specified target
    - Import and use the S3 adapter from src/adapters/s3.adapter.ts
    - Follow existing dependency injection patterns
    - Do NOT modify the S3 adapter itself
    </constraints>
    <output>
    Integrate S3 adapter into analytics module.
    CRITICAL: At the end of your work, provide a "Summary" section.
    </output>

    ## Self-Critique Verification (MANDATORY)
    [standard self-critique suffix]
  - model: opus

[Implementation 3: cart.service.ts refactoring]
Use Task tool:
  - description: "Parallel: refactor src/modules/cart/cart.service.ts"
  - prompt:
    ## Reasoning Approach
    Let's think step by step.
    Before taking any action, think through the problem systematically:
    1. "Let me first understand what is being asked for this specific target..."
    2. "Let me analyze this specific target..."
    3. "Let me plan my approach..."
    Work through each step explicitly before implementing.

    <task>Refactor and simplify the cart service</task>
    <target>src/modules/cart/cart.service.ts</target>
    <constraints>
    - Work ONLY on the specified target
    - Simplify logic, reduce complexity, improve readability
    - Preserve existing behavior — no functional changes
    - Do NOT modify other cart module files
    </constraints>
    <output>
    Refactor the cart service file.
    CRITICAL: At the end of your work, provide a "Summary" section containing:
    - Files modified (full paths)
    - Key changes (3-5 bullet points)
    - Any decisions made and rationale
    </output>

    ## Self-Critique Verification (MANDATORY)
    Before submitting, verify your work:
    1. Re-read the original task and confirm every requirement is addressed
    2. Check that existing behavior is preserved after refactoring
    3. Verify no unrelated files were modified
    4. Confirm the Summary section is complete and accurate
  - model: sonnet

[Implementation 4: cart.repository.ts refactoring]
Use Task tool:
  - description: "Parallel: refactor src/modules/cart/cart.repository.ts"
  - prompt: [Same CoT prefix + refactoring task body for cart.repository.ts + critique suffix]
  - model: sonnet

[Implementation 5: cart.controller.ts refactoring]
Use Task tool:
  - description: "Parallel: refactor src/modules/cart/cart.controller.ts"
  - prompt: [Same CoT prefix + refactoring task body for cart.controller.ts + critique suffix]
  - model: sonnet

[All 5 launched simultaneously]

阶段 5.2：评审器调度（所有实现者完成后，4 个评审器并行）：

[Judge 1: SHARED judge for S3 group — reviews both S3 adapter + analytics integration]
Use Task tool:
  - description: "Judge (shared): S3 adapter implementation and analytics integration"
  - prompt:
    You are evaluating implementation artifacts for a group of related tasks
    against a combined evaluation specification produced by the meta judge.
    These tasks are interdependent and must be reviewed together.

    CLAUDE_PLUGIN_ROOT={CLAUDE_PLUGIN_ROOT}

    ## User Prompt
    I wrote class interface for S3 service in s3.adapter.ts, please do 2 tasks:
    implement s3 adapter with tests and integrate s3 adapter to analytics module.
    Also refactor and simplify all files in cart module

    ## Tasks in This Shared Group
    - Task A: Implement S3 adapter with tests -> src/adapters/s3.adapter.ts
    - Task B: Integrate S3 adapter into analytics module -> src/modules/analytics.module.ts

    ## Pre-existing and expected parallel changes (Context Only)

    The following changes were made before or expected to be done by
    other parallel agents in the same batch now. They are NOT part of
    the current implementation agents' output for this shared group.
    Focus your evaluation on the S3 group's changes. Only verify other
    changed files/logic if they directly relate to these tasks.

    ### User modifications (before current task)
    The user made changes to the following files/modules before this
    task was started:
    - src/db/connection.ts (modified) - Refactored database connection
      pooling
    - src/db/queries.ts (modified) - Updated query builder patterns
    - src/adapters/s3.adapter.ts (created) - Added S3 class interface
      (the interface that Task A implements)
    - Several service modules updated to use new DB connection API

    ### Expected parallel changes (current batch)
    Other agents in this batch are simultaneously:
    - Refactoring src/modules/cart/cart.service.ts (repeatable group)
    - Refactoring src/modules/cart/cart.repository.ts (repeatable group)
    - Refactoring src/modules/cart/cart.controller.ts (repeatable group)

    ## Evaluation Specification
    ```yaml
    {EXACT combined spec YAML from shared S3 meta-judge}
    ```

    ## Implementation Outputs
    ### Task: Implement S3 adapter with tests -> src/adapters/s3.adapter.ts
    {Summary from S3 adapter implementation agent}
    Files: src/adapters/s3.adapter.ts (modified), src/adapters/s3.adapter.test.ts (created)

    ### Task: Integrate S3 adapter into analytics -> src/modules/analytics.module.ts
    {Summary from analytics integration agent}
    Files: src/modules/analytics.module.ts (modified)

    ## Instructions
    User prompt is provided as context, you should use it only as reference
    of changes that can occur in the project by other agents. Evaluate ALL
    tasks in this shared group together. Verify cross-task integration points
    (e.g., does the adapter's public API match what the analytics module consumes?).
    CRITICAL: For each task, indicate separately whether it PASSED or FAILED
    so that only failing tasks can be retried.
    Follow your full judge process as defined in your agent instructions!

    ## Output
    CRITICAL: You must reply with this exact structured evaluation report
    format in YAML at the START of your response! Include per-task verdicts.
  - model: opus  # HIGHEST current implementation tier among Task A and Task B (both opus)
  - subagent_type: "sadd:judge"

[Judge 2: cart.service.ts — uses SHARED reusable spec from repeatable meta-judge]
Use Task tool:
  - description: "Judge: src/modules/cart/cart.service.ts"
  - prompt:
    You are evaluating an implementation artifact for target
    src/modules/cart/cart.service.ts against an evaluation specification
    produced by the meta judge.

    CLAUDE_PLUGIN_ROOT={CLAUDE_PLUGIN_ROOT}

    ## User Prompt
    [original user prompt]

    ## Target
    src/modules/cart/cart.service.ts

    ## Pre-existing and expected parallel changes (Context Only)

    The following changes were made before or expected to be done by
    other parallel agents in the same batch now. They are NOT part of
    the current implementation agent's output. Focus your evaluation
    on the current agent's changes to its specific target. Only verify
    other changed files/logic if they directly relate to the current
    target's task requirements.

    ### User modifications (before current task)
    The user made changes to the following files/modules before this
    task was started:
    - src/db/connection.ts (modified) - Refactored database connection
      pooling
    - src/db/queries.ts (modified) - Updated query builder patterns
    - src/adapters/s3.adapter.ts (created) - Added S3 class interface
    - Several service modules updated to use new DB connection API

    ### Expected parallel changes (current batch)
    Other agents in this batch are simultaneously:
    - Implementing S3 adapter in src/adapters/s3.adapter.ts (shared group)
    - Integrating S3 adapter into src/modules/analytics.module.ts (shared group)
    - Refactoring src/modules/cart/cart.repository.ts (repeatable group)
    - Refactoring src/modules/cart/cart.controller.ts (repeatable group)

    ## Evaluation Specification
    ```yaml
    {EXACT reusable spec YAML from repeatable cart meta-judge — same for all 3 cart judges}
    ```

    ## Implementation Output
    {Summary from cart.service.ts implementation agent}

    ## Instructions
    User prompt is provided as context, you should use it only as reference
    of changes that can occur in the project by other agents. Evaluate ONLY
    the refactoring of cart.service.ts.
    Follow your full judge process as defined in your agent instructions!

    ## Output
    CRITICAL: You must reply with this exact structured evaluation report
    format in YAML at the START of your response!
  - model: sonnet  # matches cart.service.ts's own implementation tier
  - subagent_type: "sadd:judge"

[Judge 3: cart.repository.ts — uses SAME shared reusable spec]
Use Task tool:
  - description: "Judge: src/modules/cart/cart.repository.ts"
  - prompt: [Same judge template, same reusable spec YAML, cart.repository implementation output.
    Pre-existing and expected parallel changes section: same user modifications,
    expected parallel changes list S3 group, cart.service.ts, and cart.controller.ts instead]
  - model: sonnet  # matches cart.repository.ts's own implementation tier
  - subagent_type: "sadd:judge"

[Judge 4: cart.controller.ts — uses SAME shared reusable spec]
Use Task tool:
  - description: "Judge: src/modules/cart/cart.controller.ts"
  - prompt: [Same judge template, same reusable spec YAML, cart.controller implementation output.
    Pre-existing and expected parallel changes section: same user modifications,
    expected parallel changes list S3 group, cart.service.ts, and cart.repository.ts instead]
  - model: sonnet  # matches cart.controller.ts's own implementation tier
  - subagent_type: "sadd:judge"

[All 4 judges launched simultaneously]

可重复组重试场景（如果 cart.controller.ts 评审器发现问题）——展示重试时的模型升级：

Judge 4 Verdict (cart.controller.ts):
  FAIL, SCORE: 2.6/5.0
  ISSUES: The refactor introduced a circular import between
  cart.controller.ts and cart.service.ts — the implementation agent
  misunderstood the module's dependency direction, not a narrow,
  fixable nitpick (Escalation trigger 1: low first-attempt quality)

Retry Decision (per Model Escalation on Retry):
  → cart.controller.ts FAILED on a misunderstanding, not a fixable nitpick — bump ONE tier: sonnet -> opus
  → Re-launch ONLY the cart.controller.ts implementation agent, now at opus, with the judge's feedback
  → Re-launch ONLY the cart.controller.ts judge, now at opus, to re-evaluate
  → cart.service.ts and cart.repository.ts are untouched — their sonnet tier, their judges, and their PASS verdicts stand; escalation is scoped to cart.controller.ts alone, never the whole repeatable group

结果：

目标	分组	模型	评审分数	重试次数	状态
src/adapters/s3.adapter.ts	共享组	opus	4.2/5.0	0	成功
src/modules/analytics.module.ts	共享组	opus	4.4/5.0	0	成功
src/modules/cart/cart.service.ts	可重复组	sonnet	4.0/5.0	0	成功
src/modules/cart/cart.repository.ts	可重复组	sonnet	4.3/5.0	0	成功
src/modules/cart/cart.controller.ts	可重复组	sonnet → opus	4.1/5.0	1	成功

总体： 5/5 项已完成。Agent 总数：13（2 个元评审器 + 5 个实现 Agent + 4 个评审器 + 1 个重试实现 Agent + 1 个重试评审器）

---

示例 3：需求分组——全部独立

输入：

/do-in-parallel write tests for loan.service.ts, add password recovery feature to auth module and enable caching during dependency loading in github actions.

编排器分析：

Phase 2: Task Analysis + Requirement Grouping

1. Task Identification:
   - Task A: "Write tests for src/services/loan.service.ts"
   - Task B: "Add password recovery feature to src/modules/auth/"
   - Task C: "Enable caching during dependency loading in .github/workflows/ci.yml"

2. Requirement Grouping:
   - Task A: INDEPENDENT — test generation for a specific service
   - Task B: INDEPENDENT — new feature in auth module (unrelated to tasks A and C)
   - Task C: INDEPENDENT — CI configuration change (unrelated to tasks A and B)
   - No grouping possible: all 3 tasks are different task types on different targets

3. Agent Count:
   - Meta-judges: 3 (one per task — standard flow)
   - Implementation agents: 3 (one per task)
   - Judges: 3 (one per task)
   - Total: 9 agents (no reduction possible)

阶段 3：模型选择

目标	层级	理由
src/services/loan.service.ts	sonnet	按既有模式编写测试；单独生成测试不会触发关键触发条件
src/modules/auth/	opus	opus 是当之无愧的选择——auth 域会触发关键触发条件（密码重置令牌的签发与验证）
.github/workflows/ci.yml	haiku	使用标准 GitHub Action 更改小型、机械式的缓存配置；无需编写逻辑

阶段 3.5：分派 Meta-Judge（3 个 Meta-Judge 并行）：

[Meta-judge 1: Independent — loan service tests]
Use Task tool:
  - description: "Meta-judge: write tests for loan.service.ts"
  - prompt:
    ## Task

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

    CLAUDE_PLUGIN_ROOT={CLAUDE_PLUGIN_ROOT}

    ## User Prompt as Context
    write tests for loan.service.ts, add password recovery feature to auth
    module and enable caching during dependency loading in github actions.

    ## Target
    Write comprehensive unit tests for src/services/loan.service.ts

    ## Context
    Project uses Jest. Tests should cover all public methods, edge cases,
    and error scenarios for the loan service.

    ## Artifact Type
    code

    ## Instructions
    User prompt is provided as context, you should use it only as reference
    of changes that can occur in the project by other agents. Generate
    evaluation specification ONLY for the loan service test generation.
    Your report will be used to verify only this particular task, not the
    all tasks in the user prompt.
    Return only the final evaluation specification YAML in your response.
  - model: sonnet
  - subagent_type: "sadd:meta-judge"

[Meta-judge 2: Independent — password recovery feature]
Use Task tool:
  - description: "Meta-judge: add password recovery to auth module"
  - prompt:
    ## Task

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

    CLAUDE_PLUGIN_ROOT={CLAUDE_PLUGIN_ROOT}

    ## User Prompt as Context
    write tests for loan.service.ts, add password recovery feature to auth
    module and enable caching during dependency loading in github actions.

    ## Target
    Add password recovery feature to src/modules/auth/ (password reset flow:
    request, token generation, validation, password update)

    ## Context
    Auth module handles authentication. Password recovery requires new
    endpoints, email integration, token management.

    ## Artifact Type
    code

    ## Instructions
    User prompt is provided as context, you should use it only as reference
    of changes that can occur in the project by other agents. Generate
    evaluation specification ONLY for the password recovery feature.
    Your report will be used to verify only this particular task, not the
    all tasks in the user prompt.
    Return only the final evaluation specification YAML in your response.
  - model: opus
  - subagent_type: "sadd:meta-judge"

[Meta-judge 3: Independent — GH Actions caching]
Use Task tool:
  - description: "Meta-judge: enable dependency caching in GitHub Actions"
  - prompt:
    ## Task

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

    CLAUDE_PLUGIN_ROOT={CLAUDE_PLUGIN_ROOT}

    ## User Prompt as Context
    write tests for loan.service.ts, add password recovery feature to auth
    module and enable caching during dependency loading in github actions.

    ## Target
    Enable caching during dependency loading in .github/workflows/ci.yml
    (e.g., npm/yarn cache, actions/cache)

    ## Context
    GitHub Actions CI pipeline. Dependency installation step should use
    caching to speed up builds.

    ## Artifact Type
    configuration

    ## Instructions
    User prompt is provided as context, you should use it only as reference
    of changes that can occur in the project by other agents. Generate
    evaluation specification ONLY for enabling dependency caching in GH Actions.
    Your report will be used to verify only this particular task, not the
    all tasks in the user prompt.
    Return only the final evaluation specification YAML in your response.
  - model: haiku
  - subagent_type: "sadd:meta-judge"

[All 3 meta-judges launched simultaneously]

阶段 5：实现分派（Meta-Judge 完成后，3 个 Agent 并行）：

[Implementation 1: loan service tests]
Use Task tool:
  - description: "Parallel: write tests for loan.service.ts"
  - prompt:
    ## Reasoning Approach
    Let's think step by step.
    Before taking any action, think through the problem systematically:
    1. "Let me first understand what is being asked for this specific target..."
    2. "Let me analyze this specific target..."
    3. "Let me plan my approach..."
    Work through each step explicitly before implementing.

    <task>Write comprehensive unit tests for the loan service</task>
    <target>src/services/loan.service.ts</target>
    <constraints>
    - Work ONLY on the specified target
    - Create test file co-located with the service
    - Cover all public methods, edge cases, and error scenarios
    - Follow existing test patterns in the project
    </constraints>
    <output>
    Create test file for the loan service.
    CRITICAL: At the end of your work, provide a "Summary" section containing:
    - Files modified (full paths)
    - Key changes (3-5 bullet points)
    - Any decisions made and rationale
    </output>

    ## Self-Critique Verification (MANDATORY)
    Before submitting, verify your work:
    1. Re-read the original task and confirm every requirement is addressed
    2. Check that all tests follow existing patterns in the project
    3. Verify no unrelated files were modified
    4. Confirm the Summary section is complete and accurate
  - model: sonnet

[Implementation 2: password recovery]
Use Task tool:
  - description: "Parallel: add password recovery feature to auth module"
  - prompt:
    ## Reasoning Approach
    [standard CoT prefix]

    <task>Add password recovery feature to the auth module</task>
    <target>src/modules/auth/</target>
    <constraints>
    - Work ONLY on the auth module
    - Implement password reset request, token generation, validation,
      and password update
    - Follow existing auth module patterns
    - Do NOT modify unrelated modules
    </constraints>
    <output>
    Implement password recovery feature.
    CRITICAL: At the end of your work, provide a "Summary" section.
    </output>

    ## Self-Critique Verification (MANDATORY)
    [standard self-critique suffix]
  - model: opus

[Implementation 3: GH Actions caching]
Use Task tool:
  - description: "Parallel: enable dependency caching in GitHub Actions"
  - prompt:
    ## Reasoning Approach
    [standard CoT prefix]

    <task>Enable caching during dependency loading in CI pipeline</task>
    <target>.github/workflows/ci.yml</target>
    <constraints>
    - Work ONLY on the CI workflow file
    - Add dependency caching (npm/yarn cache or actions/cache)
    - Do NOT modify other workflow steps beyond what is necessary
    </constraints>
    <output>
    Update CI workflow with dependency caching.
    CRITICAL: At the end of your work, provide a "Summary" section.
    </output>

    ## Self-Critique Verification (MANDATORY)
    [standard self-critique suffix]
  - model: haiku

[All 3 launched simultaneously]

阶段 5.2：分派 Judge（所有实现者完成后，3 个 Judge 并行）：

[Judge 1: loan service tests — independent spec]
Use Task tool:
  - description: "Judge: loan.service.ts tests"
  - prompt:
    You are evaluating an implementation artifact for target
    src/services/loan.service.ts against an evaluation specification
    produced by the meta judge.

    CLAUDE_PLUGIN_ROOT={CLAUDE_PLUGIN_ROOT}

    ## User Prompt
    write tests for loan.service.ts, add password recovery feature to auth
    module and enable caching during dependency loading in github actions.

    ## Target
    src/services/loan.service.ts

    ## Evaluation Specification
    ```yaml
    {EXACT spec YAML from loan service meta-judge}
    ```

    ## Implementation Output
    {Summary from loan service test implementation agent}

    ## Instructions
    User prompt is provided as context, you should use it only as reference
    of changes that can occur in the project by other agents. Evaluate ONLY
    the test generation for loan.service.ts.
    Follow your full judge process as defined in your agent instructions!

    ## Output
    CRITICAL: You must reply with this exact structured evaluation report
    format in YAML at the START of your response!
  - model: sonnet
  - subagent_type: "sadd:judge"

[Judge 2: password recovery — independent spec]
Use Task tool:
  - description: "Judge: auth password recovery"
  - prompt:
    You are evaluating an implementation artifact for target
    src/modules/auth/ against an evaluation specification produced
    by the meta judge.

    CLAUDE_PLUGIN_ROOT={CLAUDE_PLUGIN_ROOT}

    ## User Prompt
    [original user prompt]

    ## Target
    src/modules/auth/ (password recovery feature)

    ## Evaluation Specification
    ```yaml
    {EXACT spec YAML from password recovery meta-judge}
    ```

    ## Implementation Output
    {Summary from password recovery implementation agent}

    ## Instructions
    User prompt is provided as context, you should use it only as reference
    of changes that can occur in the project by other agents. Evaluate ONLY
    the password recovery feature.
    Follow your full judge process as defined in your agent instructions!

    ## Output
    CRITICAL: You must reply with this exact structured evaluation report
    format in YAML at the START of your response!
  - model: opus
  - subagent_type: "sadd:judge"

[Judge 3: GH Actions caching — independent spec]
Use Task tool:
  - description: "Judge: GitHub Actions dependency caching"
  - prompt:
    You are evaluating an implementation artifact for target
    .github/workflows/ci.yml against an evaluation specification produced
    by the meta judge.

    CLAUDE_PLUGIN_ROOT={CLAUDE_PLUGIN_ROOT}

    ## User Prompt
    [original user prompt]

    ## Target
    .github/workflows/ci.yml (dependency caching)

    ## Evaluation Specification
    ```yaml
    {EXACT spec YAML from GH Actions caching meta-judge}
    ```

    ## Implementation Output
    {Summary from GH Actions caching implementation agent}

    ## Instructions
    User prompt is provided as context, you should use it only as reference
    of changes that can occur in the project by other agents. Evaluate ONLY
    the dependency caching in GitHub Actions.
    Follow your full judge process as defined in your agent instructions!

    ## Output
    CRITICAL: You must reply with this exact structured evaluation report
    format in YAML at the START of your response!
  - model: haiku
  - subagent_type: "sadd:judge"

[All 3 judges launched simultaneously]

结果：

目标	分组	模型	Judge 评分	重试次数	状态
src/services/loan.service.ts	独立	sonnet	4.1/5.0	0	成功
src/modules/auth/	独立	opus	4.3/5.0	0	成功
.github/workflows/ci.yml	独立	haiku	4.0/5.0	0	成功

**总体：**3/3 项已完成。Agent 总数：9（3 个 Meta-Judge + 3 个实现 Agent + 3 个 Judge）。对于完全独立的任务，无法进一步减少分组。

最佳实践

目标选择

• **具体明确：**尽可能列出确切的文件
• **谨慎使用 glob：**确认前先检查展开后的列表
• **限制范围：**每批最多 10–15 个目标，以便于管理
• **按相似性分组：**相似目标可从一致的模式中受益

模型选择指南

仅供快速参考的示例——模型选择策略具有权威性；如果某种情况无法直接对应下方的内容，请遵循选择规则表，而不是此列表。

场景	层级	原因
安全关键逻辑（身份验证、支付、数据完整性）	opus	关键触发条件——无论任务大小，均当之无愧
多文件重构或共享契约更改	opus	复杂触发条件——涉及多个文件或契约更改
限于单个文件且不更改契约的重构	sonnet	基于既有模式的单模块更改
文档生成	haiku	机械式任务，无代码或跨文件推理
代码审查或按文件生成测试	sonnet	能力均衡，遵循既有模式

Meta-Judge + Judge 验证

• 先进行需求分组——分派任何 Meta-Judge 之前，分析任务是否属于可重复、共享或独立分组，以尽量减少 Agent 总数
• 每个分组或独立任务对应一个 Meta-Judge——可重复分组共用一份可复用规范，共享分组共用一份合并规范，独立任务各自使用一份规范
• 先批量运行 Meta-Judge——并行启动所有 Meta-Judge（无论分组类型），然后启动实现者
• 重试时复用规范——每个分组/目标的评估规范在重试期间保持不变；只有实现会发生变化
• 仅解析 Judge 的标头——不要阅读完整报告，以避免上下文受到干扰
• 包含 CLAUDE_PLUGIN_ROOT——Meta-Judge 和 Judge 都需要已解析的插件根路径
• 按目标提供 YAML——仅将相关的 Meta-Judge YAML 传给对应的 Judge，不要向其中添加任何额外文本或注释！
• 共享分组的重试——只重新启动特定的失败实现 Agent，而不是整个分组

评审者选择

根据 角色配对，评审者层级与实现层级并非相互独立——默认情况下，两者层级相同。不存在由 opus 评审 haiku 层级任务的情况；强化（见角色配对表）只能提升共同的标准制定者（元评审者），不能只提升评审者。

实现层级	评审者层级	原因
opus	opus	产出者和评估者可以使用相同层级
sonnet	sonnet	产出者和评估者可以使用相同层级
haiku	haiku	产出者和评估者可以使用相同层级

**指南：**请参阅角色配对。

上下文隔离

• **最少上下文：**每个子 Agent 只获取所需信息
• **不交叉引用：**不要告诉 Agent A Agent B 的目标
• **让它们自行发现：**子 Agent 通过读取文件了解模式
• **以文件系统为准：**通过文件系统协调更改
• 跟踪已有更改——向每个 Agent 的评审者提供先前修改的上下文，避免混淆已有更改与当前更改的归属

质量保证

• **三层验证：**自我批评（内部）+ 目标专属元评审规范（结构化）+ 评审者（外部）
• **先自我批评：**实现 Agent 在提交前验证自己的工作
• **目标专属元评审规范：**为每个目标量身定制评分标准，考虑其独特特性，从而制定更精确的评估标准
• **后由外部评审者评审：**独立评审者机械地应用目标专属元评审规范，发现自我批评未能发现的盲点
• **迭代循环：**根据反馈重试，直到通过或达到最大重试次数
• **适度迭代：**遵循迭代酌情规则——由细枝末节驱动的重试最多一次，分数绝不低于 3.0，使用 --strict 时禁用
• **失败隔离：**一个目标失败不会影响其他目标
• **检查摘要：**查看是否有失败或部分完成的项目
• **之后运行测试：**并行更改可能会产生细微的相互影响
• **原子提交：**一批次中的所有更改 = 一次提交

错误处理

失败类型	描述	恢复操作
可恢复	评审者发现问题，且仍可重试	根据评审者反馈重试（每个目标最多 3 次），并遵循迭代酌情规则
方案失败	此目标的方案有误	提供选项并上报用户
基础问题	需求不明确或无法实现	上报用户以获取澄清
超过最大重试次数	目标在重试 3 次后仍失败	标记为失败，继续处理其他目标，并在最后报告

重要规则：

• 绝不在未经用户输入的情况下超过最大重试次数继续执行
• 绝不在未解决评审者指出的问题时尝试“向前修复”
• 绝不跳过评审者验证
• 如果缺少上下文，立即停止并报告（不要猜测）
• 隔离失败——一个目标失败不会导致其他目标停止