council-policy

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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

From SteveGJones/ai-first-sdlc-practices, MIT.

More from SteveGJones/ai-first-sdlc-practices