{"id":"ensemble-solving","name":"ensemble-solving","summary":"複数の多様な解決策を並行して生成し、最良のものを選びます。アーキテクチャの意思決定、複数の有効なアプローチによるコード生成、または代替案を探求することで品質を向上させるクリエイティブなタスクに利用されます。","body":"# Ensemble Problem Solving\n\nGenerate multiple solutions in parallel by spawning 3 subagents with different approaches, then evaluate and select the best result.\n\n## When to Use\n\n**Activation phrases:**\n- \"Give me options for...\"\n- \"What's the best way to...\"\n- \"Explore different approaches...\"\n- \"I want to see alternatives...\"\n- \"Compare approaches for...\"\n- \"Which approach should I use...\"\n\n**Good candidates:**\n- Architecture decisions with trade-offs\n- Code generation with multiple valid implementations\n- API design with different philosophies\n- Naming, branding, documentation style\n- Refactoring strategies\n- Algorithm selection\n\n**Skip ensemble for:**\n- Simple lookups or syntax questions\n- Single-cause bug fixes\n- File operations, git commands\n- Deterministic configuration changes\n- Tasks with one obvious solution\n\n## What It Does\n\n1. **Analyzes the task** to determine if ensemble approach is valuable\n2. **Generates 3 distinct prompts** using appropriate diversification strategy\n3. **Spawns 3 parallel subagents** to develop solutions independently\n4. **Evaluates all solutions** using weighted criteria\n5. **Returns the best solution** with explanation and alternatives summary\n\n## Approach\n\n### Step 1: Classify Task Type\n\nDetermine which category fits:\n- **Code Generation**: Functions, classes, APIs, algorithms\n- **Architecture/Design**: System design, data models, patterns\n- **Creative**: Writing, naming, documentation\n\n### Step 2: Invoke Ensemble Orchestrator\n\n```\nTask tool with:\n- subagent_type: 'ensemble-orchestrator'\n- description: 'Generate and evaluate 3 parallel solutions'\n- prompt: [User's original task with full context]\n```\n\nThe orchestrator handles:\n- Prompt diversification\n- Parallel execution\n- Solution evaluation\n- Winner selection\n\n### Step 3: Present Result\n\nThe orchestrator returns:\n- The winning solution (in full)\n- Evaluation scores for all 3 approaches\n- Why the winner was selected\n- When alternatives might be preferred\n\n## Diversification Strategies\n\n**For Code (Constraint Variation):**\n| Approach | Focus |\n|----------|-------|\n| Simplicity | Minimal code, maximum readability |\n| Performance | Efficient, optimized |\n| Extensibility | Clean abstractions, easy to extend |\n\n**For Architecture (Approach Variation):**\n| Approach | Focus |\n|----------|-------|\n| Top-down | Requirements → Interfaces → Implementation |\n| Bottom-up | Primitives → Composition → Structure |\n| Lateral | Analogies from other domains |\n\n**For Creative (Persona Variation):**\n| Approach | Focus |\n|----------|-------|\n| Expert | Technical precision, authoritative |\n| Pragmatic | Ship-focused, practical |\n| Innovative | Creative, unconventional |\n\n## Evaluation Rubric\n\n| Criterion | Base Weight | Description |\n|-----------|-------------|-------------|\n| Correctness | 30% | Solves the problem correctly |\n| Completeness | 20% | Addresses all requirements |\n| Quality | 20% | How well-crafted |\n| Clarity | 15% | How understandable |\n| Elegance | 15% | How simple/beautiful |\n\nWeights adjust based on task type.\n\n## Example\n\n**User:** \"What's the best way to implement a rate limiter?\"\n\n**Skill:**\n1. Classifies as Code Generation\n2. Invokes ensemble-orchestrator\n3. Three approaches generated:\n   - Simple: Token bucket with in-memory counter\n   - Performance: Sliding window with atomic operations\n   - Extensible: Strategy pattern with pluggable backends\n4. Evaluation selects extensible approach (score 8.4)\n5. Returns full implementation with explanation\n\n**Output:**\n```\n## Selected Solution\n\n[Full rate limiter implementation with strategy pattern]\n\n## Why This Solution Won\n\nThe extensible approach scored highest (8.4) because it provides\na clean abstraction that works for both simple use cases and\ncomplex distributed scenarios. The strategy pattern allows\nswapping Redis/Memcached backends without code changes.\n\n## Alternatives\n\n- **Simple approach**: Best if you just need basic in-memory\n  limiting and will never scale beyond one process.\n\n- **Performance approach**: Best for high-throughput scenarios\n  where every microsecond matters.\n```\n\n## Success Criteria\n\n- 3 genuinely different solutions generated\n- Clear evaluation rationale provided\n- Winner selected with confidence\n- Alternatives summarized with use cases\n- User understands trade-offs\n\n## Token Cost\n\n~4x overhead vs single attempt. Worth it for:\n- High-stakes architecture decisions\n- Creative work where first attempt rarely optimal\n- Learning scenarios where seeing alternatives is valuable\n- Code that will be maintained long-term\n\n## Integration\n\n- **feature-planning**: Can ensemble architecture decisions\n- **code-auditor**: Can ensemble analysis perspectives\n- **plan-implementer**: Executes the winning approach","author":"@mhattingpete","ownerProfile":null,"authorContacts":null,"sourceUrl":"https://github.com/mhattingpete/claude-skills-marketplace/tree/main/engineering-workflow-plugin/skills/ensemble-solving","license":"Apache-2.0","category":"writing","lang":"en","tokens":1010,"stars":0,"calls30d":2,"claimed":false,"visibility":"public","origin":"crawler","version":"0.1.0","createdAt":"2026-08-22","updatedAt":"2026-08-22","files":[{"path":"references/diversification-strategies.md","size":5188,"sha256":"2748c6f8151bddb6dee0947ac18f8f3cb3e73178422e6ed34546bdc8e0ecf927"},{"path":"references/evaluation-rubrics.md","size":5729,"sha256":"8eed50860493f39980df4faa6bd2ce6ffc89d5f093c7a1528a5a38734824caff"}],"requires":{"mcp":[],"tools":[]},"safety":{"flags":[],"scannedAt":"2026-08-22","hasScripts":false,"networkEndpoints":[]}}