Execute tasks through systematic exploration, pruning, and expansion using Tree of Thoughts methodology with meta-judge evaluation specifications and multi-agent evaluation

tree of thoughts <task Execute complex reasoning tasks through systematic exploration of solution space, pruning unpromising branches, expanding viable approaches, and synthesizing the best solution. </task <context This command implements the Tree of Thoughts (ToT) pattern for tasks requiring exploration of multiple solution paths before committing to full implementation. It combines creative sampling, meta judge generated evaluation specifications, multi perspective evaluation, adaptive strategy selection, and evidence based synthesis to produce superior outcomes. Key benefits: Systematic exploration Multiple agents explore different regions of the solution space Structured evaluation Meta judges produce tailored rubrics and criteria before judging Independent verification Judges apply meta judge specifications mechanically, reducing bias Adaptive strategy Clear winners get polished, split decisions get synthesized, failures get redesigned </context Pattern: Tree of Thoughts (ToT) This command implements an eight phase systematic reasoning pattern with meta judge evaluation and adaptive strategy selection: Process Setup: Create Directory Structure Before starting, ensure the directory structure exists: Naming conventions: Proposals: .specs/research/{solution name} {YYYY MM DD}.proposals.[a b c].md Pruning: .specs/research/{solution name} {YYYY MM DD}.pruning.[1 2 3].md Selection: .specs/research/{solution name} {YYYY MM DD}.selection.md Evaluation: .specs/reports/{solution name} {YYYY MM DD}.[1 2 3].md Where: {solution name} Derived from output path (e.g., users api from output specs/api/users.md ) {YYYY MM DD} Current date Note: Solutions remain in their specified output locations; only research and evaluation files go to .specs/ Phase 1: Exploration (Propose Approaches) Launch 3 independent agents in parallel (recommended: Sonnet for speed): 1. Each agent receives identical task description and context 2. Each agent generates 6 high level approaches (not full implementations) 3. For each approach, agent provides: Approach description (2 3 paragraphs) Key design decisions and trade offs Probability estimate (0.0 1.0) Estimated complexity (low/medium/high) Potential risks and failure modes 4. Proposals saved to .specs/research/{solution name} {date}.proposals.[a b c].md Key principle: Systematic exploration through probabilistic sampling from the full distribution of possible approaches. Prompt template for explorers: Phase 1.5: Dispatch Pruning Meta Judge CRITICAL : Launch the pruning meta judge in parallel with Phase 1 exploration agents . The meta judge does not need exploration output to generate pruning criteria — it only needs the original task description. The pruning meta judge generates an evaluation specification (rubrics, checklist, scoring criteria) tailored to evaluating high level proposals for pruning. Prompt template for pruning meta judge: Dispatch: Phase 2: Pruning (Vote for Top 3 Candidates) Wait for BOTH Phase 1 exploration agents AND Phase 1.5 pruning meta judge to complete before proceeding. Launch 3 independent judges in parallel (recommended: Opus for rigor): 1. Each judge receives ALL proposal files (from .specs/research/ ) and the pruning meta judge evaluation specification YAML 2. Judges evaluate each proposal against the meta judge generated pruning criteria 3. Each judge produces: Scores for each proposal (with evidence) Vote for top 3 proposals to expand Rationale for selections 4. Votes saved to .specs/research/{solution name} {date}.pruning.[1 2 3].md Key principle: Independent evaluation with meta judge generated criteria ensures consistent, tailored assessment without hardcoded weights. CRITICAL: Provide to each judge the EXACT pruning meta judge's evaluation specification YAML. Do not skip, add, modify, shorten, or summarize any text in it! Prompt template for pruning judges: yaml {pruning meta judge's evaluation specification YAML} Dispatch: 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: Phase 3.5: Dispatch Evaluation Meta Judge CRITICAL : Launch the evaluation meta judge in parallel with Phase 3 expansion agents . The meta judge does not need expansion output to generate evaluation criteria — it only needs the original task description. The evaluation meta judge generates an evaluation specification (rubrics, checklist, scoring criteria) tailored to evaluating full solution implementations. Prompt template for evaluation meta judge: Dispatch: Phase 4: Evaluation (Judge Full Solutions) Wait for BOTH Phase 3 expansion agents AND Phase 3.5 evaluation meta judge to complete before proceeding. Launch 3 independent judges in parallel (recommended: Opus for rigor): 1. Each judge receives ALL solution files (solution.a.md, solution.b.md, solution.c.md) and the evaluation meta judge specification YAML 2. Judges evaluate against the meta judge generated evaluation criteria 3. Each judge produces: Comparative analysis (which solution excels where) Evidence based ratings (with specific quotes/examples) Final vote (which solution they prefer and why) 4. Reports saved to .specs/reports/{solution name} {date}.[1 2 3].md Key principle: Multiple independent evaluations with meta judge generated specifications and explicit evidence reduce bias and catch different quality aspects. CRITICAL: Provide to each judge the EXACT evaluation meta judge's evaluation specification YAML. Do not skip, add, modify, shorten, or summarize any text in it! CRITICAL: NEVER provide score threshold to judges. Judge MUST not know what threshold for score is, in order to not be biased!!! Prompt template for evaluation judges: yaml {evaluation meta judge's evaluation specification YAML} Dispatch: 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: Strategy 2: REDESIGN When: All solutions scored <3.0/5.0 (fundamental issues across the board) Process: 1. Launch new agent to analyze the failure modes and lessons learned 2. Return to Phase 3 (Expansion), provide to new implementation agents the lessons learned and new constraints Note: If redesign fails twice, escalate to user for guidance. Prompt template for new implementation: Strategy 3: FULL SYNTHESIS (Default) When: No clear winner AND solutions have merit (scores =3.0) Process: Proceed to Phase 5 (Evidence Based Synthesis) Phase 5: Synthesis (Evidence Based Combination) Only executed when Strategy 3 (FULL SYNTHESIS) selected in Phase 4.5 Launch 1 synthesis agent (recommended: Opus for quality): 1. Agent receives: All solutions (from specified output location) All evaluation reports (from .specs/reports/ ) Selection rationale from pruning phase (from .specs/research/ ) 2. Agent analyzes: Consensus strengths (what multiple judges praised) Consensus weaknesses (what multiple judges criticized) Complementary elements where solutions took different approaches 3. Agent produces final solution by: Copying superior sections when one solution clearly wins Combining approaches when hybrid is better Fixing identified issues that judges caught Documenting decisions (what was taken from where and why) Key principle: Evidence based synthesis leverages collective intelligence from exploration and evaluation. Prompt template for synthesizer: <output The command produces different outputs depending on the adaptive strategy selected: Outputs (All Strategies) 1. Research directory: .specs/research/ (created if not exists) Proposals: .specs/research/{solution name} {date}.proposals.[a b c].md High level approaches with probabilities Pruning: .specs/research/{solution name} {date}.pruning.[1 2 3].md Judge evaluations and votes Selection: .specs/research/{solution name} {date}.selection.md Vote tallies and selected proposals 2. Expansion outputs: solution.a.md , solution.b.md , solution.c.md Full implementations (in specified output location) 3. Reports directory: .specs/reports/ (created if not exists) Evaluation: .specs/reports/{solution name} {date}.[1 2 3].md Final judge reports 4. Resulting solution: {output path} Strategy Specific Outputs SELECT AND POLISH : Polished solution based on winning solution, with targeted improvements REDESIGN : Do not stop; return to Phase 3 with lessons learned; eventually finishes at SELECT AND POLISH or FULL SYNTHESIS FULL SYNTHESIS : Synthesized solution combining best elements from all solutions </output Best Practices Meta Judge + Judge Verification Two meta judges Separate specs for pruning (proposals) and evaluation (full solutions) Meta judges run in parallel with implementation Don't block the pipeline; pruning meta judge runs with Phase 1, evaluation meta judge runs with Phase 3 Include CLAUDE PLUGIN ROOT Both meta judges and judges need the resolved plugin root path Meta judg

tree-of-thoughts