do-competitively

do-competitively

競争型マルチエージェント生成、メタジャッジによる評価仕様の作成、マルチジャッジ評価、エビデンスに基づく統合を通じてタスクを実行し、並列実装の最良の要素を組み合わせて、より優れた結果を生み出します。 このコマンドは、品質が速度よりも重要な重要度の高いタスク向けに、適応型戦略選択を備えた Generate-Critique-Synthesize（GCS）パターンを実装します。競争型生成とメタジャッジによる評価仕様の作成、多角的な評価を組み合わせ、その結果に基づいて最適な統合戦略をインテリジェントに選択します。

主な機能：

• 生成における自己批評ループ（Constitutional AI）
• 構造化された評価 — メタジャッジが評価の前にタスクに合わせたルーブリックを作成
• 評価における検証ループ（Chain-of-Verification）
• 適応型戦略：明確な勝者は仕上げ、意見が分かれた場合は統合し、失敗した場合は再設計
• インテリジェントな戦略選択により、コストを平均15〜20％削減

重要：あなたは実装エージェントでもジャッジでもありません。サブエージェントやタスクのコンテキストとして提供されたファイルを読んではいけません。レポートを読んではいけません。不要な情報でコンテキストを圧迫してはいけません。必ず手順に沿って進めてください。逸脱は失敗とみなされ、あなたは停止させられます！

パターン：Generate-Critique-Synthesize（GCS）

このコマンドは、複数フェーズからなる適応型の競争オーケストレーションパターンを実装します。

Phase 1: Competitive Generation with Self-Critique + Meta-Judge (IN PARALLEL)
         ┌─ Meta-Judge → Evaluation Specification YAML ───────────┐
Task ────┼─ Agent 2 → Draft → Critique → Revise → Solution B ───┐ │ 
         ├─ Agent 3 → Draft → Critique → Revise → Solution C ───┼─┤ 
         └─ Agent 1 → Draft → Critique → Revise → Solution A ───┘ │
                                                                  │
Phase 2: Multi-Judge Evaluation with Verification                 │
         ┌─ Judge 1 → Evaluate → Verify → Revise → Report A ─┐    │
         ├─ Judge 2 → Evaluate → Verify → Revise → Report B ─┼────┤
         └─ Judge 3 → Evaluate → Verify → Revise → Report C ─┘    │
                                                                  │
Phase 2.5: Adaptive Strategy Selection                            │
         Analyze Consensus ───────────────────────────────────────┤
                ├─ Clear Winner? → SELECT_AND_POLISH              │
                ├─ All Flawed (<3.0)? → REDESIGN (return Phase 1) │
                └─ Split Decision? → FULL_SYNTHESIS               │
                                          │                       │
Phase 3: Evidence-Based Synthesis         │                       │
         (Only if FULL_SYNTHESIS)         │                       │
         Synthesizer ─────────────────────┴───────────────────────┴─→ Final Solution

プロセス

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

開始前に、レポートディレクトリが存在することを確認してください。

mkdir -p .specs/reports

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

ここで：

• {solution-name} - 出力パスから導出します（例：出力 specs/api/users.md の場合は users-api）
• {YYYY-MM-DD} - 現在の日付
• [1|2|3] - ジャッジ番号

注： ソリューションは指定された出力先に保存します。評価レポートのみ .specs/reports/ に保存します。

フェーズ1：競争型生成＋メタジャッジ（並列）

3つの独立した生成エージェントと1つのメタジャッジエージェントを並列で起動します（合計4エージェント、すべて推奨：品質を重視してOpus）。

メタジャッジは3つの生成エージェントと並列で実行します。生成エージェントの出力は不要で、タスクの説明だけで評価基準を作成できるためです。

重要： 4つのエージェントをすべて、1つのメッセージで4回のTaskツール呼び出しを使って、フォアグラウンドエージェントとしてディスパッチしてください。ディスパッチ順ではメタジャッジを必ず最初のツール呼び出しにしてください。生成エージェントが変更を加える前に、コードベースのコンテキストを収集する時間を確保するためです。

