---
name: council
description: Convene a multi-model council review of a diff, branch, PR, path or design doc, using T3 Code delegates from several providers that review, cross-check, deliberate and score until satisfied. Trigger this if the user says "council" or runs /council.
argument-hint: "<what to review: diff | branch | PR | path | design doc> [--rounds 2|3] [--passes N] [focus notes]"
---

# Council review

You are the **clerk**, not a reviewer. You brief the council members, relay their work to each other verbatim, keep the findings ledger, hold the council to its scope, apply fixes between passes when permitted, and report the result. You add no findings of your own and you do not overrule anyone on merit. **The decider has the final say.**

Before an audit, if the user asked you to do the work under review or policy lets you change it, address outstanding PR comments, fix known issues, and run relevant checks, so the council reviews the updated implementation; do not defer known fixes until reviews return. If the user wants to discard the implementation and explore new ideas, skip fixes to code being replaced. Otherwise review the target as it is.

Request: `$ARGUMENTS`

## Council members

| Seat | `target.providerInstanceId` | `target.model` | `target.options` | Role |
|---|---|---|---|---|
| Opus 5.5 | `claudeAgent` | `claude-opus-5-5` | `{ "effort": "xhigh" }` | final reviewer · **decider** |
| GPT 6.1 Sol | `codex` | `gpt-6.1-sol` | `{ "reasoningEffort": "max", "serviceTier": "default" }` | final reviewer |
| Muse Wonder Full | `muse` | `muse-wonder-full-1.0` | `{ "reasoningEffort": "xhigh" }` | reviewer |

Roles: every seat reviews in Rounds 1 and 2. **Final reviewers** also sit in Round 3. Exactly one seat is the **decider**, and it is also a final reviewer. Seats can be added or removed by editing this table; nothing else in the skill depends on how many there are.

- Call `orchestrator_capabilities` once before the first round and confirm every seat's model and option values exist. If a seat is unavailable, tell the user which one and stop unless they say to continue without it. **Never substitute another model.** The council cannot run without its decider.
- Each seat's first round is a `delegate_task` with `role: "review"`, `mode: "async"`, isolation `shared`, and the table's `target`. Use `delegate_task` even for a seat on your own provider: a specified effort counts as a setting beyond yours, so never use native subagents (`Agent`, `spawn_agent`) or Workflow for this.
- Launch all of a round's seats in one message. Then follow each result's `next`; do not poll (`task_status`, sleep, Monitor, ScheduleWakeup).

## Threads

Each seat keeps **one thread for the whole council**, across every round and pass.

- From each seat's first `delegate_task` result, record its `childThreadId` and `taskId` in a seat roster (seat → thread id, current task id, letter, status). Keep the roster up to date for the whole council and include the thread links in the report.
- Every later round goes to that thread with `t3_thread_send` (`threadId` from the roster, `mode: "queue"`), only after the seat's previous run has finished. A send to a finished thread starts a new task in it and returns its `taskId`; record that and follow its `next`, or `t3_thread_wait` on the thread if no `next` is returned.
- This is deliberate (owner decision, 2026-10-30) and overrides T3 Code's default that each review re-check is a new delegate: members keep what they have read and verified. Do not switch to fresh delegates except under §Failures.
- Do not edit, stash, or switch branches in the shared checkout while any round is running. Fixes happen only between passes, when every seat is idle.

## Scope discipline

The target pinned in §0 is the council's entire scope, in every pass. Reviewers drift — toward pre-existing problems, redesigns and wish lists — and every round and pass amplifies whatever enters the ledger. Hold the line, including against yourself.

- **In scope:** defects in the target itself, and in existing code only where the target introduces, exposes or worsens the problem (a new caller of a buggy function, a removed guard, a broken contract). In later passes, also defects the council's own fixes introduce.
- **Out of scope:** pre-existing issues the target neither touches nor makes reachable; feature requests, redesigns, refactors, style preferences and "while you're here" cleanups; hypotheticals with no concrete failure path through the target; requirements the stated intent does not include; severity inflated by a threat model wider than the intent.
- **Every brief carries the scope** and requires members to list out-of-scope observations separately, one line each, never as findings.
- **The ledger is gated.** Before adding any item, check it against the scope. Out-of-scope items — from any member, the decider included — go on a **parked list** with a one-line reason. Parked items are not cross-checked or deliberated. This is a scope call, not a merit call: show the parked list in later rounds so members can object, and readmit an item only when a member shows concretely how the target introduces, exposes or worsens it. In Round 3, the decider may readmit a parked item on that same basis.
- **Fixes stay minimal.** A suggested fix is the smallest change that resolves the finding. If a real fix needs a redesign, the finding says "needs follow-up" instead of growing the review.
- **Each pass's target is frozen.** Within a pass, do not add files, commits or new questions. The next pass reviews the same target plus only the fixes for upheld findings. A later pass does not widen the scope, and a finding the decider dropped is not raised again unless a fix changed that code. If the user changes the target, restart the council.

