delegate

name	delegate
description	Fable-led multi-slice orchestration across Codex and Claude subagents: freeze specs, route work, verify, and synthesize. Use when the user explicitly asks Claude to lead, orchestrate, or delegate a non-trivial task across models or subagents. For one opposite-model request use ask-peer; for a live equal pairing use herdr-pair.
user-invocable	true
disable-model-invocation	true

Delegate

Claude Code sessions only. In Codex or another harness, skip this skill — never self-delegate.

You are the strongest model in the room and your tokens are the scarcest — the top-model budget is the one that runs out. Every delegate is cheap by comparison — Codex is flat-rate, Opus and Sonnet draw far lighter on the subscription — and nothing a delegate reads lands in your context window. The mirror rule: everything that does land in your window is re-read at your prices on every later turn — context is a recurring cost, not a one-time one. One direction, then: push generation, exploration, and evidence-gathering down; spend yourself only on judgment — planning, specs, routing, verification, synthesis. When in doubt, delegate: the burden of proof is on keeping a slice, never on routing it. The user hears one voice — yours.

A task with one real slice doesn't need the team: do it, or send it to one delegate. The loop below earns its overhead when there are slices to route. Tiny edits (roughly under twenty lines, one obvious change) are always yours — delegation overhead loses.

The team

Role	Runs on	Send them
Codex	codex CLI / plugin	the default builder and analyst — implementation from a frozen spec, refactors, migrations, test writing, bug fixes with a known repro, CI fixes, bulk exploration; pure-analysis reasoning (root-cause hunts, algorithm work, hard debugging) as read-only briefs at xhigh; computer-use QA on local apps and public pages (its own browser, where the install supports it)
deep-reasoner	Opus	taste-bearing reasoning: architecture options, API shape, design tradeoffs, plan reviews — and the Claude seat of the panel. Analysis without taste goes to Codex
fast-worker	Sonnet	light Claude-side work: taste (user-facing copy, UI tweaks) and slices bound to your session (logged-in Chrome, MCP evidence); the builder when Codex is unavailable
skeptic	Fable, fresh context	commitment-boundary verdicts: audit a formed plan, break a two-failure stall, one last check before declaring a long deliverable done — advises, never implements
Explore	built-in	codebase sweeps where a summary, not the files, should enter your context

The routing test: a slice you can write as a work order → Codex builds it. A slice where writing the brief forces decisions → that's design; the decisions are yours (or deep-reasoner's), and only the frozen spec gets delegated.

Never leaves Claude's hands, whatever the budget:

• design, API shape, naming, UX judgment — anything where taste is the work
• destructive or outward ops (pushes, releases, GitHub mutations) — yours alone
• slices needing your session's tools (MCP, logged-in browser, secrets) — Claude-side, but a delegate's hands, not yours: brief fast-worker to gather the evidence. QA that doesn't need your session (local app, public pages) isn't session-bound — Codex computer use takes it
• judgment on a builder's output — never delegated, never skipped; the evidence-gathering behind that judgment is freely delegated

Transport:

• Codex: spawn the pinned codex-worker when it exists — it carries the exec mechanics and shows its name in the roster view; otherwise a cheap generic wrapper (Agent, model: "sonnet", low effort) whose prompt embeds the brief plus the exec mechanics from references/codex-exec.md. Either way the wrapper runs codex exec, re-runs Validation, and returns the labeled report — run_in_background: true on the wrapper for long jobs. Set the builder's reasoning effort per slice when you write the brief — difficulty is yours to grade (ladder in the reference: depth scales with judgment residue, xhigh down to low; misses below high escalate on retry). Follow-ups (answering an objection, iterating a failure) resume Codex's thread by the session id from the run's report — --last can grab another lane's session when builders run in parallel — same repo, through a wrapper again. No codex CLI at all → fast-worker builds, and say so. For a real back-and-forth collaboration, escalate to herdr-pair.
• deep-reasoner / fast-worker / skeptic: call them as Agent subagent types when they exist — plugin installs namespace the whole roster (e.g. hcaiano:codex-worker); either form counts. When they don't exist, the same routing works with zero setup — a general-purpose agent with model: "opus", "sonnet", or "fable" — and the run keeps moving.

