name: fan-out description: "Parallel agent orchestration for OST exploration. Fan-out multiple solution explorations, fan-in results to compare and select winners." metadata: version: "1.0.1" 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.