/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
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, verdict, criticalIssues}`) | 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`

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. Print:

   /consensus: starting consensus loop (engine-driven, expert=[expert])

Init

Call `consensus-step` with `action: "init"`:

mcp__deliberation__consensus-step({ action: "init", prompt: "$ARGUMENTS", expert: "[expert]", cwd: "[cwd]" })

It returns `sessionId`, `status: "await_blind"`, `round: 1`, and `blindPrompt`. Carry the `sessionId` through every later call. If it returns an `error` (e.g. `session-expired` on a later call), report it and stop - the in-memory state was lost; re-run from `init`.

Round loop (driven by the returned status)

Repeat the following until a call returns `converged: true` or `status: "unresolved"`. The engine owns the round number and the cap; read `round` from each response - never assume a fixed count. **If any call returns an `error`** (e.g. `session-expired`, `unexpected-action-for-status`, or a no-reason dismissal), report it and stop - the in-memory `LoopState` for that `sessionId` may be gone, so recover by re-running from `init`.

1. **Print the round header** using the returned `round`:

   --- Round R ---

2. **Commit the blind verdict BEFORE revealing the panel.** In a message of its OWN, BEFORE the message that calls `record_blind`, Claude writes its own verdict from the returned `blindPrompt` only (it has not seen any reviewer output). Use the strict shape so it is comparable to the panel:

   **Verdict**: APPROVE | REQUEST CHANGES | REJECT
   **Critical issues** (must-fix; empty = none):
     - `[category]` issue
   **One-line bottom line**: [single sentence]

`[category]` is one of: `securit