/ensemble-solving

name: ensemble-solving
description: Generate multiple diverse solutions in parallel and select the best. Use for architecture decisions, code generation with multiple valid approaches, or creative tasks where exploring alternatives improves quality.

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