## 0. Pin the target

Before the first round, turn the request into an exact, reproducible target that a member starting with **no conversation history** can review:

- Repo path(s), and the exact commands to see the change: e.g. `git -C <repo> diff <base>...<head>`, `git diff` (uncommitted), `glab mr diff <n>`, or a list of files/docs.
- Intent: what the change is supposed to do (from the user, commit messages, or PR description), and any focus the user named.
- Scope: what is in and what is explicitly out, per §Scope discipline.
- Pointers to the project's `AGENTS.md`/runbooks the reviewers should respect.

If the target is ambiguous (e.g. "review this" with a clean tree and no PR), ask the user before starting any member.

## Passes and rounds

A **pass** reviews one frozen version of the target. Each pass has up to three **rounds**:

1. **Review** — all seats, independently.
2. **Cross-check** — all seats.
3. **Deliberation** — final reviewers only; the decider rules.

Round 3 is skipped when the Round 2 ledger has nothing contested, or when the user passes `--rounds 2`. Then the decider's Round 2 verdicts are its final ruling, and on contested items its verdict wins.

**Scores.** Every message to a member, in every round, asks for a score out of 10 for the target as it stands in that pass, with a one-line reason. A member's pass score is the last score it gave in that pass.

**Ending a pass.** After the ruling:

- If every seated member's pass score is 9 or 10, the council is satisfied. Stop and report.
- If the decider upheld findings and you may apply fixes (see §Fixes), fix them, run the relevant checks, and start the next pass on the same threads.
- If the decider upheld no findings, stop and report, even if some scores are below 9.
- If you may not apply fixes, stop after the first pass and report. Ask the user whether to fix and continue.

Stop after **3 passes** (or `--passes N`) even if the council is not satisfied. Report the remaining scores and ask the user how to continue. A pass where every Round 1 score is 9 or 10 and no in-scope findings were raised ends the council at once.

## 1. Round 1 — review (all seats)

Write the brief yourself. Give every seat the same brief, and say in it:

- **Context:** the member is one of several independent reviewers on a council, and the others are reviewing in parallel.
- **The target from §0:** what to review, the commands to see it, its intent, its scope, and the files and runbooks in scope.
- **Read-only:** do not edit, format, stage, commit, push, check out branches, start or stop services, or start subagents. Reading, read-only commands and existing tests are fine if they leave the checkout unchanged.
- **Verify each finding:** check it against the actual code and prefer fewer, well-evidenced findings. Cover correctness, security, data loss, operational risk and the user's focus, plus style only where it matters.
- **Output:** per finding, a short title, severity (critical, high, medium, low or nit), confidence, `path:line`, the problem, a concrete failure scenario or evidence, and a minimal fix. Then a list of risky areas checked and found fine, the out-of-scope list (one line each, or "none"), and the score.

In later passes, Round 1 goes to the same threads. Give the fix diff since the previous pass, the upheld findings it addresses and the parked list. Ask each member to review the updated target within the same scope: check that the fixes work and introduce no new defect. Do not ask for a fresh audit of unchanged code.

When every seat returns, build the **ledger**:

- Apply the scope gate first: anything out of scope goes on the parked list with a reason.
- Give each distinct in-scope finding a stable ID (`F1`, `F2`, …), and keep the numbering going across passes. Merge duplicates only when they share the same root cause and location. If unsure, keep them separate and note "possible duplicate of Fn".
- Record who raised each finding (by letter), each raiser's severity and confidence, and the text verbatim or near-verbatim. Do not judge merit.
- In the first pass, give each seat an anonymous letter, shuffled, so members weigh arguments, not brands. Keep the same letters for the whole council and keep the mapping in the roster.

## 2. Round 2 — cross-check (all seats)

Send each seat, in its own thread:

- the other members' Round 1 outputs, verbatim and labelled by letter;
- the ledger and the parked list, with reasons;
- a request to re-check every ledger item against the code itself, not to take anyone's word for it, including its own earlier review;
- a request to stay within scope.

Ask for:

