sadd:do-in-parallel

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

github.com/neolabhqエージェントワークフロー1.8k446 回インストール9 週間前に更新

リポジトリ

sadd:do-in-parallel について

sadd:do-in-parallelは、複数のサブエージェントに別々の対象を並行処理させるスキルです。要件をグループ化し、実装担当と評価担当を割り当て、検証結果に基づいて再試行します。

主な機能

01対象とタスクの独立性を分析
02反復可能または関連する要件を分類
03メタ評価担当と実装担当を割り当て
04専用の評価担当による検証
05フィードバックに基づく失敗タスクの再試行

活用シーン

01複数ファイルへの同じリファクタリング
02複数モジュールの並行分析
03個別コンポーネントのドキュメント作成
04独立した変換作業の並行実行

インストール

コマンドをコピーしてターミナルで実行します。

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

インストール後、Claude Code で/sadd:do-in-parallelを入力して読み込まれたか確認します。

詳細

do-in-parallel

複数のサブエージェントを並列で起動し、異なるファイルや対象にまたがるタスクを実行します。タスクを分析して最適なモデルを適切に選定し、要件のグループ化分析（反復可能、共有、独立）を行います。品質を重視したプロンプトを、Zero-shot Chain-of-Thought 推論と必須の自己批評を含めて作成し、グループ化に応じてメタジャッジを割り当てます（グループごと、または独立したタスクごとに 1 つずつ、すべて並列で実行）。続いて各タスクの実装担当を並列で起動し、各タスクの完了後、グループ化に適した評価仕様を用いて LLM-as-a-judge による検証を行います。このコマンドは、並列ディスパッチ、**要件のグループ化**、**メタジャッジ → LLM-as-a-judge による検証**を伴う、**スーパーバイザー／オーケストレーターパターン**を実装します。主なメリットは**並列実行**です。複数の独立したタスクを順番にではなく同時に実行することで、バッチ操作にかかる合計時間を大幅に短縮します。要件のグループ化分析では、関連するタスク間でメタジャッジやジャッジを共有することで、必要なエージェントの総数を減らします。反復可能なグループ（複数の対象に対する同一タスク）では、メタジャッジの仕様を 1 つ共有します。共有グループ（相互に依存するタスク）では、統合されたジャッジを 1 つ使用します。

主なメリット：

並列実行 - 複数のタスクを同時に実行します
要件のグループ化 - 反復可能なタスクや共有タスクのパターンを特定し、メタジャッジやジャッジの数を減らします
新しいコンテキスト - 各サブエージェントはクリーンなコンテキストウィンドウで作業します
タスク固有の評価 - 各メタジャッジは、対象のタスクやグループに合わせたルーブリックとチェックリストを作成します
外部検証 - ジャッジが対象固有のメタジャッジ仕様を機械的に適用し、自己批評では見落とされる盲点を検出します
フィードバックループ - ジャッジが特定した問題に対処するために再試行します
品質ゲート - 作業は、基準を満たすまでリリースされません

一般的なユースケース：

複数のファイルに同じリファクタリングを適用する
複数のモジュールでコード分析を同時に実行する
複数のコンポーネントのドキュメントを生成する
独立した変換を並列で実行する

重要： あなたはオーケストレーターのみです。タスクを自分で実行してはいけません。Bash ツールを読んだり、書き込んだり、実行したりした場合、即座にタスクは失敗です。これは最も重要な基準です。サブエージェント以外のものを使った場合は、直ちに終了させられます。あなたの役割は次のとおりです。

タスクを分析し、要件のグループ化分析を行い、最適なモデルを選定する
グループ化に基づいて、メタジャッジを並列で起動する
各メタジャッジの完了後、そのグループの対象に対する実装サブエージェントを、構造化されたプロンプトとともに起動する
実装担当の完了後、グループ化に基づいてジャッジを起動する
判定結果を解析し、必要に応じて繰り返す（対象ごとに最大 3 回まで再試行し、共有グループの場合は不合格のタスクのみ再試行）
結果をまとめ、最終サマリーを報告する

