do-and-judge

do-and-judge

タスク

実装サブエージェントを起動して単一のタスクを実行し、独立した判定エージェントで検証します。合格するか、最大再試行回数に達するまでフィードバックを受けて反復します。

引数

引数	形式	デフォルト	説明
task	自由形式のテキスト	必須	実行するタスクの説明
--model	haiku|sonnet|opus	自動選択	すべてのサブエージェント（実装、メタ判定、判定）に適用するユーザーによる明示的な指定です。省略した場合は、モデル選択ポリシーに従ってモデルを選択する必要があります。固定のフォールバック階層はありません。指定された場合は、すべてのサブエージェントについてユーザーの選択がポリシーより優先されます。エスカレーションとの関係については、エスカレーションルールを参照してください。
--strict	--strict	false	反復裁量ルールを無効にします。タスクは score >= 4.0 の場合にのみ合格し、それ以外は最大再試行回数に達するまで再試行します。

例：/do-and-judge Refactor the UserService class to use dependency injection --strict

コンテキスト

このコマンドは、メタ判定 → LLM-as-a-judgeによる検証という単一タスク実行パターンを実装します。あなた（オーケストレーター）はメタ判定エージェント（評価基準の作成用）と実装エージェントを並列で起動し、その後、メタ判定エージェントの評価仕様を使って品質を検証する判定エージェントを起動します。検証に失敗した場合は、判定エージェントからのフィードバックを受けて新しい実装エージェントを起動し、合格する（スコア ≥4、または反復裁量ルールに基づいて承認される）か、最大再試行回数（3回）に達するまで反復します。

主なメリット：

• 新鮮なコンテキスト - 実装エージェントはクリーンなコンテキストウィンドウで作業します
• 構造化された評価 - メタ判定エージェントが判定前に、タスクに合わせた評価基準とチェックリストを作成します
• 外部検証 - 判定エージェントはメタ判定エージェントの仕様を機械的に適用し、自己批評では見落とす盲点を見つけます
• 並列実行による高速化 - メタ判定と実装を同時に実行します
• フィードバックループ - 判定エージェントが特定した問題をもとに再試行します
• 品質ゲート - 作業は基準を満たすまでリリースされません

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

1. タスクを分析し、モデル選択ポリシーに従ってモデルを選択します。デフォルトは sonnet／haiku で、opus は条件を満たす場合のみ使用します
2. メタ判定エージェントと実装エージェントをフォアグラウンドエージェントとして並列に起動します（起動順ではメタ判定エージェントを先にします）
3. メタ判定エージェントの評価仕様を添えて判定エージェントを起動します
4. 判定結果を解析し、必要に応じて反復します（最大3回の再試行）
5. 最終結果を報告するか、エスカレーションします

危険信号 - 絶対にしてはいけないこと

絶対にしてはいけません：

• コードの詳細を把握するために実装ファイルを読む（サブエージェントに任せてください）
• 自分でコードを書いたり、ソースファイルを変更したりする
• 「時間を節約する」ために判定検証を省略する
• 判定レポートをすべて読む（構造化されたヘッダーのみを解析してください）
• 最大再試行回数に達した後、ユーザーの判断を仰がずに進める

必ず行ってください：

• すべての実装作業で Task ツールを使ってサブエージェントを起動する
• メタ判定エージェントと実装エージェントを並列に起動する（起動順ではメタ判定エージェントを先にする）
• 判定エージェントを起動する前に、メタ判定と実装の両方が完了するまで待つ
• メタ判定エージェントの評価仕様を判定エージェントに渡す
• メタ判定エージェントと判定エージェントへのプロンプトに CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}`` を含める
• 判定エージェントの出力から VERDICT／SCORE／ISSUES のみを解析する
• 検証に失敗した場合はフィードバックをもとに反復する

モデル選択ポリシー

モデルの選択は、最も効果の大きい唯一の判断です。プロンプトの文言をどう工夫するかよりも、タスクが正しく完了するか、どれだけ時間がかかるかを左右します。形式的に扱ってはなりません。実行に移す前に、ティアを明示し、1行で理由を述べてください。考えるのを避けるために最強のモデルを選ぶのは、慎重さではなく失敗です。

ティアのデフォルト： sonnet と haiku がデフォルトです。opus は予約済みで、明示的な選択が必要です。下の表にある条件を満たす必要があり、確信が持てないからという理由で選んではなりません。

選択ルール

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

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

判断に迷った場合のルール： どの行にも明確には該当せず、タスクが実際に2つのティアの中間にある場合に限り、より低コストのティアを選びます。保険として opus に偏らせてはなりません。エスカレーションルールにより、低コストでの最初の推測は後から修正できます。修正できた実行1回分のコストは、実行のたびに過剰なモデルを割り当てるコストよりもはるかに低くなります。

役割の組み合わせ

モデルに割り当てられるパイプラインには、最大で3つの役割があります。producer（作業を行う）、criteria-setter（「正しい」とは何かを定義する）、evaluator（その基準に照らして作業を確認する）です。このスキルでは、それぞれ implementation／meta-judge／judge として機能します。デフォルトでは、すべての役割に同じティアを使用します。また、パイプラインに独立した criteria-setter がない場合（たとえば、モデルを割り当てるだけの計画ステップやステージなど）は、このデフォルトがそのまま唯一のルールとなります。

自明でないタスクに限り、基準を評価対象の作業より厳密にするため、criteria-setter だけを1ティア上げてもかまいません。「自明でない」かどうかは検証できます。Tie-breaker によってティアが決定された（Selection Rules の行に明確に一致しなかった）場合、またはタスクに検証可能な受け入れ条件が記載されていない場合です。

パターン	Criteria-setter（meta-judge）	Producer + evaluator（implementation + judge）	適用する場面
Sharpened-haiku	sonnet	haiku	作業自体は簡単でも、「正しい」とは何かが明確でない場合
Sharpened-sonnet	opus	sonnet	曖昧、または結果の影響が大きい受け入れ条件を伴うコード作業で、それ自体は opus のトリガーに該当しない場合

Producer と evaluator は異なるティアでもかまいません。criteria-setter が作成した基準リストが複雑すぎると思われる場合は、evaluator だけを上げてもかまいません。ただし、criteria-setter を producer より下のティアにしてはなりません。

