do-in-parallel

do-in-parallel

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

主な利点：

• 並列実行 - 複数のタスクを同時に実行します
• 要件のグループ分け - 反復可能なタスクパターンや共有タスクパターンを特定し、メタジャッジとジャッジの数を減らします
• 適切なモデル規模 - モデル選択ポリシーに基づいて対象ごとに選択します。既定では sonnet／haiku を使用し、十分な理由がある場合にのみ opus を使用します
• コンテキストの初期化 - 各サブエージェントは、クリーンなコンテキストウィンドウで作業します
• タスクに特化した評価 - 各メタジャッジは、特定のタスクまたはグループに合わせたルーブリックとチェックリストを作成します
• 外部検証 - ジャッジは対象に特化したメタジャッジ仕様を機械的に適用し、自己批評では見落とされる盲点を見つけます
• フィードバックループ - ジャッジが特定した問題をもとに再試行します
• 品質ゲート - 基準を満たすまで成果物はリリースされません

一般的なユースケース：

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

引数

引数	形式	デフォルト	説明
task	自由形式のテキスト	必須	対象全体で実行するタスクの説明
--files	"file1,file2,..."	なし	対象とするファイルパスをカンマ区切りで指定
--targets	"target1,target2,..."	なし	対象とする名前付きターゲットをカンマ区切りで指定
--model	haiku|sonnet|opus	タスクごとに自動選択	すべてのタスクにおける実装、メタジャッジ、ジャッジの全サブエージェントに適用する、ユーザーによる明示的な上書き指定です。省略した場合は、モデル選択ポリシーに従ってタスクごとにティアを選択する必要があります。固定のフォールバックティアはなく、フェーズ 3 のティア評価手順も実行されません。指定された場合、すべてのサブエージェントでユーザーの選択がポリシーより優先されます。明示的な上書き指定とエスカレーションの関係については、エスカレーションルールを参照してください。
--output	パス	なし	結果の出力ディレクトリパス
--strict	--strict	false	反復裁量ルールを無効にします。ターゲットは score >= 4.0 の場合にのみ合格し、それ以外の場合は最大再試行回数に達するまで再試行します。

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

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

1. タスクを分析し、要件をグループ化して分析し、モデル選択ポリシーに従ってタスクごとのモデルティアを選択する
2. グループ化に基づいて、メタジャッジを並行してディスパッチする
3. 各メタジャッジの完了後、そのグループのターゲットに対する実装サブエージェントを、構造化されたプロンプトとともにディスパッチする
4. 実装担当者の完了後、グループ化に基づいてジャッジをディスパッチする
5. 判定を解析し、必要に応じて反復する（ターゲットごとの再試行は最大 3 回。共有グループでは失敗したタスクのみ再試行）
6. 結果を収集し、最終的な概要を報告する

レッドフラグ - 絶対にしてはいけないこと

絶対にしてはいけないこと:

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

必ず行うこと:

• すべての実装作業をサブエージェントにディスパッチするために Task ツールを使用すること
• メタジャッジをディスパッチする前に要件グループ化分析を実行すること
• グループ化に基づいてメタジャッジをディスパッチすること -- すべてを単一のレスポンスで並列に実行してください
• すべてのメタジャッジが完了するのを待ってから実装エージェントをディスパッチするのではなく、各メタジャッジが完了した直後に起動すること
• タスクの各実装エージェントは、そのメタジャッジが完了した直後に起動すること。すべてのメタジャッジが完了している場合は、すべての実装エージェントを単一のレスポンスで起動してください
• 各ターゲット固有のメタジャッジ評価仕様をそのジャッジエージェントに渡すこと
• 共有グループの場合、関連するすべての変更をまとめてレビューする 1 つのジャッジをディスパッチすること
• メタジャッジおよびジャッジエージェントへのプロンプトに CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT} を含めること
• 検証のために独立したジャッジをディスパッチするために Task ツールを使用すること
• 各実装が完了するのを待ってからそのジャッジをディスパッチすること
• ジャッジの出力から VERDICT/SCORE/ISSUES のみを解析すること
• 検証が失敗した場合はフィードバックを伴って反復すること(ターゲットごとに最大 3 リトライ)
• --strict が指定されていない限り、すべてのターゲットの判定に反復裁量ルールを適用すること
• 共有グループのリトライでは、グループ全体ではなく、失敗した特定の実装エージェントのみを再起動すること
• すべてのリトライで同じメタジャッジ仕様を再利用すること(メタジャッジを絶対に再実行しないでください)

モデル選択ポリシー

