tree-of-thoughts

思考の木

解決策の探索空間を体系的に調査し、有望でない分岐を枝刈りし、有望なアプローチを展開して、最適な解決策を統合することで、複雑な推論タスクを実行します。 このコマンドは、完全な実装に着手する前に複数の解決経路を探索する必要があるタスク向けに、Tree of Thoughts（ToT）パターンを実装します。創造的なサンプリング、メタジャッジが生成する評価仕様、多角的な評価、適応型の戦略選択、エビデンスに基づく統合を組み合わせ、より優れた成果を導きます。

主な利点：

• 体系的な探索 - 複数のエージェントが解決策の探索空間の異なる領域を調査します
• 構造化された評価 - メタジャッジが評価前に、対象に合わせたルーブリックと基準を作成します
• 独立した検証 - ジャッジはメタジャッジの仕様を機械的に適用し、偏りを抑えます
• 適応型の戦略 - 明確な勝者がいる場合は仕上げ、判断が分かれる場合は統合し、失敗した場合は再設計します

パターン：思考の木（ToT）

このコマンドは、メタジャッジによる評価と適応型の戦略選択を備えた、8 段階の体系的な推論パターンを実装します：

Phase 1: Exploration (Propose Approaches)
         ┌─ Agent A → Proposals A1, A2 (with probabilities) ─┐
Task ───┼─ Agent B → Proposals B1, B2 (with probabilities) ─┼─┐
         └─ Agent C → Proposals C1, C2 (with probabilities) ─┘ │
                                                                │
Phase 1.5: Pruning Meta-Judge (runs in parallel with Phase 1) │
         Meta-Judge → Pruning Evaluation Specification YAML ───┤
                                                                │
Phase 2: Pruning (Vote for Best 3)                             │
         ┌─ Judge 1 → Votes + Rationale ─┐                     │
         ├─ Judge 2 → Votes + Rationale ─┼─────────────────────┤
         └─ Judge 3 → Votes + Rationale ─┘                     │
                 │                                              │
                 ├─→ Select Top 3 Proposals                     │
                 │                                              │
Phase 3: Expansion (Develop Full Solutions)                    │
         ┌─ Agent A → Solution A (from proposal X) ─┐          │
         ├─ Agent B → Solution B (from proposal Y) ─┼──────────┤
         └─ Agent C → Solution C (from proposal Z) ─┘          │
                                                                │
Phase 3.5: Evaluation Meta-Judge (runs in parallel w/ Phase 3)│
         Meta-Judge → Evaluation Specification YAML ───────────┤
                                                                │
Phase 4: Evaluation (Judge Full Solutions)                     │
         ┌─ Judge 1 → Report 1 ─┐                              │
         ├─ Judge 2 → Report 2 ─┼──────────────────────────────┤
         └─ Judge 3 → Report 3 ─┘                              │
                                                                │
Phase 4.5: Adaptive Strategy Selection                         │
         Analyze Consensus ────────────────────────────────────┤
                ├─ Clear Winner? → SELECT_AND_POLISH           │
                ├─ All Flawed (<3.0)? → REDESIGN (Phase 3)     │
                └─ Split Decision? → FULL_SYNTHESIS            │
                                         │                      │
Phase 5: Synthesis (Only if FULL_SYNTHESIS)                    │
         Synthesizer ────────────────────┴──────────────────────┴─→ Final Solution

プロセス

セットアップ：ディレクトリ構造の作成

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

mkdir -p .specs/research .specs/reports

命名規則：

• 提案：.specs/research/{solution-name}-{YYYY-MM-DD}.proposals.[a|b|c].md
• 枝刈り：.specs/research/{solution-name}-{YYYY-MM-DD}.pruning.[1|2|3].md
• 選定：.specs/research/{solution-name}-{YYYY-MM-DD}.selection.md
• 評価：.specs/reports/{solution-name}-{YYYY-MM-DD}.[1|2|3].md

以下のとおりです：

