Ensemble Solving

# Ensemble Problem Solving

Generate multiple solutions in parallel by spawning 3 subagents with different approaches, then evaluate and select the best result.

## When to Use

**Activation phrases:**
- "Give me options for..."
- "What's the best way to..."
- "Explore different approaches..."
- "I want to see alternatives..."
- "Compare approaches for..."
- "Which approach should I use..."

**Good candidates:**
- Architecture decisions with trade-offs
- Code generation with multiple valid implementations
- API design with different philosophies
- Naming, branding, documentation style
- Refactoring strategies
- Algorithm selection

**Skip ensemble for:**
- Simple lookups or syntax questions
- Single-cause bug fixes
- File operations, git commands
- Deterministic configuration changes
- Tasks with one obvious solution

## What It Does

1. **Analyzes the task** to determine if ensemble approach is valuable
2. **Generates 3 distinct prompts** using appropriate diversification strategy
3. **Spawns 3 parallel subagents** to develop solutions independently
4. **Evaluates all solutions** using weighted criteria
5. **Returns the best solution** with explanation and alternatives summary

## Approach

### Step 1: Classify Task Type

Determine which category fits:
- **Code Generation**: Functions, classes, APIs, algorithms
- **Architecture/Design**: System design, data models, patterns
- **Creative**: Writing, naming, documentation

### Step 2: Invoke Ensemble Orchestrator

```
Task tool with:
- subagent_type: 'ensemble-orchestrator'
- description: 'Generate and evaluate 3 parallel solutions'
- prompt: [User's original task with full context]
```

The orchestrator handles:
- Prompt diversification
- Parallel execution
- Solution evaluation
- Winner selection

### Step 3: Present Result

The orchestrator returns:
- The winning solution (in full)
- Evaluation scores for all 3 approaches
- Why the winner was selected
- When alternatives might be preferred

## Diversification Strategies

**For Code (Constraint Variation):**
| Approach | Focus |
|----------|-------|
| Simplicity | Minimal code, maximum readability |
| Performance | Efficient, optimized |
| Extensibility | Clean abstractions, easy to extend |

**For Architecture (Approach Variation):**
| Approach | Focus |
|----------|-------|
| Top-down | Requirements → Interfaces → Implementation |
| Bottom-up | Primitives → Composition → Structure |
| Lateral | Analogies from other domains |

**For Creative (Persona Variation):**
| Approach | Focus |
|----------|-------|
| Expert | Technical precision, authoritative |
| Pragmatic | Ship-focused, practical |
| Innovative | Creative, unconventional |

## Evaluation Rubric

| Criterion | Base Weight | Description |
|-----------|-------------|-------------|
| Correctness | 30% | Solves the problem correctly |
| Completeness | 20% | Addresses all requirements |
| Quality | 20% | How well-crafted |
| Clarity | 15% | How understandable |
| Elegance | 15% | How simple/beautiful |

Weights adjust based on task type.

## Example

**User:** "What's the best way to implement a rate limiter?"

**Skill:**
1. Classifies as Code Generation
2. Invokes ensemble-orchestrator
3. Three approaches generated:
   - Simple: Token bucket with in-memory counter
   - Performance: Sliding window with atomic operations
   - Extensible: Strategy pattern with pluggable backends
4. Evaluation selects extensible approach (score 8.4)
5. Returns full implementation with explanation

**Output:**
```
## Selected Solution

[Full rate limiter implementation with strategy pattern]

## Why This Solution Won

The extensible approach scored highest (8.4) because it provides
a clean abstraction that works for both simple use cases and
complex distributed scenarios. The strategy pattern allows
swapping Redis/Memcached backends without code changes.

## Alternatives

- **Simple approach**: Best if you just need basic in-memory
  limiting and will never scale beyond one process.

- **Performance approach**: Best for high-throughput scenarios
  where every microsecond matters.
```

## Success Criteria

- 3 genuinely different solutions generated
- Clear evaluation rationale provided
- Winner selected with confidence
- Alternatives summarized with use cases
- User understands trade-offs

## Token Cost

~4x overhead vs single attempt. Worth it for:
- High-stakes architecture decisions
- Creative work where first attempt rarely optimal
- Learning scenarios where seeing alternatives is valuable
- Code that will be maintained long-term

## Integration

- **feature-planning**: Can ensemble architecture decisions
- **code-auditor**: Can ensemble analysis perspectives
- **plan-implementer**: Executes the winning approach