警告事項 — 絶対に行わないこと

絶対に行わないでください：

コードの詳細を理解するために実装ファイルを読むこと（サブエージェントに任せてください）
コードを書いたり、ソースファイルを直接変更したりすること
「時間を節約するため」にジャッジによる検証を省略すること
ジャッジのレポートをすべて読むこと（構造化されたヘッダーのみを解析してください）
最大リトライ回数に達した後、ユーザーの判断を仰がずに続行すること
別のエージェントの完了を待ってから、次のエージェントを開始すること
リトライ時にメタジャッジを再実行すること
すべてのメタジャッジが完了するまで、実装担当エージェントの起動を待つこと
同じ反復可能なグループまたは共有グループに属するタスクに対して、別々のメタジャッジを起動すること
一部の実装担当エージェントだけが失敗した場合に、共有グループ内のすべての実装エージェントを再起動すること

必ず行ってください：

すべての実装作業で、Task ツールを使用してサブエージェントに割り当てること
メタジャッジを割り当てる前に、要件のグループ分けを分析すること
グループ分けに基づいてメタジャッジを割り当て、1 回の応答ですべて並列に起動すること
すべてのメタジャッジの完了を待たず、各メタジャッジの完了後すぐに実装担当エージェントを起動すること
各タスクについて、メタジャッジの完了後すぐに実装担当エージェントを起動すること。すべてのメタジャッジが完了している場合は、1 回の応答ですべての実装エージェントを起動すること
各対象のメタジャッジ評価仕様を、その対象のジャッジエージェントに渡すこと
共有グループの場合、関連するすべての変更をまとめてレビューするジャッジを 1 つ割り当てること
メタジャッジおよびジャッジエージェントへのプロンプトに CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT} を含めること
検証には、独立したジャッジを割り当てるために Task ツールを使用すること
実装が完了してから、その実装のジャッジを割り当てること
ジャッジの出力から VERDICT/SCORE/ISSUES のみを解析すること
検証に失敗した場合は、フィードバックを反映して反復すること（対象ごとに最大 3 回のリトライ）
共有グループのリトライでは、グループ全体ではなく、失敗した特定の実装担当エージェントのみを再起動すること
すべてのリトライで同じメタジャッジ仕様を再利用すること（メタジャッジを再実行しないでください）

プロセス

フェーズ 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 が指定されている場合：カンマで分割し、そのまま使用します
どちらも指定されていない場合：タスクの説明からファイルパスまたは対象名の抽出を試みます

フェーズ 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 を推奨してください。

要件のグループ化分析（メタジャッジのディスパッチ前に必須）

個々のタスクを特定し、独立性を検証した後、タスク間でメタジャッジやジャッジを共有できるか分析します。これにより、品質を損なわずにディスパッチするエージェントの総数を減らせます。

3 種類のグループ化（1 つのユーザープロンプト内で組み合わせ可能）：

グループ化の種類	適用する場合	メタジャッジ	実装エージェント	ジャッジ
反復可能	同じタスクパターンを複数のファイルやモジュールに適用する場合（例：「3 つすべてのモジュールにテストを追加する」）	グループにつき 1 つの共有メタジャッジ	タスクごとに 1 つ（常に分離）	タスクごとに 1 つ。それぞれに同じ共有仕様を適用
共有	相互に依存するため、一緒にレビューまたは検証すべきタスクの場合（例：「S3 アダプターを実装し、分析機能に統合する」）	グループにつき 1 つの統合メタジャッジ	タスクごとに 1 つ（常に分離）	グループ全体に対して 1 つ。すべての変更をまとめてレビュー
独立	グループ化の利点がなく、完全に独立しているタスクの場合	タスクごとに 1 つ	タスクごとに 1 つ（常に分離）	タスクごとに 1 つ