- **Verdicts:** one line per ledger ID, `Fn — CONFIRM | REFUTE | UNSURE — severity — reason with path:line or command evidence`.
- **Missed findings:** in-scope findings no one raised, in the Round 1 format.
- **Retractions:** its own findings it withdraws, and why.
- **Parked-item objections:** each showing concretely how the target introduces, exposes or worsens the item.
- **The score.**

Update the ledger with every verdict, retraction and objection that meets the bar. Gate new findings through scope before giving them IDs. Classify each item:

- **Unanimous** — every seated member CONFIRMs and the severities are within one step, or every seated member REFUTEs or retracts.
- **Contested** — anything else: split verdicts, UNSURE, a severity spread of two or more steps, a new Round 2 finding the others have not seen, or a readmitted parked item.

## 3. Round 3 — deliberation (final reviewers only)

Reviewers who are not final reviewers do not sit in Round 3. Their Round 2 verdicts stay in the record.

**3a. Final reviewers other than the decider argue, in parallel.** Send each one the ledger with every Round 2 verdict and its reason, the Unanimous or Contested labels, and the parked list with objections.

Ask for each Contested item to be re-verified in the code and answered as `Fn — KEEP <severity> | DROP — firm | soft — evidence`. A member may challenge an Unanimous item only with concrete evidence. It must not introduce new findings or widen the scope. Ask for a score.

**3b. The decider rules**, after 3a returns. Send it the same ledger plus every 3a output, verbatim. Ask it to:

- re-verify the contested items;
- rule `Fn — UPHELD <severity> | DROPPED — reason (path:line / evidence)` on every ledger ID;
- answer the evidence of every firm position it rejects directly, rather than dismissing it;
- readmit a parked item only with a concrete account of how the target introduces, exposes or worsens it;
- introduce no new findings.

Ask for its final findings, most severe first, in the Round 1 format with minimal fixes; a dissent line for each ruling against a firm position or a Round 2 majority; and its score.

The decider's ruling is final for this pass. Do not re-litigate it.

## Fixes

Apply fixes only if the user asked for them, or you have been given permission or autonomy to apply fixes by policy (for example a project `AGENTS.md`, a standing instruction, or the task you were delegated). Fix only upheld findings, each with the smallest change that resolves it: nothing from the parked list and no adjacent cleanups. Small fixes are yours to make directly. Run the relevant checks before the next pass.

## 4. Report to the user

Lead with the result, then the record. Map letters back to seat names.

1. **Council review:** the ratings, in this form. Number rounds across passes. Write `—` where a seat did not sit in a round, `no score` where it sat but gave none, and `failed` where it errored. Do not invent a score.

   ```markdown
   ## Council review

   Passes: 2 · Rounds: 5

   | Delegate | P1 R1 | P1 R2 | P1 R3 | P2 R1 | P2 R2 |
   | --- | --- | --- | --- | --- | --- |
   | Opus 5.5 | 7/10 | 8/10 | 8/10 | 9/10 | 10/10 |
   | GPT 6.1 Sol | 8/10 | 8/10 | 9/10 | 10/10 | 10/10 |
   | Muse Wonder Full | 7/10 | 8/10 | — | 9/10 | 9/10 |
   ```

2. **Final findings:** the decider's final list from the last ruling, most severe first. Give each one's severity, `path:line`, problem, failure scenario, fix, whether it was fixed and in which pass, and its provenance (for example `raised by Sol, Muse · confirmed by all` or `contested — Opus upheld over Sol`).
3. **Dropped:** one line per dropped or refuted item, and why.
4. **Dissent:** each upheld or dropped item that another member disagreed with.
5. **Noticed, out of scope:** the parked list, one line each, clearly not findings. Flag any that look like security or data-loss risks so the user can decide on a follow-up. Take no action on them.
6. **Process:**
   - passes and rounds run;
   - why the council stopped;
   - any seat that failed or was replaced;
   - a link to every council thread (each thread's `link` verbatim on first mention).

## Failures

- **A seat errors or times out.** Retry once in its own thread. If the thread is gone or the send fails, start a fresh `delegate_task` for that seat with the brief plus all of its own earlier outputs, verbatim. Record the new thread in the roster and use it from then on. If the retry fails too, continue without that seat, mark it `failed`, and say so in the report.
- **The decider fails after one retry.** Report the ledger, the other final reviewers' positions and the Round 2 verdicts, clearly labelled **no final ruling**. Apply no fixes, and let the user decide.
- **The user says stop, or to proceed without a seat.** `task_cancel` that seat's running task and do not start a replacement.