Panama/user/agents/skills/ticket/COUNCIL.md

# The review council

Several fresh agents from different model families review the same change, each knowing nothing
of how it was built. You judge what they return. This runs before `pre-mr-review`, because
that audit may not run anything and so cannot catch a claim that is plausible on the page and
false in reality. A reviewer that can run things can. It has caught a mitigation proven by
construction to be wrong, on a branch whose own audit had blessed it.

Order matters. `pre-mr-review`'s verdict gets pasted verbatim into `mr.md`, and anything that
lands after it invalidates that verdict. Council first, fix, commit, then the audit over the
final tree.

## Seats

| Seat | `providerInstanceId` | `model` |
|---|---|---|
| Claude | `claudeAgent` | `claude-opus-5-5` |
| Codex | `codex` | `gpt-6.1-sol` |

Klaude never takes a seat. It is the work account, and its only job is the `pre-mr-review` run
in Phase 2 step 7, which stays a separate required step after the council.

Adding a seat is adding a row. `orchestrator_capabilities` has the IDs, with `search` for a
model it does not list. Nothing else here changes with the seat count. T3 can leave out a model
the provider really has, as it does with `opencode-go/*`. List such a model under that provider's
`customModels` in `~/.t3/userdata/settings.json`, which T3 picks up without a restart.

## When it runs

Run it whenever the change adds or modifies a procedure, touches schema or migrations, touches
permissions or auth, involves concurrency, or has a risk table in its ticket. When unsure, run
it. A copy tweak, a styling fix, or a one line correction with no logic skips it.

## Convene

1. Confirm the suite is green, and note the base and head of the commit range. A seat should
   never spend its review on code the suite already rejects.
2. In one turn, call `delegate_task` once per seat with the brief below: `role: "review"`,
   `mode: "async"`, a title of `Council <seat> <KEY>`, and the seat's `target`. Leave `isolation`
   unset, so each seat reads this checkout, and leave `runtimeMode` unset.
3. End your turn. T3 wakes you as each seat finishes. Leave the checkout alone until every seat
   has returned, because they are reading it.
4. A seat refused with `model_unavailable`, or one that fails: record it with `ticket-page event`,
   carry on with the rest, and name it at hand-off. Keep the seat empty rather than filling it with
   another model. If no seat can run, ask Gib with AskUserQuestion. A timeout or silence is not
   an approval.

Outside T3 Code (no `T3CODE_THREAD_ID`), run one fresh subagent from the harness with the same
brief. Never review the change in your own context: the value here is the reviewer not being
the author.

### The brief

A delegate gets none of this thread, so the brief is all it knows. Fill the placeholders.

```
Review only. Do not edit, commit, push, run anything destructive, or start subagents.
Repo: <absolute path>   Range: <base>..<head>   Ticket: <KEY>

Read in this order, or you will report conventions this project already settled:
1. .claude/docs/epics/<EPIC-KEY>/summary.md, if it exists
2. <scratch path of `ticket-page md <KEY>`>
3. <target-dir>/resources/
4. AGENTS.md
5. git diff <base>..<head>, then the code around it

Verify rather than suspect. You may run tests and read-only checks. Try to refute each finding
before you report it. A plausible worry is not a finding.

Re-derive every "proven by X" already written into the ticket's risk or test tables. A false
proof claim in Jira is worse than an unproven one, because it stops anyone else from checking.

Answer these against the ticket and plan, not the diff alone, quoting the AC ID or plan step:
- What did the ticket ask for that is missing or only partly done?
- What behavior is in the diff that nothing asked for?
- What looks implemented but is implemented wrongly?

Hold the change to its smallest correct form. Flag code, tests, or guards the ticket does not need.
blocker = the intended case is wrong. should = a real bug callers will hit. nit = everything else,
including rare paths, small performance costs, and style.

Reply with:
VERDICT: APPROVE or CHANGES
S1 [blocker|should|nit] [CONFIRMED|PLAUSIBLE] <file>:<line> <claim>. Failure: <concrete scenario>. Fix: <smallest fix>
```

## Judge the findings

Findings are not automatically true, and reviewers produce confident wrong answers. Check each
one against the code yourself, and regrade it: a rare path is a nit whatever label it came with.
Two seats reporting the same thing is one finding with more weight behind it. A finding only one
seat raised is still worth checking, since catching what the others miss is why the seats differ.

Put each on the page as you judge it, with its grade and its seats in the text:
`finding <KEY> add "[should] <text> (Claude, Codex)" --severity CONFIRMED --where <file:line>`, then
`fixed --commit <sha>`, or `rejected --reason "<why>"`.

- **Fix every blocker and should you confirm,** each meaningful fix as its own commit. These do
  not defer to a follow-up ticket unless Gib decides that.
- **Take the smallest fix.** Prefer deleting or narrowing code over a new lock, cache, helper, or
  option. Compare `git diff --shortstat <base>` before and after: if review grew the diff, cut
  first. Review loops grow a change one cheap-looking fix at a time, and it is your job to hold
  the scope.
- **Decline nits in one line** with `rejected --reason`, and list them at hand-off as follow-ups.
  Agreeing just to end the review is how a change bloats.
- **When a fix changes a mechanism rather than a line,** write a test that fails against the old
  behavior and passes against the new one, and confirm it fails by reverting the fix. A test that
  passes either way proves nothing.
- **If a finding invalidates something already in Jira or a deliverable,** correct it there too.
  Fixing the code does not fix the false claim.

## Stop

One round is the default. `pre-mr-review` reviews the whole diff, your fixes included, and serves
as the next pass. A second round runs only if a fix changed a mechanism: fresh `delegate_task`
calls, the same brief, the ledger of what you fixed and rejected with your evidence, and an
instruction to check only the open ids and the changed code. Two rounds is the limit. A finding
still disputed then goes to Gib with AskUserQuestion, both sides in two or three lines each.

## Checking a dev review

`review-ticket` borrows the seats for a draft instead of a diff. Same `delegate_task` settings, and
no code gets changed. Give each seat this:

```
Review only. Do not edit anything, write to Jira, or start subagents.
Repo: <absolute path>   Draft: <dir>/review.md   Story: <scratch path of the fetched story>

Check the draft against the code. Report each Current State claim that is false, each "does not
exist" that does, each named pattern that is a poor fit or has a better neighbour, each seam the
Relationships section gets wrong, and any story AC the implementation guidance would not satisfy.
Say whether the estimate misses work the code paths table leaves out.

Reply with:
VERDICT: APPROVE or CHANGES
S1 [blocker|should|nit] <section> <claim>. Evidence: <file:line>. Fix: <suggestion>
```