• {solution-name} - 出力パスから導出します（例：出力 specs/api/users.md の場合は users-api）
• {YYYY-MM-DD} - 現在の日付

注： 解決策は指定された出力先に保存されます。.specs/ に保存されるのは、調査ファイルと評価ファイルのみです。

フェーズ 1：探索（アプローチの提案）

3 つの独立したエージェントを並列で起動します（速度を重視する場合は Sonnet を推奨）：

1. 各エージェントに同一のタスク説明とコンテキストを渡します
2. 各エージェントは6 つの高レベルなアプローチを生成します（完全な実装ではありません）
3. 各アプローチについて、エージェントは以下を提示します：
   • アプローチの説明（2～3 段落）
   • 主要な設計上の決定事項とトレードオフ
   • 確率の推定値（0.0～1.0）
   • 推定される複雑さ（低／中／高）
   • 潜在的なリスクと失敗モード
4. 提案は .specs/research/{solution-name}-{date}.proposals.[a|b|c].md に保存します

主要な原則： 考えられるアプローチの全分布から確率的にサンプリングし、体系的に探索します。

探索エージェント用プロンプトテンプレート：

<task>
{task_description}
</task>

<constraints>
{constraints_if_any}
</constraints>

<context>
{relevant_context}
</context>

<output>
{.specs/research/{solution-name}-{date}.proposals.[a|b|c].md - each agent gets unique letter identifier}
</output>

Instructions:

Let's approach this systematically by first understanding what we're solving, then exploring the solution space.

**Step 1: Decompose the problem**
Before generating approaches, break down the task:
- What is the core problem being solved?
- What are the key constraints and requirements?
- What subproblems must any solution address?
- What are the evaluation criteria for success?

**Step 2: Map the solution space**
Identify the major dimensions along which solutions can vary:
- Architecture patterns (e.g., monolithic vs distributed)
- Implementation strategies (e.g., eager vs lazy)
- Trade-off axes (e.g., performance vs simplicity)

**Step 3: Generate 6 distinct high-level approaches**

**Sampling guidance:**
Please sample approaches at random from the [full distribution / tails of the distribution]
- For first 3 approaches aim for high probability, over 0.80
- For last 3 approaches aim for diversity - explore different regions of the solution space, such that the probability of each response is less than 0.10

For each approach, provide:
   - Name and one-sentence summary
   - Detailed description (2-3 paragraphs)
   - Key design decisions and rationale
   - Trade-offs (what you gain vs what you sacrifice)
   - Probability (0.0-1.0)
   - Complexity estimate (low/medium/high)
   - Potential risks and failure modes

**Step 4: Verify diversity**
Before finalizing, check:
- Are approaches genuinely different, not minor variations?
- Do they span different regions of the solution space?
- Have you covered both conventional and unconventional options?


CRITICAL:
- Do NOT implement full solutions yet - only high-level approaches
- Ensure approaches are genuinely different, not minor variations

フェーズ 1.5：枝刈り用メタジャッジの起動

重要： 枝刈り用メタジャッジは、フェーズ 1 の探索エージェントと並列で起動してください。メタジャッジが枝刈り基準を作成するために、探索結果は必要ありません。元のタスク説明のみを必要とします。

枝刈り用メタジャッジは、高レベルな提案を枝刈りの対象として評価するための評価仕様（ルーブリック、チェックリスト、採点基準）を作成します。

枝刈り用メタジャッジのプロンプトテンプレート：

## Task

Generate an evaluation specification yaml for pruning high-level solution proposals. You will produce rubrics, checklists, and scoring criteria that judge agents will use to select the top 3 proposals for full development.

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## User Prompt
{Original task description from user}

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

## Artifact Type
proposals (high-level approaches with probability estimates, not full implementations)

## Evaluation Focus
Feasibility, alignment with requirements, potential for high-quality result, risk manageability

## Instructions
Return only the final evaluation specification YAML in your response.
The specification should support comparative evaluation and ranking of proposals.

起動：

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

