council

/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](../../docs/architecture/operating-loop.md) 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](references/council-modes.feature).

| --mode | Pattern | Synthesis | |----------|---------|-----------| | brainstorm | diverge — agents generate options independently before any cross-talk | ranked set of ideas, perspectives, risks (no PASS/WARN/FAIL) | | debate | contend — independent positions → adversarial 0–1000 cross-scoring → reveal round | ranked decision with recorded dissent | | verdict (default) | converge — agents judge the artifact against the bar independently | one PASS / WARN / FAIL with consolidated findings |

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](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](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; the legacy expert-council command 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](references/dueling-route.md).

Aliases (absorbed skills)

These trigger phrases route to --mode=debate — there is no separate skill (the former expert-council skill was absorbed here):

| You typed | Runs | |-----------|------| | "expert-council \<question\>" | /council --mode=debate <question> | | "expert-council" (slate of named experts) | /council --mode=debate — persona slate confirmed in Phase 1 | | "expert council", "dueling council", "council of \<names\>" | /council --mode=debate | | "dueling-idea-wizards" | /council --mode=debate --focus=ideas |

When invoked under any of these, run debate mode directly with the same arguments — do not run a separate workflow.

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](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](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](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 pairin