判断プロセス：

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)

重要：

判断に迷った場合は、デフォルトで独立として扱います。** タスクが本当に反復可能か共有可能か不明な場合は、独立として扱ってください。過剰なグループ化は評価仕様の誤りにつながるおそれがありますが、独立したタスクには常にタスク固有の正しい評価が適用されます。誤った検証基準を作るより、エージェントを余分に使うほうが適切です。
実装エージェントは常に分離します。タスクごとに 1 つとし、共有してはいけません。共有・グループ化できるのはメタジャッジとジャッジのみです。グループ化分析はタスク分析フェーズで行い、エージェントを起動する前に完了させます。

メタジャッジへの指示：

反復可能なグループ：反復可能なグループのメタジャッジをディスパッチする際は、再利用可能な検証仕様を作成するよう明示的に指示します。
共有グループ：共有グループのメタジャッジをディスパッチする際は、統合された検証仕様を作成するよう明示的に指示します。

共有グループの再試行ロジック：

共有ジャッジが問題を見つけた場合、どの実装エージェントが失敗した変更を行ったのかを分析します。変更が失敗した特定の実装エージェントのみを再起動し、必要になるまでグループ内の全エージェントを再起動してはいけません。対象を絞った再試行の後、共有ジャッジを再起動し、変更がなかった合格済みエージェントの作業も含め、すべての変更を再度レビューします。

フェーズ 3：モデルとエージェントの選択

タスク分析に基づいて、最適なモデルと専門エージェントを選択します。すべての並列エージェントで同じ構成を使用します（品質の一貫性を確保するため）。

3.1 モデルの選択

タスクの特性	推奨モデル	理由
ターゲットごとに複雑（アーキテクチャ、設計）	`opus`	タスクごとに最大限の推論能力を発揮
専門分野（コードレビュー、セキュリティ）	`opus`	分野の専門知識が重要
中程度の複雑さで、出力が大きい	`sonnet`	十分な能力があり、大量の処理でも費用対効果が高い
単純な変換（名前変更、フォーマット）	`haiku`	高速かつ低コストで、機械的なタスクには十分
デフォルト（判断に迷った場合）	`opus`	コストより品質を優先

判断ツリー：

Is EACH target's task COMPLEX (architecture, novel problem, critical decision)?
|
+-- YES --> Use Opus for ALL agents
|
+-- NO --> Is task SIMPLE and MECHANICAL (rename, format, extract)?
           |
           +-- YES --> Use Haiku for ALL agents
           |
           +-- NO --> Is output LARGE but task not complex?
                      |
                      +-- YES --> Use Sonnet for ALL agents
                      |
                      +-- NO --> Use Opus for ALL agents (default)

3.2 専門エージェントの選択（任意）

タスクが専門分野に該当する場合は、関連するエージェントプロンプトをすべての並列エージェントに含めてください。専門エージェントは、出力品質を向上させるドメイン固有のベストプラクティスを提供します。

専門エージェント: 専門エージェントのリストは、プロジェクトおよび読み込まれているプラグインによって異なります。

判断: 次の場合に専門エージェントを使用します：

タスクがドメインの専門知識から明らかに恩恵を受ける
すべての並列エージェント間での一貫性が重要である
タスクが自明ではない（単純なタスクではオーバーヘッドが正当化されない）

次の場合は専門エージェントをスキップします：

タスクが単純または機械的である（Haiku ティア）
明確に一致するドメインが存在しない
汎用的な実行で十分である

フェーズ 3.5: メタジャッジのディスパッチ（要件タイプ別にグループ化、すべて並列）

