/deliberation

name: "deliberation"
description: "When and how to delegate to GPT, Gemini, Grok, and OpenRouter expert subagents via the deliberation MCP tools."

<!-- GENERATED by scripts/sync-hosts.js - edit the source under prompts/, docs/tool-guide.md, or examples/, then regenerate. -->

Deliberation

Host-neutral guidance for any AI coding agent connected to the deliberation MCP server (Claude Code, Cursor, Codex, Kiro, Antigravity, Windsurf, Zed, and others): what the tools do and when to delegate. The per-host skills and Powers are generated from this file by `scripts/sync-hosts.js`.

What deliberation is

A single MCP server that exposes GPT (via the Codex CLI), Gemini 3 (via the Antigravity CLI), Grok (via the xAI API), local models (Ollama, LM Studio), and OpenRouter models (400+, advisory) as expert subagents. You stay the primary agent. When a task benefits from a second opinion or cross-model review, call one of the tools below, read the result, and apply your own judgment. Every tool here is ADVISORY: this server reads and reasons, it never edits your files. (Implementation exists only in the Claude Code plugin's standalone Gemini bridge, which this server does not expose.)

Tools

Fan-out and single-provider:

• `ask-all` - send one question to GPT, Gemini, Grok, local models, and

configured OpenRouter models in parallel, get every answer back independently (no cross-talk).

• `consensus` - run the FULL multi-round convergence loop server-side with a provider

arbiter (peer fan-out -> adjudicate -> revise, plus a blind pass per round when `consensus.blindVote` is on) and get the converged verdict in one call. Depth is `consensus.maxRounds` (config, default 5); pass `maxRounds` to override. Pass `synthesizeAlways:true` for a SINGLE arbiter synthesis pass instead of the loop (best for open questions): it returns a free-text `synthesis` (the enum `verdict` and `converged`/`confidence` are null, `rounds` is 1). Set a concrete `consensus.arbiter` (a provider or `openrouter:<alias>`) for the server-side pass; in `host` mode the tool returns the opinions for YOU to synthesize. An optional blind pre-vote (`consensus.blindVote`) is available on the synthesize path.

• `consensus-step` - drive the loop yourself as the arbiter, one action per call:

`init` (returns a `sessionId` + blind prompt) -> `record_blind` (your pre-commit verdict) -> `dispatch_peers` (the server fans out to the panel) -> `submit_adjudication` (your verdict + per-issue accept/dismiss/defer, each dismiss needs a reason) -> `submit_revision` (your revised plan), looping until converged or the round cap. State is held server-side by `sessionId` (ephemeral). `dispatch_peers` may report `droppedProviders[]` - peers the circuit breaker removed after 2 consecutive failed rounds, so they are no longer dispatched or billed; print them once, and stop listing them as errored. It can also return a TERMINAL `status: "unresolved"` with `stopReason` `all-providers-circuit-broken` (every peer dropped), `no-providers`, or `budget-exhausted` (`consensus.maxWallMs` spent) - report the reason and the `finalReport`, then stop; there is no session left to step.

• `ask-gpt` / `ask-gemini` / `ask-grok` / `ask-openrouter` - one question to one

provider for a single-shot second opinion.

• `panel` - return the exact provider names `ask-all` would dispatch for the current

config + expert (enabled, healthy built-ins + eligible OpenRouter aliases, fanout cap applied), WITHOUT calling them. `unavailable[]` names enabled built-ins that cannot answer right now (CLI not on PATH, no credential) with the reason - they are skipped by every fan-out, so report them once rather than treating them as errors. `needsLogin[]` names panel members that have no login yet but stay on the panel (codex on a fresh machine): run `codex-login` and let the user approve BEFORE dispatching, so GPT answers from the first call. Pass `for: "consensus"` for the consensus panel. No provider calls and never starts a login; the only write is one local dashboard journal line, and only when that journal is on. When the local dashboard journal is on (`dashboard.enabled`), it also returns a `runId` (the ask-all panel only): pass it to every `ask-one` of that fan-out so the dashboard draws them as one run. Optional `prompt` is recorded on that run, never sent to a provider.

• `codex-login` - start (or join) the ChatGPT device login for GPT and return its link and

one-time code, without asking GPT anything. Show the returned `message` to the user as-is; GPT answers once they approve. Call it before a fan-out when `panel.needsLogin` contains `codex`, then ask the user to approve and call it again to confirm `authenticated`. Never skip a GPT call because GPT looks logged out: with no login, `ask-gpt` / `ask-one codex` start the same login and return the same code.

• `ask-one { provider, prompt }` - one question to ONE provider named by `panel`

(e.g. `codex`, `grok`, `openrouter:<alias>`). The progress pattern: call `panel`, then issue one `ask-one` per name **in a single turn** so they run concurrently and each result lands independently as it finishes - visible per-provider progress with parallel wall-time, instead of the one opaque `ask-all` call. (The single-call `ask-all` still works; `ask-one` is the progressive alternative.) Pass the returned `fanoutId` to every `ask-one` in that group. It exists even with logging disabled, pins panel/settings, rejects duplicates and expires. The longest pinned peer limit supplies a shared deadline; each request still obeys its own host ceiling. Group expiry/shutdown cancels outstanding members. Optional `runId` (from `panel`, also accepted by the `ask-*` tools) joins the call to that dashboard run; an id this server's `panel` did not open is ignored.

• `analyze` - read-only run analytics. Reads the opt-in debug log (per-model p50/p95/max

latenc