モデルの選択は、あなたが行う単一で最もレバレッジの効く意思決定です -- プロンプトの文言以上に、ターゲットが正しく返ってくるかどうか、そしてバッチにかかる時間を左右します。これを形式的なものとして扱ってはいけません。各ターゲットをディスパッチする前に、ティアを明示し、一行の根拠を示してください。考えるのを避けたいがために最強のモデルに手を伸ばすことは、慎重さではなく失敗です。

ティアのデフォルト: sonnet と haiku がデフォルトです。opus は予約済みかつオプトインです -- 以下の表のトリガーによって獲得されなければならず、自信がないからといって選ばれてはいけません。

実行単位ではなくタスク単位: ティアはすべてのタスクに対して個別に、そのタスク自身のスコープ、複雑さ、リスクから選択されます -- バッチはもはや「すべての並列エージェントに同じ構成」という 1 つに強制されることはありません。独立したタスクはそれぞれ、それ自体の妥当性に基づいてティア分けされます。反復可能グループの共有メタジャッジは 1 つの再利用可能な仕様を生成しますが、それが 1 つのティアを強制するわけではありません。グループ内の各タスクは、以下の選択ルールに従って自身の実装ティアとジャッジティアを保持するため、それ以外は機械的なグループ内のクリティカルドメインのターゲットが、その兄弟タスクはより安価なままで opus に到達することもあります。共有グループの単一のジャッジはグループ内のすべてのタスクをまとめてレビューするため、それらの中で現在の最高の実装ティアで実行されます(ロールペアリングを参照)。あるタスクによって到達されたティア(エスカレーションによって到達されたものを含む)は、兄弟タスクや次のバッチに持ち越してはいけません。

選択ルール

タスクの形状	ティア	例
ドキュメント／テキストファイル1つの修正 — コードなし、複数ファイルにまたがる推論なし	haiku	誤字の修正、リンクの更新、README の古いコマンドの修正
1つのファイルに限定された、小規模で数行程度（およそ10行以下）の機械的なコード変更	haiku	定数の値の変更、ガード節の追加、ローカル変数名の変更、設定値の編集
コードの作成 — 新しい関数、コンポーネント、テスト、単一モジュールの変更、確立されたパターン	sonnet	エンドポイントの追加、サービスメソッドとテストの作成、1つのモジュールのリファクタリング
複数ファイルのリファクタリング（およそ3ファイル以上、または共有契約が変更される場合はファイル数を問わない）、またはクリティカルな変更（認証、支払い／請求、データ整合性、取り消し不可能なマイグレーション、公開 API の破壊）、または複雑なロジック（並行処理、単純ではないアルゴリズム、アーキテクチャ上の判断）	opus	横断的なリファクタリング、認証または支払いのロジック、スキーママイグレーション、新しいアルゴリズムの設計

優先順位（必須）：最初に一致した行だけでなく、すべての行を評価してください。複数の行に一致する場合は、一致した中で最も高いティアを選びます。クリティカル性と複雑さは、常に規模より優先されます。セキュリティ上クリティカルな認証ハンドラー内の4行の null チェックは、haiku の行と opus の行の両方に一致するため、opus です。クリティカルのリストは網羅的であり、例示ではありません。本番環境へのリリース、実際のユーザーへの影響、公開 API への追加はトリガーではないため、1つのサービスファイル内でバリデーションを行う新しいエンドポイントは sonnet のままです。機械的な変更の範囲に関する例外：変更範囲の広さだけでは複雑さに当たりません。純粋に機械的な変更、つまりロジックも契約の変更もなく、ルールに従って同一の編集を複数の対象に繰り返す場合、適用されないのは複数ファイルのトリガーのみです。クリティカルと複雑なロジックのトリガーは引き続き適用されます。タスクが1つのファイルだけに及ぶものとして、1回の変更内容に基づいて必ずティアを判定してください。そのため、40ファイルにわたる機械的なシンボル名の変更は haiku ですが、同じ変更が src/auth/ 内に限定される場合は opus です。変更範囲にかかわらず、1回の変更内容でクリティカルトリガーが適用されるためです。この例外は共有契約の変更（上記のとおり、すでに opus のトリガー）には適用されません。そのため、複数ファイルにまたがる共有インターフェースの抽出は引き続き opus です。

**同点時のルール：**どの行にも明確に一致せず、タスクが実際に2つのティアの中間にある場合に限り、低コストのティアを選びます。安全策として opus に引き上げてはいけません。エスカレーションルールにより、最初の低コストな見積もりは後から修正できます。修正が必要なタスク1件のコストは、すべてのタスクに過剰なリソースを割り当てるコストよりもはるかに低くなります。

ロールの組み合わせ

モデルに割り当てられたパイプラインには、最大で3つのロールがあります。producer（作業を行う）、criteria-setter（「正しい」とは何かを定義する）、evaluator（その基準に照らして作業を確認する）です。このスキルでは、これらは並列タスクごとに、実装／メタジャッジ／ジャッジとして割り当てられます。繰り返し実行するグループでは、複数のタスクでメタジャッジを共有し、共有グループでは、さらに複数のタスクでジャッジも共有します。デフォルト：そのタスクの3つのロールすべてに同じティアを使用します。

