fan-out git:20261011.9a4eb45A

Immutable. This exact content never changes and is served at /api/v1/blob/22be3c4a6af65d8d.

---
name: fan-out
description: "Parallel agent orchestration for OST exploration. Fan-out multiple solution explorations, fan-in results to compare and select winners."
metadata:
  instruction_budget: "22"
  framework_dependency: "mycelium"
  framework_dependency_note: "This skill is designed to run within the Mycelium framework (https://github.com/haabe/mycelium). Standalone use will skip the canvas state, theory gates, and harness behavior the skill assumes. Install: /plugin install mycelium@haabe-mycelium."
---

# Fan-Out / Fan-In Orchestration

## When to Use
- OST has 2+ solutions for the same opportunity that need parallel exploration
- Independent delivery work items that can be parallelized
- Multiple research streams needed simultaneously

## Workflow

### 1. Prepare (Lead Agent)
- Read .claude/canvas/opportunities.yml
- Identify solutions needing parallel work
- For each: identify riskiest assumption and design test

### 2. Fan-Out (Spawn Workers)
For each solution:
- Spawn subagent or Agent Team member
- Provide: clear task, read-only canvas context, worktree isolation, time bound
- Each worker runs independently

### 3. Fan-In (Collect Results)
- Collect all worker results
- Update ICE scores in canvas
- Run `/mycelium:bias-check` on combined findings
- Select winner(s) based on evidence
- Log decision in .claude/harness/decision-log.md

### Leaf Bakeoff Mode

When comparing competing OST leaves for the same opportunity (two or more leaves that each have an untested riskiest assumption; no ICE gap is consulted):
- Each worker returns a structured **scorecard** (Four Risks + ICE + assumption test result + segment fit)
- Lead agent applies **winner selection rules**, which read the assumption-test verdicts: clear winner (one passes, the others fail), several pass in the same segment (tiebreaker), several pass in different segments (segment split, both advance), both fail (archive and re-evaluate). A leaf whose riskiest assumption failed is archived.
- The ICE total only orders which assumption is tested first. It never decides when to compare or which leaf wins (until 0.320.0 a "clear winner" was a leaf more than 20% ahead on ICE).
- Losers are archived to `.claude/canvas/archived-solutions.yml` with full evidence snapshot

See `${CLAUDE_PLUGIN_ROOT}/orchestration/leaf-bakeoff.md` for the complete bakeoff protocol.

## Rules
- Workers NEVER write to canvas (lead agent does)
- Workers NEVER progress diamonds
- Lead agent ALWAYS runs bias check on combined results
- Minimum 2 workers for meaningful comparison
- Maximum 3 leaves per bakeoff (respects L3 WIP ceiling)
- Inside an L3 (v0.301.0), the leaves are its set under the L2's target, and a clear winner is the candidate for its `front_runner`; recording it is the human's choice

See `${CLAUDE_PLUGIN_ROOT}/orchestration/agent-teams.md` for full orchestration patterns.