/council — Multi-Model Consensus Council

Convene N independent reasoners over a shared briefing and return one synthesis. --mode selects the deliberation pattern — brainstorm, debate, or verdict. Everything else (--focus, --depth, --runtime, --roster) is an orthogonal knob.

Loop position

Cross-cutting judgment gate available at any operating loop move where multi-model consensus is required: typically pre-flight on the slice plan (between moves 3 and 4), per-slice on non-mechanical correctness (move 6), and on the bead acceptance roll-up. Council does not own a loop move — it provides verdicts that other moves consume. Use it at slice level when a single test cannot capture taste; use it at bead level when acceptance examples are passing but the consumer-facing behavior still needs adversarial review.

Quick Start

/council validate this plan                                    # verdict mode (the default)
/council --mode=brainstorm caching approaches                  # brainstorm mode
/council --mode=debate should we adopt event sourcing?         # debate mode (named personas duel)
/council --depth=quick validate recent                         # fast inline check
/council --mode=brainstorm --focus=research k8s upgrade paths   # research = focused brainstorm
/council --roster=security-audit validate the auth system      # preset persona roster
/council --depth=deep --runtime=mixed --roster=leadership-quartet validate product thesis
/council --adversarial validate the auth system                # verdict over 2 adversarial rounds
/council                                                       # infers mode from context

Council works independently — no RPI workflow, no ratchet chain, no ao CLI required.

Modes — the deliberation taxonomy

--mode selects one of exactly three deliberation patterns; verdict is the default. The taxonomy is frozen as an executable spec — references/council-modes.feature.

verdict runs when --mode is omitted. validate is a verdict alias; research folds into brainstorm (--focus=research). When --mode is omitted council infers it from natural language — trigger words in references/task-type-rigor-gate.md.

Mode and focus are orthogonal. --mode is the deliberation pattern; --focus is the subject. --depth, --runtime, and --roster are knobs, never modes. Every mode runs the same lifecycle — convene → brief → deliberate → synthesize → record — and deliberate always isolates each agent before any cross-talk. Full taxonomy, knob aliases (--quick/--deep/--mixed), and the lifecycle contract: references/modes.md.

Spawn backend (MANDATORY)

Council requires a runtime that can spawn parallel subagents and (for debate and --adversarial) send messages between agents. If no multi-agent capability is detected, fall back to --depth=quick (inline single-agent). Skills describe WHAT to do, not WHICH tool — see skills/shared/SKILL.md for the capability contract. Backend-specific spawn/wait/message/cleanup examples:

• Claude Native Teams → references/backend-claude-teams.md · Codex Sub-Agents / CLI → references/backend-codex-subagents.md
• Background Tasks → references/backend-background-tasks.md · Inline → references/backend-inline.md
• Shared Claude feature contract → skills/shared/references/claude-code-latest-features.md (local mirror: references/claude-code-latest-features.md)

See references/cli-spawning.md for the council-specific spawning flow (phases, timeouts, output collection).

Debate mode (--mode=debate)

--mode=debate convenes 2–4 named domain-expert personas who duel: each writes an independent verdict in character, every persona adversarially cross-scores every rival 0–1000, then a mandatory reveal round forces concessions and surfaces blind spots. Synthesis is a score matrix → a ranked decision with dissent kept verbatim. dueling-idea-wizards maps to --mode=debate --focus=ideas; /expert-council routes here.

Constraints: personas decide and the orchestrator only counts; the briefing goes on disk, never through argv; the reveal is never skipped. Per-phase persona-slate / duel / reveal / score-matrix templates: references/dueling-route.md.

Adversarial round (--adversarial) — a verdict intensifier

--adversarial is a verdict-mode flag, not the debate mode. It runs verdict over two rounds — R1 independent verdicts, R2 steel-manning revision via backend messaging — for high-stakes verdicts where judges are likely to disagree (security audits, architecture decisions, migration plans). Skip it for routine validation where consensus is expected. Full protocol: references/adversarial-protocol.md.

Incompatibilities:

• --depth=quick and --adversarial cannot be combined. If both are passed, exit with error: "Error: --quick and --adversarial are incompatible."
• --adversarial only applies to verdict mode. Combined with --mode=brainstorm or --mode=debate, exit with error: "Error: --adversarial is only supported with verdict mode."

Architecture

See references/architecture-flow.md for the context-budget rule, full Phase 1→3 execution flow diagram, reviewer-config loading, graceful degradation table, effort levels, and pre-flight checks.

Packet Format (JSON)

See references/packet-format.md for the full JSON packet schema (fields, output_schema, judge-prompt boundary rules) and the Empirical Evidence Rule for feasibility reviews.

Perspectives

Perspectives & Presets: Use Read tool on skills/council/references/personas.md for persona definitions, preset configurations, and custom perspective details.

Auto-Escalation: When --preset or --perspectives specifies more perspectives than the current judge count, automatically escalate judge count to match. The --count flag overrides auto-escalation.

Mixed-mode perspective assignment: Under --mixed, the perspective list is built once and each perspective is assigned to one Claude judge and one Codex judge with identical prompt and packet. This produces head-to-head pairs (perspective × vendor) so verdict differences isolate the vendor variable. Without --preset or --perspectives, both vendors run 3 generic judges each (6 total). With a 4-perspective preset like security-audit, plan-review, or leadership-quartet, both vendors run those 4 perspectives (8 total). Do not split perspectives across vendors — symmetric pairing is the whole point of --mixed.

Named Perspectives & Consensus

See references/consensus-and-output.md for named-perspective usage (--perspectives, --perspectives-file, YAML format, flag priority), consensus verdict rules (PASS/WARN/FAIL combination table, DISAGREE resolution), and the finding-extraction flywheel protocol. See references/personas.md for built-in presets.

Explorer Sub-Agents

Explorer Details: Use Read tool on skills/council/references/explorers.md for explorer architecture, prompts, sub-question generation, and timeout configuration.

Summary: Judges c