明白でないタスクに限り、基準を評価対象の作業より厳密にするため、criteria-setterだけを1ティア上げてもかまいません。明白でないかどうかは、次の方法で判定できます。ティアがタイブレーカーによって決定された（選択ルールの行に明確に該当しなかった）、またはタスクに確認可能な受け入れ条件が記載されていない場合です。

パターン	Criteria-setter（メタジャッジ）	Producer + evaluator（実装 + ジャッジ）	使用する場面
Sharpened-haiku	sonnet	haiku	作業は単純ですが、何をもって「正しい」とするかが明白でない場合
Sharpened-sonnet	opus	sonnet	受け入れ条件が曖昧、または重大な結果を伴うコード作業で、それ自体はopusの条件に該当しない場合

Producerとevaluatorは、必ず同じティアを使用しなければなりません。繰り返し実行するグループ、または複数のタスクを担当する共有グループのジャッジでは、「同じティアを使用する」とは、そのジャッジが担当するタスクの中で、現在の実装ティアが最も高いものに合わせることを意味します。これにより、自身のティアを超える作業をジャッジすることはありません（再試行時のモデル昇格を参照）。evaluatorだけを上げてはならず、criteria-setterをproducerのティアより下に設定してもなりません。**明示的な--modelオーバーライドは、このセクション全体より優先されます。**ユーザーが--modelを指定した場合、すべてのタスクのすべてのロールがそのティアで実行され、ロールの組み合わせによってメタジャッジをそのティアより上げてはなりません。

エスカレーションルール

次のいずれかのトリガーが発火した場合、プロデューサーと評価者の両方（失敗したタスクの実装とジャッジ）を、次の試行に向けて1段階引き上げます。

1. 初回試行の品質が低い — スコアが低い、またはモデルが単に細部を見落としたのではなくタスクを誤解していることを示す問題がある場合。
2. ユーザーが苦情を述べる — 品質が低すぎる、または結果が間違っているという苦情を、PASS が報告された後を含むいつでも述べた場合。

階段: haiku → sonnet → opus。opus は上限です — それ以上の段階はありません。opus 段階の作業が依然として失敗する場合は、ユーザーにエスカレーションし、決してループしないでください。

• 唯一の例外 — 段階を維持する（このルールの唯一の記述、トリガー (1) のみ）: トリガー (1) が発火したが、ジャッジの問題が能力の不足ではなく特定の修正可能な欠陥である場合（モデルが明確に理解していた、狭く正確に特定された問題）、段階を維持し、引き上げる代わりにジャッジの正確なフィードバックを用いて同じ段階で再試行してもよい（MAY）。これは、トリガー (1) に基づく引き上げが必須でない唯一の状況です。それ以外のすべてのケースでは、トリガー (1) は引き上げます。トリガー (2)（ユーザーの苦情）にはそのような例外はありません — 以下の例外規定のとおり、常に即座に引き上げます。
• 明示的な --model の例外規定（このルールの唯一の記述）: 明示的な --model はユーザーによる上書きであるため、トリガー (1) はそれを暗黙に覆してはなりません（MUST NOT） — 最大再試行回数に達するまで、上書きモデルで反復を続けてください。最終的に目標が依然として達成されない場合は、見つかった問題を強調し、ユーザーへの引き上げを提案してください。トリガー (2) はまさにその承認であるため、即座に引き上げます。
• 失敗したタスクのみに限定されます。 エスカレーションは、そのタスクの実装とジャッジの再試行を再段階付けします。バッチを再段階付けするものではありません。同時に実行されている兄弟タスク、および後続のバッチ内のすべてのタスクは、選択ルールに従ってそれぞれの妥当性に基づいて評価され、sonnet/haiku のデフォルトから再び開始されます。
• エスカレーションは実装とジャッジのみを移動させます。タスクのメタジャッジ（反復可能/共有グループの場合はグループのもの）は再実行されず、再段階付けもされません — その仕様はタスクの再試行を通じて再利用され、タスクの途中で基準を変更すると試行間の比較が無効になります。
• エスカレーションは、真の根本原因の修正を補完するものであり、決してその代替ではありません。ジャッジの具体的なフィードバックを依然として再試行に渡さなければなりません（MUST）。より高い段階で同じプロンプトを再ディスパッチし、期待するだけのことは禁止されています。
• エスカレーションは、スコア閾値、反復裁量ルール、およびターゲットごとの最大3回再試行の予算とは直交します — それはどのモデルが次の試行を実行するかを変えるものであり、試行が正当化されるかどうかを変えるものでは決してありません。
• PASS が報告された後の再エントリー（このルールの唯一の記述）: PASS が報告されても作業は終了しません。ユーザーが後にあるターゲットの結果が間違っている、またはその品質が低すぎると述べた場合、トリガー (2) の下でそのターゲットの再試行パスに再エントリーし、そのターゲットの再試行予算はリセットされます — 以前のサイクルが使い果たされていたとしても、苦情は最大3回の再試行の新たなサイクルを開始します。