エスカレーションルール

次のいずれかのトリガーが発生した場合、次のイテレーションではproducer と evaluator の両方（implementation と judge）を1ティア上げます。

1. 初回イテレーションの品質が低い — スコアが低い場合、または単に詳細を見落としたのではなく、モデルがタスクを誤解したことを示す問題がある場合。
2. ユーザーから品質が低すぎる、または結果が間違っていると指摘される — PASS の報告後を含め、いつ指摘されたかは問いません。

段階は haiku → sonnet → opus です。opus が上限で、それ以上のティアはありません。opus ティアの作業でも失敗した場合は、ループせず、ユーザーにエスカレーションします。

• 明示的な --model の例外（このルールを述べている箇所はここだけです）： 明示的な --model はユーザーによる上書き指定なので、トリガー（1）によってこれを暗黙に無効にしてはなりません。最大リトライ回数に達するまで、上書き指定されたモデルでイテレーションを続けます。それでも最後まで目標を達成できない場合は、見つかった問題を説明し、ユーザーにティアを上げることを提案します。トリガー（2）はその承認にあたるため、直ちにティアを上げます。
• エスカレーションによって変更するのは producer と evaluator だけです。すでに評価仕様を作成した criteria-setter は再実行もティア変更も行いません。タスクの途中で基準を変更すると、試行間の比較が無効になるためです。
• エスカレーションは、根本原因を正しく修正することの補完であり、代替ではありません。リトライ時には、judge の具体的なフィードバックを必ず渡します。同じプロンプトをより高いティアで再度実行し、うまくいくことを期待するだけの対応は禁止されています。
• エスカレーションは、スコアのしきい値や Iteration Discretion Rule とは独立しています。変更されるのは、次のイテレーションをどのモデルで実行するかであり、イテレーションが必要かどうかではありません。

プロバイダー間の同等性

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

ティア	役割	他のプロバイダーの同等モデル
haiku	高速で低コスト。機械的な作業	gemini-flash-lite、gemma クラス、gpt-oss クラス、小規模なオープンウェイトモデル
sonnet	バランスの取れた主力モデル。コード作成の大半に使用	gemini-pro クラスおよびフル版の gemini-flash（haiku ティアに相当する -lite バリアントは除く）、GPT-5-mini クラス、大規模な Qwen ／ DeepSeek クラス
opus	最先端の推論。重要または複雑な作業	各プロバイダーが拡張／熟考型推論ティアとして提供するモデル。現時点では GPT-5.5、deep-think モード、Kimi K3 クラスなど、処理量よりも長い熟考を強みとするモデル

対応付けは名前ではなく、能力ティアに基づきます。ベンダーが新しいモデルをリリースするにつれて、正確なモデル名は変わります。上記のルールはすべてティアで定義されています。そのため、他のプロバイダーでは、ティアを該当クラスのモデルに対応付けてから、選択、ペアリング、エスカレーションのルールをそのまま適用してください。

プロセス

フェーズ 1：タスクの分析とモデルの選択

最初に設定を解決します。STRICT_MODE = --strict present || false。タスクテキストからすべてのフラグを取り除き、サブエージェントのプロンプトには決して渡さないでください。

ユーザーが --model を渡していない場合は、タスクを次の 3 つの軸で評価し、選択ルールの表からティアを直接読み取ります。

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

実行を指示する前に、3 つの評価結果、選択したティア、および 1 行の根拠を示します。次に役割のペアリングを適用し、メタジャッジのティアを決定します。タスクが本当に判断しにくい場合を除き、実装と同じティアにしてください。ユーザーが --model を渡した場合は、どちらのステップも実行しません。 そのティアを実装、メタジャッジ、ジャッジのすべてに使用し、役割のペアリングによってメタジャッジのティアを引き上げてはなりません。

専門エージェント： sdd プラグインに含まれる一般的なエージェントには、sdd:developer、sdd:researcher、sdd:software-architect、sdd:tech-lead、sdd:business-analyst があります。適切な専門エージェントが利用できない場合は、専門化されていない汎用エージェントに切り替えてください。タスクと専門エージェントの間に直接の関連性がない場合、またはそのエージェントが利用できない場合は、必ず general-purpose を使用してください。

フェーズ 2：メタジャッジと実装エージェントの実行（並列）

重大： 2 つの Task ツール呼び出しを使い、両方のエージェントを同じメッセージで起動してください。実装エージェントが成果物を変更する前に確認できるよう、メタジャッジをメッセージ内の最初のツール呼び出しにしてください。

両エージェントはフォアグラウンドで実行されます。フェーズ 3 に進む前に、両方の完了を待ってください。

2.1 メタジャッジのプロンプト

メタジャッジは、このタスクに合わせた評価仕様（ルーブリック、チェックリスト、採点基準）を作成します。評価仕様は YAML で返されます。

## Task

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

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## User Prompt
{Original task description from user}

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

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

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

