judge-with-debate

議論による評価

独立した評価者が分析し、互いの評価に異議を唱え、合意に達するまで、または最大ラウンド数に達するまで評価を反復的に改善する、マルチエージェント議論を通じてソリューションを評価します。 このコマンドは、複数の視点と厳密な議論によって評価の精度を高める、高品質な評価のためのマルチエージェント議論パターンを実装します。1 回限りの評価とは異なり、議論によって評価者は根拠を示して自らの立場を擁護し、反論を考慮する必要があります。

主な利点：

• 構造化された評価 - メタ評価者が評価開始前に、個別に調整されたルーブリックと基準を作成します
• 複数の視点 - 3 人の独立した評価者によって、個人のバイアスを軽減します
• 根拠に基づく議論 - 評価者は、ソリューションと評価仕様からの具体的な根拠を示して自らの立場を擁護します
• 反復的な改善 - 最大 3 回の議論ラウンドにより、正確なスコアへの収束を促します
• 共有仕様 - メタ評価者は 1 回だけ実行され、すべてのラウンドにおけるすべての評価者が同じ評価仕様を共有します

パターン：議論に基づく評価

このコマンドは、複数の評価者による反復的な議論を実装します：

Phase 0: Setup
         mkdir -p .specs/reports
                  |
Phase 0.5: Dispatch Meta-Judge
         Meta-Judge (Opus)
              |
         Evaluation Specification YAML
              |
Phase 1: Independent Analysis (3 judges in parallel)
         +- Judge 1 -> {name}.1.md -+
Solution +- Judge 2 -> {name}.2.md -+-+
         +- Judge 3 -> {name}.3.md -+ |
                                      |
Phase 2: Debate Round (iterative)     |
    Each judge reads others' reports  |
         |                            |
    Argue + Defend + Challenge        |
    (grounded in eval specification)  |
         |                            |
    Revise if convinced --------------+
         |                            |
    Check consensus                   |
         +- Yes -> Final Report       |
         +- No -> Next Round ---------+

プロセス

セットアップ：レポートディレクトリの作成

評価を開始する前に、レポートディレクトリが存在することを確認します：

mkdir -p .specs/reports

レポートの命名規則： .specs/reports/{solution-name}-{YYYY-MM-DD}.[1|2|3].md

ここで：

• {solution-name} - ソリューションのファイル名から取得します（例：src/api/users.ts の場合は users-api）
• {YYYY-MM-DD} - 現在の日付
• [1|2|3] - 評価者の番号

フェーズ 0.5：メタ評価者の起動

独立した分析の前に、メタ評価者エージェントを起動し、個別に調整された評価仕様を作成します。メタ評価者は 1 回だけ実行され、すべての評価者がすべてのラウンドで使用するルーブリック、チェックリスト、採点基準を作成します。

メタ評価者のプロンプトテンプレート：

## Task

Generate an evaluation specification yaml for the following evaluation task. You will produce rubrics, checklists, and scoring criteria that multiple judge agents will use to evaluate the solution through independent analysis and multi-round debate.

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## User Prompt
{task description - what the solution was supposed to accomplish}

## Context
{Any relevant context about the solution being evaluated}

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

## Evaluation Mode
Multi-judge debate with consensus-seeking across rounds

## Instructions
Return only the final evaluation specification YAML in your response.
The specification should support both independent analysis and debate-based refinement.

起動：

Use Task tool:
  - description: "Meta-judge: generate evaluation specification for {solution-name}"
  - prompt: {meta-judge prompt}
  - model: opus
  - subagent_type: "sadd:meta-judge"

メタ評価者が完了するまで待ち、その出力から評価仕様の YAML を抽出してから、フェーズ 1 に進みます。

フェーズ 1：独立した分析

3 つの独立した評価者エージェントを並列で起動します（厳密な評価のため Opus を使用）：

1. 各評価者には以下を渡します：
   • 評価対象となるソリューションのパス
   • メタ評価者による評価仕様の YAML
   • タスクの説明
2. 各評価者は、.specs/reports/{solution-name}-{date}.[1|2|3].md に保存する独立した評価を作成します
3. レポートには以下を含める必要があります：
   • 根拠を添えた基準ごとのスコア
   • 評価を裏付ける具体的な引用や例
   • 重み付けされた総合スコア
   • 主な長所と短所