メタジャッジエージェント（1エージェント）

メタジャッジは、この特定のタスクに合わせた評価仕様YAML（ルーブリック、チェックリスト、採点基準）を作成します。3人のジャッジ全員が使用する評価仕様YAMLを返します。

メタジャッジ用プロンプトテンプレート：

## Task

Generate an evaluation specification yaml for the following task. You will produce rubrics, checklists, and scoring criteria that judge agents will use to evaluate and compare competitive implementation artifacts.

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

## Number of Solutions
3 (competitive implementations to be compared)

## Instructions
Return only the final evaluation specification YAML in your response.
The specification should support comparative evaluation across multiple solutions.

ディスパッチ：

Use Task tool:
  - description: "Meta-judge: {brief task summary}"
  - prompt: {meta-judge prompt}
  - model: opus
  - subagent_type: "sadd:meta-judge"

生成エージェント（3エージェント）

1. 各エージェントには、同一のタスク説明とコンテキストを渡します
2. エージェントは、互いの成果物を見ずに独立して作業します
3. 各エージェントは、同じ問題に対する完全なソリューションを作成します
4. ソリューションは、それぞれ異なるファイルに保存します（例：{solution-file}.[a|b|c].[ext]）

ソリューションの命名規則： {solution-file}.[a|b|c].[ext] ここで：

• {solution-file} - タスクから導出します（例：create users.ts の場合、ソリューションファイル名は users）
• [a|b|c] - サブエージェントごとの一意の識別子
• [ext] - ファイル拡張子（例：md、ts など）

重要な原則： 独立性による多様性 — エージェントが異なるアプローチを探ります。

重要：エージェントとジャッジには、[a|b|c]識別子を含むファイル名を必ず指定してください！！！指定しない場合、直ちに終了させられます！

生成エージェント用プロンプトテンプレート：

<task>
{task_description}
</task>

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

{additional_constraints_if_any}
</constraints>

<context>
{relevant_context}
</context>

<output>
{define expected output following such pattern: {solution-file}.[a|b|c].[ext] based on the task description and context. Each [a|b|c] is a unique identifier per sub-agent. You MUST provide filename with it!!!}
</output>

Instructions:
Let's approach this systematically to produce the best possible solution.

1. First, analyze the task carefully - what is being asked and what are the key requirements?
2. Consider multiple approaches - what are the different ways to solve this?
3. Think through the tradeoffs step by step and choose the approach you believe is best
4. Implement it completely
5. Generate 5 verification questions about critical aspects
6. Answer your own questions:
   - Review solution against each question
   - Identify gaps or weaknesses
7. Revise solution:
   - Fix identified issues
8. Explain what was changed and why

並列ディスパッチの例

4つのTaskツール呼び出しをすべて1つのメッセージで送信してください。メタジャッジを最初に、その後に生成エージェントを続けます。

Message with 4 tool calls:
  Tool call 1 (meta-judge):
    - description: "Meta-judge: {brief task summary}"
    - model: opus
    - subagent_type: "sadd:meta-judge"

  Tool call 2 (generator A):
    - description: "Generate solution A: {brief task summary}"
    - model: opus

  Tool call 3 (generator B):
    - description: "Generate solution B: {brief task summary}"
    - model: opus

  Tool call 4 (generator C):
    - description: "Generate solution C: {brief task summary}"
    - model: opus

フェーズ2に進む前に、4つすべてのエージェントからの応答を待ってください。

フェーズ 2：複数の評価者による評価

3 人の独立した評価者を並行して起動します（厳密さを重視する場合は Opus を推奨）。

重要： 評価者を起動する前に、フェーズ 1 のエージェント（メタ評価者 + 3 人の生成エージェント）がすべて完了するまで待ってください。

重要： 各評価者には、メタ評価者の評価仕様 YAML をそのまま渡してください。省略したり、何かを追加したり、変更したり、内容を短縮または要約したりしないでください。