Use Task tool:
  - description: "Meta-judge: {brief task summary}"
  - prompt: {meta-judge prompt}
  - model: {meta-judge model — the user's `--model` if one was passed; otherwise same as implementation, or one tier up per Role Pairing}
  - subagent_type: "sadd:meta-judge"

2.2 実装エージェントのプロンプト

次の必須要素を含む実装プロンプトを作成します。

ゼロショットの思考連鎖プレフィックス（必須 — 必ず最初に配置）

## Reasoning Approach

Before taking any action, think through this task systematically.

Let's approach this step by step:

1. "Let me understand what this task requires..."
   - What is the specific objective?
   - What constraints exist?
   - What is the expected outcome?

2. "Let me explore the relevant code..."
   - What files are involved?
   - What patterns exist in the codebase?
   - What dependencies need consideration?

3. "Let me plan my approach..."
   - What specific modifications are needed?
   - What order should I make them?
   - What could go wrong?

4. "Let me verify my approach before implementing..."
   - Does my plan achieve the objective?
   - Am I following existing patterns?
   - Is there a simpler way?

Work through each step explicitly before implementing.

タスク本文

## Task
{Task description from user}

## Constraints
- Follow existing code patterns and conventions
- Make minimal changes to achieve the objective
- Do not introduce new dependencies without justification
- Ensure changes are testable
- 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.

## Output
Provide your implementation along with 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

自己批評サフィックス（必須 — 必ず最後に配置）

## Self-Critique Verification (MANDATORY)

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

### Verification Questions

| # | Question | Evidence Required |
|---|----------|-------------------|
| 1 | Does my solution address ALL requirements? | [Specific evidence] |
| 2 | Did I follow existing code patterns? | [Pattern examples] |
| 3 | Are there any edge cases I missed? | [Edge case analysis] |
| 4 | Is my solution the simplest approach? | [Alternatives considered] |
| 5 | Would this pass code review? | [Quality check] |

### Answer Each Question with Evidence

Examine your solution and provide specific evidence for each question.

### Revise If Needed

If ANY verification question reveals a gap:
1. **FIX** - Address the specific gap identified
2. **RE-VERIFY** - Confirm the fix resolves the issue
3. **UPDATE** - Update the Summary section

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

実行指示

タスクと利用可能なエージェントに基づいて最適なエージェントの種類を決定します。たとえば、コードの実装には sdd:developer エージェントを使用します。判断に迷う場合は、誤った種類のエージェントを実行するより、general-purpose エージェントを使用してください。

Use Task tool:
  - description: "Implement: {brief task summary}"
  - prompt: {constructed prompt with CoT + task + self-critique}
  - model: {selected implementation model}
  - subagent_type: "{selected agent type}"

2.3 並列実行の例

2 つの Task ツール呼び出しを同じメッセージで送信します。メタジャッジを先に、実装を後にしてください。

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

  Tool call 2 (implementation):
    - description: "Implement: {brief task summary}"
    - model: {selected implementation model}
    - subagent_type: "{selected agent type}"

フェーズ 3 に進む前に、両方からの返答を待ってください。

フェーズ 3: ジャッジエージェントのディスパッチ

メタジャッジと実装の両方が完了したら、ジャッジエージェントをディスパッチします。

重要: ジャッジにはメタジャッジの評価仕様 YAML を正確にそのまま渡してください。省略や追加は一切行わず、いかなる形でも変更せず、テキストを短縮したり要約したりしないでください。

メタジャッジの出力から抽出:

• 最終的な評価仕様 YAML

実装の出力から抽出:

• 概要セクション (変更されたファイル、主な変更点)
• 変更されたファイルのパス

3.1 既存の変更セクションの分析

ジャッジをディスパッチする前に、ジャッジが認識しておく必要のある既存の変更がコードベースに存在するかどうかを評価します。「既存の変更」セクションは、ジャッジが以前の変更を現在の実装エージェントの作業と混同するのを防ぎます。

含めるべき場合:

• 同じセッション内で以前に完了した do-and-judge タスクの実行
• スキルを呼び出す前に行われたユーザーの手動変更 (会話コンテキストまたは git で確認可能)
• このタスクより前に実行された他のツールやエージェントによる変更

省略すべき場合:

• 既知の以前の変更がなく、これが最初のタスクである場合は、セクション全体を省略します
• 同じタスク内でのリトライでは、実装エージェント自身の以前の試行を「既存の変更」として含めないでください。それらは現在のタスクのイテレーションサイクルの一部です

コンテンツのガイドライン:

• 高レベルの概要を使用します: タスクの説明、影響を受けるファイル/モジュールのリスト、変更の一般的な性質 (作成、変更、削除)
• コードブロック、差分、行レベルの詳細は含めず、簡潔に保ちます
• ソースを明確にラベル付けします: 「以前のタスク: {説明}」、「ユーザーの変更 (現在のタスクより前)」など
• 既存の変更のソースが複数ある場合は、それぞれに別々のサブセクションを使用します

重要: コードベース全体や git 履歴を読むことは避け、高レベルの git diff/status を使用してどのファイルが変更されたかを判断するか、会話コンテキストを使用して既存の変更があるかどうかを判断してください。

3.2 プロンプトと仕様 YAML を使用したジャッジの起動

ジャッジプロンプトテンプレート:

You are evaluating an implementation artifact against an evaluation specification produced by the meta judge.

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## User Prompt
{Original task description from user}

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

## Pre-existing Changes (Context Only)

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

### {Source of changes: e.g., "Previous Task: {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}

実装の出力

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

指示

エージェントの指示で定義されている完全なジャッジプロセスに従ってください!

出力

重要: 応答の冒頭に、この正確な構造化評価レポート形式を YAML で返信する必要があります!

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

**Dispatch:**

Task ツールを使用:

• description: "Judge: {簡単なタスク概要}"
• prompt: {メタジャッジの正確な仕様 YAML を含むジャッジ検証プロンプト、および該当する場合は既存の変更セクション}
• model: {ジャッジモデル — エスカレーション後も含め、現在の実装モデルと一致している必要があります}
• subagent_type: "sadd:judge"

### Phase 4: Parse Verdict and Iterate

Parse judge output (DO NOT read full report):

ジャッジの返信から抽出:

• VERDICT: PASS または FAIL
• SCORE: X.X/5.0
• ISSUES: 問題のリスト (ある場合)
• IMPROVEMENTS: 提案のリスト (ある場合)

**Decision logic:**

スコア ≥4 の場合: → VERDICT: PASS → 概要とともに成功を報告 → IMPROVEMENTS を任意の改善として含める

3.0 ≤ スコア <4 かつ STRICT_MODE でない場合: → 以下のイテレーション裁量ルールを適用 → 承認 → VERDICT: PASS (未解決の問題を報告) → 却下 → VERDICT: FAIL → 以下の「リトライ回数の確認」へ進む

それ以外の場合 (スコア <3.0、または STRICT_MODE でスコア <4): → VERDICT: FAIL → リトライ回数を確認

リトライ < 3 の場合: → フェーズ 5「リトライ時のモデルエスカレーション」に従ってリトライ層を決定 (実装とジャッジの両方を引き上げるか、維持する) → ジャッジのフィードバックを添えてリトライ実装エージェントをディスパッチ → フェーズ 3 に戻る (同じメタジャッジ仕様でのジャッジ検証)

リトライ ≥ 3 の場合: → ユーザーにエスカレーション (エラー処理を参照) → ユーザーの判断なしに進めない

Note: `retries` counts attempts within the CURRENT cycle only. This budget **resets** on re-entry after a reported PASS (see [Phase 6 Re-entry](#phase-6-final-report)) — a later user quality complaint opens a fresh cycle of up to 3 retries even if a prior cycle already reached the limit above.

#### Iteration Discretion Rule

Your main task is to COMPLETE the task within target quality. Two failure modes are equally real:

- Burning retries and context on nitpicks so the task never completes on time → **the task is failed**; a developer is waiting on this result and may have dependent work blocked, so implementation effort MUST stay proportionate to the task's size.
- Reporting a result whose quality is genuinely too poor to be considered complete → **an even worse failure**.

Apply to every judge score:

- **`score < 3.0` → FAIL, unconditionally. No discretion.** Retry with judge feedback until it passes or max retries is reached.
- **`3.0 <= score < 4.0` → discretion band.** ONLY inside this band MAY you decide that a result below the `4.0` target is acceptable. The fixed `4.0` target puts the effective floor at `3.0`, so no separate bounded-drop guard is needed.
- Inside the band, when the outstanding issues are ONLY low/medium priority (any High or Critical finding removes discretion entirely) AND none of them breaks a target requirement of the task or causes a meaningful defect (i.e. they are nitpicks), you MUST reason FIRST — before dispatching a retry — about whether another attempt is worth the developer's time and your context.
- **At most ONE nitpick-driven retry**, and it counts against the retry budget. If it again surfaces only nitpicks, you MUST report PASS (☑️ ACCEPTED) with the outstanding issues listed in the final report. If it returns a score below `3.0`, the unconditional-FAIL rule applies instead.
- You MUST be critical, NOT lenient. Stopping short of target MUST be an intentional decision grounded in the absence of real, requirement-breaking issues. A genuine blocking issue that prevents completing the task within max retries MUST be escalated as a failure, never papered over.
- **If `STRICT_MODE` is true, this whole rule is DISABLED**: stop only when `score >= 4.0` or max retries is reached. `--strict` changes nothing else — the `4.0` target, the max-retry limit, the `< 3.0` unconditional FAIL and meta-judge/judge dispatch are unaffected.

### Phase 5: Retry with Feedback (If Needed)

#### Model Escalation on Retry

Before dispatching any retry you MUST decide the tier explicitly per the [Escalation Rule](#escalation-rule) — which governs in full — and state the decision in your output. 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).
- **Hold the tier** when the failure is a specific fixable defect rather than a capability gap — narrow, precisely specified issues are resolved faster by a same-tier retry with exact feedback.
- If `opus` still fails, escalate to the user per [Error Handling](#error-handling).

**Retry prompt template:**

```markdown
## Retry Required

Your previous implementation did not pass judge verification.

## Original Task
{Original task description}

## Judge Feedback
VERDICT: FAIL
SCORE: {score}/5.0
ISSUES:
{list of issues from judge}

## Your Previous Changes
{files modified in previous attempt}

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

1. Review each issue the judge identified
2. For each issue, determine the root cause
3. Plan the fix for each issue
4. Implement ALL fixes
5. Verify your fixes address each issue
6. Provide updated Summary section

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

フェーズ 6：最終レポート

タスクが検証に合格した後：

## Execution Summary

**Task:** {original task description}
**Result:** ✅ PASS (or ☑️ ACCEPTED below target per the Iteration Discretion Rule)
**Strict Mode:** {STRICT_MODE}

### Verification
| Attempt | Score | Status |
|---------|-------|--------|
| 1 | {X.X}/5.0 | {PASS/ACCEPTED/FAIL} |
| {N} | {X.X}/5.0 | {PASS/ACCEPTED/FAIL} | (one row per retry that occurred, up to 3)

### Outstanding Issues (if accepted below target)
{Nitpicks left unresolved, with priority — omit this section when score >= 4.0}

### Files Modified
- {file1}: {what changed}
- {file2}: {what changed}

### Key Changes
- {change 1}
- {change 2}

### Suggested Improvements (Optional)
{IMPROVEMENTS from judge, if any}

レポート後の再開： PASS を報告しても、タスクは終了しません。その後、ユーザーから結果が間違っている、または品質が低すぎると指摘された場合は、その指摘をフィードバックとしてフェーズ 5 に戻ってください。これはエスカレーションルールのトリガー（2）に該当するため、プロデューサーと評価者を両方とも 1 段階上げ（すでに opus の場合を除く）、再試行します。再試行回数の上限はリセットされます。指摘によって新しいサイクルが開始され、前のサイクルで上限に達していても、最大 3 回まで再試行できます。

エラー処理

最大再試行回数を超えた場合

3 回再試行しても検証に合格しない場合：

1. 停止 - 先に進まないでください
2. 報告 - 失敗の分析を提示します：
   • 元のタスク要件
   • すべての判定結果とスコア
   • 再試行を通じて解消されない問題
3. エスカレーション - ユーザーに選択肢を提示します：
   • 再試行に向けて追加のコンテキストやガイダンスを提供する
   • 次のモデルティアで再実行する（すでに opus で実行されていた場合は利用できません）
   • タスク要件を変更する
   • タスクを中止する
4. 待機 - ユーザーが判断するまで、先に進まないでください

エスカレーションレポートの形式：

## Task Failed Verification (Max Retries Exceeded)

### Task Requirements
{original task description}

### Verification History
| Attempt | Score | Key Issues |
|---------|-------|------------|
| 1 | {X.X}/5.0 | {issues} |
| 2 | {X.X}/5.0 | {issues} |
| 3 | {X.X}/5.0 | {issues} |

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

### Options
1. **Provide guidance** - Give additional context for another retry
2. **Escalate the tier** - Re-run implementation and judge one tier up (omit this option if already `opus`)
3. **Modify requirements** - Simplify or clarify task
4. **Abort** - Stop execution

Awaiting your decision...

例

例 1：ドキュメントの更新（初回で合格）

入力：

/do-and-judge Rewrite the API authentication section in docs/api-reference.md to cover the new OAuth2 flow

実行：

Phase 1: Task Analysis
  - Complexity: Medium (rewriting existing documentation with new technical flow)
  - Risk: Low (documentation only, no code changes)
  - Scope: Small (single file, focused section)
  → Model: haiku (implementation + judge), sonnet (meta-judge)
    Reasoning: Single documentation file, no code written — no opus
    trigger fires. It is more than a one-line correction, so it straddles
    haiku/sonnet; the tie-breaker sends it DOWN to haiku, and escalation
    covers a thin first pass. The task states no checkable acceptance
    condition — the second non-obvious disjunct — so the sharpened-haiku
    pairing raises the meta-judge one tier to sonnet.
  → Agent type: general-purpose
    Reasoning: This is a documentation task — writing and restructuring
    prose, not implementing code. The sdd:developer agent is optimized
    for code implementation patterns, not technical writing. A
    general-purpose agent handles documentation tasks more effectively
    because it applies broader writing and reasoning skills without
    code-centric constraints.

Phase 2: Parallel Dispatch (single message, 2 tool calls)
  Tool call 1 — Meta-judge (Sonnet)...
    Meta-judge prompt sent:
    ┌─────────────────────────────────────────────────────────
    │ ## Task
    │ Generate an evaluation specification yaml for the
    │ following task. You will produce rubrics, checklists,
    │ and scoring criteria that a judge agent will use to
    │ evaluate the implementation artifact.
    │
    │ CLAUDE_PLUGIN_ROOT=...
    │
    │ ## User Prompt
    │ Rewrite the API authentication section in
    │ docs/api-reference.md to cover the new OAuth2 flow
    │
    │ ## Context
    │ Existing docs/api-reference.md contains an outdated
    │ "Authentication" section describing API key auth.
    │ The codebase recently migrated to OAuth2 with PKCE.
    │ Related source: src/auth/oauth2.ts, src/auth/config.ts.
    │
    │ ## Artifact Type
    │ documentation
    │
    │ ## Instructions
    │ Return only the final evaluation specification YAML
    │ in your response.
    └─────────────────────────────────────────────────────────
    → Generated evaluation specification YAML
    → 3 rubric dimensions (accuracy, completeness, clarity)
    → 5 checklist items

  Tool call 2 — Implementation (general-purpose + Haiku)...
    Implementation prompt sent (abbreviated):
    ┌─────────────────────────────────────────────────────────
    │ ## Reasoning Approach
    │ Before taking any action, think through this task
    │ systematically.
    │ [... step-by-step reasoning template ...]
    │
    │ ## Task
    │ Rewrite the API authentication section in
    │ docs/api-reference.md to cover the new OAuth2 flow.
    │ Replace the outdated API key auth documentation with
    │ OAuth2 + PKCE flow documentation including token
    │ endpoints, scopes, refresh token handling, and
    │ example requests.
    │
    │ ## Constraints
    │ - Follow existing documentation patterns and conventions
    │ - Make minimal changes to achieve the objective
    │ - Do not introduce new dependencies without justification
    │ - Ensure changes are testable
    │
    │ ## Output
    │ Provide your implementation along with 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
    │
    │ ## Self-Critique Verification (MANDATORY)
    │ [... verification questions and revision process ...]
    └─────────────────────────────────────────────────────────
    → Rewrote Authentication section in docs/api-reference.md
    → Added OAuth2 flow diagram, token endpoints, scopes table
    → Added code examples for authorization and token refresh
    → Summary: 1 file modified, authentication section rewritten

Phase 3: Dispatch Judge (with meta-judge specification)
  NOTE: No pre-existing changes — first task on a clean codebase.
  The "Pre-existing Changes" section is OMITTED from the judge prompt.

  Judge prompt sent:
  ┌─────────────────────────────────────────────────────────
  │ You are evaluating an implementation artifact against
  │ an evaluation specification produced by the meta judge.
  │
  │ CLAUDE_PLUGIN_ROOT=...
  │
  │ ## User Prompt
  │ Rewrite the API authentication section in
  │ docs/api-reference.md to cover the new OAuth2 flow
  │
  │ ## Evaluation Specification
  │ ```yaml
  │ {meta-judge's evaluation specification YAML}
  │ ```
  │
  │ ## Implementation Output
  │ Files: docs/api-reference.md (modified)
  │ Key changes: Replaced API key auth section with OAuth2
  │ + PKCE flow, added token endpoints, scopes table,
  │ and code examples for authorization and refresh...
  │
  │ ## Instructions
  │ Follow your full judge process...
  └─────────────────────────────────────────────────────────

  Judge (sadd:judge + Haiku)...   ← same tier as implementation
    → VERDICT: PASS, SCORE: 4.2/5.0
    → ISSUES: None
    → IMPROVEMENTS: Add error response examples for expired tokens

Phase 4: Parse Verdict
  → Score 4.2 ≥ 4.0 threshold → PASS
  → No retry needed (Phase 5 skipped)

Phase 6: Final Report
  ✅ PASS on attempt 1
  Files: docs/api-reference.md (modified)

例 2：モデルのエスカレーション後に再試行して合格

入力：

/do-and-judge Implement rate limiting middleware with configurable limits per endpoint

実行：

Phase 1: Task Analysis
  - Complexity: Medium (new middleware, established pattern)
  - Risk: Medium (middleware sits in front of all endpoints)
  - Scope: Small (single middleware + config schema)
  → Model: sonnet (implementation + meta-judge + judge)
    Reasoning: Code writing on an established pattern, confined to one
    module. No opus trigger fires — not multi-file, not complex logic,
    and rate limiting is on none of the critical list; breadth of reach
    is not itself a trigger. Same tier for all three roles.

Phase 2: Parallel Dispatch (Attempt 1)
  Tool call 1 — Meta-judge (Sonnet)...
    → Generated evaluation specification YAML
    → 4 rubric dimensions, 8 checklist items
  Tool call 2 — Implementation (sdd:developer + Sonnet)...
    → Created RateLimiter middleware
    → Added configuration schema

Phase 3: Dispatch Judge (with meta-judge specification)
  Judge (sadd:judge + Sonnet)...
    → VERDICT: FAIL, SCORE: 2.9/5.0
    → ISSUES:
      - Missing per-endpoint configuration (a stated requirement)
      - Limiter is not concurrency-safe under parallel requests
    → IMPROVEMENTS: Add monitoring hooks

Phase 5: Retry with Feedback
  Model Escalation on Retry:
    → Score 2.9 < 3.0 and the concurrency issue shows the task was
      misunderstood, not merely under-delivered → ESCALATE
    → Bump BOTH implementation and judge: sonnet → opus
    → Meta-judge NOT re-run, NOT re-tiered — same specification reused
  Implementation (sdd:developer + Opus)...
    → Added endpoint-specific limits
    → Replaced the counter with an atomic, concurrency-safe token bucket

Phase 3: Dispatch Judge (Attempt 2, same meta-judge specification)
  Judge (sadd:judge + Opus)...   ← escalated with the implementation
    → VERDICT: PASS, SCORE: 4.4/5.0
    → IMPROVEMENTS: Add metrics export

Phase 6: Final Report
  ✅ PASS on attempt 2
  Files: RateLimiter.ts, config/rateLimits.ts, adapters/RedisAdapter.ts

例 3：エスカレーションが必要なタスク

入力：

/do-and-judge Migrate the database schema to support multi-tenancy

実行：

Phase 1: Task Analysis
  - Complexity: High (multi-tenancy affects every query path)
  - Risk: High (database schema change)
  - Scope: Large (schema, migrations, query layer)
  → Model: opus (implementation + meta-judge + judge)
    Reasoning: opus is EARNED here — two triggers fire: multi-file
    refactoring and critical (data integrity, irreversible migration).

Phase 2: Parallel Dispatch
  Meta-judge → evaluation specification YAML
  Implementation → initial migration scaffolding

Attempt 1: FAIL (2.8/5.0) - Missing tenant isolation in queries
Attempt 2: FAIL (3.2/5.0) - Incomplete migration script
Attempt 3: FAIL (3.3/5.0) - Edge cases in existing data migration

ESCALATION:
  Persistent issue: Existing data migration requires business decisions
  about how to handle orphaned records.

  Options presented to user (tier escalation omitted — already at the
  opus ceiling, no bump available):
  1. Provide guidance on orphan handling
  2. Simplify to new tenants only
  3. Abort

User chose: Option 1 - "Delete orphaned records older than 1 year"

Attempt 4 (with guidance): PASS (4.1/5.0)

例 4：順次実行する do-and-judge（前のタスクから引き継がれた変更がある場合）

入力（1 回目）：

/do-and-judge add basic authentication module

実行（1 回目）：

Phase 1: Task Analysis
  - Complexity: High (new feature, security-sensitive)
  - Risk: High (authentication is critical)
  - Scope: Medium (new module, several files)
  → Model: opus (implementation + meta-judge + judge)
    Reasoning: opus is EARNED — the critical trigger fires on auth.
  - Pre-existing Changes: None

Phase 2: Parallel Dispatch (Attempt 1)
  Tool call 1 — Meta-judge (Opus)...
    Meta-judge prompt sent:
    ┌─────────────────────────────────────────────────────────
    │ ## Task
    │ Generate an evaluation specification yaml for the
    │ following task. You will produce rubrics, checklists,
    │ and scoring criteria that a judge agent will use to
    │ evaluate the implementation artifact.
    │
    │ CLAUDE_PLUGIN_ROOT=...
    │
    │ ## User Prompt
    │ Add basic authentication module
    │
    │ ## Context
    │ Express.js backend, src/auth/ directory does not exist
    │ yet. Existing middleware pattern in src/middleware/.
    │
    │ ## Artifact Type
    │ code
    │
    │ ## Instructions
    │ Return only the final evaluation specification YAML
    │ in your response.
    └─────────────────────────────────────────────────────────
    → Generated evaluation specification YAML
    → 4 rubric dimensions, 7 checklist items

  Tool call 2 — Implementation (sdd:developer + Opus)...
    Implementation prompt sent (abbreviated):
    ┌─────────────────────────────────────────────────────────
    │ ## Reasoning Approach
    │ Before taking any action, think through this task
    │ systematically.
    │ [... step-by-step reasoning template ...]
    │
    │ ## Task
    │ Add basic authentication module to the Express.js
    │ backend. Create login, logout, and register endpoints
    │ with proper middleware for route protection.
    │
    │ ## Constraints
    │ - Follow existing code patterns and conventions
    │ - Make minimal changes to achieve the objective
    │ - Do not introduce new dependencies without
    │   justification
    │ - Ensure changes are testable
    │
    │ ## Output
    │ Provide your implementation along with 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
    │
    │ ## Self-Critique Verification (MANDATORY)
    │ [... verification questions and revision process ...]
    └─────────────────────────────────────────────────────────
    → Created src/auth/AuthService.ts
    → Created src/auth/AuthMiddleware.ts
    → Created src/auth/auth.routes.ts
    → Modified src/app.ts
    → Summary: 4 files changed, auth module added

Phase 3: Dispatch Judge (with meta-judge specification)
  NOTE: No pre-existing changes — this is the first task on a clean codebase.
  The "Pre-existing Changes" section is OMITTED from the judge prompt.

  Judge prompt sent:
  ┌─────────────────────────────────────────────────────────
  │ You are evaluating an implementation artifact against
  │ an evaluation specification produced by the meta judge.
  │
  │ CLAUDE_PLUGIN_ROOT=...
  │
  │ ## User Prompt
  │ Add basic authentication module
  │
  │ ## Evaluation Specification
  │ ```yaml
  │ {meta-judge's evaluation specification YAML}
  │ ```
  │
  │ ## Implementation Output
  │ Files: src/auth/AuthService.ts (new), ...
  │ Key changes: Added login/logout/register endpoints...
  │
  │ ## Instructions
  │ Follow your full judge process...
  └─────────────────────────────────────────────────────────

  Judge (sadd:judge + Opus)...
    → VERDICT: FAIL, SCORE: 3.0/5.0
    → ISSUES:
      - Missing password hashing (plain-text storage)
      - No unit tests for AuthService
    → IMPROVEMENTS: Add rate limiting on login endpoint

Phase 5: Retry with Feedback (Attempt 2)
  Model Escalation on Retry:
    → Already at opus — the ceiling, no bump available. Retry at the
      same tier with the judge's specific feedback; if this fails
      repeatedly, escalate to the user rather than looping.
  Implementation (sdd:developer + Opus)...
    → Added bcrypt password hashing
    → Created tests/auth/AuthService.test.ts
    → Summary: 2 files modified, 1 file created

Phase 3: Dispatch Judge (Attempt 2, same meta-judge specification)
  NOTE: This is a retry within the SAME task — do NOT include the
  implementation agent's previous attempt as "pre-existing changes".
  The "Pre-existing Changes" section is still OMITTED.

  Judge (sadd:judge + Opus)...
    → VERDICT: PASS, SCORE: 4.3/5.0
    → IMPROVEMENTS: Add integration tests

Phase 6: Final Report
  ✅ PASS on attempt 2
  Files: AuthService.ts, AuthMiddleware.ts, auth.routes.ts,
         AuthService.test.ts, app.ts

入力（2 回目、同じセッション）：

/do-and-judge refactor auth module to use dependency injection

実行（2 回目）：

Phase 1: Task Analysis
  - Complexity: Medium (refactoring existing code)
  - Risk: Medium (modifying working auth module)
  - Scope: Large (5 files across the module and its wiring)
  → Model: opus (implementation + meta-judge + judge)
    Reasoning: opus is EARNED — multi-file refactoring, and the module
    being rewired is the security-critical auth path.
  - Pre-existing Changes: Auth module created in previous task

Phase 2: Parallel Dispatch
  Tool call 1 — Meta-judge (Opus)...
    Meta-judge prompt sent:
    ┌─────────────────────────────────────────────────────────
    │ ## Task
    │ Generate an evaluation specification yaml for the
    │ following task. You will produce rubrics, checklists,
    │ and scoring criteria that a judge agent will use to
    │ evaluate the implementation artifact.
    │
    │ CLAUDE_PLUGIN_ROOT=...
    │
    │ ## User Prompt
    │ Refactor auth module to use dependency injection
    │
    │ ## Context
    │ Existing auth module at src/auth/ with AuthService,
    │ AuthMiddleware, auth.routes. Tests in tests/auth/.
    │
    │ ## Artifact Type
    │ code
    │
    │ ## Instructions
    │ Return only the final evaluation specification YAML
    │ in your response.
    └─────────────────────────────────────────────────────────
    → Generated evaluation specification YAML
    → 3 rubric dimensions, 5 checklist items

  Tool call 2 — Implementation (sdd:developer + Opus)...
    Implementation prompt sent (abbreviated):
    ┌─────────────────────────────────────────────────────────
    │ ## Reasoning Approach
    │ Before taking any action, think through this task
    │ systematically.
    │ [... step-by-step reasoning template ...]
    │
    │ ## Task
    │ Refactor the auth module to use dependency injection.
    │ AuthService should accept its dependencies via
    │ constructor instead of importing them directly.
    │
    │ ## Constraints
    │ - Follow existing code patterns and conventions
    │ - Make minimal changes to achieve the objective
    │ - Do not introduce new dependencies without
    │   justification
    │ - Ensure changes are testable
    │
    │ ## Output
    │ Provide your implementation along with 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
    │
    │ ## Self-Critique Verification (MANDATORY)
    │ [... verification questions and revision process ...]
    └─────────────────────────────────────────────────────────
    → Refactored AuthService to accept dependencies via constructor
    → Created src/auth/AuthServiceFactory.ts
    → Updated tests to use mocked dependencies
    → Summary: 4 files modified, 1 file created

Phase 3: Dispatch Judge (with meta-judge specification)
  NOTE: Pre-existing changes detected — the previous do-and-judge run
  created the auth module. Include "Pre-existing Changes" section so the
  judge does not confuse prior work with the current refactoring task.

  Judge prompt sent:
  ┌─────────────────────────────────────────────────────────
  │ You are evaluating an implementation artifact against
  │ an evaluation specification produced by the meta judge.
  │
  │ CLAUDE_PLUGIN_ROOT=...
  │
  │ ## User Prompt
  │ Refactor auth module to use dependency injection
  │
  │ ## Pre-existing Changes (Context Only)
  │
  │ The following changes were made BEFORE the current
  │ implementation agent started working. They are NOT part
  │ of the current task's output. Focus your evaluation on
  │ the current task's changes. Only verify pre-existing
  │ changed files/logic if they directly relate to the
  │ current task requirements.
  │
  │ ### Previous Task: "Add basic authentication module"
  │ The following files were created/modified as part of a
  │ previous task:
  │ - src/auth/AuthService.ts (new) - Authentication service
  │   with login/logout/register
  │ - src/auth/AuthMiddleware.ts (new) - Express middleware
  │   for route protection
  │ - src/auth/auth.routes.ts (new) - Auth API routes
  │ - tests/auth/AuthService.test.ts (new) - Unit tests for
  │   auth service
  │ - src/app.ts (modified) - Integrated auth routes and
  │   middleware
  │
  │ These files exist in the codebase and may be modified by
  │ the current task, but you should evaluate only the
  │ changes made by the current implementation agent for the
  │ current task (refactoring to dependency injection).
  │
  │ ## Evaluation Specification
  │ ```yaml
  │ {meta-judge's evaluation specification YAML}
  │ ```
  │
  │ ## Implementation Output
  │ Files: src/auth/AuthService.ts (modified), ...
  │ Key changes: Refactored to constructor injection...
  │
  │ ## Instructions
  │ Follow your full judge process...
  └─────────────────────────────────────────────────────────

  Judge (sadd:judge + Opus)...
    → VERDICT: PASS, SCORE: 4.5/5.0
    → ISSUES: None
    → IMPROVEMENTS: Add interface documentation

Phase 6: Final Report
  ✅ PASS on attempt 1
  Files: AuthService.ts (modified), AuthServiceFactory.ts (new),
         AuthMiddleware.ts (modified), AuthService.test.ts (modified),
         app.ts (modified)

例 5：do-and-judge の前にユーザーがコードベースを変更した場合

シナリオ：

会話中、ユーザーは EC サイトのコードベースに取り組んでいます。do-and-judge を実行する前に、ショッピングカート、商品カタログ、チェックアウトのフローを変更しました。

入力：

/do-and-judge fix shopping cart module bug when it adds duplicated items

実行：

Phase 1: Task Analysis
  - Complexity: Medium (bug fix in existing module)
  - Risk: Medium (cart logic affects checkout)
  - Scope: Small (focused bug fix)
  → Model: sonnet (implementation + meta-judge + judge)
    Reasoning: Code writing on a contained bug plus a regression test.
    No opus trigger — not a multi-file refactor, nothing on the critical
    list (in-memory cart state, not billing), no intricate logic. Too
    much reasoning is needed for haiku, so sonnet for all three roles.
  - Pre-existing Changes: User modified several files before this task

Phase 2: Parallel Dispatch
  Tool call 1 — Meta-judge (Sonnet)...
    → Generated evaluation specification YAML
    → 3 rubric dimensions, 5 checklist items
  Tool call 2 — Implementation (sdd:developer + Sonnet)...
    → Fixed duplicate detection in CartService.addItem()
    → Added deduplication guard in cart.routes.ts
    → Added regression test for duplicate item scenario
    → Summary: 3 files modified

Phase 3: Dispatch Judge (with meta-judge specification)
  NOTE: The orchestrator is aware from git diff/status that the user
  modified several files before this task. Include "Pre-existing Changes"
  section so the judge focuses only on the bug fix.

  Judge prompt sent:
  ┌─────────────────────────────────────────────────────────
  │ You are evaluating an implementation artifact against
  │ an evaluation specification produced by the meta judge.
  │
  │ CLAUDE_PLUGIN_ROOT=...
  │
  │ ## User Prompt
  │ Fix shopping cart module bug when it adds duplicated items
  │
  │ ## Pre-existing Changes (Context Only)
  │
  │ The following changes were made BEFORE the current
  │ implementation agent started working. They are NOT part
  │ of the current task's output. Focus your evaluation on
  │ the current task's changes. Only verify pre-existing
  │ changed files/logic if they directly relate to the
  │ current task requirements.
  │
  │ ### User modifications (before current task)
  │ The user made changes to the following files/modules
  │ before this task was started:
  │ - src/cart/CartService.ts (modified) - Shopping cart
  │   business logic updates
  │ - src/cart/cart.routes.ts (modified) - Updated cart API
  │   endpoints
  │ - src/products/ProductCatalog.ts (modified) - Product
  │   listing changes
  │ - src/checkout/CheckoutFlow.ts (modified) - Checkout
  │   process updates
  │ - tests/cart/CartService.test.ts (modified) - Updated
  │   cart tests
  │
  │ The current task focuses specifically on fixing the
  │ duplicate items bug in the shopping cart module.
  │ Pre-existing changes to cart files may overlap with the
  │ current task scope — evaluate whether the implementation
  │ agent's changes correctly address the bug without
  │ breaking the pre-existing modifications.
  │
  │ ## Evaluation Specification
  │ ```yaml
  │ {meta-judge's evaluation specification YAML}
  │ ```
  │
  │ ## Implementation Output
  │ Files: src/cart/CartService.ts (modified), ...
  │ Key changes: Added duplicate item detection...
  │
  │ ## Instructions
  │ Follow your full judge process...
  └─────────────────────────────────────────────────────────

  Judge (sadd:judge + Sonnet)...   ← same tier as implementation
    → VERDICT: PASS, SCORE: 4.1/5.0
    → ISSUES: None
    → IMPROVEMENTS: Consider extracting deduplication logic
      into a shared utility

Phase 6: Final Report
  ✅ PASS on attempt 1
  Files: CartService.ts (modified), cart.routes.ts (modified),
         CartService.test.ts (modified)

ベストプラクティス

モデルの選択

ルールはモデル選択ポリシーで定められています。以下は、そのルールを徹底するための習慣です：

• 判断理由を明確に述べる - ディスパッチする前に、対象範囲、複雑さ、リスクと、それに基づくティアを示します。これは実行全体で最も影響の大きい判断です
• opus は必要な場合にのみ選ぶ - 重複や同点はすべて、直感ではなく選択ルールの優先順位とタイブレークルールに従って解決します
• 役割間でティアを統一する - ティアを上げるのは基準設定者（メタジャッジ）のみとし、タスクが明白でない場合に限ります（役割の組み合わせ）
• 根拠に基づいてエスカレーションする - 明らかに質の低い反復結果、またはユーザーからの品質に関する指摘がある場合にエスカレーションします（エスカレーションルール）

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

• メタジャッジを省略しない - 個別に調整された評価基準によって、汎用的な基準よりも良い判定が得られます
• 再試行ではメタジャッジの仕様を再利用する - 評価仕様は再試行の間も一定に保ちます。変更するのは実装のみです
• ジャッジの出力からはヘッダーだけを解析する - コンテキストの汚染を避けるため、レポート全体は読まないでください
• しきい値を守る - 4/5.0 が品質ゲートです。これを下回った場合は、反復に関する裁量ルールに従って判断します（--strict を指定した場合を除く）
• CLAUDE_PLUGIN_ROOT を含める - メタジャッジとジャッジの両方に、解決済みのプラグインルートパスが必要です

反復

• 修正箇所を絞る - すべてを書き直すのではなく、具体的な問題を修正します
• フィードバックをそのまま渡す - 実装エージェントには問題点を正確に伝えます
• 同じメタジャッジ仕様を使う - 再試行時にメタジャッジを再実行しないでください。評価基準は変わりません
• 適切にエスカレーションする - 根本的な問題に対して無限にループさせないでください
• 作業量を適切に保つ - 反復に関する裁量ルールに従って、タスクの規模に見合う作業量にします。些細な指摘を理由にした再試行は最大 1 回までです

コンテキスト管理

• すっきり保つ - オーケストレーションはあなたが担い、実装はサブエージェントに任せます
• コピーせず要約する - ファイルの内容をすべて渡すのではなく、要約を渡します
• サブエージェントを信頼する - サブエージェント自身でファイルを読み取れます
• メタジャッジ用の YAML - メタジャッジ用の YAML のみをジャッジに渡し、追加のテキストやコメントは一切加えないでください！
• 既存の変更を記録する - 変更の帰属が混同されないよう、以前の変更に関するコンテキストをジャッジに渡します