/consensus

name: consensus
description: Arbiter-mediated consensus - GPT + Gemini + Grok (plus any configured OpenRouter delegates) review while Claude commits a blind verdict, adjudicates, and synthesizes. Converges only with cross-model agreement. Driven by the consensus-step engine.
allowed-tools: mcp__deliberation__consensus-step, mcp__deliberation__panel, mcp__deliberation__codex-login, AskUserQuestion
timeout: 900000

Consensus (arbiter-mediated convergence loop, driven by the core engine)

This command is a THIN DRIVER over the `mcp__deliberation__consensus-step` tool. The multi-round loop - round counting, the convergence rule, the max-rounds cap, and the round history - lives in the core state machine (`core/consensus-loop.js`), NOT in this prompt. The command's job is the three things only the host (Claude) can do as the arbiter: commit a **blind verdict** before seeing the panel, **adjudicate** which critical issues are real (with a reason for every dismissal), and **author the revised plan** between rounds.

This is **arbiter-mediated consensus, not pure democracy**: the external models vote independently (the server fans out to them in `dispatch_peers`), but Claude commits its blind verdict first, cannot converge on its own vote alone (the engine requires a responding peer to APPROVE), and must show a reason for every dismissed issue.

Input

Plan, design, spec, or proposal to refine: $ARGUMENTS

When to use

• Refining a plan before execution
• Stress-testing a design decision
• Reaching consensus on a tradeoff
• Any case where you want signed-off agreement, not just parallel opinions

When NOT to use

• One-off lookup or fact check (use `/ask-gpt` or `/ask-gemini`)
• You only want parallel one-shot opinions without the convergence loop (use `/ask-all`)
• Time-sensitive work - this loop can take several minutes

How the engine maps to this command

`consensus-step` is one action per call; it holds the `LoopState` server-side by `sessionId` (ephemeral - lost on server restart / TTL). The status it returns tells you the next action:

| Action | You supply | Engine returns | Next | |--------|-----------|----------------|------| | `init` | `prompt` (the plan), `expert`, `cwd` | `sessionId`, `status: await_blind`, `round`, `blindPrompt` | write blind, `record_blind` | | `record_blind` | `sessionId`, `blindVerdict` (your verdict text) | `status: await_peers` | `dispatch_peers` | | `dispatch_peers` | `sessionId` | `status: await_adjudication`, `opinions[]` (per-voice `{source, isError, message?, verdict, criticalIssues}`), optional `droppedProviders[]`, optional `unavailableProviders[]` (`{name, reason}`: skipped before dispatch - no CLI / no credential); or a terminal `status: unresolved` + `stopReason` | adjudicate, `submit_adjudication` | | `submit_adjudication` | `sessionId`, `verdict`, `decisions[]` | `converged: true` + `finalReport` + `confidence`, OR `status: await_revision` | done, OR revise | | `submit_revision` | `sessionId`, `revisedPlan`, `diffSummary` | `status: await_blind` (next round), OR `status: unresolved` + `finalReport` (hit the cap) | next round, OR done |

The engine injects the expert persona server-side from the `expert` key (no prompt-file read needed), authors the per-round blind/peer prompts, parses each reviewer's verdict + categorized critical issues, counts rounds, enforces the configurable max-rounds cap (`consensus.maxRounds`, default 5), evaluates convergence, and computes the confidence label. Do NOT re-implement any of that here.

Workflow

Setup (run once)

1. **Identify the expert key.** Default `plan-reviewer`. Override only if `$ARGUMENTS` clearly maps to another role:

• Architecture / design tradeoffs -> `architect`
• Security / threat modeling -> `security-analyst`
• Code review of a concrete diff -> `code-reviewer`
• A post, article, README, or other prose meant to read like its author -> `writing-editor`

Pass this key verbatim as `expert`; the server injects the matching persona for the PEER dispatch. There is no prompt-file Glob and no inlined fallback - the running MCP server is the single source of truth for persona text. An unknown key does NOT error: the server silently runs WITHOUT a persona (generic review), so use a key from the list above. Also adopt the chosen expert's lens yourself when writing your blind verdict and adjudicating (the engine's host prompts are generic; you supply the expert framing). 2. **Set cwd**: use `process.cwd()` as the MCP `cwd` on `init` AND on `dispatch_peers` (that is where peers actually run; the server reads `cwd` from the `dispatch_peers` call, not from `init`). The other actions do not need it. 3. **Log GPT in first.** Call `mcp__deliberation__panel({ for: "consensus", expert: "[expert]", cwd: "[cwd]" })` and read only its `needsLogin`. If it contains `codex`, GPT has no ChatGPT login on this machine yet. Log it in now, before `init`, so GPT votes from round 1 (a codex voice that errors every round is dropped by the circuit breaker): 1. Call `mcp__deliberation__codex-login({})` and print its `message` as-is EVERY time you call it (the link and the code each stay on their own line). Then act on `status`:

• `authenticated`: keep codex and go on.
• `starting` (no code yet; each call already waits up to ~20s for one): call again.

Three `starting` results in a row count as `failed`.

• `pending`: go to step 2.
• `failed`, `unavailable`, a call that errors, or anything else: continue without waiting for GPT, and name it once with that message.

2. Ask the user with `AskUserQuestion` ("Approve the GPT login in the browser with the code above, then pick one"), options `Done - include GPT` and `Skip GPT this run`. A host without `AskUserQuestion` asks the same in one plain line and ends the turn; treat the user's reply as that choice. 3. `Skip`: continue without waiting for GP