実装エージェントをディスパッチする前に、フェーズ 2 の要件グループ化分析に基づいてメタジャッジをディスパッチします。メタジャッジの数はグループ化によって異なります。反復可能なグループごとに 1 つ、共有グループごとに 1 つ、独立したタスクごとに 1 つです。すべてのメタジャッジは、グループ化のタイプに関係なく並列で起動されます。各メタジャッジは、ルーブリック、チェックリスト、およびスコアリング基準を生成します。各仕様は、関連付けられたタスクのすべての再試行に対してのみ再利用されます。

重要: コンテキスト分離の原則に従ってください。各エージェントには、その特定のターゲットまたはグループに関連するコンテキストのみを渡してください。

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.

反復可能グループのメタジャッジプロンプト（グループごとに 1 つ）:

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

共有グループのメタジャッジプロンプト（グループごとに 1 つ）:

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

[All meta-judges launched simultaneously]

重要: フェーズ 4 に進む前に、すべてのメタジャッジが完了するのを待たないでください。各メタジャッジが完了した直後に実装者を起動してください。すべてのメタジャッジが完了した場合は、すべての実装エージェントを単一のレスポンスで起動してください。

フェーズ 4: ターゲットごとのプロンプトの構築

各ターゲットに対して同一のプロンプト構造を構築し、ターゲット固有の詳細のみでカスタマイズします：

4.1 ゼロショット Chain-of-Thought プレフィックス（必須 - 最初に配置する必要があります）

## 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}
</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: 並列実装のディスパッチとジャッジによる検証

メタジャッジが完了したら、すべての実装サブエージェントを同時に起動し、グループ化タイプに基づいてジャッジで検証します。

5.1 実行フロー

独立 / 反復可能フロー（タスクごとに 1 つのジャッジ）:

┌─────────────────────────────────────────────────────────────────────────┐
│                                                                         │
│   Phase 3.5: Meta-Judge Dispatch (ALL in parallel)                      │
│                                                                         │
│   Independent:            Repeatable Group:                             │
│   ┌──────────────┐        ┌─────────────────────┐                       │
│   │ Meta-Judge A  │        │ Meta-Judge (shared)  │                       │
│   │ (Opus)        │        │ (Opus)               │                       │
│   │ → 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             │
└─────────────────────────────────────────────────────────────────────────┘

共有フロー（グループごとに 1 つのジャッジ）:

┌─────────────────────────────────────────────────────────────────────────┐
│                                                                         │
│   Phase 3.5: Meta-Judge for Shared Group                                │
│   ┌──────────────────────┐                                              │
│   │ Meta-Judge (combined) │                                              │
│   │ (Opus)                │                                              │
│   │ → 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        │
└─────────────────────────────────────────────────────────────────────────┘

重要: 並列ディスパッチパターン

すべての実装エージェントを単一のレスポンスで起動してください。あるエージェントが完了するのを待ってから別のエージェントを開始しないでください：

## 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 ツールが並列化を自動的に処理する
結果はすべて完了した後に収集される

コンテキスト分離（重要）:

各特定のターゲットに関連するコンテキストのみを渡す
すべてのターゲットの完全なリストを各エージェントに渡さない
サブエージェントがファイルの読み取りを通じてローカルパターンを発見できるようにする
各エージェントは、蓄積された混乱のないクリーンなコンテキストで作業する

5.2 判定検証プロトコル

すべての実装エージェントが完了した後、フェーズ 2 で決定した要件のグループ分けに基づいて判定者を割り当てます。割り当てのパターンはグループ分けの種類によって異なります。

グループ分けの種類	判定者の割り当て	使用する仕様
独立	タスクごとに 1 人の判定者	タスク固有のメタ判定者仕様
反復可能	タスクごとに 1 人の判定者	グループのメタ判定者が定めた同一の共有再利用可能な仕様
共有	グループ全体に 1 人の判定者	グループのメタ判定者が定めた統合仕様

