fan-out — Claude Code skill: parallel solution exploration

---
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, design test, and write its `runs_on` (disk | network | human, as in `/mycelium:assumption-test`)
- Register each `human` test (survey, fake door, interviews, paid pilot) through `/mycelium:handoff`. No subagent runs it: a subagent can only simulate what people would do, and a simulated verdict is not a test result (v0.330.0)

### 2. Fan-Out (Spawn Workers, disk and network tests only)
For each solution with a disk or network test:
- Spawn subagent or Agent Team member
- Provide: clear task, read-only canvas context, worktree isolation, and a turn cap where the runtime has one (`maxTurns` in an agent definition). A time bound in the brief is advice: Claude Code has no time limit for a subagent
- Each worker runs independently and reports its evidence with its source, not only a verdict

### 3. Fan-In (Collect Results)
- Collect all worker results, and the `human` tests' verdicts once logged through `/mycelium:log-evidence`
- 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 from the leaf's record, the result of its disk or network test, segment fit); a leaf whose test is `human` gets its scorecard from the lead once the verdict is logged
- 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). On Claude Code the guard-state gate refuses a subagent's write to `.claude/canvas/` or `.claude/diamonds/` (v0.330.0); the other rules below are the lead's discipline and no hook checks them
- Workers NEVER progress diamonds
- Workers NEVER run a `human` test
- 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.