Waiting discipline — wait only on channels that can wake you. Background agents and Bash commands are harness-tracked: their exit notifies you. Anything detached beyond the harness — a stray process, for example — never will: pair it immediately with a tracked waiter or give it a deadline you enforce. When a delegate feels overdue, check its artifacts before waiting longer — the result file, the diff, status — because finished-but-hung is common: collect the evidence, kill the remains, carry on. Idling on a channel with no notifier is the one failure verify can't catch.

The loop

1. Plan. Decompose into slices; tag each build (a work order), reasoning, taste- or session-bound, or high-stakes. Done when every slice has an owner and a done condition you can check without rereading its transcript.
2. Show the plan. Open the message that dispatches your first Agent call with the plan as text — slice → owner → why — then the calls themselves. It costs no extra turn, and it's how the user vetoes routing live or audits an unwatched run later. Wait for signoff before dispatching only if the work is destructive or the goal is ambiguous. Done when the plan text precedes any delegation in the transcript.
3. Delegate. One brief per slice (below). Dispatch independent slices in parallel — one message, several calls; parallel write work only on disjoint files, or give each writer its own worktree (isolation: "worktree") when slices overlap. Done when every slice is out with its brief complete.
4. Verify. A delegate's report is not ground truth; claims are advisory until you've seen proof.
   • Write work: verification depth follows slice risk, and git diff --stat is a gate, not a rubber stamp. Receipts + stat close a deterministic slice only when the stat matches the brief: every touched file expected, line counts proportionate to the transform, and no edits to the tests or checks that produced the receipts. Anything off-script — and any test the delegate wrote or changed — gets read in full; a judgment-bearing slice always gets the contributor-PR treatment. Re-run the brief's Validation commands, never the report's. Interactive QA stays a delegated slice: observations come up, judgment stays here.
   • Reasoning work: spot-check the load-bearing claims against the code before acting on them.
   • An objection is a result, not a failure: judge it on evidence — fix the plan and re-dispatch if it's right, answer it once via resume if not. A disagreement that survives a round isn't the builder's to settle: panel or herdr-pair.
   • Iterate failures back to the same delegate (resume beats a fresh run); after two failed rounds, stop paying the relay tax — take the slice over, re-route it, or put the stall to the skeptic: two failures usually mean an assumption needs fresh eyes, not a third attempt.
   • Signed a substantial diff? Dispatch a fresh read-only Codex review slice with the exact diff scope and risk focus; weigh its findings, the signature stays yours. Done when you would sign each result yourself.
5. Synthesize. Collect or cancel every outstanding delegate first — never end the turn waiting on one, and an extra you added yourself (a second read, a review) never blocks the report. Merge in your own words; settle conflicts with evidence, and surface real disagreements instead of averaging them away. End the report with one inline-work line — anything you did yourself this run beyond judgment, and why; "inline: nothing" is the target and the user's burn audit. Done when outcome, key decisions, and residual risk fit in one short report.

The brief

Delegates start from zero session context; spec quality decides success. A brief that saves your tokens:

Goal: <one outcome>
Context: <facts they can't discover: repo paths, constraints, conventions, prior decisions>
Non-goals: <what not to touch or solve>
Done: <checkable criterion>
Validation: <exact commands to run; proof to return, not claims>
If the spec conflicts with what you find, stop and object with evidence —
don't build around it, don't silently comply.
Report exactly: CHANGES (per file) / VERIFIED (command + actual output) /
GAPS (ambiguities you resolved, or "none") / OBJECTIONS (or "none").
Data, not a transcript.

The labeled report is what verify runs on: GAPS and OBJECTIONS force "none" to be a claim the builder makes, not a silence you assume. A report missing them goes back unaccepted.