1. 各評価者には、メタ評価者の評価仕様 YAML と すべての候補ソリューション（A、B、C）へのパスを渡します
2. 評価者は、メタ評価者の基準（ハードコードされた基準ではありません）に照らして評価します
3. 各評価者は以下を作成します：
   • 比較分析（各ソリューションが優れている点）
   • 根拠に基づく評価（具体的な引用や例を含む）
   • 最終投票（どのソリューションを選ぶか、その理由）
4. レポートはそれぞれ異なるファイルに保存します（例：.specs/reports/{solution-name}-{date}.[1|2|3].md）

重要な原則： 複数の独立した評価によってバイアスが軽減され、異なる問題を発見できます。

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

You are evaluating {number} competitive solutions against an evaluation specification produced by the meta judge.

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## Task
{task_description}

## Solutions
{list of paths to all candidate solutions}

## Evaluation Specification

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

出力

完全なレポートを次の場所に書き込みます： {.specs/reports/{solution-name}-{date}.[1|2|3].md - 各評価者には一意の番号識別子を割り当てます}

重要：次の正確な構造のヘッダー形式で返信してください：

---

VOTE: [Solution A/B/C] SCORES: Solution A: [X.X]/5.0 Solution B: [X.X]/5.0 Solution C: [X.X]/5.0 CRITERIA:

• {criterion_1}: [X.X]/5.0
• {criterion_2}: [X.X]/5.0 ...

---

[評価の概要]

指示

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

重要：印象ではなく、根拠に基づいて評価してください。具体的な文言を引用してください。

出力

重要：回答の先頭に、次の正確な構造の評価レポートを YAML 形式で記載してください！

CRITICAL: NEVER provide score threshold to judges. Judge MUST not know what threshold for score is, in order to not be biased!!!

**Dispatch:**

Task ツールを使います（1 つのメッセージで 3 回呼び出します）：

• description: "評価者 [1|2|3]：{タスクの簡単な概要}"
• prompt: {メタ評価者の評価仕様 YAML をそのまま含む評価者用プロンプト}
• model: opus
• subagent_type: "sadd:judge"

### Phase 2.5: Adaptive Strategy Selection (Early Return)

**The orchestrator** (not a subagent) analyzes judge outputs to determine the optimal strategy.

#### Decision Logic

**Step 1: Parse structured headers from judge reply**

Parse the judges reply.
CRITICAL: Do not read reports files itself, it can overflow your context.

**Step 2: Check for unanimous winner**

Compare all three VOTE values:

- If Judge 1 VOTE = Judge 2 VOTE = Judge 3 VOTE (same solution):
  - **Strategy: SELECT_AND_POLISH**
  - **Reason:** Clear consensus - all three judges prefer same solution

**Step 3: Check if all solutions are fundamentally flawed**

If no unanimous vote, calculate average scores:

1. Average Solution A scores: (Judge1_A + Judge2_A + Judge3_A) / 3
2. Average Solution B scores: (Judge1_B + Judge2_B + Judge3_B) / 3
3. Average Solution C scores: (Judge1_C + Judge2_C + Judge3_C) / 3

If (avg_A < 3.0) AND (avg_B < 3.0) AND (avg_C < 3.0):

- **Strategy: REDESIGN**
- **Reason:** All solutions below quality threshold, fundamental approach issues

**Step 5: Default to full synthesis**

If none of the above conditions met:

- **Strategy: FULL_SYNTHESIS**
- **Reason:** Split decision with merit, synthesis needed to combine best elements

#### Strategy 1: SELECT_AND_POLISH

**When:** Clear winner (unanimous votes)

**Process:**

1. Select the winning solution as the base
2. Launch subagent to apply specific improvements from judge feedback
3. Cherry-pick 1-2 best elements from runner-up solutions
4. Document what was added and why

**Benefits:**

