Council
Run multi-model brainstorm, debate, or verdict councils on plans, slices, and acceptance so one synthesized judgment gates risky agent work.
Overview
council is an agent skill most often used in Ship (also Validate scope, Build pm) that runs multi-judge consensus in brainstorm, debate, or verdict modes and emits a synthesized verdict.json.
Install
npx skills add https://github.com/boshu2/agentops --skill councilWhat is this skill?
- Multi-model consensus with modes: brainstorm, debate, verdict
- Orthogonal knobs: --focus, --depth, --runtime, --roster over shared briefing
- Designed for pre-flight plan validation, per-slice correctness, and bead acceptance roll-up
- Output contract: verdict.json (and result.json) via declared JSON schema
- Cross-cutting gate—does not own a loop move but feeds verdicts other moves consume
- Three deliberation modes: brainstorm, debate, verdict
Adoption & trust: 2.3k installs on skills.sh; 384 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
One agent model approved your plan or slice, but you still lack trustworthy multi-perspective judgment before you commit engineering time.
Who is it for?
Agentops-style solo builders running slice plans, beads, and acceptance examples who want explicit multi-model gates on plans and non-mechanical correctness.
Skip if: Quick one-off scripts or mechanical changes fully covered by unit tests with no taste or product judgment component.
When should I use this skill?
Multi-model consensus is required at a loop gate—typically pre-flight on the slice plan, per-slice non-mechanical correctness, or bead acceptance roll-up.
What do I get? / Deliverables
You get a schema-backed verdict synthesis from N reasoners that downstream loop moves can treat as a pre-flight or acceptance gate.
- verdict.json
- result.json synthesis per output contract
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Council is documented as a judgment gate on correctness and taste where tests alone fail—canonical placement is Ship → review alongside code review workflows. It returns verdict.json synthesis from independent reasoners for acceptance roll-ups and adversarial review, matching the review subphase rather than raw test execution.
Where it fits
Brainstorm mode on a slice plan between planning and coding to stress-test scope before agents touch the repo.
Debate mode when mechanical tasks are clear but prioritization and trade-offs need opposing reasoners.
Verdict mode on bead acceptance when unit tests pass but consumer-facing flows still feel wrong.
How it compares
Structured multi-model verdict workflow with JSON contract—not a single-pass linter or one-shot code review prompt.
Common Questions / FAQ
Who is council for?
Builders using agentops operating loops who need independent models to deliberate on plans, slices, or acceptance before merging or shipping.
When should I use council?
Between validate and build on slice plans, during build pm when scope is ambiguous, and in ship review when tests pass but behavior still needs debate or verdict modes.
Is council safe to install?
It orchestrates external model runtimes per your --runtime configuration; check the Security Audits panel on this page and treat briefings as confidential.
Workflow Chain
Requires first: standards
SKILL.md
READMESKILL.md - 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 ```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 me