| 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
- Analyzes the task to determine if ensemble approach is valuable
- Generates 3 distinct prompts using appropriate diversification strategy
- Spawns 3 parallel subagents to develop solutions independently
- Evaluates all solutions using weighted criteria
- 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:
- Classifies as Code Generation
- Invokes ensemble-orchestrator
- Three approaches generated:
- Simple: Token bucket with in-memory counter
- Performance: Sliding window with atomic operations
- Extensible: Strategy pattern with pluggable backends
- Evaluation selects extensible approach (score 8.4)
- 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