プロバイダー間の同等性

このスキルが Anthropic のモデルコンテキスト以外で実行される場合は、同じクラスで最も近いモデルにティアを対応付けてください。

ティア	役割	他のプロバイダーの同等モデル
haiku	高速で低コスト。機械的な作業	gemini-flash-lite、gemma クラス、gpt-oss クラス、小規模なオープンウェイトモデル
sonnet	バランスの取れた主力。大半のコード作成	gemini-pro クラスとフル版の gemini-flash（haiku ティアに相当する -lite バリアントは除く）、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 の場合のみです。それ以外は最大再試行回数に達するまで再試行します
• サブエージェントのプロンプトを作成する前に、タスクテキストからすべてのフラグを削除します。フラグをサブエージェントのプロンプトに渡すことは絶対にしないでください

例：/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 を共有できるかどうかを分析します。これにより、品質を犠牲にすることなく、ディスパッチされるエージェントの総数を削減できます。

3 つのグループ化タイプ（単一のユーザープロンプト内で組み合わせ可能）：

グループ化タイプ	適用する場面	Meta-Judge	実装エージェント	Judge
Repeatable	同じタスクパターンを複数のファイル/モジュールに適用する場合（例：「3 つすべてのモジュールにテストを追加する」）	グループに対して 1 つの共有 meta-judge	タスクごとに 1 つ（常に分離）	タスクごとに 1 つ、それぞれが同じ共有スペックを受け取る
Shared	相互依存しているため、まとめてレビュー/検証すべきタスク（例：「S3 アダプターを実装し、それを分析に統合する」）	グループに対して 1 つの統合 meta-judge	タスクごとに 1 つ（常に分離）	グループ全体に対して 1 つの judge が、すべての変更をまとめてレビューする
Independent	完全に独立しており、グループ化の利点がないタスク	タスクごとに 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)

重要：

• 迷ったときは、デフォルトで INDEPENDENT にします。**タスクが本当に repeatable または shared であるか不明な場合は、独立しているものとして扱います。過度なグループ化は誤った評価スペックのリスクを生みますが、独立したタスクは常に正しいタスク固有の評価を受け取ります。誤った検証基準を生み出すよりも、余分なエージェントを使うほうがよいです。
• 実装エージェントは常に分離されていることを維持します -- タスクごとに 1 つで、決して共有しません。共有/グループ化できるのは meta-judge と judge のみです。グループ化分析はここ、タスク分析フェーズで、あらゆるエージェントが起動される前に実施されます。

Meta-judge の指示：

• Repeatable グループ：repeatable グループに対して meta-judge をディスパッチする際は、再利用可能な検証スペックを生成するための明示的な指示を含めます。
• Shared グループ：shared グループに対して meta-judge をディスパッチする際は、統合された検証スペックを生成するための明示的な指示を含めます。

Shared グループのリトライロジック：

shared judge が問題を発見した場合、失敗した変更を生成した特定の実装エージェントを分析します。変更が失敗した特定の実装エージェントのみを再起動します -- 必要になるまでグループ内のすべてのエージェントを再起動しないでください。対象を絞ったリトライの後、shared judge を再起動して、すべての変更（合格したエージェントの変更されていない作業を含む）を再度レビューします。

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

フェーズ 2 の分析に基づき、モデル選択ポリシーに従って、タスクごとにモデル階層と特化エージェントを選択します -- デフォルトでは sonnet/haiku、正当な理由がある場合のみ opus。--model が渡された場合は、直接 3.2 に進みます。すべてのタスクのすべてのサブエージェントが、ロールペアリングのオーバーライド条項に従って、ユーザーの階層で実行されます。

3.1 タスクごとのモデルティア選択

以下の3つの軸ですべてのタスクを評価し、選択ルールの表からティアを直接選びます。ティアはタスクごとに選択し、バッチ全体に対して一度だけ選ぶことはありません。

• 範囲 — 1つのファイル、1つのコンポーネント、または複数のファイルですか？
• 複雑さ — 機械的な編集、確立されたパターン、または新規で複雑なロジックですか？
• リスク — 独立していて元に戻せるもの、内部的なもの、または選択ルールのopus行にある網羅的なリストに該当するクリティカルなものですか？

グループ化の種類ごと：