フェーズ 2：絞り込み（上位 3 候補に投票）

次に進む前に、フェーズ 1 の調査エージェントとフェーズ 1.5 の絞り込みメタジャッジの両方が完了するまで待ってください。

独立した 3 人のジャッジを並行して起動します（厳密な評価には Opus を推奨）：

1. 各ジャッジに、すべての提案ファイル（.specs/research/ 内）と絞り込みメタジャッジの評価仕様 YAMLを渡します。
2. ジャッジは、メタジャッジが生成した絞り込み基準に照らして各提案を評価します。
3. 各ジャッジは以下を作成します。
   • 各提案のスコア（根拠付き）
   • 拡張する上位 3 件の提案への投票
   • 選定の理由
4. 投票結果は .specs/research/{solution-name}-{date}.pruning.[1|2|3].md に保存します。

重要な原則： メタジャッジが生成した基準を用いた独立評価により、固定の重み付けを使わずに、一貫性のある個別最適化された評価が可能になります。

重要：各ジャッジには、絞り込みメタジャッジの評価仕様 YAML をそのまま正確に渡してください。その内容を省略、追加、変更、短縮、要約してはいけません。

絞り込みジャッジ用プロンプトテンプレート：

You are evaluating {N} proposed approaches against an evaluation specification produced by the meta judge, to select the top 3 for full development.

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## Task
{task_description}

## Proposals
{list of paths to all proposal files}
Read all proposals carefully before evaluating.

## Evaluation Specification

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

出力

{.specs/research/{solution-name}-{date}.pruning.[1|2|3].md}

指示

エージェントの指示で定義された、ジャッジとしての全プロセスに従ってください。

重要：応答の冒頭に、以下と完全に一致する構造化された評価レポートを YAML 形式で返してください。

**Dispatch:**

Task ツールを使用：

• description: "Pruning Judge {1|2|3}: {brief task summary}"
• prompt: {pruning judge prompt with exact meta-judge specification YAML}
• model: opus
• subagent_type: "sadd:judge"

### Phase 2b: Select Top 3 Proposals

After judges complete voting:

1. **Aggregate votes** using ranked choice:
   - 1st choice = 3 points
   - 2nd choice = 2 points
   - 3rd choice = 1 point
2. **Select top 3** proposals by total points
3. **Handle ties** by comparing average scores across criteria
4. **Document selection** in `.specs/research/{solution-name}-{date}.selection.md`:
   - Vote tallies
   - Selected proposals
   - Consensus rationale

### Phase 3: Expansion (Develop Full Solutions)

Launch **3 independent agents in parallel** (recommended: Opus for quality):

1. Each agent receives:
   - **One selected proposal** to expand
   - **Original task description** and context
   - **Judge feedback** from pruning phase (concerns, questions)
2. Agent produces **complete solution** implementing the proposal:
   - Full implementation details
   - Addresses concerns raised by judges
   - Documents key decisions made during expansion
3. Solutions saved to `solution.a.md`, `solution.b.md`, `solution.c.md`

**Key principle:** Focused development of validated approaches with awareness of evaluation feedback.

**Prompt template for expansion agents:**

