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

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