Fusion

Fusion

Use the local Fusion CLI for independent panel feedback when a task benefits from critique, architecture tradeoff review, implementation planning, or synthesis.

Operating Rules

• Use the local commands directly: fusion-high, fusion-med, or fusion.
• Do not substitute Oracle/MCP wrappers for the Fusion CLI.
• Before real runs, inspect providers with fusion-high --list-providers, fusion-med --list-providers, or fusion --list-providers.
• Run all configured providers for the selected preset first, and wait for every provider to reach a terminal state: ok, failed, timedOut, quotaLimited, spawnError, or interrupted.
• Fusion is a blocking council call. After starting a real Fusion run, do not plan, implement, edit files, run unrelated commands, answer the user, or "work ahead" while waiting. The point of Fusion is to use the council output as the next input.
• Do not treat elapsed time, early partial artifacts, or one strong provider answer as permission to continue independently. Continue only after Fusion exits and summary.json plus final output have been read, or after a real terminal failure/interruption has been captured.
• Treat panel-*.stdout.md and panel-*.json as partial council artifacts until Fusion writes summary.json and final output. Do not interrupt a run merely because one or more useful provider responses have landed.
• While a run is active, use panel-status.json and heartbeat stderr messages to see which providers are still pending or running.
• If one provider fails or times out after panel artifacts are created, keep the artifact and let Fusion continue to judge/synthesis with the degraded panel.
• If any provider reports quota, rate-limit, usage-limit, or 429 exhaustion, treat that provider as non-blocking for the current run. Do not stop to ask the user; report the model as quota-limited and continue with the remaining provider outputs.
• Do not use --only for ordinary narrowing, model preference, or convenience. It is allowed only when the user explicitly requests a subset.
• For long prompts, write a prompt file and use --file instead of fragile shell quoting.
• Use --dry-run when command shape, provider IDs, config, or output location is uncertain.
• Let Fusion choose its default output location unless the user explicitly asks for a run directory. Current Fusion writes automatic runs to ~/.fusion/sessions/YYYY/MM/DD/<session-id>/ and indexes them in ~/.fusion/sessions.jsonl.
• Do not pass --out .fusion-runs/<slug> by default; --out intentionally bypasses the ~/.fusion session store.
• Treat Fusion output as advisory. Read the artifacts, reconcile disagreements, and make the final engineering call from repo evidence.

Command Shape

fusion-high --list-providers
fusion-high --dry-run --file path/to/prompt.md
fusion-high --file path/to/prompt.md

For moderate planning:

fusion-med --list-providers
fusion-med --file path/to/prompt.md

For custom config:

fusion --config path/to/fusion.config.json --file path/to/prompt.md

Use explicit output overrides only when requested or when a workflow needs repo-local artifacts:

fusion-high --file path/to/prompt.md --out .fusion-runs/<slug>
fusion-high --file path/to/prompt.md --runs-dir .fusion-runs

Prompt Guidance

Include the user request, success criteria, relevant repo paths, constraints, commands already run, observed failures, desired panel roles, and requested verification steps.

Avoid sending secrets, tokens, credentials, or unrelated large context.