• 独立タスク — 各タスクを個別に評価します。それぞれに専用のメタジャッジと、そのティアに応じたジャッジが割り当てられます。
• 反復可能なグループ — 共有のメタジャッジが再利用可能な仕様を1つ作成しますが、各タスクの実装とジャッジのティアは引き続き個別に決定します。各対象を、あたかも独立タスクであるかのように選択ルールに照らして評価します。グループ内のクリティカルな領域の対象（たとえば、あるファイルが認証コードである場合）は、opusになる一方、同じ仕様を共有していても、ほかの対象はsonnetまたはhaikuのままになることがあります。
• 共有グループ — まず各タスクの内容に基づいて個別にティアを選び、次に役割の組み合わせに従って、グループで共有するジャッジのティアを、その中で最も高いティアに設定します。これにより、ジャッジ自身のティアを超える作業を評価させることがありません。

各タスクをディスパッチする前に、3つの評価結果、選択したティア、1行の根拠を示します。その後、役割の組み合わせを全面的に適用し、--modelによるオーバーライドも含めて、そのタスク（またはグループ）のメタジャッジのティアを決定します。

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 ディスパッチパターン

グループ化の種類にかかわらず、メタジャッジをすべて1回の応答でディスパッチします。

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に進む前に、メタジャッジがすべて完了するのを待ってはいけません。各メタジャッジの完了後、すぐに実装エージェントを起動します。メタジャッジがすべて完了している場合は、実装エージェントをすべて1回の応答で起動します。

フェーズ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：並列実装のディスパッチとジャッジによる検証

メタジャッジの完了後、すべての実装サブエージェントを同時に起動し、グループ化の種類に応じてジャッジで検証します。

5.1 実行フロー

独立型／反復可能型のフロー（タスクごとにジャッジ 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             │
└─────────────────────────────────────────────────────────────────────────┘

共有型のフロー（グループごとにジャッジ 1 人）：

┌─────────────────────────────────────────────────────────────────────────┐
│                                                                         │
│   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        │
└─────────────────────────────────────────────────────────────────────────┘

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

すべての実装エージェントを 1 つの応答で起動します。別のエージェントを開始する前に、1 つのエージェントの完了を待ってはいけません。

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

並列化のガイドライン：

• 独立したすべてのタスクを 1 つのバッチで起動します（同じ応答内）
• 別のタスクを開始する前に、1 つのタスクの完了を待ってはいけません
• Task ツールを順番に呼び出してはいけません
• Task ツールが並列化を自動的に処理します
• すべてのタスクが完了した後に結果を収集します

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

• 各ターゲットに関連するコンテキストのみを渡します
• すべてのターゲットの一覧を各エージェントに渡してはいけません
• サブエージェントがファイルを読み取ってローカルのパターンを見つけられるようにします
• 各エージェントは、混乱が蓄積していないクリーンなコンテキストで作業します

5.2 ジャッジによる検証プロトコル

すべての実装エージェントが完了した後、フェーズ 2 で決定した要件のグループ化に応じてジャッジをディスパッチします。ディスパッチのパターンは、グループ化の種類によって異なります。

グループ化の種類	ジャッジのディスパッチ	使用する仕様
独立型	タスクごとにジャッジ 1 人	タスク固有のメタジャッジ仕様
反復可能型	タスクごとにジャッジ 1 人	グループのメタジャッジで共有される同一の再利用可能な仕様
共有型	グループ全体にジャッジ 1 人	グループのメタジャッジによる統合仕様

重要：ジャッジにはメタジャッジの評価仕様 YAML を正確に渡してください。省略や追加、変更をしてはいけません。また、テキストを短縮したり要約したりしてはいけません。反復可能型グループでは、各ターゲットのジャッジに同一の再利用可能な仕様を渡します。共有型グループでは、すべてのタスクを網羅する統合仕様を 1 人のジャッジに渡します。

5.2.1 既存または予想される並列変更のセクションを分析する

各ターゲットのジャッジをディスパッチする前に、ジャッジが把握しておく必要のある、コードベース内の既存または予想される並列変更があるかどうかを評価します。「既存または予想される並列変更」セクションは、以前の変更を現在の実装エージェントの作業とジャッジが混同しないようにするためのものです。

含める場合：

• 同じセッション内で、以前の do-in-parallel 実行が完了している（前のバッチの全ターゲット）
• スキルの実行前にユーザーが手動で変更している（会話のコンテキストまたは git で確認できる）
• 今回の並列ディスパッチ前に実行された別のツールまたはエージェントによる変更
• 同じバッチ内の他の並列エージェントによる予想される変更（たとえば、並列開発中に他のエージェントがリポジトリ内の別のファイルを変更すると予想される場合）

省略する場合：

