Council Policy

sdlc-model-council is a cross-model council: it assesses the peer agentic CLIs installed on this machine, keeps a project roster of how each model performs by task type, and runs fan-out plays — the same task to a decorrelated panel, synthesised into one attributed verdict — on top of an in-session, uncontainerised, single-machine delegation substrate to locally-installed peer agentic CLIs. No Archon, no Docker, no DAG. (That's the one-line distinction from sdlc-workflows, which is Archon- orchestrated, containerised, DAG-based delegation — reach for that plugin instead when a task genuinely needs an isolated container or a multi-step workflow graph; reach for this one for a single in-session hand-off to a peer CLI, or a cross-model fan-out play, without any of that machinery.)

§3.3 Routing: sibling-plugin hand-off vs our delegation-runner

Before dispatching anything, work out whether the request is better served by an installed sibling plugin's own slash command than by our adapter. Per-vendor plugins do the per-vendor job well; our value is cross-vendor uniformity, graded postures, and fan-out — not re-implementing what a sibling plugin already does better.

Detecting whether a sibling plugin is installed — the harness-truth signal first: the most reliable, token-free signal is whether the sibling's own slash commands (/codex:review, /codex:adversarial-review, /codex:rescue, /codex:transfer, /codex:status, /codex:result, /codex:cancel; /antigravity:delegate, /antigravity:review, /antigravity:research, /antigravity:cloud-run-debug, /antigravity:status, /antigravity:result, /antigravity:cancel) appear in your own available-skills listing in this session — if they're there, the plugin is installed and invocable directly, no probing needed. Only fall back to the ~/.claude/plugins/installed_plugins.json probe (extdel.sh list-backends runs this for you, advisory-only, never gating) when you can't otherwise tell — e.g. deciding what to recommend for a different session, or writing guidance that must hold before this session's own skill listing is available.

Task shape	codex-plugin-cc (/codex:*) installed	Route
Review my diff / adversarial review gate / rescue a stuck codex task / continue a persistent codex thread	yes	Hand off to the matching /codex:* command in the main thread; do NOT also dispatch delegation-runner for the same task
Same task shapes	no	Dispatch delegation-runner backend=codex; note in your response that the official codex@openai-codex plugin exists and would be a better fit (/plugin install codex@openai-codex hint)
Cross-model compare/fan-out, unified §4.2-contract collection, an isolated second opinion under a graded posture, posture-graded write delegation	either	Always our adapter — this is exactly the work no per-vendor plugin does
Anything involving Gemini/agy	either	Always our agy adapter. The installed antigravity@antigravity-for-claude-code plugin is itself capable (cost-disciplined delegate/review/research/cloud-debug with verification) — this is a coexist relationship, not a supersession. Our differentiators are narrow but real: graded --gemini_dir read-only/workspace postures (finer than a blanket write-approval) and the unified cross-vendor contract + cross-model fan-out that a single-vendor plugin can't offer by definition. Do not claim our agy adapter is strictly better — it solves a different problem (uniformity across vendors) than the sibling plugin does (depth on one vendor).

Why hand-off, not call-through: our delegation-runner subagent (Haiku; Bash/Read/Grep/Glob, no Skill/Agent tool) cannot invoke another plugin's slash command, and granting it that ability would break context isolation and be unreliable. Even from the main thread, calling /codex:review and then wrapping its output would mean scraping another plugin's own conversational output into a different shape — fragile, and it double- spends context. So "prefer codex-plugin-cc when installed" is a routing decision made once, in the main thread, before dispatch — never inter-plugin RPC. Say this plainly if a caller asks how the hand-off works; there is no hidden call-through mechanism.

Picking a backend

Run ${CLAUDE_PLUGIN_ROOT}/scripts/extdel.sh list-backends (add --probe-auth for a live auth check, --json for machine-readable output) to see which backends are registered as adapters, which are actually installed on this machine, and — advisory only — whether a sibling plugin for that vendor is present. Use this before dispatching delegation-runner if you're not sure a backend is ready; it's a pure read-only report, no handle created, no tokens spent.

If the caller names a provider ("GPT", "codex", "Gemini", "agy"), that picks the backend directly. If they just say "get a second opinion" without naming one, ask rather than guessing, or default to whichever list-backends shows as installed+authenticated on this project.

Which platform: codex vs agy

Both backends present the identical caller-facing contract (design doc §4.2) — the choice is purely about which model/provider's take you want:

	codex	agy
Provider / model	OpenAI, GPT	Google Antigravity, Gemini (and other models agy models lists)
Continuity mode shipped	resume	resume
Held-process (mode: persistent)	not yet shipped (planned: codex mcp-server daemon)	not planned as a held process at all — agy's own continuity is server-side/id-addressable, so a pty-held interactive session would trade real state for fragile heuristic completion detection; mode: persistent is a clean Status: ERROR, not attempted
Headless permission model	a real sandbox (-s read-only/workspace-write) gates tool use non-interactively	auto-denies every tool call (read_file/command/write_file/edit_file) in --print mode unless pre-allowed — --mode/--sandbox do NOT gate anything headless (live-probed; see the design doc's §9.15)
read-only posture mapping	-s read-only	a per-handle --gemini_dir config carrying a permissions.allow list scoped to reads + read-only shell commands — the real enforcement lever, not --mode/--sandbox
Answer source	-o/--output-last-message file	plain stdout (no separate answer file from the CLI itself — extdel.sh captures it into the same turn-NNN.last-message.txt convention)
Installed sibling plugin	codex@openai-codex (official) — prefer-for review/rescue/persistent-thread shapes, see the routing table above	antigravity@antigravity-for-claude-code — coexist, see the routing table above

Delegate out to delegation-runner

Delegate to an external agentic CLI backend when the value is specifically in a different model/provider's take on the problem, not just in offloading verbose output (that's what command-delegation's command-runner family is for):

• Cross-model second opinion. You want GPT's (codex) or Gemini's (agy) independent read on a design, a bug, or a piece of code — to compare against or merge with your own analysis.
• Independent fan-out sub-problems. N genuinely independent sub-tasks where you want N concurrent external sessions rather than doing them serially yourself or via N internal subagents.
• Continuing an existing external conversation. The caller already has a handle from a prior delegation-runner turn and wants to continue that specific external session (pass handle: through — never start a new one when continuity with the prior turn matters).

Keep it inline or use an internal subagent instead

• The sub-problem doesn't benefit from a different model's perspective — use a Claude subagent (or handle it directly).
• You need to react to output turn-by-turn, mid-stream — external delegation is submit-then-poll; you get a compact answer only once each turn finishes, not a live stream.
• The task is destructive/mutating and needs a human in the loop for approval — external CLIs run non-interactively (codex exec / agy --print), so anything requiring an approval prompt will just fail under read-only/workspace posture rather than pausing for a human. That's intended behavior, not a bug to route around. (codex's app-server protocol exposes a real per-action approval loop — ExecCommandApprovalRequest/ApplyPatchApprovalRequest/etc, answered with a ReviewDecision — that a future rpc-server-kind adapter could drive for fine-grained, in-conversation approval; agy has no equivalent verb in its machine channel. Out of scope for this build — see the design doc's §6.3/§9.15 for the roadmap.)
• It's a local shell command, build, test suite, or log to watch — that's command-delegation's territory (command-runner/build-runner/ test-runner/process-monitor), not this plugin.

Posture: default read-only, escalate only when the caller says so

posture	codex mapping	agy mapping	when
read-only (default)	-s read-only — read and reason; no writes, no network from its side	--gemini_dir allow-list scoped to read_file(*) + read-only shell command prefixes (cat/head/tail/sed/grep/rg/ls/find/wc/git) — no write_file/edit_file rule at all	the default for every delegation unless told otherwise
workspace	-s workspace-write — can write files within its working directory	the read-only allow-list PLUS write_file(*)/edit_file(*) and a build/test command set (python/node/npm/pytest/go/cargo/make/bash/sh)	only when the caller explicitly wants the external model to make edits
dangerous	--dangerously-bypass-approvals-and-sandbox	--dangerously-skip-permissions (supersedes any allow-list; a config dir is still passed for uniformity)	only when the caller explicitly opts in — never chosen by the wrapper itself

Why agy's mapping changed from --mode/--sandbox: an earlier design mapped agy's posture onto --mode plan|accept-edits + --sandbox. Live probing (design doc §9.15) found neither flag gates anything in headless --print mode — agy auto-denies every tool call there regardless of --mode, and only a permissions.allow entry (delivered via --gemini_dir) or --dangerously-skip-permissions actually lets a tool call through. extdel.sh writes a fresh per-handle agy-cfg/antigravity-cli/settings.json before every turn (start AND every resume), so a --steal posture escalation is picked up automatically.

Escalation is a caller decision, never the wrapper's. delegation-runner is instructed to never select dangerous on its own initiative, and a handle's posture is pinned at start time — extdel.sh prompt refuses a differing posture unless --steal is passed explicitly, so any escalation mid-conversation is visible in the transcript rather than silent. This pin is enforced identically for every backend — extdel.sh refuses the mismatch before it ever builds a command line, regardless of adapter.

read-only is not read-nothing. The sandbox/allow-list posture restricts what the external model can do (write, run network-touching commands) — it does not restrict what it can read. Under any posture, codex or agy can read any file on disk that the calling environment's user could read: .env files, ~/.ssh/, credentials, anything in the delegated cwd/add_dirs. That content becomes part of what's sent to the external provider's infrastructure (OpenAI for codex, Google for agy) as prompt context. This is inherent to delegating to an external CLI, not a bug in this plugin — name it plainly to the caller if a delegation is pointed at a directory that plausibly contains secrets, rather than silently proceeding.

Fan-out and process count

Each delegation is submit-then-poll, not a held daemon, in the resume mode this build ships for every backend — so a single delegated turn is one detached process while it runs, not three, regardless of backend. (Codex persistent mode, when it ships, will use a daemon + holder + watchdog per handle — 3 processes per handle — worth knowing in advance: N concurrent persistent handles ≈ 3N processes, against the family's fan-out cap of 5 concurrent external sessions. agy has no persistent/held-process mode planned at all — see the platform comparison table above — so this concern is codex-only.) Apply the cap of 5 regardless of backend or mode when deciding how many delegation-runner dispatches to fan out at once — it exists to bound both process count and concurrent spend against the external provider's quota. This cap applies to compare/fan-out (below) exactly as it does to individual delegate dispatches.

agy's old cross-handle id-capture race is now closed by construction: earlier builds read a single machine-global ~/.gemini/antigravity-cli/cache/last_conversations.json keyed by cwd, so two agy start calls landing in the same cwd at nearly the same time could race on which conversation that shared cache ended up recording. Each handle now gets its own isolated --gemini_dir (./tmp/model-council/<HANDLE>/agy-cfg/), so id capture reads a per-handle cache with nothing else to race against — concurrent delegation-runner dispatches in the same cwd no longer contend over id capture at all. status can still surface a WARNING if a handle's own isolated cache entry changes identity out-of-band between turns (now a much narrower, more anomalous signal than the old cross-process race) — report it, don't silently trust the newer id.

NO_OUTPUT: an exit-0 turn is not automatically a successful one

delegation-runner can report Status: NO_OUTPUT on any backend — a turn that exited success-shaped (exit code 0) but whose captured answer was empty after trimming whitespace. This is never silently upgraded to SUCCESS. It's most common with agy: the headless auto-deny above means a turn can complete cleanly while the actual requested tool call was denied, leaving nothing useful in the answer. When that's the cause, ## Errors carries agy's own diagnostic verbatim (its "no output produced ... auto-denied" wording) plus the fix — broaden the posture on a fresh handle, or rephrase the task to fit the current one. A codex turn can also exit 0 with an empty -o file (e.g. an unretried sandbox denial); the same check applies there too, backend-generally. A NO_OUTPUT with no permission hint at all is a legitimately empty answer, not a crash — the wrapper agent reports it as-is rather than fabricating content or silently retrying.

Cost is real and invisible to Claude's own telemetry

Delegated turns spend the external provider's quota/credits (OpenAI's for codex, Google's for agy), not Anthropic's — and that spend does not show up in Claude Code's own token/cost reporting. Codex's --json event stream includes token-count events; agy's --log-file output is retained per turn. The full transcript for either backend is kept under ./tmp/model-council/<HANDLE>/, so it's auditable after the fact, but nothing surfaces it proactively today. Don't fan out delegations casually; each one is real spend on someone else's bill — this is what makes the fan-out cap above a cost control, not just a process-count control.

Plays (cross-model fan-out)

A play is a choreographed fan-out over the delegation substrate above — the same task goes to a decorrelated panel of models, the results are collected on disk (never inheriting the main thread's context), and a combine step produces one attributed answer. Four plays are designed; one ships in v1.

• Diff+Synthesis — SHIPPING in v1. Cast a decorrelated panel (default k=3) from the project roster, fan the same task out to each member (cap 5, per the fan-out section above), and dispatch the council-judge agent (Sonnet, reads result files from disk under blind labels) to synthesise them into combine/synthesis.md: Convergent (points of agreement) / Divergent (attributed) (disagreements, each pinned to its model) / Adjudication (the judge's call on each divergence) / Confidence / Baseline delta (did the panel materially beat the roster's single best model for this task, the baseline_member?). Run it via /…:council-run task-type=… input=….
• Consensus/Vote — designed, deferred. An odd-N cast each ends its response with a mechanically-tallied VERDICT: APPROVE|BLOCK|UNSURE line; a split or majority-UNSURE escalates to a judge.
• Best-of-N — designed, deferred. N generators produce independent candidates; an outcome scorer (test-pass rate for code, judge-vs-rubric for design) ranks them and returns an attributed winner.
• Generator↔Verifier — designed, deferred. A generator and a cross-family verifier run one bounded repair round; an unverified result is flagged rather than silently accepted.

The measurability spine: every play keeps the roster's best single model in the cast as the baseline_member, and the synthesis states plainly whether the panel beat it, confirmed it, or was net-negative. This is not decoration — it's how the whole approach proves or disproves its own worth. If, over real use, the panel rarely beats the baseline member, the honest fallback is roster-driven single-model routing (/…:delegate with the roster's pick, no fan-out at all) — a feature removal, not a rewrite, and one this policy exists to make honest to reach for.

Policy & commission consult

A project's council configuration lives under .sdlc/model-council/: roster.json (per-model performance by task type, from assessment), policy.json (task-type → {play, cast or cast_rule, budget}), and commission.json (the record of how the project was commissioned).

/…:council-run reads policy.json for the task type it's given, to pick the play, the cast, and the budget guardrail without the caller having to specify them. If the project isn't commissioned (no policy.json), it falls back to heuristics — play = diff-synthesis, cast built live from roster.json if present, else ask the caller — and says plainly that the project isn't commissioned rather than silently guessing.

Casts in policy are usually a cast_rule (re-evaluated live against the current roster at run time), not a pinned list of addresses — that way a policy set up today keeps selecting good models after a roster refresh or a model's retirement, rather than pointing at addresses that no longer resolve well or at all. Pinned casts are supported for when a caller deliberately wants a fixed panel.

Set this up with /…:council-commission (discover → characterize → assess → write roster + policy), refresh it with /…:council-assess, inspect the roster with /…:council-roster, and preview spend with /…:council-estimate before a run that would cost real money.