重要な原則： 初期分析における独立性によって、集団思考を防ぎます。

初期評価者向けプロンプトテンプレート：

You are Judge {N} evaluating a solution independently against an evaluation specification produced by the meta judge.

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## Solution
{path to solution file(s)}

## Task Description
{what the solution was supposed to accomplish}

## Evaluation Specification

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

出力ファイル

.specs/reports/{solution-name}-{date}.{N}.md

指示

エージェントの指示に定義されている、評価者としてのすべてのプロセスに従ってください！

追加の指示：

1. ソリューションを十分に読み込む
2. 評価仕様の各基準について：
   • 具体的な根拠を見つける（正確なテキストを引用する）
   • 定義された尺度で採点する
   • 具体例を挙げて正当化する
3. 重み付けされた総合スコアを計算する
4. 包括的なレポートを {output_file} に書き込む

レポートの先頭に Done by Judge {N} を追加する

**Dispatch each judge:**

Task ツールを使用：

• description: "Judge {N}: {solution-name} の独立分析"
• prompt: {評価仕様 YAML を含む評価者向けプロンプト}
• model: opus
• subagent_type: "sadd:judge"

### Phase 2: Debate Rounds (Iterative)

For each debate round (max 3 rounds):

Launch **3 debate agents in parallel**:

1. Each judge agent receives:
   - Path to their own previous report (`.specs/reports/{solution-name}-{date}.[1|2|3].md`)
   - Paths to other judges' reports (`.specs/reports/{solution-name}-{date}.[1|2|3].md`)
   - The original solution
   - The meta-judge's evaluation specification YAML
2. Each judge:
   - Identifies disagreements with other judges (>1 point score gap on any criterion)
   - Defends their own ratings with evidence from the solution and evaluation specification
   - Challenges other judges' ratings they disagree with
   - Considers counter-arguments
   - Revises their assessment if convinced
3. Updates their report file with new section: `## Debate Round {R}`
4. After they reply, if they reached agreement move to Phase 3: Consensus Report

**Key principle:** Judges communicate only through filesystem - orchestrator doesn't mediate and don't read reports files itself, it can overflow your context.

**Prompt template for debate judges:**

