rbergman/council

Council Deliberation Pattern

When facing decisions where multiple valid perspectives exist, spawn a deliberation team rather than relying on a single viewpoint. Council is a premium tool — use it rarely, for decisions that warrant deep thought from multiple angles.

When to Use

• Architecture decisions with trade-offs (e.g., WebSockets vs SSE vs polling)
• Evaluating a spec or design for completeness
• Choosing between implementation approaches
• Any "should we X or Y?" decision with non-obvious trade-offs
• Post-mortem analysis of what went wrong

Council Structure

| Role | Purpose | Model | |------|---------|-------| | Advocate | Argues for the most promising approach | opus | | Skeptic | Finds flaws, challenges assumptions | opus | | Pragmatist | Focuses on practical constraints (time, complexity, maintenance) | opus | | Domain Expert | Brings specialized knowledge relevant to the topic | opus | | Lead (you) | Frames the question, moderates, synthesizes | opus |

3 perspectives minimum, 5 maximum. Tailor roles to the specific decision.

All councilors use opus for maximum depth of reasoning. The council is designed for quality over speed — for fast iteration, talk to a single subagent instead.

Debate Protocol

Phase 1 — Framing (lead)

• State the question clearly
• Provide relevant context (files, constraints, prior decisions)
• Assign perspectives and initial positions to teammates

Phase 2 — Opening Statements (teammates)

• Each teammate states their position with evidence
• 200-400 words per opening statement

Phase 3 — Challenge Round (teammates message each other)

• Teammates directly challenge each other's positions
• Key mechanism: teammates should address specific claims, not general disagreement
• Lead monitors for convergence or stalemate
• 1-2 rounds of challenges typically sufficient

Phase 4 — Synthesis (lead)

• Summarize points of agreement and disagreement
• Identify the strongest arguments from each perspective
• Make a recommendation with reasoning
• Note dissenting views that have merit

Phase 5 — Persist (lead, mandatory)

Write the synthesis to history/ so it survives context loss:

# Ensure history/ exists and is gitignored
mkdir -p history
grep -qx 'history/' .gitignore 2>/dev/null || echo 'history/' >> .gitignore

File: history/council-<topic-slug>-<YYYY-MM-DD>.md

Contents: The full output format (see below) — question, perspectives, key debates, recommendation, dissenting views, confidence.

Why this is mandatory: Council deliberations are expensive (3-5 opus subagents). If the session runs out of context or crashes, the recommendation is lost and must be re-run. Writing to history/ makes recovery trivial — a fresh session reads the file and has the full council output.

Recovery: If a session finds history/council-*.md files, it can read them to recover prior deliberation results without re-running the council.

Phase 6 — Rotate (lead, recommended)

Council deliberations consume ~25-35k tokens of conversation history (subagent prompts + responses). If the session needs to act on the council's recommendation (implementation work), strongly recommend rotating first:

1. Run /rotate to snapshot the session
2. /copy → /clear → paste snapshot into new session
3. Read history/council-<topic>.md for the full recommendation (~2k tokens vs 25-35k in conversation)

This prevents the #1 cause of council-related context overflow: running deliberation AND implementation in the same session.

Exception: If the council result is small and the follow-up work is trivial, skip the rotate.

Model & Perspective Strategy

Epistemic diversity comes from different analytical frames, not different models. All councilors run on opus for maximum reasoning depth. Diversity is achieved through:

• Distinct system prompts that enforce different analytical lenses (e.g., advocate vs. skeptic)
• Role-specific constraints (e.g., "you must find at least 2 flaws" for the skeptic)
• Different information emphasis (same context, different focus areas)

Future option: cross-model councils (e.g., Codex, Gemini) via driver plugins could add genuine model diversity. Not yet implemented.

Output Format

## Council Deliberation: [Topic]

### Question
[The specific question debated]

### Perspectives
- **[Role A]** ([model]): [1-2 sentence position summary]
- **[Role B]** ([model]): [1-2 sentence position summary]
- **[Role C]** ([model]): [1-2 sentence position summary]

### Key Debates
1. [Debate point] — [who argued what, resolution or ongoing disagreement]
2. [Debate point] — [...]

### Recommendation
[Lead's synthesized recommendation with reasoning]

### Dissenting Views
[Positions that lost but have merit — record for future reference]

### Confidence
[High/Medium/Low] — [why]

Anti-patterns

• Spawning a council for trivial decisions (use a single subagent or decide directly)
• All teammates agreeing immediately (reframe perspectives to create genuine tension)
• Council as delay tactic (set time/round limits)
• Ignoring dissent (always record minority positions)

Related Skills

• dm-team:lead — team coordination protocol; spawn councilors as teammates
• dm-work:advice — single-agent second-opinion brief (cheaper alternative)