/ct-council

name: ct-council
description: Convene "The Council" — a 5-advisor, shuffled gate-based peer-review, chairman-synthesis workflow for reviewing a plan, decision, architecture, or piece of work inside the current project. Use when the user says "convene the council" (or "counsel"), "get the council on this", "council review", "run the five advisors", "stress-test this", "get multiple perspectives", or asks for a rigorous multi-angle challenge of a proposal (Contrarian, First Principles, Expansionist, Outsider, Executor → shuffled peer review with pass/fail gates → convergence detector → Chairman verdict). Operates on the current codebase — each advisor grounds their analysis in actual files/commits before opining. Output is validated by scripts/validate.py.
metadata:
  version: 1.1.1
  tier: on-demand
  install: harness
  stability: stable

The Council

Overview

The Council reviews a proposal, plan, architecture decision, or existing implementation from five locked perspectives, cross-checks each perspective through a shuffled gate-based peer review, runs a convergence detector to catch frame drift, then has a Chairman synthesize one final verdict for the owner.

**Five advisors** → **Shuffled peer review (4 pass/fail gates per reviewee)** → **Convergence detector** → **Chairman synthesis** → **Single verdict to owner**.

Every Council run's output is validated by `scripts/validate.py` — structural failures are caught automatically.

When to use

• Owner presents a plan, design, or existing implementation and wants it stress-tested from multiple angles.
• A decision is high-stakes enough that a single-perspective analysis feels thin.
• The user explicitly invokes the council ("convene the council", "council on X", "run the five", etc.).

Do NOT use for simple factual questions, routine implementation tasks, or anything the user wants a quick answer on. The Council is heavyweight by design.

The five advisors

Each advisor has their own progressive-disclosure file with full persona, mandate, hard rules, and self-contained output template. When running an advisor pass, **load only that advisor's file** — this enforces frame integrity and works equally well in single-Claude mode (re-read per pass) and subagent mode (each subagent briefed with only their persona).

| Advisor | Frame | Produces | Persona file | |---|---|---|---| | Contrarian | Devil's advocate / risk analyst | Failure modes with trigger conditions | [references/contrarian.md](references/contrarian.md) | | First Principles | Zero-based rebuilder | Atomic truths + reconstructed solution | [references/first-principles.md](references/first-principles.md) | | Expansionist | Frame-expander / opportunity-spotter | Asymmetric upside + latent assets | [references/expansionist.md](references/expansionist.md) | | Outsider | Cold-read stranger | Claim/reality gaps from the artifact alone | [references/outsider.md](references/outsider.md) | | Executor | Action-only | Exactly one 60-minute action with expected outcome | [references/executor.md](references/executor.md) |

Each persona's "Your lane vs. other advisors' lanes" section enforces boundaries — frame bleed fails the G3 gate in peer review.

Execution mode — subagents are the default

**Default: subagent mode.** Spawn five parallel `Agent` calls, one per advisor. Each subagent receives *only* the shared evidence pack and the path to their own persona file — nothing else. This is the only execution mode with true frame isolation, and it is the default for any non-trivial question.

**Exception: single-Claude mode** is permitted only when (a) the question is extremely narrow (single file, single function), or (b) subagent infrastructure is unavailable. In single-Claude mode, Claude re-reads each persona file before each pass and explicitly acknowledges the "Your lane vs." section. The convergence detector (Phase 2.5) is especially load-bearing in this mode.

Canonical file layout (mandatory)

Every run lives under a run directory (`<run-dir>/`, created by `scripts/run_council.py init`). **Each subagent writes its own output file** — the orchestrator does NOT transcribe agent text into its own context. This is structurally important: agent outputs land directly on disk, the orchestrator reads them back when needed (or at assembly time), and the run directory is the audit trail.

| File | Owner | When written | |---|---|---| | `<run-dir>/phase0.md` | **Orchestrator** | Phase 0 (evidence pack) | | `<run-dir>/phase1-contrarian.md` | **Contrarian agent** | Phase 1 | | `<run-dir>/phase1-first-principles.md` | **First Principles agent** | Phase 1 | | `<run-dir>/phase1-expansionist.md` | **Expansionist agent** | Phase 1 | | `<run-dir>/phase1-outsider.md` | **Outsider agent** | Phase 1 | | `<run-dir>/phase1-executor.md` | **Executor agent** | Phase 1 | | `<run-dir>/peer-contrarian-on-first-principles.md` | **Contrarian-as-reviewer agent** | Phase 2 | | `<run-dir>/peer-first-principles-on-expansionist.md` | **First Principles-as-reviewer agent** | Phase 2 | | `<run-dir>/peer-expansionist-on-outsider.md` | **Expansionist-as-reviewer agent** | Phase 2 | | `<run-dir>/peer-outsider-on-executor.md` | **Outsider-as-reviewer agent** | Phase 2 | | `<run-dir>/peer-executor-on-contrarian.md` | **Executor-as-reviewer agent** | Phase 2 | | `<run-dir>/phase2_5.md` | **Orchestrator** | Phase 2.5 (convergence) | | `<run-dir>/phase3.md` | **Orchestrator** (or Chairman agent if delegated) | Phase 3 | | `<run-dir>/output.md` | **Orchestrator** (assembled from above) | After Phase 3 | | `<run-dir>/verdict.md`, `tldr.md` | **Auto-generated** by `run_council.py ingest` | After validate | | CleoDocs store doc (slug `council-run-<run_id>`) | **Auto-written** by `run_council.py ingest` via `cleo docs add`/`cleo docs update` | After validate (T13363 AC2) |

The agent file-write contract: each Phase-1 / Phase-2 subagent must use the `Write` tool to save its full output markdown to the path above a