```markdown
You are developing a full solution based on a selected proposal.

<task>
{task_description}
</task>

<selected_proposal>
{write selected proposal EXACTLY as it is. Including all details provided by the agent}
Read this carefully - it is your starting point.
</selected_proposal>

<judge_feedback>
{concerns and questions from judges about this proposal}
Address these in your implementation.
</judge_feedback>

<output>
solution.[*].md where [*] is your unique identifier (a, b, or c)
</output>

Instructions:

Let's work through this systematically to ensure we build a complete, high-quality solution.

**Step 1: Understand the proposal deeply**
Before implementing, analyze:
- What is the core insight or approach of this proposal?
- What are the key design decisions already made?
- What gaps need to be filled for a complete solution?

**Step 2: Address judge feedback**
For each concern raised by judges:
- What specific change or addition addresses this concern?
- How does this change integrate with the proposal's approach?

**Step 3: Decompose into implementation subproblems**
Break the solution into logical parts:
- What are the main components or sections?
- What must be defined first for other parts to build upon?
- What are the dependencies between parts?

**Step 4: Implement each subproblem**
For each component, work through:
- Core functionality and behavior
- Edge cases and error handling
- Integration points with other components

**Step 5: Self-verification**
Generate 3-5 verification questions about critical aspects, then answer them:
- Review solution against each question
- Identify gaps or weaknesses
- Fix identified issues

**Step 6: Document changes**
Explain what was changed from the original proposal and why.

<example>
**Example of good expansion thinking:**

Proposal: "Use event-driven architecture with message queue"

Step 1 Analysis:
- Core insight: Decouple components via async messaging
- Key decisions: Events as primary communication, eventual consistency
- Gaps: Need to define event schemas, queue technology, error handling

Step 2 - Addressing judge concern "What about message ordering?":
- Add partition keys for ordered processing within entity scope
- Document ordering guarantees and limitations

Step 3 - Subproblems:
1. Event schema definitions (foundational - others depend on this)
2. Producer interfaces (depends on schemas)
3. Consumer handlers (depends on schemas)
4. Error handling and dead letter queues (depends on both)
5. Integration patterns (builds on all above)
</example>

CRITICAL:
- Stay faithful to the selected proposal's core approach
- Do not switch to a different approach midway
- Address judge feedback explicitly
- Produce a complete, implementable solution

フェーズ 3.5：評価メタジャッジの起動

重要： フェーズ 3 の拡張エージェントと並行して、評価メタジャッジを起動してください。メタジャッジは評価基準の生成に拡張結果を必要とせず、元のタスクの説明だけを必要とします。

評価メタジャッジは、完全なソリューション実装の評価に特化した評価仕様（ルーブリック、チェックリスト、採点基準）を生成します。

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

## Task

Generate an evaluation specification yaml for evaluating full solution implementations. You will produce rubrics, checklists, and scoring criteria that judge agents will use to evaluate and compare competitive implementations.

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 (full implementations developed from selected proposals)

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

起動：

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

フェーズ 4：評価（完全なソリューションをジャッジ）

次に進む前に、フェーズ 3 の拡張エージェントとフェーズ 3.5 の評価メタジャッジの両方が完了するまで待ってください。

独立した 3 人のジャッジを並行して起動します（厳密な評価には Opus を推奨）：

1. 各ジャッジに、すべてのソリューションファイル（solution.a.md、solution.b.md、solution.c.md）と評価メタジャッジの仕様 YAMLを渡します。
2. ジャッジは、メタジャッジが生成した評価基準に照らして評価します。
3. 各ジャッジは以下を作成します。
   • 比較分析（各ソリューションがどの点で優れているか）
   • 根拠に基づく評価（具体的な引用や例を含む）
   • 最終投票（どのソリューションを選ぶか、およびその理由）
4. レポートは .specs/reports/{solution-name}-{date}.[1|2|3].md に保存します。

重要な原則： メタジャッジが生成した仕様と明示的な根拠に基づく複数の独立評価により、偏りを減らし、品質のさまざまな側面を見落としにくくなります。

重要：各ジャッジには、評価メタジャッジの評価仕様 YAML をそのまま正確に渡してください。その内容を省略、追加、変更、短縮、要約してはいけません。

重要：スコアのしきい値をジャッジに絶対に知らせないでください。偏りを避けるため、ジャッジはスコアのしきい値を知らない必要があります。

評価ジャッジ用プロンプトテンプレート：

You are evaluating {number} full 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 solution files}
Read all solutions carefully before evaluating.

## Evaluation Specification

```yaml
{evaluation 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 形式で返してください！

**Dispatch:**

Task ツールを使用：

• description: "評価審査員 {1|2|3}：{タスクの簡単な概要}"
• prompt: {正確なメタ審査員仕様 YAML を含む評価審査員プロンプト}
• model: opus
• subagent_type: "sadd:judge"

### Phase 4.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 report files themselves, as they 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 4: 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 approach this polishing task methodically to improve without disrupting what works.

**Step 1: Understand why this solution won**
Analyze the winning solution:
- What are its core strengths that judges praised?
- What makes its approach superior to alternatives?
- Which parts should remain untouched?

**Step 2: Catalog improvement opportunities**
From judge feedback, identify:
- Specific weaknesses mentioned (list each one)
- Missing elements judges noted
- Areas where runner-ups were praised

**Step 3: Prioritize changes by impact**
For each improvement opportunity:
- High impact: Directly addresses judge criticism
- Medium impact: Adds praised element from runner-up
- Low impact: Nice-to-have refinement

Focus on high-impact changes first.

**Step 4: Apply improvements surgically**
For each change:
- Locate the specific section to modify
- Make the minimal change needed to address the issue
- Verify the change integrates cleanly with surrounding content

**Step 5: Cherry-pick from runners-up**
Review runner-up solutions for:
- 1-2 specific elements that judges praised
- Elements that complement (not conflict with) the winning approach
- Only incorporate if clearly superior to winning solution's version

**Step 6: Document all changes**
Record:
- What was changed and why (with reference to judge feedback)
- What was added from other solutions (cite source)
- What was intentionally left unchanged

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

戦略 2：REDESIGN

条件： すべての解決策のスコアが 3.0/5.0 未満（全般的に根本的な問題がある）

プロセス：

1. 新しいエージェントを起動し、失敗の要因と得られた教訓を分析する
2. フェーズ 3（展開）に戻り、得られた教訓と新たな制約を新しい実装エージェントに提示する

注： 再設計が 2 回失敗した場合は、ユーザーに指示を仰いでください。

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

You are analyzing why all solutions failed to meet quality standards, to inform a redesign. 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 solution files}
Average scores: A={avg_a}/5.0, B={avg_b}/5.0, C={avg_c}/5.0
</failed_solutions>

