流程

设置：创建目录结构

开始前，确保目录结构存在：

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}

Output

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

Instructions

Follow your full judge process as defined in your agent instructions!

CRITICAL: You must reply with this exact structured evaluation report format in YAML at the START of your response!

**Dispatch:**

Use Task tool:

• 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:

  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}

Output

Write full report to: .specs/reports/{solution-name}-{date}.[1|2|3].md

CRITICAL: You must reply with this exact structured header format:

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

[Summary of your evaluation]

Instructions

Follow your full judge process as defined in your agent instructions!

CRITICAL: You must reply with this exact structured evaluation report format in YAML at the START of your response!

**Dispatch:**

Use Task tool:

• description: "Evaluation Judge {1|2|3}: {brief task summary}"

• prompt: {evaluation judge prompt with exact meta-judge specification 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:

  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. 启动新的智能体来分析失败模式和经验教训
2. 返回到阶段 3（扩展），向新的实现智能体提供经验教训和新的约束

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

新实现的提示模板：

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 (FULL_SYNTHESIS) 时执行

启动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：综合了所有解决方案最佳元素的综合方案

最佳实践

元评委 + 评委验证

• 两个元评委 - 分别用于筛选（提案）和评估（完整解决方案）的规范
• 元评委与实现并行运行 - 不阻塞流程；筛选元评委与阶段 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

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

Prompt template for expansion agents:

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

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:

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.

Reports directory: .specs/reports/ (created if not exists)

• Evaluation: .specs/reports/{solution-name}-{date}.[1|2|3].md - Final judge reports