• 既知の変更がない初回実行の場合は、このセクション全体を省略します
• 同一ターゲット内の再試行では、実装エージェント自身の前回の試行を「既存の変更」として含めてはいけません。これは現在のターゲットの反復サイクルの一部です

内容のガイドライン：

• タスクの説明、影響を受けるファイル／モジュールの一覧、変更の概要（作成、変更、削除）を簡潔にまとめます
• コードブロック、差分、行単位の詳細は含めず、簡潔にします
• 変更元を明確に示します：「以前の 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}

実装の出力

{実装エージェントの 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}

実装の出力

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

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

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

指示

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

出力

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

##### 5.2.4 Dispatch Judges by Grouping Type

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

Task ツールを使用：

• description: "判定者：{target name}"
• prompt: {正確なメタ判定者仕様YAMLを含む判定者確認プロンプト、および該当する場合は「事前に存在する変更または想定される並行変更」セクション}
• model: {判定者モデル — ユーザーが --model を指定した場合はそのモデル。指定されていない場合は、エスカレーション後も含め、このタスクの現在の実装ティアと必ず同じモデル}
• 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: "判定者（共有）：{group description}"
• prompt: {5.2.3の共有グループ判定プロンプト。統合されたメタ判定者仕様YAMLとすべての実装出力を含める}
• model: {判定者モデル — ユーザーが --model を指定した場合はそのモデル。指定されていない場合は、いずれかのタスクがエスカレーションされた後も含め、このグループのタスクの現在の実装ティアのうち最も高いものと必ず同じモデル}
• 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 かつ STRICT_MODEでない場合： -> Iteration Discretion Rule（5.5）を適用 -> 受け入れられた場合 -> VERDICT: PASS（対象を完了としてマークし、未解決の問題を報告） -> 受け入れられなかった場合 -> VERDICT: FAIL -> 以下の「再試行回数を確認」に進む

それ以外の場合（スコア < 3.0、またはSTRICT_MODEでスコア < 4の場合）： -> VERDICT: FAIL -> 対象の再試行回数を確認

retries < 3 の場合： -> 以下の「5.3.1 再試行時のモデルエスカレーション」に従って、この対象の再試行ティアを決定 （エスカレーションルールに従い、唯一の保留例外に該当する場合を除き、実装モデルと判定者モデルの両方を引き上げる） -> 判定者のフィードバックを添えて、そのティアで再試行用実装エージェントを起動 -> 同じ対象固有のメタ判定者仕様を使用して判定者による確認に戻り、 再試行ティアの判定者を起動（判定者のモデルは常に実装モデルと一致させる）

retries >= 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:

共有判定者の返信から以下を抽出：

• タスクごとの判定：
  • Task 1（{target}）：VERDICT: PASS/FAIL、SCORE: X.X/5.0、ISSUES: [...]
  • Task 2（{target}）：VERDICT: PASS/FAIL、SCORE: X.X/5.0、ISSUES: [...]
• OVERALL SCORE: X.X/5.0
• CROSS-TASK ISSUES: 統合上の問題のリスト（ある場合）

**Shared group retry logic:**

共有判定者が失敗を検出した場合：

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

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

##### 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 反復の裁量に関するルール

主なタスクは、目標品質を満たしてタスクを完了することです。反復にかける労力は、各ターゲットの規模に見合ったものにしなければなりません。次の2つの失敗パターンはいずれも実際に起こり得ます。

• 細かな指摘に再試行とコンテキストを浪費し、バッチ全体が完了しない → タスク失敗
• 完了とみなすには品質が明らかに不十分なターゲットを受け入れる → さらに深刻な失敗

各ジャッジスコアに適用します（共有グループでは、グループ内のタスクごとの判定に適用します）。

• score < 3.0 → 無条件に失敗。裁量の余地はありません。 ターゲットが合格するか、最大再試行回数に達するまで、ジャッジのフィードバックに基づいて再試行します。
• 3.0 <= score < 4.0 → 裁量範囲。 この範囲内に限り、4.0の目標スコアを下回るターゲットを許容可能と判断できます。固定された4.0の目標により、実質的な下限は3.0となるため、別途、下落幅の上限を設ける必要はありません。
• この範囲内で、未解決の問題が低優先度または中優先度のみであり（高優先度または重大な指摘が1つでもあれば裁量の余地はなくなります）、かつターゲット要件に違反したり、意味のある不具合を生じさせたりしない（つまり、細かな指摘にとどまる）場合は、再試行を指示する前に、もう一度試す価値が時間とコンテキストのコストに見合うかどうかを必ず最初に検討してください。
• 細かな指摘を理由とする再試行は最大1回までであり、再試行回数の上限に含まれます。その再試行でも細かな指摘のみが挙がった場合は、ターゲットを完了（ACCEPTED）と判定し、最終サマリーで未解決の問題を報告して次に進んでください。スコアが3.0未満になった場合は、無条件の失敗ルールが適用されます。
• 甘い判断ではなく、厳格に評価してください。 目標に達する前に停止する判断は、要件に違反する実質的な問題がないことに基づいて、意図的に行わなければなりません。最大再試行回数までに完了できない真の阻害要因がある場合は、決して見過ごさず、ターゲットを失敗として報告してください。
• STRICT_MODEがtrueの場合、このルール全体は無効です。 停止条件はscore >= 4.0または最大再試行回数への到達のみです。--strictによって、それ以外の条件（4.0の目標スコア、最大再試行回数、< 3.0の無条件失敗、メタジャッジ／ジャッジのディスパッチ）は変更されません。

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

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

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

