/fusion

name: fusion
description: >-
  Answer a hard question by fanning it out to a PANEL of models running in parallel — each answering
  independently with web search and bash, none seeing the others' work — then having Opus 4.8 judge every
  response into a structured analysis (consensus, contradictions, partial coverage, unique insights, blind
  spots) and write a final answer grounded in it. The panel is two independent Opus 4.8 runs (slug
  opus4.8-4.8), Opus 4.8 + GPT-5.5 via codex (opus4.8-gpt5.5), Opus 4.8 + Gemini 3.1 Pro via agy
  (opus4.8-gemini3.1pro), or all three (opus4.8-gpt5.5-gemini3.1pro). Opus always judges and writes the final answer — the pipeline can't be
  reversed. Runs on local CLI subscriptions (no metered API), and saves a timestamped provenance .md per
  run. Use this whenever the user asks to "run it through Fusion", says
  /fusion, wants a multi-model / panel / ensemble answer, wants a question cross-checked across models, or
  wants a higher-confidence answer with consensus and blind spots surfaced — even if they don't say
  "fusion". General-purpose: any topic (research, law, strategy, technical, personal). Best for high-stakes
  research, design calls, and debugging where being confidently wrong is expensive.

Fusion

Fusion turns one prompt into a panel. The question goes to several models **at the same time**, each answering independently — with web search and bash, and with no knowledge of the others. Then Opus 4.8 (this very session — the orchestrator) reads every answer, extracts the structure of the panel's reasoning (what they agree on, where they conflict, what only one saw, what they all missed), and writes a final answer grounded in that analysis.

The whole mechanism is **independence, then synthesis**. The diversity that makes a panel beat a single model is harvested, not manufactured: running the same prompt independently yields different reasoning paths, tool calls, and sources. So there are **no assigned "lenses" or personas** — every panelist gets the user's task **verbatim** and answers it straight. (See `references/panel.md`.)

**One hard rule: Opus 4.8 always judges and writes the final answer — the pipeline can't be reversed.** The panelist models can't call back out to spawn Opus, so Opus is always the driver. The slug reads driver-first for that reason.

Throughout, `<skill_dir>` is the directory containing this SKILL.md (when installed: `~/.claude/skills/fusion`). Write the user's question **verbatim** to `/tmp/fusion_question.txt` first — several steps reuse it.

Step 0 — Pick the panel

bash <skill_dir>/scripts/detect_panel.sh

It prints a `SLUG=` line recommending the richest panel possible on this machine:

| Slug | Panel | Requires | | --- | --- | --- | | `opus4.8-4.8` | the same prompt run twice as 2 independent Opus 4.8 panelists | nothing — always available | | `opus4.8-gpt5.5` | Opus 4.8 + GPT-5.5 in parallel | `codex` CLI | | `opus4.8-gemini3.1pro` | Opus 4.8 + Gemini 3.1 Pro in parallel | `agy` CLI | | `opus4.8-gpt5.5-gemini3.1pro` | Opus 4.8 + GPT-5.5 + Gemini 3.1 Pro in parallel | `codex` + `agy` CLIs |

If the user named a slug (or used a pinned `/fusion-*` command), honor it — but if a required CLI is missing, say so, drop that panelist, and fall back to the next-richest panel rather than failing. Otherwise use the detector's recommendation.

Step 1 — Preflight (informational, never a gate)

bash <skill_dir>/scripts/preflight.sh <SLUG> /tmp/fusion_question.txt

Show its output to the user (rough token/call estimate + Codex cap reminder), then proceed. It never blocks. Each panelist is bounded by a per-panelist timeout (`FUSION_TIMEOUT`, default 300s) baked into the runners; raise it for heavy deep-research questions (`FUSION_TIMEOUT=600 bash <skill_dir>/scripts/...`).

Step 2 — Fan out, in parallel and blind

Read `references/panel.md`. Build each panelist's prompt as the user's task **verbatim** plus the short instruction to research with web + bash and return a complete, self-contained answer as one of several independent experts who won't see the others' work. Do **not** assign lenses; do **not** pre-digest the task. (Answer in the user's question language.)

Launch **all panelists in a single turn** so they run concurrently:

• **Opus 4.8 panelist(s)** → the `Agent` tool, `subagent_type: general-purpose` (web + bash built in).

For `opus4.8-4.8`, spawn **two** independent Opus subagents with the *same* prompt — two cold runs. For every other slug (`opus4.8-gpt5.5`, `opus4.8-gemini3.1pro`, `opus4.8-gpt5.5-gemini3.1pro`) spawn **exactly one** Opus panelist alongside the external panelist(s). Spawn them in the same message so they run at once. When each returns, write its answer to a temp file for provenance: `/tmp/fusion_opusA.md` (and `/tmp/fusion_opusB.md` for the second Opus run).

• **GPT-5.5 panelist** (if slug includes it) → write its prompt to a temp file, then run:

  fusion_run_dir="$(mktemp -d "${TMPDIR:-/tmp}/fusion-panel.XXXXXX")"
  bash <skill_dir>/scripts/run_codex.sh "$fusion_run_dir/codex_prompt.md" "$fusion_run_dir/codex_out.md" xhigh

Allocate one unique `fusion_run_dir` per Fusion invocation and put every prompt/output file for that invocation under it. Never use fixed paths like `/tmp/fusion_codex_prompt.txt` or `/tmp/fusion_codex_out.md`; multiple Claude Code sessions can run Fusion concurrently, and fixed names let one run read another run's prompt or answer. The runner copies the current repo/workdir to a throwaway directory, then launches `codex exec` with full local access against that copy. This preserves the live checkout while letting the GPT-5.5 panelist use the same local tools and keychain-backed credentials as a trusted terminal Codex run. `-o` makes codex write only its final answer to the out file; read it once it finishes. Exit 124 = timed out (`FUSION_TIMEOUT`); any other non-zero exit = drop GPT-5.5 and