/ask-all

name: ask-all
description: Ask GPT, Gemini, Grok, and any configured OpenRouter models in parallel for independent second opinions, then synthesize and compare. Zero cross-contamination.
allowed-tools: mcp__deliberation__panel, mcp__deliberation__ask-one, mcp__deliberation__ask-all, mcp__deliberation-openrouter__openrouter-list, Read, Bash
timeout: 660000

Ask All (GPT + Gemini + Grok + OpenRouter)

Parallel dispatch to GPT (Codex), Gemini, Grok (xAI), and any eligible OpenRouter aliases for independent second opinions on the same question. The server fans out in ONE call - each delegate runs on a fresh advisory thread and none sees the others' output. Final synthesis compares verdicts and flags disagreement. All delegates run advisory (`read-only`) - the bridge enforces read-only itself (macOS `sandbox-exec` write-deny for Gemini, `--sandbox read-only` for Codex, plus a prompt guard and post-run git mutation detection); selection and dispatch happen server-side, so the command never names an alias.

Input

User question or topic: $ARGUMENTS

Workflow

<!-- Selection moved server-side: the mcp__deliberation__ask-all tool selects AND dispatches the delegate set (enabled built-ins + eligible OpenRouter aliases, fanout cap applied) in one call. This command never names an alias, so it cannot dispatch a disabled or stale one - the orchestrator has no way to send an alias the server has not approved. -->

0. **Prep - identify the expert and load its prompt.** Identify the expert role first (step 1 below is *reasoning* on `$ARGUMENTS`, no tool call), then read the expert prompt:

• `Glob` `~/.claude/plugins/cache/*/deliberation/*/prompts/[expert].md` (expert prompt)

Delegate selection - which built-ins are enabled, which OpenRouter aliases are eligible, the fanout cap - is resolved server-side by `mcp__deliberation__ask-all`. The command does not read `config.json`, list OpenRouter aliases, or pre-read provider model config. The exact dispatched delegates, their models, and any fanout-capped omissions come back in the tool response, so the status block (step 4) is built from that response, not from pre-read sources.

1. **Identify expert** - match `$ARGUMENTS` against trigger patterns in `~/.claude/rules/deliberation/triggers.md`. The server applies the **same expert role** to every delegate so verdicts are comparable. Default to Architect if unclear.

2. **Read expert prompt** via this resolution sequence: 1. Glob `~/.claude/plugins/cache/*/deliberation/*/prompts/[expert].md`. Pick the match with the highest semver version segment (the segment immediately after `deliberation/`, parsed as semver - not lexical string compare). 2. If no match, look up the inlined fallback under the heading `## Inlined fallback - [Expert]` in this command file (see end of this file). 3. If neither found, abort with: `Error: deliberation plugin cache missing for expert "[Expert]". Run /plugin install deliberation or /reload-plugins.`

Pass the loaded prompt as the `developerInstructions` argument so the server injects the same expert prompt into every delegate.

3. **Build 7-section delegation prompt** per `~/.claude/rules/deliberation/delegation-format.md`. **Identical prompt** sent to every delegate - the server forwards the same `prompt` to all of them, so there is no provider-specific framing. This is the `prompt` argument for the tool call. Include:

• Verbatim user question from `$ARGUMENTS`
• Relevant code snippets / file paths from current conversation context
• Any specific constraints user has mentioned this session

**Repo-wide context (file-blind delegates):** the server fans out to advisory providers, some of which (notably Grok and OpenRouter aliases) see ONLY what the `prompt` names - they do not walk the filesystem. For any open-ended, repo-wide question ("improve this repo", "audit this code", "what are the tradeoffs in our architecture"), embed the orientation context directly in the `prompt`:

1. Pick 2-6 high-signal files: project `CLAUDE.md` / `AGENTS.md` / `README.md`, the top-level entrypoint (`main.tf`, `package.json`, `app.py`, `Cargo.toml`, `pyproject.toml`, etc.), and the module the question targets. 2. Paste or summarize the load-bearing parts of those files into the `prompt`, and state which files the evidence came from ("Context from CLAUDE.md, main.tf, app/app.py - reason from these."). 3. Fallback when `CLAUDE.md`/`AGENTS.md` is absent: substitute `README.md`, then the top-level entrypoint inferred from project type.

This keeps file-blind delegates reasoning from real source instead of a bare description. If you skip it for a whole-repo question, NOTE the asymmetry in the synthesis ("file-blind delegates answered without repo source; discount their specificity").

**Server auto-attach (if configured):** when `orientation.enabled` is `true` in `config.json`, the server automatically attaches the orientation bundle to file-blind delegates that carry no files of their own - so the manual embedding above becomes optional for those providers. When `orientation.enabled` is `false` (the default), the manual approach above is the only way to give file-blind delegates repo context.

4. **Set cwd** - use `process.cwd()` as the MCP `cwd`; the server resolves each provider's working directory from it.

4b. **Discover the panel** - call `mcp__deliberation__panel` to get the EXACT provider set the server would dispatch for this config + expert (enabled built-ins + eligible OpenRouter aliases, fanout cap already applied), WITHOUT calling any provider:

   mcp__deliberation__panel({ expert: "[chosen expert]", cwd: "[cwd]" })

It returns `{ providers: ["codex","gemini","grok","openrouter:<alias>", ...], omitted: [...] }`. `omitted` lists aliases dropped for the fanout cap - report it as the cap note in the synthesis, never silent t