council

What this skill does

# /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

```bash
/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