- Saves synthesis cost (simpler than full synthesis)
- Preserves proven quality of winning solution
- Focused improvements rather than full reconstruction

**Prompt template:**

```markdown
You are polishing the winning solution based on judge feedback.

<task>
{task_description}
</task>

<winning_solution>
{path_to_winning_solution}
Score: {winning_score}/5.0
Judge consensus: {why_it_won}
</winning_solution>

<runner_up_solutions>
{list of paths to all runner-up solutions}
</runner_up_solutions>

<judge_feedback>
{list of paths to all evaluation reports}
</judge_feedback>

<output>
{final_solution_path}
</output>

Instructions:
Let's work through this step by step to polish the winning solution effectively.

1. Take the winning solution as your base (do NOT rewrite it)
2. First, carefully review all judge feedback to understand what needs improvement
3. Apply improvements based on judge feedback:
   - Fix identified weaknesses
   - Add missing elements judges noted
4. Next, examine the runner-up solutions for standout elements
5. Cherry-pick 1-2 specific elements from runners-up if judges praised them
6. Document changes made:
   - What was changed and why
   - What was added from other solutions

CRITICAL: Preserve the winning solution's core approach. Make targeted improvements only.

戦略 2：REDESIGN

条件： すべてのソリューションのスコアが 3.0/5.0 未満である（全体的に根本的な問題がある）

プロセス：

1. 新しいエージェントを起動して、失敗のパターンと得られた教訓を分析します。エージェントには以下を依頼します：
   • 段階的に考える：各ソリューションで何が問題だったか？
   • すべてのソリューションに共通する失敗のパターンを分析する
   • 得られた教訓を抽出する（避けるべきこと）
   • すべてのアプローチが失敗した根本原因を特定する
   • これらの知見に基づいて、新しいタスクの分割方法または制約を作成する
2. フェーズ 1 に戻り、得られた教訓と新しい制約を新しい実装エージェントに渡します。

新しい実装用プロンプトのテンプレート：

You are analyzing why all solutions failed to meet quality standards. And implement new solution based on it.

<task>
{task_description}
</task>

<constraints>
{constraints_if_any}
</constraints>

<context>
{relevant_context}
</context>

<failed_solutions>
{list of paths to all candidate solutions}
</failed_solutions>

<evaluation_reports>
{list of paths to all evaluation reports with low scores}
</evaluation_reports>

Instructions:
Let's break this down systematically to understand what went wrong and how to design new solution based on it.

1. First, analyze the task carefully - what is being asked and what are the key requirements?
2. Read through each solution and its evaluation report
3. For each solution, think step by step about:
   - What was the core approach?
   - What specific issues did judges identify?
   - Why did this approach fail to meet the quality threshold?
4. Identify common failure patterns across all solutions:
   - Are there shared misconceptions?
   - Are there missing requirements that all solutions overlooked?
   - Are there fundamental constraints that weren't considered?
5. Extract lessons learned:
   - What approaches should be avoided?
   - What constraints must be addressed?
6. Generate improved guidance for the next iteration:
   - New constraints to add
   - Specific approaches to try - what are the different ways to solve this?
   - Key requirements to emphasize
7. Think through the tradeoffs step by step and choose the approach you believe is best
8. Implement it completely
9. Generate 5 verification questions about critical aspects
10. Answer your own questions:
   - Review solution against each question
   - Identify gaps or weaknesses
11. Revise solution:
   - Fix identified issues
12. Explain what was changed and why

戦略 3：FULL_SYNTHESIS（デフォルト）

条件： 明確な勝者はいないものの、各ソリューションに価値がある（スコアが 3.0 以上）

プロセス： フェーズ 3（根拠に基づく統合）に進みます。

フェーズ 3：根拠に基づく統合

フェーズ 2.5 で戦略 3（FULL_SYNTHESIS）が選択された場合にのみ実行されます

1 つの統合エージェントを起動します（品質を重視する場合は Opus を推奨）。

1. エージェントに以下を渡します：
   • すべての候補ソリューション（A、B、C）
   • すべての評価レポート（1、2、3）
2. エージェントは以下を分析します：
   • 各評価者が評価した要素（強みについての合意点）
   • 各評価者が指摘した問題（弱点についての合意点）
   • ソリューションごとのアプローチの違い
3. エージェントは以下の方法で最終ソリューションを作成します：
   • あるソリューションが明らかに優れている場合は、優れたセクションをコピーする
   • ハイブリッドの方が優れている場合は、アプローチを組み合わせる
   • すべての評価者が指摘した問題を修正する
   • 何をどこから採用し、その理由を記録する

重要な原則： 根拠に基づく統合により、集合知を活用できます。

統合エージェント用プロンプトのテンプレート：

You are synthesizing the best solution from competitive implementations and evaluations.

<task>
{task_description}
</task>

<solutions>
{list of paths to all candidate solutions}
</solutions>

<evaluation_reports>
{list of paths to all evaluation reports}
</evaluation_reports>

<output>
{define expected output following such pattern: solution.md based on the task description and context. Result should be a complete solution to the task.}
</output>

Instructions:
Let's think through this synthesis step by step to create the best possible combined solution.

1. First, read all solutions and evaluation reports carefully
2. Map out the consensus:
   - What strengths did multiple judges praise in each solution?
   - What weaknesses did multiple judges criticize in each solution?
3. For each major component or section, think through:
   - Which solution handles this best and why?
   - Could a hybrid approach work better?
4. Create the best possible solution by:
   - Copying text directly when one solution is clearly superior
   - Combining approaches when a hybrid would be better
   - Fixing all identified issues
   - Preserving the best elements from each
5. Explain your synthesis decisions:
   - What you took from each solution
   - Why you made those choices
   - How you addressed identified weaknesses

CRITICAL: Do not create something entirely new. Synthesize the best from what exists.

選択された適応型戦略に応じて、コマンドの出力は異なります。 ### 出力 (すべての戦略)

1. 候補ソリューション: {solution-file}.[a|b|c].[ext] (指定された出力場所)
2. 評価レポート: .specs/reports/{solution-name}-{date}.[1|2|3].md
3. 最終ソリューション: {output_path}

戦略固有の出力

• SELECT_AND_POLISH: 勝者となったソリューションに基づく洗練されたソリューション
• REDESIGN: 停止せず、フェーズ 1 に戻り、最終的には SELECT_AND_POLISH または FULL_SYNTHESIS 戦略で終了する必要があります
• FULL_SYNTHESIS: すべての中から最良のものを組み合わせた統合ソリューション

オーケストレーターの返信

コマンドの実行が完了したら、以下の構造でユーザーに返信します:

## Execution Summary

Original Task: {task_description}

Strategy Used: {strategy} ({reason})

### Results

| Phase                   | Agents | Models   | Status      |
|-------------------------|--------|----------|-------------|
| Phase 1: Competitive Generation + Meta-Judge | 4 (3 generators + 1 meta-judge) | opus x 4 | [Complete / Failed] |
| Phase 2: Multi-Judge Evaluation | 3 | opus x 3 | [Complete / Failed] |
| Phase 2.5: Adaptive Strategy Selection | orchestrator | - | {strategy} |
| Phase 3: [Synthesis/Polish/Redesign] | [N] | [model] | [Complete / Failed] |

Files Created

Final Solution:
- {output_path} - Synthesized production-ready command

Candidate Solutions:
- {solution-file}.[a|b|c].[ext] (Score: [X.X]/5.0)

Evaluation Reports:
- .specs/reports/{solution-file}-{date}.[1|2|3].md (Vote: [Solution A/B/C])

Synthesis Decisions

| Element              | Source           | Rationale   |
|----------------------|------------------|-------------|
| [element]            | Solution [B/A/C] | [rationale] |

ベストプラクティス

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

• メタジャッジを決してスキップしない - カスタマイズされた評価基準は、汎用的なものよりも優れた判定を生み出します
• メタジャッジは 1 回だけ実行する - 3 人のジャッジすべてに同じ仕様を使用します
• CLAUDE_PLUGIN_ROOT を含める - メタジャッジとジャッジの両方に、解決済みのプラグインルートパスが必要です
• メタジャッジ YAML - ジャッジにはメタジャッジ YAML のみを渡し、追加のテキストやコメントを加えないでください!

よくある落とし穴

• 些細なタスクに使用する - オーバーヘッドが正当化されません
• 曖昧なタスク記述 - 比較不能なソリューションにつながります
• 不十分なコンテキスト - エージェントが質の高い作業を生み出せません
• 明確な勝者が存在するのに統合を強制する - コストを浪費し、品質を低下させるリスクがあります
• 根本的に欠陥のあるソリューションを統合する - ゴミを洗練するよりも再設計する方が良いです
• メタジャッジをスキップする - ハードコードされた基準はカスタマイズされたものよりも効果が低いです
• ジャッジに渡す前にメタジャッジ YAML を変更する - ジャッジは正確な仕様を受け取る必要があります

すべきこと:

• 明確な制約を持つ、よく定義されたタスク
• 情報に基づいた意思決定のための豊富なコンテキスト
• 適応的な戦略選択を信頼する
• 明確な勝者を洗練させ、意見が分かれた場合は統合し、失敗した場合は再設計する
• 速度のためにメタジャッジをジェネレーターと並行してディスパッチする

例

例 1: API 設計 (明確な勝者 - SELECT_AND_POLISH)

/do-competitively "Design REST API for user management (CRUD + auth)" \
  --output "specs/api/users.md" \
  --criteria "RESTfulness,security,scalability,developer-experience"

フェーズ 1 の出力 (4 つの並列エージェント):

• メタジャッジ: 5 つの基準次元を持つ評価仕様 YAML、比較ルーブリック
• specs/api/users.a.md - ネストされたルートを持つリソースベースの設計
• specs/api/users.b.md - RPC スタイルのエンドポイントを持つアクションベースの設計
• specs/api/users.c.md - 最小限の設計、認証の考慮が欠けている

フェーズ 2 の出力 (日付が 2025-01-15、メタジャッジ仕様を使用する 3 人のジャッジと仮定):

• .specs/reports/users-api-2025-01-15.1.md:

  VOTE: Solution A
  SCORES: A=4.5/5.0, B=3.2/5.0, C=2.8/5.0
  

  "最も RESTful、優れたセキュリティ"

• .specs/reports/users-api-2025-01-15.2.md:

  VOTE: Solution A
  SCORES: A=4.3/5.0, B=3.5/5.0, C=2.6/5.0
  

  "クリーンなリソース設計、スケーラブル"

• .specs/reports/users-api-2025-01-15.3.md:

  VOTE: Solution A
  SCORES: A=4.6/5.0, B=3.0/5.0, C=2.9/5.0
  

  "ベストプラクティス、明確な構造"

フェーズ 2.5 の決定 (オーケストレーターがヘッダーを解析):

• 満場一致の投票: A、A、A
• 平均スコア: A=4.5、B=3.2、C=2.8
• 戦略: SELECT_AND_POLISH
• 理由: 1.0 ポイント以上の差がある満場一致の勝者

フェーズ 3 の出力:

• specs/api/users.md - ソリューション A を以下で洗練:
  • レート制限のドキュメントを追加 (B から)
  • ネストされたルートを簡素化 (ジャッジのフィードバック)
  • 総コスト: 8 エージェント (フェーズ 1 の 4 + ジャッジ 3 + 洗練 1)

例 2：アルゴリズムの選定（意見が分かれた判断 — FULL_SYNTHESIS）

/do-competitively "Design caching strategy for high-traffic API" \
  --output "specs/caching.md" \
  --criteria "performance,memory-efficiency,simplicity,reliability"

フェーズ 1 の出力（4 つの並列エージェント）：

• メタジャッジ：4 つの評価基準の軸と比較評価基準を含む評価仕様 YAML
• specs/caching.a.md - LRU 退避方式の Redis
• specs/caching.b.md - マルチティアキャッシュ（メモリ + Redis）
• specs/caching.c.md - CDN + アプリケーションキャッシュ

フェーズ 2 の出力（日付を 2025-01-15 とし、メタジャッジの仕様を使用する 3 人のジャッジを想定）：

• .specs/reports/caching-2025-01-15.1.md：

  VOTE: Solution B
  SCORES: A=3.8/5.0, B=4.2/5.0, C=3.9/5.0
  

  「最高のパフォーマンスだが、複雑」

• .specs/reports/caching-2025-01-15.2.md：

  VOTE: Solution A
  SCORES: A=4.0/5.0, B=3.9/5.0, C=3.7/5.0
  

  「シンプルで、信頼性が高く、実績がある」

• .specs/reports/caching-2025-01-15.3.md：

  VOTE: Solution C
  SCORES: A=3.6/5.0, B=4.0/5.0, C=4.1/5.0
  

  「グローバルに展開でき、費用対効果が高い」

フェーズ 2.5 の判断（オーケストレーターがヘッダーを解析）：

• 投票が分散：B、A、C（合意なし）
• 平均スコア：A=3.8、B=4.0、C=3.9
• スコア差：4.0 - 3.9 = 0.1（しきい値 1.0 未満）
• 戦略：FULL_SYNTHESIS
• 理由：判断が分かれ、すべての解決策が 3.0 以上で、明確な勝者がいない

フェーズ 3 の出力：

• specs/caching.md - ハイブリッドアプローチ：
  • マルチティアアーキテクチャ（B より）
  • シンプルな LRU ポリシー（A より）
  • 静的コンテンツ用 CDN（C より）
  • エージェントの合計数：8（フェーズ 1 が 4 + ジャッジが 3 + 統合が 1）

例 3：認証の設計（すべてに欠陥あり — REDESIGN）

/do-competitively "Design authentication system with social login" \
  --output "specs/auth.md" \
  --criteria "security,user-experience,maintainability"

フェーズ 1 の出力（4 つの並列エージェント）：

• メタジャッジ：3 つの評価基準の軸と比較評価基準を含む評価仕様 YAML
• specs/auth.a.md - カスタム OAuth2 実装
• specs/auth.b.md - ソーシャルプロバイダーを利用したセッションベース方式
• specs/auth.c.md - パスワードのみの認証を用いる JWT

フェーズ 2 の出力（日付を 2025-01-15 とし、メタジャッジの仕様を使用する 3 人のジャッジを想定）：

• .specs/reports/auth-2025-01-15.1.md：

  VOTE: Solution A
  SCORES: A=2.5/5.0, B=2.2/5.0, C=2.3/5.0
  

  「セキュリティリスクがあり、車輪の再発明」

• .specs/reports/auth-2025-01-15.2.md：

  VOTE: Solution B
  SCORES: A=2.4/5.0, B=2.8/5.0, C=2.1/5.0
  

  「セッションはスケールせず、要件も満たしていない」

• .specs/reports/auth-2025-01-15.3.md：

  VOTE: Solution C
  SCORES: A=2.6/5.0, B=2.5/5.0, C=2.3/5.0
  

  「ソーシャルログインがなく、セキュリティ上の懸念がある」

フェーズ 2.5 の判断（オーケストレーターがヘッダーを解析）：

• 投票が分散：A、B、C（合意なし）

• 平均スコア：A=2.5、B=2.5、C=2.2（すべて 3.0 未満）

• 戦略：REDESIGN

• 理由：すべての解決策がしきい値の 3.0 を下回り、根本的な問題がある

• 停止せず、フェーズ 1 に戻ります。最終的に、SELECT_AND_POLISH または FULL_SYNTHESIS 戦略で完了するはずです。