breadth-of-thought

name	breadth-of-thought
description	Exhaustive solution space exploration methodology. Use when solution space is unknown, you need multiple viable options (not just one best), or can't afford to miss alternatives. Explores 8-10 approaches in parallel at each level, prunes conservatively (keep above 40% confidence), returns 3-5 viable solutions. Example - data pipeline options - Apply BoT to explore all architectures exhaustively.
model	opus
context	fork
agent	general-purpose
user-invocable	true

Effort & Thinking Budget

• Recommended effort: high — exhaustive exploration needs depth to avoid shallow analysis
• Include "ultrathink" in complex analysis phases to enable extended thinking
• For time-constrained scenarios, use effort: medium with reduced branch count (5 approaches instead of 8-10)

Model Recommendation

Best with Opus for maximum reasoning depth. On Sonnet, reduce to 5 approaches per level to maintain analysis quality.

Breadth of Thought Reasoning Methodology

Purpose: Exhaustive exploration of solution spaces through systematic parallel breadth-first reasoning. Maintains multiple hypotheses, explores diverse approaches, and returns 3-5 viable solutions instead of prematurely converging on one.

When to Use Breadth of Thought

✅ Use BoT when:

• Unknown solution space (you don't know what you don't know)
• Multiple valid solutions needed (need 3-5 good options, not just 1 best)
• High-stakes decisions (can't afford to miss viable alternatives)
• Novel problems (no clear best practice exists)
• Debugging complex issues (multiple potential root causes)
• Comprehensive planning (need to evaluate ALL options before deciding)

❌ Don't use BoT when:

• Clear evaluation criteria exist and you need THE single best solution → Use tree-of-thoughts
• Problem requires deep sequential reasoning with dependencies → Use self-reflecting-chain
• Single obvious approach exists → Solve directly
• Time-critical with simple trade-offs → Quick analysis sufficient

Examples:

• "Redesign data pipeline: batch, streaming, hybrid, or other?" (unknown space) ✅
• "System crashes intermittently: network, DB, memory, race, or config?" (multiple causes) ✅
• "Choose caching strategy: write-through, eventual, hybrid?" (clear criteria - use ToT) ❌
• "Fix syntax error" (obvious solution) ❌

---

Breadth vs Depth Comparison

Dimension	Breadth of Thought	Tree of Thoughts
Exploration	Wide: 8-10 branches per level	Deep: 5 branches → 1 best
Pruning	Conservative: Keep >40%	Aggressive: Keep top 1-2
Levels	Shallow: 2-3 levels	Deep: 4-6 levels
Output	3-5 viable solutions	1 optimal solution
Use when	Solution space unknown	Evaluation criteria clear
Total exploration	50-100 branches	25-40 branches
Philosophy	"Don't miss anything"	"Find the best"

---

Core Methodology: 4-Step Process

Step 1: Solution Space Mapping (8-10 Approaches)

Objective: Identify 8-10 fundamentally distinct approaches

Actions:

1. Analyze problem from multiple perspectives:

   • Technical: Different technologies, architectures, patterns
   • Business: Different cost models, value propositions
   • Organizational: Different team structures, processes
   • Risk: Conservative vs innovative approaches
   • Timeline: Quick wins vs long-term solutions

2. Generate 8-10 distinct approaches (not variations)

3. For each approach, create brief description and viability estimate

4. Do NOT prune yet - explore all in parallel

Approach Diversity Requirement:

• ❌ Variations: "Use PostgreSQL" vs "Use MySQL" (both relational)
• ✅ Distinct: "Relational DB" vs "Document store" vs "Event sourcing" vs "In-memory cache"

Example (Data Pipeline):

1. **Batch processing** (traditional ETL)
2. **Real-time streaming** (Kafka/Flink)
3. **Micro-batch** (Spark Structured Streaming)
4. **Lambda architecture** (batch + stream hybrid)
5. **Kappa architecture** (stream-only)
6. **Event sourcing** (immutable log)
7. **Change data capture** (DB triggers)
8. **Serverless functions** (FaaS on events)

Deliverable: 8-10 distinct approaches ready for parallel exploration

---

Step 2: Level 0 Breadth Exploration (Parallel)

Objective: Explore EACH approach in depth with self-reflection

For each of 8-10 approaches:

1. Research the approach comprehensively
2. Analyze strengths, weaknesses, constraints
3. Identify use cases where it excels vs struggles
4. Estimate feasibility, complexity, risk
5. Rate confidence (0-100%) in viability
6. Document trade-offs and assumptions

Exploration Template (per approach):

## Approach [N]: [Name]

### Overview
[2-3 sentence description]

### Strengths
- [Strength 1]
- [Strength 2]
- [Strength 3]

### Weaknesses
- [Weakness 1]
- [Weakness 2]
- [Weakness 3]

### Use Cases
- **Excels when**: [Scenario where this is optimal]
- **Struggles when**: [Scenario where this is problematic]

### Feasibility Assessment
- **Technical**: [Complexity, maturity, team expertise]
- **Operational**: [Maintenance, monitoring, scaling]
- **Business**: [Cost, time-to-market, ROI]

### Confidence: [0-100]%

**Rationale**: [Why this confidence level]

### Key Assumptions
- [Assumption 1]
- [Assumption 2]

Execution Options:

• With Task tool: Spawn 8-10 parallel tasks for independent exploration
• Without Task tool: Explore sequentially, using TodoWrite to track progress
• Hybrid: Use Task for complex approaches, sequential for simpler ones

Deliverable: 8-10 explored approaches with confidence scores

---

Step 3: Conservative Pruning (Keep >40%)

Objective: Evaluate all branches and prune ONLY the clearly non-viable

Pruning Philosophy: Breadth of Thought is conservative - we keep branches that might work, even if not optimal. Only prune if confidence <40% AND fatal blocker exists.

Actions:

1. Review all Level 0 explorations
2. Score each approach:
   • Feasibility: Technical, operational, business viability
   • Completeness: How thoroughly was it explored?
   • Risk vs Reward: What's the upside/downside balance?
3. Prune ONLY if:
   • Confidence <40% AND
   • Fatal technical blocker identified AND
   • No mitigating strategies possible
4. For retained branches (typically 5-7), document why kept
5. Rank retained branches for Level 1 expansion

Pruning Examples:

✅ Keep (50% confidence):

• Approach is technically feasible but has implementation challenges
• Team lacks expertise but can hire/learn
• Cost is high but ROI justifies it
• Reason: Viable with mitigation, worth exploring deeper

❌ Prune (35% confidence):

• Approach requires technology that doesn't exist yet
• Violates hard constraint (e.g., regulatory compliance impossible)
• Cost exceeds budget by 10x with no path to reduce
• Reason: Fundamentally not viable, no mitigating strategies

Typical Outcome: Prune 2-3 approaches, retain 5-7 for Level 1

Deliverable: 5-7 retained approaches ranked by viability

---

Step 4: Level 1+ Expansion (5 Sub-Approaches Each)

Objective: For each retained approach, explore 5 variations/implementations

Actions:

1. Take each of the 5-7 retained approaches from Step 3
2. For each approach, identify 5 sub-approaches (variations, implementations, configurations)
3. Explore each sub-approach (same depth as Level 0)
4. Evaluate and prune conservatively (keep >40%)
5. (Optional) Level 2: If time allows and depth needed, repeat for top branches

Level 1 Decomposition (per retained approach):

## Level 1: Expanding Approach [N]

### Sub-Approach [N].1: [Variation 1]
[Exploration...]

### Sub-Approach [N].2: [Variation 2]
[Exploration...]

### Sub-Approach [N].3: [Variation 3]
[Exploration...]

### Sub-Approach [N].4: [Variation 4]
[Exploration...]

### Sub-Approach [N].5: [Variation 5]
[Exploration...]

Example (Expanding "Real-time Streaming"):

Approach 2: Real-time Streaming
├─ 2.1: Kafka + Flink
├─ 2.2: Kafka + Spark Streaming
├─ 2.3: AWS Kinesis + Lambda
├─ 2.4: Pulsar + custom processors
└─ 2.5: Redis Streams + Node.js workers

Stopping Criteria:

• After Level 1: If you have 10-15 viable sub-approaches (sufficient breadth)
• Continue to Level 2: If approaches still too abstract, need implementation details
• Maximum Depth: 3 levels (breadth over depth philosophy)

Deliverable: 10-20 viable solutions across all expanded approaches

---

Final Synthesis: Return Top 3-5 Solutions

Objective: Synthesize exploration into actionable recommendations

Actions:

1. Review ALL explored branches (Level 0 + Level 1 + Level 2)
2. Identify top 10-15 branches by confidence score
3. Group similar approaches together
4. Select top 3-5 distinct solutions representing different trade-off profiles
5. For each selected solution, document:
   • Full path (e.g., Approach 2 → Sub-approach 2.3)
   • Confidence score and rationale
   • Key strengths and weaknesses
   • Best use case
   • Implementation considerations

Synthesis Template:

## Breadth of Thought Analysis Complete

### Total Exploration
- **Level 0**: 8 approaches explored → 6 retained
- **Level 1**: 30 sub-approaches explored → 12 retained
- **Total branches analyzed**: 38
- **Time**: [X] minutes

### Top 5 Viable Solutions

#### Solution 1: [Name] (Confidence: [X]%)
- **Path**: Approach [N] → Sub-approach [N.M]
- **Best for**: [Use case where this excels]
- **Strengths**: [Key strengths]
- **Weaknesses**: [Key weaknesses]
- **Implementation**: [Complexity, timeline, resources]

#### Solution 2: [Name] (Confidence: [X]%)
[Same structure...]

#### Solution 3: [Name] (Confidence: [X]%)
[Same structure...]

#### Solution 4: [Name] (Confidence: [X]%)
[Same structure...]

#### Solution 5: [Name] (Confidence: [X]%)
[Same structure...]

### Trade-Off Analysis

**If you prioritize [X]**, choose **Solution [N]**
**If you prioritize [Y]**, choose **Solution [M]**
**If you prioritize [Z]**, choose **Solution [P]**

### Recommendation

Based on [stated priorities/constraints], I recommend:
1. **Primary**: Solution [N] ([X]% confidence)
2. **Alternative**: Solution [M] ([X]% confidence) if [condition]
3. **Backup**: Solution [P] ([X]% confidence) if [condition]

### Branches Not Explored

Due to time/scope constraints, the following were not explored:
- [Potential approach 1]
- [Potential approach 2]

These could be investigated if none of the top 5 solutions work out.

Deliverable: 3-5 viable solutions with clear trade-off analysis

---

Resource Management

Time Budget (if resource-constrained):

• Level 0: 15-20 minutes (8-10 approaches)
• Level 1: 20-30 minutes (5-7 approaches × 5 sub-approaches)
• Level 2: 15-20 minutes (optional, if time allows)
• Total: 50-70 minutes maximum

Batch Execution (with Task tool):

1. Spawn Level 0 tasks in single batch (8-10 tasks)
2. Wait for completion, evaluate, prune
3. Spawn Level 1 tasks in batches of 10-15
4. Monitor time, stop spawning if approaching limit

Early Termination (if time runs out):

• Evaluate completed branches only
• Return partial results with note about incomplete exploration
• State confidence level based on partial coverage

---

Self-Critique Checklist

After applying BoT methodology, verify:

• Sufficient Breadth: Did I explore 8-10 approaches at Level 0?
• Approach Diversity: Are approaches fundamentally different (not variations)?
• Conservative Pruning: Did I keep all branches >40% confidence?
• Depth Per Branch: Did each branch get thorough exploration (not surface-level)?
• Multiple Solutions: Am I returning 3-5 solutions (not just 1 "best")?
• Trade-Off Clarity: Can user choose based on their priorities?
• Confidence Validity: Are confidence scores justified by exploration depth?
• Completeness: Did I explore enough to confidently say "I didn't miss anything major"?

---

Common Mistakes to Avoid

1. Premature Pruning: Cutting branches at 50-60% confidence instead of <40%
2. Depth Over Breadth: Going 5 levels deep on 2 approaches instead of 2 levels on 8 approaches
3. Variation vs Diversity: Exploring PostgreSQL, MySQL, MariaDB as "3 approaches" (all relational)
4. Single Winner: Returning only 1 solution like ToT, defeating purpose of BoT
5. Shallow Exploration: Brief 1-paragraph analyses instead of thorough investigation
6. Ignoring Unknown Unknowns: Not exploring "wild card" unconventional approaches
7. Over-Execution: Going to Level 3-4 when Level 2 already gave 20+ viable solutions

---

Breadth-First vs Depth-First Decision Guide

| Problem Characteristic | Use BoT (Breadth) | Use ToT (Depth) |