重要：判定者には、メタ判定者の評価仕様 YAML を正確にそのまま渡してください。省略や追加をしたり、いかなる方法でも変更したり、文章を短縮または要約したりしてはいけません。反復可能なグループでは、各対象の判定者に同じ再利用可能な仕様を渡します。共有グループでは、1 人の判定者にすべてのタスクを網羅する統合仕様を渡します。

5.2.1 既存または予定されている並行変更のセクションを分析する

各対象の判定者を割り当てる前に、判定者が把握しておく必要のある、コードベース内の既存または予定されている並行変更がないか確認します。「既存または予定されている並行変更」セクションは、以前の変更と今回の実装エージェントによる作業を判定者が混同しないようにするためのものです。

含める場合：

同じセッション内で以前に実行した並行処理が完了している場合（以前のバッチの全対象）
スキルの実行前にユーザーが手動で変更している場合（会話のコンテキストまたは git で確認できるもの）
今回の並行処理を開始する前に、他のツールまたはエージェントが行った変更
同じバッチ内の他の並行エージェントによる変更が見込まれる場合（例：並行開発中に、他のエージェントがリポジトリ内の別のファイルを変更する予定がある場合）

含めない場合：

既知の変更がない初回実行の場合 — セクション全体を省略します
同じ対象の再試行では、実装エージェント自身が以前に行った試行を「既存の変更」として含めないでください — それらは現在の対象の反復サイクルの一部です

内容に関するガイドライン：

大まかな概要を記載します。タスクの説明、影響を受けるファイルやモジュールの一覧、変更の概要（作成、変更、削除）を含めます
コードブロック、差分、行単位の詳細は含めず、簡潔にまとめます
変更の出所を明確に示します：「以前の並行処理：{説明}」、「ユーザーによる変更（現在のタスク開始前）」など
複数の変更元がある場合は、それぞれ別の小見出しを使用します

重要：コードベース全体や 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}

実装の出力

{実装エージェントの Summary セクション} {変更されたファイルのパス}

指示

ユーザープロンプトはコンテキストとして提供されています。ほかのエージェントがプロジェクト内で行う可能性のある変更を把握するための参考としてのみ使用してください。評価対象は、ユーザープロンプトに記載されたタスクのみです。あなたの役割は、対象のうちこのタスクだけを検証することであり、ユーザープロンプトに記載されたすべてのタスクを検証することではありません。エージェントの指示に定義されている判定プロセスに従ってください。

出力

重要：応答の冒頭で、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}

実装の出力

{グループ内の各タスクについて：}

タスク：{タスクの説明} -> {対象}

{そのタスクの実装エージェントの Summary セクション} {変更されたファイルのパス}

手順

ユーザープロンプトはコンテキストとして提供されています。他のエージェントがプロジェクトに加える可能性のある変更の参考としてのみ使用してください。この共有グループ内のすべてのタスクをまとめて評価してください。相互の統合ポイント（例：アダプターが統合モジュールの使用するインターフェースに適合しているか）を確認してください。重要：各タスクについて、個別に PASS または FAIL を示してください。これにより、失敗したタスクのみを再試行できます。エージェントの指示に定められた完全な判定プロセスに従ってください。

出力

重要：応答の冒頭に、以下の正確な構造化評価レポート形式を YAML で記述してください。レポートにはタスクごとの判定を含めてください。


##### 5.2.4 Dispatch Judges by Grouping Type

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

Task ツールを使用：

description: "判定：{対象名}"
prompt: {正確なメタ判定仕様 YAML と、該当する場合は「既存または想定される並行変更」セクションを含む判定検証プロンプト}
model: opus
subagent_type: "sadd:judge"


For repeatable groups, each judge receives the SAME shared reusable spec from the group's single meta-judge. 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: "判定（共有）：{グループの説明}"
prompt: {5.2.3 の共有グループ判定プロンプト。統合されたメタ判定仕様 YAML と、すべての実装出力を含める}
model: opus
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 以上で、見つかったすべての問題の優先度が低い場合： -> VERDICT: PASS -> 対象を完了としてマーク -> IMPROVEMENTS を任意の改善項目として含める