```markdown
You are Judge {N} in debate round {R}.

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## Your Previous Report
{path to .specs/reports/{solution-name}-{date}.{N}.md}

## Other Judges' Reports
Judge 1: .specs/reports/{solution-name}-{date}.1.md
...

## Task Description
{what the solution was supposed to accomplish}

## Solution
{path to solution}

## Evaluation Specification

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

出力ファイル

.specs/reports/{solution-name}-{date}.{N}.md（既存のファイルに追記）

指示

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

追加のディベート指示:

1. {your_previous_report} から自身の前回の評価を読む
2. 他のすべてのジャッジのレポートを読む
3. 不一致 (スコアが 1 点を超えて異なる箇所) を特定する
4. それぞれの主要な不一致について:
   • 不一致を明確に述べる
   • ソリューションと評価仕様からの証拠をもって自身の立場を擁護する
   • 反証をもって他のジャッジの立場に異議を唱える
   • 相手の証拠によって自身の見解が変わるかどうかを検討する
5. ディベートラウンドのセクションを追記して、レポートファイルを更新する
6. 合意に達したかどうか、またどのジャッジと合意したかを返信する。再検討したスコアと評価基準のスコアを含めること。

重要:

• 評価仕様の基準に基づいて議論を組み立てる
• 相手の証拠に説得力があると判断した場合にのみ修正する
• それでも自身の当初のスコアが正しいと考える場合は擁護する
• ソリューションから具体的な証拠を引用する

**Dispatch each debate judge:**

Task ツールを使用:

• description: "Judge {N}: debate round {R} for {solution-name}"
• prompt: {debate judge prompt with evaluation specification YAML}
• model: opus
• subagent_type: "sadd:judge"

### Consensus Check

After each debate round, check for consensus:

**Consensus achieved if:**
- All judges' overall scores within 0.5 points of each other
- No criterion has >1 point disagreement across any two judges
- All judges explicitly state they accept the consensus

**If no consensus after 3 rounds:**
- Report persistent disagreements
- Provide all judge reports for human review
- Flag that automated evaluation couldn't reach consensus

**Orchestration Instructions:**

**Step 1: Dispatch Meta-Judge (Phase 0.5)**

1. Launch meta-judge agent
2. Wait for meta-judge to complete
3. Extract the evaluation specification YAML from meta-judge output

**Step 2: Run Independent Analysis (Phase 1)**

1. Launch 3 judge agents in parallel (Judge 1, 2, 3) with the evaluation specification YAML
2. Each writes their independent assessment to `.specs/reports/{solution-name}-{date}.[1|2|3].md`
3. Wait for all 3 agents to complete

**Step 3: Check for Consensus**

Let's work through this systematically to ensure accurate consensus detection.

Read all three reports and extract:
- Each judge's overall weighted score
- Each judge's score for every criterion

Check consensus step by step:
1. First, extract all overall scores from each report and list them explicitly
2. Calculate the difference between the highest and lowest overall scores
   - If difference <= 0.5 points -> overall consensus achieved
   - If difference > 0.5 points -> no consensus yet
3. Next, for each criterion, list all three judges' scores side by side
4. For each criterion, calculate the difference between highest and lowest scores
   - If any criterion has difference > 1.0 point -> no consensus on that criterion
5. Finally, verify consensus is achieved only if BOTH conditions are met:
   - Overall scores within 0.5 points
   - All criterion scores within 1.0 point

**Step 4: Decision Point**

- **If consensus achieved**: Go to Step 6 (Generate Consensus Report)
- **If no consensus AND round < 3**: Go to Step 5 (Run Debate Round)
- **If no consensus AND round = 3**: Go to Step 7 (Report No Consensus)

**Step 5: Run Debate Round**

1. Increment round counter (round = round + 1)
2. Launch 3 judge agents in parallel with the same evaluation specification YAML
3. Each agent reads:
   - Their own previous report from filesystem
   - Other judges' reports from filesystem
   - Original solution
4. Each agent appends "Debate Round {R}" section to their own report file
5. Wait for all 3 agents to complete
6. Go back to Step 3 (Check for Consensus)

**Step 6: Reply with Report**

Let's synthesize the evaluation results step by step.

1. Read all final reports carefully
2. Before generating the report, analyze the following:
   - What is the consensus status (achieved or not)?
   - What were the key points of agreement across all judges?
   - What were the main areas of disagreement, if any?
   - How did the debate rounds change the evaluations?
3. Reply to user with a report that contains:
   - If there is consensus:
     - Consensus scores (average of all judges)
     - Consensus strengths/weaknesses
     - Number of rounds to reach consensus
     - Final recommendation with clear justification
   - If there is no consensus:
       - All judges' final scores showing disagreements
       - Specific criteria where consensus wasn't reached
       - Analysis of why consensus couldn't be reached
       - Flag for human review
4. Command complete

**Step 7: Report No Consensus**

- Report persistent disagreements
- Provide all judge reports for human review
- Flag that automated evaluation couldn't reach consensus

### Phase 3: Consensus Report

If consensus achieved, synthesize the final report by working through each section methodically:

```markdown
# Consensus Evaluation Report

Let's compile the final consensus by analyzing each component systematically.

## Consensus Scores

First, let's consolidate all judges' final scores:

| Criterion | Judge 1 | Judge 2 | Judge 3 | Final |
|-----------|---------|---------|---------|-------|
| {Name}    | {X}/5   | {X}/5   | {X}/5   | {X}/5 |
...

**Consensus Overall Score**: {avg}/5.0