<evaluation_reports>
{list of paths to all evaluation reports}
All solutions scored below 3.0/5.0 threshold.
</evaluation_reports>

<output>
.specs/research/{solution-name}-{date}.redesign-analysis.md
</output>

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 以上）

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

フェーズ 5：統合（根拠に基づく組み合わせ）

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

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

1. エージェントに次のものを渡します：
   • すべての解決策（指定された出力先から）
   • すべての評価レポート（.specs/reports/ から）
   • 選定理由（プルーニングのフェーズから .specs/research/ を参照）
2. エージェントが分析する内容：
   • 共通する強み（複数の審査員が評価した点）
   • 共通する弱点（複数の審査員が指摘した点）
   • 相補的な要素（解決策ごとに異なるアプローチを採用した部分）
3. エージェントが次の方法で最終解決策を作成します：
   • ある解決策が明らかに優れている場合は、優れたセクションをコピーする
   • ハイブリッドのほうが優れている場合は、アプローチを組み合わせる
   • 審査員が指摘した問題を修正する
   • 決定内容（どの部分をどこから採用したか、その理由）を記録する

重要な原則： 根拠に基づく統合では、探索と評価から得られた集合知を活用します。

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

You are synthesizing the best solution from explored, pruned, and evaluated implementations.

<task>
{task_description}
</task>

<solutions>
{list of paths to all solution files}
</solutions>

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

<selection_rationale>
{path to selection.md explaining why these proposals were chosen}
</selection_rationale>

<output>
{output_path} - The final synthesized solution
</output>

Instructions:

Let's approach this synthesis systematically by first analyzing, then decomposing, then building.

**Step 1: Build the evidence base**
Before synthesizing, gather evidence from judge reports:
- What did multiple judges praise? (consensus strengths)
- What did multiple judges criticize? (consensus weaknesses)
- Where did judges disagree? (areas needing careful analysis)