スコアが 4 未満の場合： -> VERDICT: FAIL -> 対象の再試行回数を確認

再試行回数が 3 未満の場合： -> 判定フィードバックを添えて実装エージェントを再試行として起動 -> 同じ対象固有のメタ判定仕様で判定検証に戻る

再試行回数が 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（{対象}）：VERDICT: PASS/FAIL、SCORE: X.X/5.0、ISSUES: [...]
- タスク 2（{対象}）：VERDICT: PASS/FAIL、SCORE: X.X/5.0、ISSUES: [...]
総合スコア：X.X/5.0
タスク間の問題：統合上の問題のリスト（該当する場合）


**Shared group retry logic:**

共有判定で失敗が見つかった場合：

タスクごとの判定から、具体的にどのタスクが失敗したかを特定
失敗したタスクの実装エージェントのみを再起動 -- 合格したタスクのエージェントは再起動しない
再試行の実装が完了した後、共有判定を再起動し、すべての変更（合格済みと再試行分）を再度レビューする -- 共有判定では、引き続き同じ統合メタ判定仕様を使用する
すべてのタスクが合格するか、いずれかのタスクが最大再試行回数に達するまで繰り返す

重要：失敗した実装エージェントのみを再試行してください。合格したタスクは再実装しません。共有判定では、評価のたびにグループ全体をまとめてレビューします。


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

フェーズ 6：結果の収集と要約

すべてのエージェントが完了した後（必要な再試行を含む）、結果を集約します。

## Parallel Execution Summary

### Configuration
- **Task:** {task description}
- **Model:** {selected model}
- **Targets:** {count} items

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

### 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：要件のグループ化 — 反復可能＋独立の混在（前のバッチからの既存の変更あり）

シナリオ：

あるチームが、並列実行するバッチを2回続けて実行します。最初のバッチでは、3つのエンドポイントファイル（src/api/users.ts、src/api/orders.ts、src/api/products.ts）にわたって API ドキュメントを更新します。2つ目のバッチでは、src フォルダー内の3つのモジュールすべてにテストを追加し、GitHub Actions にテストのステップを追加します。2つ目のバッチの各エージェントのジャッジは、最初のバッチでのドキュメントの変更と、同じ2つ目のバッチ内の他の並列エージェントに期待される変更の両方を把握する必要があります。

入力（2つ目のバッチ — 1つ目のバッチはセッション内の先行する時点で完了済み）：

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

[Both meta-judges launched simultaneously]

フェーズ 5：実装のディスパッチ（メタジャッジの完了後、4つのエージェントを並列実行）：