## Consensus Strengths
[Review each judge's identified strengths and extract the common themes that all judges agreed upon]

## Consensus Weaknesses
[Review each judge's identified weaknesses and extract the common themes that all judges agreed upon]

## Debate Summary
Let's trace how consensus was reached:
- Rounds to consensus: {N}
- Initial disagreements: {list with specific criteria and score gaps}
- How resolved: {for each disagreement, explain what evidence or argument led to resolution}

## Final Recommendation
Based on the consensus scores and the key strengths/weaknesses identified:
{Pass/Fail/Needs Revision with clear justification tied to the evidence}

コマンドは次を生成します:

1. レポートディレクトリ: .specs/reports/ (存在しない場合は作成されます)
2. 初回レポート: .specs/reports/{solution-name}-{date}.1.md、.specs/reports/{solution-name}-{date}.2.md、.specs/reports/{solution-name}-{date}.3.md
3. ディベート更新: ラウンドごとに各レポートファイルへ追記されるセクション
4. 最終統合: ユーザーへの返信 (合意または不一致の要約)

ベストプラクティス

メタジャッジ + ジャッジ検証

• メタジャッジを決して省略しない - カスタマイズされた評価基準は、より優れた判定とより根拠のあるディベートを生み出します
• メタジャッジは 1 回だけ実行する - すべてのディベートラウンドを通じて 3 人のジャッジすべてに同じ仕様を使用します
• CLAUDE_PLUGIN_ROOT を含める - メタジャッジとジャッジの両方に、解決済みのプラグインルートパスが必要です
• メタジャッジ YAML - ジャッジには YAML のみを渡し、変更しないでください
• ディベートの根拠付け - ジャッジは立場を擁護する際に評価仕様の基準を参照する必要があります

よくある落とし穴

• ジャッジが追記ではなく新しいレポートを作成する - ディベート履歴が失われます
• オーケストレーターがジャッジ間でレポートを渡す - ファイルシステム通信の原則に違反します
• 弱い初回評価 - ごみを入れればごみが出てきます
• ディベートラウンドが多すぎる - 3 ラウンドを超えると収穫逓減になります
• ディベートにおける追従性 - ジャッジは実際の証拠なしに簡単に合意してしまいます
• メタジャッジ YAML の変更 - 仕様はすべてのジャッジにそのまま渡す必要があります
• ラウンド間でのメタジャッジの再実行 - 仕様は 1 回生成され、共有されます

やるべきこと

• ジャッジは自身のレポートファイルに追記する
• ジャッジはファイルシステムから他のレポートを直接読む
• 強力な証拠に基づく初回評価
• 最大 3 ディベートラウンド
• 立場を変える際には証拠を要求する
• ディベートの議論を評価仕様の基準に根拠付ける
• すべてのラウンドで同じ評価仕様を使用する

使用例

API 実装の評価

/judge-with-debate Implement REST API for user management --solution "src/api/users.ts" 

フェーズ 0.5 - メタジャッジ（日付を 2025-01-15 と仮定）：

• メタジャッジが、次の基準を含む評価仕様 YAML を生成します：
  • 正確性（30%）、設計（25%）、セキュリティ（20%）、パフォーマンス（15%）、ドキュメント（10%）
  • 各基準のルーブリック、チェックリスト、採点の定義

フェーズ 1 - 個別分析（3 人のジャッジが仕様を受け取る）：

• .specs/reports/users-api-2025-01-15.1.md - ジャッジ 1 は正確性を 4/5、セキュリティを 3/5 と採点
• .specs/reports/users-api-2025-01-15.2.md - ジャッジ 2 は正確性を 4/5、セキュリティを 5/5 と採点
• .specs/reports/users-api-2025-01-15.3.md - ジャッジ 3 は正確性を 5/5、セキュリティを 4/5 と採点

意見の相違を検出： セキュリティの採点が 3～5 に分かれています

フェーズ 2 - ディベート第 1 ラウンド（ジャッジは評価仕様を参照）：

• ジャッジ 1 は 3/5 とした理由を説明：「レート制限がなく、仕様チェックリスト項目 4 に照らすと入力検証が不完全です」
• ジャッジ 2 は反論：「ミドルウェアにレート制限があります（45 行目）。仕様のルーブリックを満たしています」
• ジャッジ 1 は 4/5 に修正：「ミドルウェアを見落としていましたが、仕様に照らすと入力検証は依然として不十分です」
• ジャッジ 3 は 4/5 とした理由を説明：「仕様で定義された要件に対して、入力検証は十分です」

ディベート第 1 ラウンドの結果：

• セキュリティの採点はすべて 4～5/5 となり、差は 1 点以内です
• 入力検証については意見の相違が残っています

ディベート第 2 ラウンド（同じ評価仕様）：

• ジャッジは、仕様の基準に照らして具体的な検証コードを調べます
• ジャッジ 2 は 4/5 に修正：「再検討したところ、仕様チェックリストに照らすとメールアドレス検証の正規表現は不十分です」
• 合意：セキュリティ = 4/5

最終合意：

Correctness: 4.3/5
Design: 4.5/5
Security: 4.0/5 (2 debate rounds to consensus)
Performance: 4.7/5
Documentation: 4.0/5

Overall: 4.3/5 - PASS