シナリオ：

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

入力（2つ目のバッチ――最初のバッチはセッション内ですでに完了しています）：

/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 ステップを1つ追加する小規模で機械的な作業です。

反復可能グループのタスクは、同じメタジャッジの仕様を共有していても、すべて同じティアになるわけではありません。auth.ts と payments.ts はそれぞれ独立して重要なトリガーに該当しますが、cart.ts は該当しません。共有のメタジャッジ自体は、担当する3つのタスクのうち最も高いティアである 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つのエージェントを並列実行）：

[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 完了。エージェント総数：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：モデルの選択

対象	グループ化	ティア	理由
src/adapters/s3.adapter.ts	共有	opus	共有契約のトリガー — この公開インターフェースは、タスク B が統合時に使用する契約です
src/modules/analytics.module.ts	共有	opus	共有契約のトリガー — 対応するタスクで定義されたアダプターの公開インターフェースを使用して統合します
src/modules/cart/cart.service.ts	反復可能	sonnet	1 ファイル内で完結するリファクタリングで、契約の変更はありません
src/modules/cart/cart.repository.ts	反復可能	sonnet	1 ファイル内で完結するリファクタリングで、契約の変更はありません
src/modules/cart/cart.controller.ts	反復可能	sonnet	1 ファイル内で完結するリファクタリングで、契約の変更はありません

共有グループが opus になるのは、タスク A と B が、アナリティクス統合で使用する S3 アダプターの公開インターフェースという契約を共有しているためです。選択ルールでは、これを「共有契約が変更される場合は、ファイル数にかかわらず」opus を選択するトリガーとして定めています。反復可能グループが sonnet になるのは、各カートファイルのリファクタリングが個別に完結し、契約の変更を伴わないためです。共有グループのメタジャッジと単一のジャッジも opus で実行されます。ロールペアリングのデフォルトでは、タスクの 3 つのロールすべてに同じティアが適用されます。また、共有ジャッジのティアは、担当するタスクの現在の実装ティアのうち最も高いものとなり、両方のタスクで一致しているため 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 つのエージェントを並列実行）：

[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 件が完了しました。エージェント合計：13（メタジャッジ 2 + 実装 5 + ジャッジ 4 + 再試行実装 1 + 再試行ジャッジ 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 は獲得される — 認証ドメイン(パスワードリセットトークンの発行と検証)でクリティカルトリガーが発動する
.github/workflows/ci.yml	haiku	標準的な GitHub Action を使用した、小さく機械的なキャッシュ設定の変更。記述すべきロジックがない

フェーズ 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: 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: 実装のディスパッチ (メタジャッジ完了後、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: haiku

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

結果:

ターゲット	グループ化	モデル	ジャッジスコア	リトライ	ステータス
src/services/loan.service.ts	独立	sonnet	4.1/5.0	0	SUCCESS
src/modules/auth/	独立	opus	4.3/5.0	0	SUCCESS
.github/workflows/ci.yml	独立	haiku	4.0/5.0	0	SUCCESS

全体: 3/3 完了。エージェントの合計: 9 (3 メタジャッジ + 3 実装 + 3 ジャッジ)。完全に独立したタスクではグループ化による削減はできません。

ベストプラクティス

ターゲットの選択

• 具体的に指定する: 可能な場合は正確なファイルを列挙します
• glob は慎重に使用する: 確定する前に展開されたリストを確認します
• スコープを制限する: 管理しやすさのため、1 バッチあたり最大 10〜15 ターゲットとします
• 類似性でグループ化する: 類似したターゲットは一貫したパターンから恩恵を受けます

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

これは簡単な参照用の例にすぎません — モデル選択ポリシーが正式なものです。シナリオが以下のどれにも当てはまらない場合は、このリストではなく選択ルールの表に従ってください。

シナリオ	ティア	理由
セキュリティ上重要なロジック (認証、決済、データ整合性)	opus	クリティカルトリガー — タスクの規模に関係なく獲得される
複数ファイルのリファクタリングまたは共有コントラクトの変更	opus	複雑性トリガー — ファイル間の広がりまたはコントラクトの変更
1 ファイル内に限定されたリファクタリングで、コントラクト変更なし	sonnet	確立されたパターンでの単一モジュールの変更
ドキュメントの生成	haiku	機械的なタスクで、コードやファイル間の推論を伴わない
ファイルごとのコードレビューまたはテスト生成	sonnet	バランスの取れた能力、確立されたパターン

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

• まず要件をグループ化する - メタジャッジをディスパッチする前に、タスクを反復可能、共有、または独立のグループ化について分析し、エージェントの総数を最小化します
• グループまたは独立したタスクごとに 1 名のメタジャッジ - 反復可能なグループは 1 つの再利用可能な仕様を共有し、共有グループは 1 つの統合された仕様を共有し、独立したタスクはそれぞれ独自の仕様を持ちます
• メタジャッジを先にバッチ実行する - すべてのメタジャッジを (グループ化の種類に関係なく) 並列で起動してから、実装者を起動します
• リトライ時に仕様を再利用する - 各グループ/ターゲットの評価仕様はリトライを通じて一定に保たれます。変更されるのは実装のみです
• ジャッジからはヘッダーのみを解析する - コンテキストの汚染を避けるため、完全なレポートは読まないでください
• CLAUDE_PLUGIN_ROOT を含める - メタジャッジとジャッジの両方に、解決済みのプラグインルートパスが必要です
• ターゲット固有の YAML - 関連するメタジャッジ YAML のみをそのジャッジに渡し、追加のテキストやコメントを加えないでください!
• 共有グループのリトライ - グループ全体ではなく、失敗した特定の実装エージェントのみを再起動します

ジャッジの選定

役割の組み合わせに従い、ジャッジのティアは実装のティアと独立しているわけではありません。デフォルトでは、両者は同じティアです。haikuティアのタスクがopusによって評価されるケースはありません。強化（「役割の組み合わせ」表を参照）で引き上げられるのは、共有の基準設定者（メタジャッジ）だけであり、ジャッジ単独のティアが引き上げられることはありません。

実装ティア	ジャッジのティア	理由
opus	opus	制作者と評価者は同じティアを共有できます
sonnet	sonnet	制作者と評価者は同じティアを共有できます
haiku	haiku	制作者と評価者は同じティアを共有できます

ガイドライン：役割の組み合わせを参照してください。

コンテキストの分離

• **最小限のコンテキスト：**各サブエージェントには、必要な情報だけを渡します
• **相互参照なし：**エージェント A にエージェント B の対象を知らせないでください
• **自ら調査させる：**サブエージェントにファイルを読ませてパターンを把握させます
• **ファイルシステムを真実の基準にする：**変更はファイルシステムを介して調整します
• **既存の変更を追跡する：**既存の変更と現在の変更の帰属が混同されないよう、各エージェントのジャッジに過去の変更に関するコンテキストを渡します

品質保証

• **3 層の検証：**自己批評（内部）＋対象固有のメタジャッジ仕様（構造化）＋ジャッジ（外部）
• **まず自己批評：**実装エージェントは提出前に自らの作業を検証します
• **対象固有のメタジャッジ仕様：**対象ごとに、その固有の特性を考慮したルーブリックを用意し、より精密な評価基準を設定します
• **次に外部ジャッジ：**独立したジャッジが対象固有のメタジャッジ仕様を機械的に適用し、自己批評では見落とされる盲点を検出します
• **反復ループ：**合格するか、最大再試行回数に達するまで、フィードバックを受けて再試行します
• 適切な反復：反復の裁量ルールを適用します。細かな指摘を理由とする再試行は最大 1 回とし、3.0未満には下げません。--strictでは無効になります
• **失敗を分離する：**1 つの対象の失敗がほかの対象に影響しないようにします
• **概要を確認する：**失敗または部分的な完了がないか確認します
• **その後にテストを実行する：**並行して行った変更が、微妙な相互作用を生む場合があります
• **アトミックにコミットする：**1 バッチのすべての変更を 1 つのコミットにまとめます

エラー処理

失敗の種類	説明	回復アクション
回復可能	ジャッジが問題を見つけ、再試行が可能	ジャッジのフィードバックを受けて再試行します（対象ごとに最大 3 回）。反復の裁量ルールに従います
アプローチの失敗	この対象に対するアプローチが誤っています	選択肢を示してユーザーにエスカレーションします
基盤の問題	要件が不明確、または実現不可能です	明確化を求めてユーザーにエスカレーションします
最大再試行回数超過	3 回再試行した後も対象が失敗しました	失敗としてマークし、ほかの対象を続行して、最後に報告します

重要なルール：

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