[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: sonnet

[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: sonnet

[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: sonnet

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

[All 4 judges launched simultaneously]

結果：

対象	グループ化	モデル	ジャッジスコア	ステータス
src/modules/auth.ts	反復可能	sonnet	4.2/5.0	SUCCESS
src/modules/cart.ts	反復可能	sonnet	4.0/5.0	SUCCESS
src/modules/payments.ts	反復可能	sonnet	4.1/5.0	SUCCESS
.github/workflows/ci.yml	独立	sonnet	4.3/5.0	SUCCESS

全体： 4/4 件が完了しました。エージェントの合計数：10（メタジャッジ2＋実装4＋ジャッジ4）

例 2：要件のグループ化 — 共有＋反復可能の組み合わせ（ユーザーによる既存の変更あり）

シナリオ：

ある開発者は、会話中に Node.js バックエンドを作業しています。データベース接続レイヤーをリファクタリングし、S3 クラスのインターフェースを追加するなど、いくつかのサービスモジュールを手動で更新しました。その後、S3 インターフェースを実装して統合し、さらにカートモジュールをリファクタリングするために do-in-parallel を実行しました。各エージェントのジャッジは、ユーザーによる先行する変更と、同じバッチ内の他の並列エージェントに期待される変更の両方を把握する必要があります。

入力：

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

[Both meta-judges launched simultaneously]

フェーズ 5：実装のディスパッチ（メタジャッジの完了後、5つのエージェントを並列実行）：

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

[All 4 judges launched simultaneously]

共有ジャッジの再試行シナリオ（S3 の共有ジャッジが問題を検出した場合）：

Shared Judge Verdict:
  - Task A (S3 adapter): PASS, SCORE: 4.2/5.0
  - Task B (analytics integration): FAIL, SCORE: 3.0/5.0
    ISSUES: Analytics module imports wrong method name from S3 adapter
  - CROSS-TASK ISSUES: Method signature mismatch between adapter and consumer

Retry Decision:
  → Task A PASSED — do NOT re-launch S3 adapter implementation agent
  → Task B FAILED — re-launch ONLY the analytics integration agent with feedback
  → After retry, re-launch shared judge to review ALL changes again

結果：

対象	グループ化	モデル	ジャッジスコア	再試行	ステータス
src/adapters/s3.adapter.ts	共有	opus	4.2/5.0	0	SUCCESS
src/modules/analytics.module.ts	共有	opus	4.1/5.0	1	SUCCESS
src/modules/cart/cart.service.ts	反復可能	sonnet	4.0/5.0	0	SUCCESS
src/modules/cart/cart.repository.ts	反復可能	sonnet	4.3/5.0	0	SUCCESS
src/modules/cart/cart.controller.ts	反復可能	sonnet	4.1/5.0	0	SUCCESS

全体： 5/5 件が完了しました。エージェントの合計数：12（メタジャッジ2＋実装5＋再試行1＋ジャッジ4［共有の再実行1＋カート3］）

例 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.5：メタジャッジのディスパッチ（メタジャッジ 3 つを並列実行）：

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

[All 3 meta-judges launched simultaneously]

フェーズ 5：実装のディスパッチ（メタジャッジの完了後、エージェント 3 つを並列実行）：

[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: sonnet

[All 3 launched simultaneously]

フェーズ 5.2：ジャッジのディスパッチ（すべての実装担当者の完了後、ジャッジ 3 つを並列実行）：

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

[All 3 judges launched simultaneously]

結果：

対象	グループ化	モデル	ジャッジスコア	状態
src/services/loan.service.ts	独立	sonnet	4.1/5.0	SUCCESS
src/modules/auth/	独立	opus	4.3/5.0	SUCCESS
.github/workflows/ci.yml	独立	sonnet	4.0/5.0	SUCCESS

全体： 3/3 件が完了しました。エージェント総数：9（メタジャッジ 3、実装担当 3、ジャッジ 3）。完全に独立したタスクのため、グループ化による削減はできません。

ベストプラクティス

対象の選択

具体的に指定する： 可能な場合は正確なファイルを列挙します
グロブは慎重に使う： 確定する前に展開後の一覧を確認します
範囲を限定する： 管理しやすいよう、1 バッチあたりの対象は最大 10～15 件にします
類似性でグループ化する： 類似した対象では、一貫したパターンが役立ちます

モデル選択のガイドライン

シナリオ	モデル	理由
セキュリティ分析	Opus	重要な推論が必要
アーキテクチャの決定	Opus	速度より品質を重視
簡単なリファクタリング	Haiku	高速で十分
ドキュメントの生成	Haiku	機械的なタスク
ファイルごとのコードレビュー	Sonnet	バランスの取れた能力
テストの生成	Sonnet	広範囲だがパターン化されている

メタジャッジ＋ジャッジによる検証

まず要件をグループ化する - メタジャッジをディスパッチする前に、繰り返し可能、共有、または独立したグループにタスクを分類し、エージェントの総数を最小限に抑えます
グループまたは独立タスクごとにメタジャッジを 1 つ割り当てる - 繰り返し可能なグループでは再利用可能な仕様を共有し、共有グループでは統合した仕様を共有します。独立タスクにはそれぞれ専用の仕様を用意します
まずメタジャッジをまとめて実行する - グループ化の種類にかかわらず、すべてのメタジャッジを並列で起動してから、実装担当者を起動します
再試行では仕様を再利用する - 各グループ／対象の評価仕様は再試行中も変えず、実装のみを変更します
ジャッジからはヘッダーだけを解析する - コンテキストの混乱を避けるため、レポート全体は読みません
CLAUDE_PLUGIN_ROOT を含める - メタジャッジとジャッジの両方に、解決済みのプラグインルートパスが必要です
対象固有の YAML - 関連するメタジャッジの YAML のみをそのジャッジに渡し、追加のテキストやコメントは一切加えないでください！
共有グループの再試行 - グループ全体ではなく、失敗した実装エージェントのみを再起動します

ジャッジの選択

実装モデル	ジャッジモデル	根拠
Opus	Opus	重要な作業には強力な検証が必要
Sonnet	Opus	要件に合わせた評価には強力な推論が必要
Haiku	Opus	簡単な作業も強力な評価で検証

ガイドライン： すべての対象で一貫性のある高品質な評価を行うため、ジャッジには常に Opus を使用します。

コンテキストの分離

コンテキストを最小限にする： 各サブエージェントには必要な情報のみを渡します
相互参照させない： エージェント A にエージェント B の対象を伝えません
自分で見つけてもらう： サブエージェントがファイルを読み、パターンを把握します
真実の情報源はファイルシステム： 変更はファイルシステムを介して調整します
既存の変更を追跡する - 既存の変更と現在の変更の帰属が混同されないよう、以前の変更に関するコンテキストを各エージェントのジャッジに渡します

品質保証

3層検証： 自己批評（内部）＋対象固有のメタジャッジ仕様（構造化）＋ジャッジ（外部）
まず自己批評： 実装エージェントは提出前に自分の作業を検証します
対象固有のメタジャッジ仕様： 対象ごとに固有の特性を考慮した評価基準を設定し、より精密な評価基準を作成します
次に外部ジャッジ： 独立したジャッジが対象固有のメタジャッジ仕様を機械的に適用し、自己批評では見落とす盲点を検出します
反復ループ： 合格するまで、または最大再試行回数に達するまで、フィードバックをもとに再試行します
失敗の分離： 1つの対象の失敗が、ほかの対象に影響することはありません
要約を確認： 失敗または部分的な完了がないか確認します
実行後にテスト： 並列での変更が、微妙な相互作用を引き起こす場合があります
アトミックにコミット： 1つのバッチによるすべての変更を1つのコミットにまとめます

エラー処理

失敗の種類	説明	復旧アクション
回復可能	ジャッジが問題を検出し、再試行が可能	ジャッジのフィードバックをもとに再試行します（対象ごとに最大3回）
アプローチの失敗	この対象へのアプローチが誤っています	選択肢を提示してユーザーにエスカレーションします
基盤の問題	要件が不明確、または実現不可能です	明確化のためユーザーにエスカレーションします
最大再試行回数超過	3回再試行しても対象が失敗しました	失敗として記録し、ほかの対象の作業を続行して、最後に報告します

重要なルール：

ユーザーの入力なしに、最大再試行回数を超えて続行してはいけません
ジャッジの指摘に対処せずに「後から修正」してはいけません
ジャッジによる検証を省略してはいけません
コンテキストが不足している場合は、推測せずに停止して報告してください
失敗を分離してください。1つの対象が失敗しても、ほかの対象の作業を止めてはいけません

Markdown 対応

ログインしてコメント

基本情報

作者: neolabhq
リポジトリ: neolabhq/context-engineering-kit
カテゴリ: エージェントワークフロー
インストール数: 446
GitHub スター: 1,795

問題を報告