$council — Multi-Model Consensus Council (Codex Native)

Spawn parallel judges with different perspectives via

spawn_agent

Quick Start

$council --quick validate recent                               # fast inline check
$council validate this plan                                    # validation (2 judges)
$council brainstorm caching approaches                         # brainstorm
$council --deep validate the implementation                    # 3 judges
$council --preset=security-audit validate the auth system      # preset personas

Modes

--quick

spawn_agent

--deep

spawn_agent

--mixed

spawn_agent

Note:

--debate

spawn_agent

send_input

Note:

--mixed

codex

codex --version

--mixed

--mixed

Note:

--profile=<name>

balanced

budget

fast

inherit

quality

thorough

references/model-profiles.md

COUNCIL_CLAUDE_MODEL

COUNCIL_EXPLORER_MODEL

COUNCIL_CODEX_MODEL

COUNCIL_TIMEOUT

COUNCIL_EXPLORER_TIMEOUT

COUNCIL_R2_TIMEOUT

--technique=<name>

references/brainstorm-techniques.md

--profile=<name>

references/model-profiles.md

Task Types

Execution Flow

Phase 1: Build Packet

1. Determine task type from user prompt
2. Identify target (files, diffs, plan, code)
3. Read relevant context files
4. Select perspectives (or use preset)

Phase 1a: Spawn Judges

Use one

spawn_agent

spawn_agent(message="You are judge-1.

Perspective: correctness

Task: validate the following target.
Target files: ...
Context: ...

Write your full analysis to .agents/council/judge-1.md and your verdict to the final paragraph.")

spawn_agent(message="You are judge-2.

Perspective: completeness

Task: validate the following target.
Target files: ...
Context: ...

Write your full analysis to .agents/council/judge-2.md and your verdict to the final paragraph.")

With

--mixed

.agents/council/codex-{N}.json

--output-schema

.agents/council/codex-{N}.md

references/cli-spawning.md

Step 1b: Load Project Reviewer Config

Check for project-level reviewer configuration before spawning judges:

REVIEWER_CONFIG=".agents/reviewer-config.md"
if [ -f "$REVIEWER_CONFIG" ]; then
    # Parse YAML frontmatter for reviewer list
    # Use reviewers/plan_reviewers/skip_reviewers to select judge perspectives
fi

If

reviewer-config.md

• Use

  reviewers

  list to select which judge perspectives to spawn
• Use

  plan_reviewers

  for plan validation specifically
• Use

  skip_reviewers

  to exclude perspectives even if preset includes them
• Pass markdown body as additional context to all judges

If no config exists, use defaults (current behavior unchanged).

For schema details and an example, see

references/reviewer-config-example.md

Phase 1b: Wait for Judges

wait_agent(ids=["agent-id-1", "agent-id-2"])

If a judge needs follow-up, use

send_input

close_agent

Phase 2: Consolidation (Lead — Inline)

The lead reads each judge's output file and synthesizes:

1. Read each

   .agents/council/judge-*.md

   file
2. Compute consensus verdict:
   • PASS: All judges PASS (or majority PASS, none FAIL)
   • WARN: Any judge WARN, none FAIL
   • FAIL: Any judge FAIL
   • Core rules: All PASS -> PASS; Any FAIL -> FAIL; Mixed PASS/WARN -> WARN; cross-vendor disagreement -> DISAGREE.
3. Identify shared findings across judges
4. Surface disagreements with attribution
5. Generate final report

Phase 3: Write Report

Save to

.agents/council/YYYY-MM-DD-<type>-<target>.md

# Council Report: <type> <target>

**Consensus:** PASS/WARN/FAIL
**Judges:** N responded / N spawned
**Date:** YYYY-MM-DD

## Shared Findings
- Finding 1 (judges 1, 2)
- Finding 2 (judges 1, 3)

## Disagreements
- Judge 1 says X, Judge 2 says Y

## Recommendations
1. ...
2. ...

## Individual Verdicts
| Judge | Perspective | Verdict | Confidence | Findings |
|-------|-------------|---------|------------|----------|
| judge-1 | correctness | PASS | high | 3 |
| judge-2 | completeness | WARN | medium | 5 |

Presets

Use:

$council --preset=security-audit validate the auth system

Graceful Degradation

--quick

Context Budget Rule

Judges write ALL analysis to output files. Results to the lead contain ONLY minimal signals. This prevents N judges from flooding the lead's context.

Standards Integration

If

$standards

First-Pass Rigor Gate (validate mode)

When validating plans/specs, judges must check:

1. Mutation + ack sequence is explicit and non-contradictory
2. Consume-at-most-once path is crash-safe
3. Status/precedence behavior has field-level truth table
4. Conformance includes boundary failpoint tests

Missing gate item → minimum WARN. Critical unverifiable invariant → FAIL.

Reference Documents

• references/model-routing.md
• references/agent-prompts.md
• references/backend-background-tasks.md
• references/backend-codex-subagents.md
• references/backend-inline.md
• references/brainstorm-techniques.md
• references/caching-guidance.md
• references/cli-spawning.md
• references/debate-protocol.md
• references/explorers.md
• references/finding-extraction.md
• references/model-profiles.md
• references/output-format.md
• references/personas.md
• references/presets.md
• references/quick-mode.md
• references/ralph-loop-contract.md
• references/reviewer-config-example.md
• references/strategic-doc-validation.md