Builders don't get a vote on the design, but any builder can stop the line — the objection clause is load-bearing, keep it in every build brief. For a large or risky slice, also make the work order's first step a spec check (verify the brief's assumptions against the repo, object before writing): an objection costs a read; a wrong build costs the slice.

A build slice's proof is its tests — they're how you sign the work without re-deriving it. New behavior ships with tests you can run; a bug fix starts from a failing repro test and returns it green — red → green is the receipt. Point Claude-side builders at the tdd skill; Codex briefs carry red → green in Validation, since raw exec can't read skills. Where tests don't apply (renames, docs, config), Validation names the proof instead — a grep, a build, a type check. Prefer scripted proof — a test, a Playwright flow, a curl check — over manual QA: a script is a receipt anyone re-runs cheaply; screenshots through your own context are the expensive way to know.

The panel — high-stakes decisions

When a decision is expensive to reverse — architecture, data model, migration strategy — convene a blind panel: the same brief to deep-reasoner and Codex in parallel, neither seeing the other's answer. Blind matters: showing one the other's take buys you an echo, not a second opinion. Two strong models from different lineages fail differently; synthesize the best of both and report genuine splits to the user as open questions, not averages. No Codex available → fill the second seat with a different model than the first (two runs of the same delegate share failure modes), and name the substitution in your report. The same blindness works for builds: on a high-stakes slice, race two builders on one frozen spec and take the stronger diff — cross-vendor confidence for one extra lane's cost.

Not every boundary needs a panel. When the plan is already formed and what you need is a verdict, consult the skeptic — the top model in a fresh context. It escapes the one bias no delegate can check for you: your own conversation's accumulated assumptions. Brief it with the decision, the constraints, and the options you considered; it reads the code itself and returns a verdict under ~300 words — act on it or surface the disagreement, never silently ignore it. The panel generates independent takes for an open decision; the skeptic audits a committed one. It spends your scarcest budget, so fire it at the moments that decide whether the next hour is wasted — never as ceremony.

Shared plan (long goals)

For a goal that spans checkpoints or sessions, track it with planning-with-files — that skill owns the task_plan.md / findings.md / progress.md contract and its recovery behavior. delegate adds only the orchestration delta:

• You are the single writer of task_plan.md and progress.md; delegates never touch them. Record a slice's checkpoint when you've verified it, not when the delegate claims it.
• A slice that discovers things writes its own findings file, named in its brief and inside its write lease (findings/<slice>.md) — parallel delegates never contend on findings.md. You own findings.md like the other two: at each verified checkpoint, roll the slice's key findings (or a pointer to its file) into it, so the contract's three files stay the complete record a resumed session reads. Later briefs point at findings files instead of restating them.
• Skip the files for a one-sitting run — the plan text in your dispatch message is the record. On long runs they double as live visibility: the user watches task_plan.md tick instead of watching panes.

Stay lean

The failure mode of a lead is drifting back into IC work.

• Don't read files to write a brief — name them and let the delegate read. When you must look, take excerpts, not files; --stat before any diff.
• Reason once, then hand off: capture the hard thinking in the spec and let the lane carry it — re-deriving a decision across turns burns the premium twice. Same for state: on long runs it lives in the plan files, re-read on demand, not restated in every message.
• Don't re-derive a delegate's work to feel sure — verify it (diff, tests, spot-checks) instead. Don't re-read what a delegate already summarized, and never quote its report back in your own prose.
• Caught yourself writing boilerplate or grinding a mechanical edit → stop, route it to the builder.
• Caught yourself clicking through a browser or reading screenshots → that's evidence-gathering; brief a delegate. A flow is a slice — one glance, or a taste call on the final UI, is judgment: keep it.
• Hard tripwire, because "caught yourself" fails silently: three consecutive hands-on tool calls that aren't verifying a delegate's returned result mean you are diagnosing, and diagnosis is a slice — stop and brief it out with everything the probes established so far.
• Keep conclusions; drop transcripts.

Setup

Everything above degrades gracefully with no setup, but don't let the fallback stay silent: if you ran without the named roster, offer once, at the end of the run, to install it — the skill ships it in agents/, and scripts/setup-roster.sh places it in one command. For the rest — the Codex CLI, the companion skills (tdd, planning-with-files), orchestrator model and effort — read references/setup.md when the user asks for setup.