**Step 2: Decompose into synthesis subproblems**
Break the solution into logical sections or components. For each component:
- Which solution handles this best? (cite evidence)
- Are there complementary elements from multiple solutions?
- What issues were identified that need fixing?

**Step 3: Solve each subproblem**
For each component/section, determine the synthesis strategy:

*Strategy A - Clear winner:* If one solution is clearly superior for this component:
- Copy that section directly
- Document: "Taken from Solution X because [judge evidence]"

*Strategy B - Complementary combination:* If solutions have complementary strengths:
- Identify what each contributes
- Combine carefully, ensuring consistency
- Document: "Combined X from Solution A with Y from Solution B because [rationale]"

*Strategy C - All flawed:* If all solutions have issues in this area:
- Start with the best version
- Apply fixes based on judge criticism
- Document: "Based on Solution X, modified to address [specific issues]"

**Step 4: Integrate and verify consistency**
After synthesizing all components:
- Check that combined elements work together
- Resolve any contradictions between borrowed sections
- Ensure consistent terminology and style

**Step 5: Document synthesis decisions**
Create a synthesis log:
- What you took from each solution (with specific citations)
- Why you made those choices (reference judge feedback)
- How you addressed identified weaknesses
- Any novel combinations or improvements

<example>
**Example synthesis decision for an API design:**

Component: Authentication flow
- Solution A: JWT with refresh tokens (praised for security by 2/3 judges)
- Solution B: Session-based (praised for simplicity by 1 judge, criticized for scalability)
- Solution C: OAuth2 only (criticized as over-engineered for use case)

Decision: Take Solution A's authentication flow directly.
Evidence: Judges 1 and 3 both noted "JWT approach provides good balance of security and statelessness"
Modification: None needed - this section was rated highest across judges.
</example>

**Step 6: Revise your solution**
- Generate 5 verification questions about critical aspects
- Answer your own questions:
   - Review solution against each question
   - Identify gaps or weaknesses
- Revise solution:
   - Fix identified issues
- Explain what was changed and why


CRITICAL:
- Do not create something entirely new - synthesize the best from what exists
- Cite your sources (which solution, which section)
- Explain every major decision
- Address all consensus weaknesses identified by judges

コマンドの出力は、選択された適応戦略によって異なります：

出力（すべての戦略）

1. 調査ディレクトリ： .specs/research/（存在しない場合は作成）

   • 提案：.specs/research/{solution-name}-{date}.proposals.[a|b|c].md - 確率を付した大まかなアプローチ
   • プルーニング：.specs/research/{solution-name}-{date}.pruning.[1|2|3].md - 審査員の評価と投票
   • 選定：.specs/research/{solution-name}-{date}.selection.md - 投票集計と選定された提案

2. 展開の出力：

   • solution.a.md、solution.b.md、solution.c.md - 完全な実装（指定された出力先）

3. レポートディレクトリ： .specs/reports/（存在しない場合は作成）

   • 評価：.specs/reports/{solution-name}-{date}.[1|2|3].md - 最終審査員レポート

4. 生成される解決策： {output_path}

戦略固有の出力

• SELECT_AND_POLISH：勝利した解決策に基づき、対象を絞った改善を加えた洗練済みの解決策
• REDESIGN：停止せず、得られた教訓をもとにフェーズ 3 に戻ります。最終的に SELECT_AND_POLISH または FULL_SYNTHESIS で完了します
• FULL_SYNTHESIS：すべての解決策から優れた要素を組み合わせた統合済みの解決策

ベストプラクティス

メタ審査員と審査員による検証

• メタ審査員は 2 つ - プルーニング（提案）用と評価（完全な解決策）用に仕様を分けます
• メタ審査員は実装と並行して実行します - パイプラインを停止させないでください。プルーニング用メタ審査員はフェーズ 1 と並行して実行し、評価用メタ審査員はフェーズ 3 と並行して実行します
• CLAUDE_PLUGIN_ROOT を含めます - メタ審査員と審査員の両方に、解決済みのプラグインルートパスが必要です
• メタ審査員の YAML - 審査員には YAML のみを渡し、変更しないでください

