tree-of-thoughts

思维树

通过系统地探索解决方案空间、剪除前景不佳的分支、扩展可行方案，并综合得出最佳解决方案，来执行复杂的推理任务。 此命令为需要在全面实施前探索多条解决路径的任务实现了思维树（ToT）模式。它结合创造性采样、由元评审生成的评估规范、多视角评估、自适应策略选择和基于证据的综合分析，从而产出更优结果。

主要优势：

• 系统探索 - 多个 Agent 探索解决方案空间的不同区域
• 结构化评估 - 元评审在评判前制定定制化评分标准和评估准则
• 独立验证 - 评审者机械地应用元评审规范，减少偏见
• 自适应策略 - 明确的胜出方案会得到完善，意见分歧会得到综合，失败方案则会重新设计

模式：思维树（ToT）

此命令实现了一个包含元评审评估和自适应策略选择的八阶段系统化推理模式：

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 个独立 Agent（建议使用速度较快的 Sonnet）：

1. 每个 Agent 接收相同的任务描述和上下文
2. 每个 Agent 生成 6 个高层方案（不是完整实现）
3. 对于每个方案，Agent 提供：
   • 方案描述（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 的探索 Agent 并行启动。元评审无需等待探索输出即可制定剪枝标准，只需获取原始任务描述即可。

剪枝元评审会生成评估规范（评分标准、检查清单、评分准则），以便针对高层提案进行剪枝评估。

剪枝元评审提示词模板：

## 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 的探索 Agent 和阶段 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}

指令

请遵循 Agent 指令中定义的完整评审流程！

重要：你必须在回复开头以 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 的扩展 Agent 并行启动评估元评审。生成评估标准不需要扩展输出——评估元评审只需原始任务描述。

评估元评审会生成一份评估规范（评分细则、检查清单、评分标准），用于针对完整解决方案的实现进行评估。

评估元评审提示词模板：

## 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 的扩展 Agent 和阶段 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 ...

---

[评估摘要]

说明

按照 Agent 指令中定义的完整评审流程执行！

关键：必须在回复开头以 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：重新设计

条件： 所有方案得分均 <3.0/5.0（各方案都存在根本性问题）

流程：

1. 启动新 Agent，分析失败模式并总结经验教训
2. 返回阶段 3（扩展），向新的实现 Agent 提供经验教训和新约束

注意： 如果重新设计失败两次，请向用户寻求指导。

新实现提示词模板：

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：完整综合（默认）

条件： 没有明显胜出者，但各方案都有可取之处（得分 >=3.0）

流程： 进入阶段 5（基于证据的综合）

阶段 5：综合（基于证据的组合）

仅当在阶段 4.5 中选择策略 3（完整综合）时才执行

启动 1 个综合 Agent（建议使用 Opus，以保证质量）：

1. Agent 接收：
   • 所有方案（来自指定的输出位置）
   • 所有评估报告（来自 .specs/reports/）
   • 筛选阶段的选择依据（来自 .specs/research/）
2. Agent 分析：
   • 共识优势（多位评审员赞赏的内容）
   • 共识弱点（多位评审员批评的内容）
   • 各方案采用不同方法的互补要素
3. Agent 通过以下方式生成最终方案：
   • 当某个方案明显更优时，复制其出色部分
   • 混合方案更优时，组合不同方法
   • 修复评审员发现的问题
   • 记录决策（采用了哪些内容、来自哪里以及原因）

核心原则： 基于证据的综合利用探索和评估中的集体智慧。

综合 Agent 提示词模板：

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：综合所有方案的最佳要素后生成的方案

最佳实践

元评审员与评审员验证

• 两位元评审员——分别为筛选（提案）和评估（完整方案）制定规范
• 元评审员与实现并行运行——不要阻塞工作流；筛选元评审员与阶段 1 并行运行，评估元评审员与阶段 3 并行运行
• 包含 CLAUDE_PLUGIN_ROOT——元评审员和评审员都需要解析后的插件根路径
• 元评审员 YAML——只将 YAML 传给评审员，不要修改它

常见陷阱

• 探索不足 - Agent 提出相似的方法
• 忽略评审反馈 - 扩展阶段忽视精简阶段提出的问题
• 提案含糊 - 缺少实现细节，无法进行恰当评估
• 过度探索 - 提案过多，评估成本随之增加
• 已有明确胜出方案时仍强行综合 - 浪费成本，还有降低质量的风险
• 综合存在根本缺陷的方案 - 与其美化糟糕的方案，不如重新设计

建议

• 鼓励多样化探索 - 提示 Agent 探索解决方案空间中的不同区域
• 传递反馈 - 扩展阶段的 Agent 应回应精简阶段提出的问题
• 把握合适的细节程度 - 提案应包含足够的细节，以便评估
• 积极精简 - 仅扩展最有希望的 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 - Agent A 提出的 6 种方法
• .specs/research/users-api-2025-01-15.proposals.b.md - Agent B 提出的 6 种方法
• .specs/research/users-api-2025-01-15.proposals.c.md - Agent 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）