brainstorm

name	brainstorm
description	Send a topic to multiple LLM providers in parallel while Claude Opus performs its own independent research in parallel, then synthesize all findings. Usage /brainstorm [providers] <topic>. External providers default to antigravity,codex. Example /brainstorm antigravity,codex,ollama "review this architecture"
user_invocable	true

Multi-LLM Brainstorm

Consult multiple external LLM providers simultaneously on a topic while Claude Opus performs its own independent research in parallel, then synthesize the findings from all participants.

Instructions

Phase 1: Parse arguments

• If the first argument looks like a comma-separated provider list (e.g., antigravity,codex or gemini,codex,ollama), use those as the external providers
• If no provider list is given, default to antigravity,codex
• Valid external providers: gemini, codex, ollama, antigravity
• antigravity requires agy installed + logged in; if it's unavailable the coordinator surfaces that and continues with the other providers
• Everything after the provider list (or all args if no list) is the topic
• Claude Opus is always a participant — it's not in the provider list because it runs inside the coordinator

Phase 2: Determine and prepare the brainstorm topic

• If the user provided a topic directly, use it
• If the context is about code changes, gather the relevant diff:
  • git status --short first to see what's modified/added/deleted
  • git add -N <new-files> for untracked files the user wants included
  • git diff + git diff --cached combined
  • Filter noise: exclude :!docs/ :!apps/docs/ :!*.md :!yarn.lock :!*.lock :!*.png from the pathspec — providers don't need to review your ADR/doc additions
  • Size-check: if combined diff > 150KB, ask the user before sending (the providers will take 5–15 min on payloads that large)
• If the context is a design/plan, gather the relevant documentation or conversation context
• If no topic is clear, ask the user what they'd like to brainstorm about
• Create a compact Context Brief before launching the coordinator. Keep it tiny for simple topics; add detail when the request is architecture/design/security/concurrency/migration related, spans packages, references external specs, or depends on conversation context external providers cannot see.

## Context Brief

Intent:
- User request:
- Brainstorm mode:
- Providers: <list the selected providers for this run>

Scope:
- Changed/referenced files:
- Included files/docs:
- Excluded files/docs and reason:
- Diff bytes:

Repository signals:
- Relevant package/workspace:
- CLAUDE.md files read:
- ADRs/docs read:

Risk focus:
- Security:
- Data loss:
- Concurrency/state:
- API/contract:
- Tests/build:

Open questions:
- Items not verified before dispatch:

Phase 3: Launch the brainstorm-coordinator agent

Launch with: the topic, the selected external providers list, the Context Brief, and any gathered context (diff/files/docs).

The coordinator handles:

• Phase 3B: its own Claude Opus research (reads actual files, traces code, uses WebFetch/WebSearch on referenced external docs) — runs FIRST so Claude doesn't anchor on external responses
• Context Brief update: after Phase 3B, records verified files/docs and unverified assumptions before external dispatch
• Phase 3A: external provider dispatch via a single blocking foreground Bash call (ADR-050 dispatch pattern)
• Phase 4: synthesis — consensus, unique insights, contradictions across all participants
• Verified findings (backed by Claude's file reads) are weighted higher than inferred ones
• Failed providers are surfaced inline with their stderr, not silently dropped

Phase 4: Present the coordinator's synthesis

Pass through the coordinator's structured output. If the coordinator returned a partial result (some providers failed), present what landed and explicitly note what's missing — don't paraphrase or hide compromises.

Important — verification matters

Confidence scores are not an oracle. The coordinator's Phase 3B exists specifically because external LLMs can return high-confidence findings that turn out to be factually wrong (a real example from 2026-04-17: Gemini returned 95/100-confidence claims that were contradicted by the actual .d.ts file). Claude's "Verified" findings carry more weight than external "Inferred" findings precisely for this reason.

If you want a code-review-specific version of this with explicit per-finding source verification, use /multi-review instead.