よくある落とし穴

• 探索が不十分 - エージェントが似たアプローチを提案します
• 審査役のフィードバックを無視する - 展開時に、枝刈り時の懸念が考慮されません
• 提案が曖昧 - 実装の詳細がないと適切に評価できません
• 探索しすぎる - 提案が多すぎると、評価のコストが高くなります
• 明確な勝者がいるのに統合を強行する - コストが無駄になり、品質を損なうリスクがあります
• 根本的に欠陥のある解決策を統合する - ひどい案を磨くより、再設計するほうが適切です

推奨事項

• 多様な探索を促す - 解決策の異なる領域を探るように指示します
• フィードバックを次の段階に反映する - 展開を担当するエージェントが、枝刈りで挙がった懸念に対処します
• 適切な詳細度にする - 提案には評価に十分な詳細を含めます
• 積極的に枝刈りする - 最も有望な3つのアプローチだけを展開します
• 適応型の戦略選択を信頼する - 明確な勝者は磨き、意見が分かれた場合は統合し、失敗した場合は再設計します

例：API 設計

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

フェーズ1の出力（日付が2025-01-15の場合）：

• .specs/research/users-api-2025-01-15.proposals.a.md - エージェントAによる6つのアプローチ
• .specs/research/users-api-2025-01-15.proposals.b.md - エージェントBによる6つのアプローチ
• .specs/research/users-api-2025-01-15.proposals.c.md - エージェントCによる6つのアプローチ

フェーズ1.5の出力（フェーズ1と並行して実行）：

• 枝刈りメタ審査役（Opus、sadd:meta-judge）が枝刈り評価仕様のYAMLを生成

フェーズ2の出力（枝刈りメタ審査役の仕様を使用する3人の審査役）：

• .specs/research/users-api-2025-01-15.pruning.1.md - 上位3案：リソースベースのREST、純粋なREST、モノリシック
• .specs/research/users-api-2025-01-15.pruning.2.md - 上位3案：純粋なREST、ハイブリッド（サービス）、リソースベースのREST
• .specs/research/users-api-2025-01-15.pruning.3.md - 上位3案：リソースベースのREST、RESTとGraphQLのハイブリッド、純粋なREST
• .specs/research/users-api-2025-01-15.selection.md - 選出案：リソースベースのREST（8点）、純粋なREST（7点）、モノリシック（4点）

フェーズ3の出力：

• specs/api/users.a.md - ネストされたルートを持つ、リソースベースの完全な設計
• specs/api/users.b.md - シンプルなエンドポイントを持つ、フラットなREST設計
• specs/api/users.c.md - サービス指向の内部構造を持つ、モノリシックAPI

フェーズ3.5の出力（フェーズ3と並行して実行）：

• 評価メタ審査役（Opus、sadd:meta-judge）が評価仕様のYAMLを生成

フェーズ4の出力（評価メタ審査役の仕様を使用する3人の審査役）：

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

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

  「RESTらしさではAを支持し、Cの複雑さを批判」

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

  VOTE: Solution B
  SCORES: A=3.9/5.0, B=4.1/5.0, C=3.5/5.0
  

  「シンプルさではBを支持し、Aの深いネストを批判」

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

  VOTE: Solution A
  SCORES: A=4.3/5.0, B=3.6/5.0, C=3.2/5.0
  

  「発見しやすさではAを支持し、Bに構造が欠けている点を批判」

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

• 投票が分かれる：A、B、A（一致した勝者なし）
• 平均スコア：A=4.1、B=3.8、C=3.4（すべて3.0以上）
• 戦略：FULL_SYNTHESIS
• 理由：意見は分かれているものの各案に長所があり、統合が必要

フェーズ5の出力（統合）：

• specs/api/users.md - リソースベースの構造（Aから）、最大2階層のネスト（Bから）、内部サービス（Cから）