Chris Parsons/delegatev1.0.73

delegate

Delegate bounded coding tasks to workers, with Astra or Fable coordinating scope, review, and integration. Load before dispatching coding subagents or background builds. Also use for finite model experiments, benchmarking, worker routing decisions, and picking a metered open-weight model when the subscription limits are spent.

by @chrismdp

What is airskills?

airskills is one home for your SKILL.md files. Standard format, no lock-in — back them up, publish them, and sync across your whole team in one command. Works with Claude Code, Cursor, Copilot, ChatGPT, and more.

Learn more about airskills →

Install this skill

Pick your agent. Free, no account needed for public skills.

One-liner with npx — installs to every detected agent on your machine (~/.claude/skills/,~/.cursor/skills/, and more).

$ npx airskills add chrismdp/delegate

Or install the Go CLI once: curl -fsSL https://airskills.ai/install.sh | bash

See all install options →Sign in to publish your own
---
name: delegate
description: Delegate bounded coding tasks to workers, with Astra or Fable coordinating scope, review, and integration. Load before dispatching coding subagents or background builds. Also use for finite model experiments, benchmarking, worker routing decisions, and picking a metered open-weight model when the subscription limits are spent.
---

Delegate — Coordinated Work and Bounded Model Experiments

Use Astra or Fable as the coordinator when available. The coordinator defines bounded tasks, selects workers, reviews their output, and owns integration and shipping. Delegate work when that improves delivery. Keep design decisions and final judgment with the coordinator.

Choose coordinator and worker roles by demonstrated ability to understand the whole assignment, not by a fixed subject specialism. The coordinator owns decomposition, dependencies and acceptance; a bounded worker can operate in any domain for which it has suitable context, tools and evidence. If Chris assigns work directly to a worker, bring its original brief and result into the coordinator's review so it does not become an invisible side task. Optimise for accepted outcomes and Chris's ability to leave the work in capable hands, including his attention and correction time in delivery cost.

Treat model capability and reasoning effort as separate choices (Chris, 2026-09-19). When coordinating at medium reasoning, use a fresh expert at higher supported reasoning for a second read of especially tricky work, conflicting evidence or consequential decisions. The expert may be the same model in a fresh context or another capable model, such as Astra or Fable. Give it the original task, constraints, relevant artefacts and the specific uncertainty to examine, rather than just the coordinator's conclusion. Select and record the supported effort setting explicitly; a role label does not change capability, and effort labels are not equivalent across providers. The coordinator evaluates the review and retains final acceptance and security judgement. Use this escalation where it adds value, not for every routine task; preserve explicit user model, provider and effort constraints.

One implementation per task by default. Model experiments are optional, bounded work with their own question, budget, and decision. Production work ships when its reviewed implementation and required checks pass. An experiment never holds up shipping, documentation, or issue updates.

Complete deliverables, fewer handoffs

Give one worker ownership of each bounded deliverable. Include its implementation or investigation, affected checks, evidence, and final report in the assignment. For evaluations, assign the agreed batch and comparison together. The coordinator makes the acceptance decision after the batch, rather than approving each run.

Use the cheapest worker that meets the task requirements. Reserve Astra or Fable workers for a named difficult question or consequential judgment. Parallel Astra workers can reduce elapsed time, but do not protect the coordinator model's usage budget.

Workers report completion, a genuine blocker, or a decision outside their brief. Put routine progress in the task report. The coordinator does not acknowledge routine updates or ask for status without evidence of a problem. This rule governs agent-to-agent messages. Keep Chris informed through normal user-facing updates.

Use completion notifications or the harness wait mechanism while workers run. Do independent work when available. Avoid sleep, status-check, and message loops that repeatedly invoke the model with the same growing history. When notifications are unavailable, check process completion at intervals suited to the job. Quiet output alone does not prove a stall.

Keep implementation ownership with one worker per area. Give reviewers a completed artifact and a specific question. Share findings when they change another worker's decision, rather than forwarding every progress update. Handle urgent correctness or safety findings immediately.

The First Question Is SURFACE, Not Difficulty (Chris, 2026-08-13)

Before routing anything, ask who ends up looking at the output. That, not how hard the ticket is, decides whether it gets delegated at all.

  • No human-visible surface, and you can verify the outcome yourself — a unit test, a curl against the dev worker, a query against the live telemetry, a row in a store. Delegate it whole, fire and forget, close on green. Refactors, internal stores, access gates, migrations, CLI tooling, test plumbing, redirect rules. Run these in the background, several at once, while the interactive session does something else.
  • A UX DESIGN call with nothing decided behind it — layout, placement, a new page or flow, an interactive surface, what a screen IS — is NOT delegated. It is built INTERACTIVELY with Chris, against a running dev server he can drive. His words (2026-08-13): "anything that needs me to QA or check UX or visuals on webpages or slack interactive I'll build with you using a local server setup." A delegated build satisfies "Chris reviews it before it lands" on paper by reporting well, and still fails this: he wants to watch the real thing while it changes. What lifts it is an artboard, not a better-written brief — the exemption is about where the DECISION was made.

Judge by what a human ends up seeing, not by which workspace the diff is in. A backend-only change that alters what a page shows is a UX ticket; a frontend-only change to a route's caching is not.

Why the split is drawn there (27agents, 2026-08-12): four delegated refactor tickets landed with zero QA defects, while every defect Chris found in live QA was last-mile presentation. Not one was a logic bug. Agents are reliable at logic and blind to what a person sees, because nothing in their loop renders it.

Copy is not a blocker (Chris, 2026-08-22)

His words: "I'm really happy for you to proceed and make small arbitrary decisions on copy. The artboard should always take precedence. I can always tweak things quickly there. If you're doing copy for agents then I'll send back evaluations who don't like the copy and you can loop on them and improve them there."

Wording is small, reversible and cheap for him to change, so it never blocks a ticket, never forces one interactive, and never gets parked for his eyeball. Three rules, in order:

  1. The artboard always wins. If a prototype shows the string, that string ships verbatim; copy on a prototype is real copy, not a placeholder to improve on. A worker that reworks it is overriding an approved design.
  2. Where nothing supplies the string, write it. Pick the obvious wording, ship it, and list in the report every string you composed. Do not stop and ask. Where the surface has an artboard, add the new string to it in the same change — Chris's tweak loop runs on the canvas, so the canvas has to hold what shipped.
  3. Copy an AGENT speaks is corrected by evals, not by him. Replies, prompts, tool descriptions, digests, result text: ship the wording, and a returned evaluation that dislikes it becomes a case you iterate against (27agents: /eval).

Delegating UX — the artboard is the entry condition (Chris, 2026-08-19)

UX work is delegable when the DESIGN is already fixed somewhere the worker can look: an artboard or prototype the brief names by path (a .dc.html, a design canvas, a static mockup), showing layout, placement and the words. Without one it stays interactive; with one, the brief must say all four of these:

  1. The prototype is the authority; the prose is a summary of it. Where they disagree, follow the prototype and say so in the report. ds4-295-remove-config had an approved Done.dc.html showing three periods as ONE combined bullet, read the brief's looser "one bullet per enabled period" literally, and shipped three.
  2. Follow its copy exactly, and never borrow a string from an unrelated surface (that run filled its three bullets with sentences lifted from a settings form). Compose only what the prototype leaves out, per Copy is not a blocker above.
  3. Name every surface the prototype covers, and check each one. 305-shared-settings moved a per-bot editor into the shared card against the artboard's placement and skipped Miriam's page; 306-settings-artboards shipped a web-only diff and missed two WORKER strings the change had made untrue. Both had artboards. Neither read all of them.
  4. Demand the ARTIFACT, not a claim about it. "The description no longer names email" is a claim; "here is the exact string this renders, verbatim" is evidence, and a lie is then sitting in the report in plain text.

A prototype settles the taste question — it does not defer it. If an artboard shows the layout, whether that layout feels right is ALREADY DECIDED and the worker builds it rather than evaluates it. So a prototyped UX ticket does not need a taste-7 worker — the taste was spent drawing the artboard; route it on the logic. What is still open is what the prototype does not cover: a state it does not draw, an error case, a surface it never shows. Ask when that gap is a design call; write it when the gap is only wording.

You Stay the Engineer of Record

You pick the work, write the spec-prompt, review the returned diff, run the AFFECTED gate yourself (see Which Gate below), own commit/push/CI. Never delegate the final review or security judgment.

Keep for yourself: anything whose design you can't fully spell out in the prompt, and security boundaries you haven't enumerated (the four-boundary tests can be delegated once YOU have named them).

Design work turning on decisions Chris hasn't made stays interactive (Chris, 2026-07-29). A subagent handed a design question returns a finished, defended design — and a finished design is something Chris reacts to rather than participates in, which is the wrong shape when the question is "what should this product be" rather than "what does this code do". The tell: the answer depends on his intent, not on anything discoverable in the repo. Split it instead — delegate the expensive reading (what the tickets say, where they contradict each other and the code, what each option forecloses downstream) as a spike that stops before deciding, then decide with him and write the doc from that conversation. Once a recommendation is on the table he is anchored, so the delegation has to end before the opinion starts. (2026-07-29: a fable agent was briefed to write the Em memory model doc and told to "be opinionated, make the recommendation and defend it" — Chris pulled it back to interactive.)

Verify the Gate Yourself — Every Worker, Every Time

A subagent claiming "done" is not evidence — verify the gate yourself, sonnet and opus included, not just Codex. Confirmed 2026-07-08 (same session): two separate Agent-tool workers — one sonnet, one opus — ended their turn without ever having actually run and confirmed the gate green. One's final message was "waiting on the npm run check monitor to report back" and then it just stopped; the other exited mid-gate with no pass/fail line at all. Neither had committed. A subagent's self-report is a claim, not a receipt.

Before trusting a branch or flipping any status: confirm there IS a commit (git log -1 on its branch/worktree), confirm the worktree is clean (git status --short), and re-run the gate yourself in that worktree (or after merging) rather than accepting "tests passed" prose at face value. If a subagent's final report doesn't quote the literal exit status / pass count of every gate step, treat the work as unverified until you've checked it yourself.

Which Gate — AFFECTED, not the whole suite

"The gate" in this skill always means the AFFECTED gate, never the full suite. Every repo defines two, and the repo's own CLAUDE.md is the authority on the exact commands:

  • AFFECTED — the tests the diff can actually reach, plus a typecheck for each area it touches. In a vitest repo that is --changed <base-ref>, which walks the module graph from the changed files. This is what an arm runs, and what you re-run to check the arm's claim.
  • FULL — the whole suite, every workspace. CI runs this on every push and is the backstop. Neither you nor an arm runs it locally without a specific reason.

Never put a suite-wide command in a brief — not npm run check, not npm test --workspace <name>, not a bare vitest run. This is the failure mode to watch for, because it does not look like one: on 2026-08-19 three arms were each running a seven-minute worker suite simultaneously on a four-core box, load average 22.8, all three still unfinished at fifteen minutes — because each brief had spelled the gate out by hand and reached for the whole suite. The cost is not paid by the arm that runs it; it is paid by every other arm on the machine.

"Scoped to a workspace" is not the affected gate. A workspace's test script usually carries no filter, so scoping that way is the full suite wearing a smaller name — the phrase reads cheap and is not. Only an explicit --changed or file list narrows anything.

scripts/worker_rules.md carries this for the worker; your job is not to restate the gate commands in the brief, but to name the base ref the arm should pass to --changed.

Agent-tool arms do not get those rules unless you paste them. codex_arm.sh appends worker_rules.md to the brief and pi_bench.py does the same for every arm it runs — but a sonnet/opus/fable arm dispatched straight through the Agent tool goes through neither, so it receives no gate rule, no don't-push, no don't-delegate. Append the contents of scripts/worker_rules.md to every Agent-tool brief, the same way the scripts do. This is exactly how a hand-written brief ends up spelling the gate out from memory and reaching for the whole suite.

Routing — Cost / Intelligence / Taste, Not Habit

Delegation is the default, not the exception (Chris, 2026-09-16; global CLAUDE.md "Delegate by default"). When the session runs on a Fable or Astra class model, its own usage is the scarce budget: hand every bounded coding, investigation or evaluation task to a cheaper worker and keep only design, briefing, review, the affected gate, real model/browser checks and release. The routing table below picks the worker; the question is never whether to delegate, only to whom.

The main channel is for orchestration only (Chris, 2026-09-17: "reserve the main channel only for orchestration and v quick tiny changes where it's quicker to do than to set up the delegate"). Orchestration means the brief, the dispatch, the review of the returned diff, the affected gate, the merge and the release. Everything else goes to a worker, including a change that touches several files, a copy change that lands on more than one surface, and any change with its own test. The one exception is a change so small that writing the brief would take longer than making it: a one-line fix, a config value, a status flip. If you are about to edit three files by hand, that is a worker's job. Caught the same day: the coordinator carried a saved artboard's wording into two more artboards and the shared copy source itself, and was told to hand it off.

Higher = better on every axis: cost is what you actually pay (higher = cheaper to run), intelligence is how hard a problem you can hand it unsupervised, taste covers UI/UX, code quality, API design, and copy.

model cost intelligence taste reach
gpt-5.6-sol 7 8.5 5 Codex CLI — codex exec -c model="gpt-5.6-sol" -c model_reasoning_effort="high" (Chris, 2026-07-29: use 5.6-sol, not 5.5; cost 7 not 9 — pricier than 5.5 was, so it is not free to run. The exact id is gpt-5.6-sol — bare gpt-5.6 400s on this account)
sonnet-5 5 5 7 Agent tool model: "sonnet"
opus-5/xhigh 4 8 8 Agent tool model: "opus" + effort: "xhigh"
fable-5.1 2 10 9 Agent tool model: "fable"
gpt-6-astra 3 10 8 Codex CLI — codex exec -c model="gpt-6-astra" -c model_reasoning_effort="high" (Chris, 2026-09-08, updated 2026-09-18 when fable-5.1 reached 10: same intelligence as fable, more token efficient, not as good at design; it is the default in ~/.codex/config.toml)

Workers are Anthropic models on the Anthropic provider, never OpenRouter (Chris, 2026-09-18: "ALWAYS use anthropic models from the anthropic provider NEVER openrouter — too expensive"). OpenRouter routes are metered per token; the Anthropic subscription is not. Concretely: pi agent files pin provider-qualified ids (anthropic/claude-sonnet-4-5), Codex workers ride the Codex subscription, and no worker brief names an openrouter/ model. This retires the metered OpenRouter lane measured on 2026-09-17/18 across tickets #447, #429 and #443; the experiment record lives in doc/openweight-delegation-experiment-2026-09-17.md in the 27agents repo.

When the pi subagent route to Anthropic is blocked (the provider answers 400 "Third-party apps now draw from your extra usage" — hit 2026-09-18), run the work through claude -p instead: claude -p --model fable --allowedTools Read < brief.md. The CLI aliases are fable, opus, sonnet — dated ids like fable-5.1 are NOT in the CLI's model catalog. Give the brief on stdin, bound it with --max-turns, and write output to a file (Chris, 2026-09-18: "just use claude -p then for these runs"). The claude CLI has no --cwd and cannot be spawned from inside a Claude Code session; from pi it is fine.

Astra or Fable coordinates experiments with other models. A candidate can receive a bounded implementation, investigation, or review task. For production work, the coordinator reviews and verifies the result before accepting it. Use isolated frozen tasks for independent comparisons. Read references/shadow-benchmarking.md before starting an experiment.

Judge total delivery cost. Token rates alone miss execution time, coordinator review, and corrections. Read the ledger at ~/vault/data/model-bench/runs.jsonl alongside the project delegation log. Preserve missing measurements as unknown. Compare completed outcomes under named models and harnesses. The benchmarking reference explains the limits of the summary report.

Defaults, not limits: standing permission to override without asking — if a cheaper worker's output misses the bar, redo it on a smarter one. Judge the output, not the price tag; escalating costs less than shipping mediocre work. Cost is a tie-breaker only; when the axes conflict on anything that ships, intelligence > taste > cost. Never use Haiku.

Work whose judgment is aesthetic needs taste ≥ 7: visual design, or an API shape other people will have to live with. Read that narrowly — a ticket that merely composes a string does not qualify, because copy is correctable after it ships (see Copy is not a blocker). An artboard removes the aesthetic judgment from the ticket, so the taste floor does not apply to it (Chris, 2026-08-19) — what is left is implementing what it shows. Route those on the logic, not the taste column. See Delegating UX above. Logic a user can reach but which makes no copy or design call — a redirect rule, an access gate, a migration, a record store, a CLI — is not a taste job. Read "user-facing" broadly and it swallows nearly every ticket in a product repo, which quietly disqualifies the cheap workers from everything.

Who builds what (cheapest worker that clears the bar wins):

  • Codex / gpt-5.6-sol (codex exec, see below) — the default worker, and it should be carrying a real share of the load. Two defaults, two scopes: scripts/codex_arm.sh pins gpt-5.6-sol for worker runs, and ~/.codex/config.toml sets gpt-6-astra as the CLI default for everything else, so pass the model explicitly when you want Astra as a worker. Chris's own framing (2026-08-03): it lands between opus and fable on intelligence, and cheaper than either. That is what the table's 8.5 means — reach for it on any well-specified slice on a STABLE spec that makes no copy or design call: clear-spec implementation, internal stores and APIs, CLI tooling, data analysis, migrations. Also root-cause debugging where the fix needs researching an external system's real behavior. Fire-and-forget — no mid-flight correction — and graded adversarially for its one failure mode neither Agent-tool worker has shown: weakening a test to make it pass rather than fixing the code (the review step below exists to catch it). That failure mode is also the one place to route around it: the tests guarding a security or privacy boundary are exactly where a quietly weakened assertion costs most, so either put those on opus/xhigh or diff every touched test file against its pre-change version before accepting.
  • model: "sonnet" / "opus" (Agent tool) — when you need to steer mid-flight (SendMessage a scope correction while it runs): sonnet for mechanical work (bulk edits, renames, test scaffolds, doc updates, broad searches), opus/xhigh for well-specified implementation slices and security-boundary work. Request xhigh on every opus dispatch — pass effort: "xhigh" (or state it in the brief where the surface doesn't expose it) and record opus/xhigh in the log; the default can silently drop to a lower tier (session effort, cron runs, harness changes), and the table's intelligence rating assumes xhigh.
  • model: "fable" (Agent tool) — top intelligence and top taste: the hardest well-specified slices and any surface where the judgment is aesthetic (taste ≥ 7). The premium option; reserve it for work that earns it.
  • z-ai/glm-5.3-flash / z-ai/glm-5.3 (pi through OpenRouter) — the metered pair, for code-only slices when the subscription limits are spent or the volume is high. Dispatch flash by default and escalate to 5.3 for a ticket that needs a verification rig, a judgment between paths, or a retry after flash has missed. Both need the coordinator to run the acceptance check, because in the measurement neither ever wrote a wrong implementation and both sometimes left a stated acceptance item undone beside a green gate. The taste ratings are estimated from logic work only, so neither takes a UI or API-shape ticket.

Keep dispatch simple. scripts/codex_arm.sh <label> <brief-file> [base-ref] prepares a worktree and starts a Codex worker. Use the current tool surface for other workers. Check dependency setup before dispatch instead of assuming that a launcher supplies it.

Experiments are on demand, not per delegation (Chris, 2026-09-18). Nothing in this section runs on an ordinary delegated change; it is the harness for a chosen comparison.

Bounded model experiments

Astra or Fable owns the experiment question, task boundaries, review, and final decision. The question is which tasks a model can handle usefully under that supervision. A worker does not need to outperform the coordinator to earn work.

Define the task or finite task batch, candidate model and harness, acceptance criteria, time and cost limits, and decision before dispatch. Include coordinator review and corrections in the budget. A small initial batch of 5–10 tasks is a screening option, not a required sample size.

Use one of these forms:

  • Supervised task: give a worker a bounded piece of useful work, then review and verify its result. Record help and corrections.
  • Focused review or investigation: ask a specific question with a concrete deliverable. Record whether its finding changed the implementation or decision.
  • Independent comparison: give candidates the same frozen task and starting source in isolated environments. The comparison can run after production work ships.

Read references/shadow-benchmarking.md for isolation, launchers, measurement, and grading. Keep experiments off the production dependency chain. At the budget limit, record the result and decide whether to use the model for that task class, revise the experiment, or stop.

Task Shape — Plan, Fix, Spike

Name the task shape before dispatch. Workers behave better when the brief names the mindset:

  • Plan/build — new behaviour from a stable spec. Worker writes red tests and code together, then lands a clean implementation slice.
  • Fix — existing behaviour is wrong. Existing tests must stay green and unchanged unless the defect lacks coverage; add a failing regression test first, then fix the code. Watch especially for workers weakening a test to make their patch pass.
  • Spike — read-only exploration. No production code, no reusable implementation, no opportunistic cleanup. The output is findings, options, and a proposed next spec/ticket.

If a run starts as a spike and discovers the build path, stop and write the follow-on spec/ticket. Don't let exploratory context turn into production code by drift.

Briefing — Every Worker Starts Cold

Point the worker at the canonical spec document — a ticket file, a design doc — in its own worktree and let it read the file. Don't write a parallel plan.md or restate the spec in prose. Add only what the spec doesn't already say: task shape (plan/fix/spike), the project's testing discipline (red-first), the relevant CLAUDE.md gotchas verbatim (a cold worker doesn't have your session's context), whether other parallel builds are running (demand a surgical diff if so), the gate command, the commit message format, and "do not push". If the repo has architecture.md, ARCHITECTURE.md, or ADRs, name them in the brief and require the worker/reviewer to check fit against them. Same spec, same brief, different worker — that's what keeps runs genuinely comparable.

Name every acceptance criterion in the brief, and require evidence for each one. A brief that states the criteria without insisting on them loses one: on 2026-09-18 every miss in the measured batch was an acceptance item the worker read, judged secondary, and left undone with a green gate beside it — a CI job cap never added, a detector that never loaded. Close the brief with the criteria as a checklist and the shape of the evidence for each: the exact test, the captured payload, the string that renders. It costs three lines, and it is the difference between a diff that passes and a diff that is done.

Brief template

Add these fields to the canonical task reference. Keep the brief self-contained without copying the coordinator conversation:

  • Deliverable and owner: the complete result this worker owns, including checks and report location.
  • Scope and decisions: what the worker can decide, what is excluded, and what requires the coordinator.
  • Inputs and dependencies: the spec, source or base ref, environment, and any dependency on another worker.
  • Acceptance evidence: the artifact or check for each criterion, plus the conditions that mean the task is complete.
  • Return conditions: completion, a genuine blocker with evidence, or a decision outside the brief. Routine progress needs no message.

Append scripts/worker_rules.md when the launcher does not supply it. For an evaluation batch, also name the fixed cases, controls, budget, and decision the results will inform.

Challenger coaching and review

pi_bench.py owns challenger coaching and the post-stop review pass. Before using or grading a challenger, read references/shadow-benchmarking.md; do not copy its coaching block into a brief.

This is the benchmark path, and it is OPT-IN (Chris, 2026-09-18). The coaching, the review pass and the ledger row ARE the experiment. An ordinary delegation is one pass with no ledger, and comparisons are run ad hoc, on demand. Reach for the benchmark form when you are deliberately comparing, not for every delegated change. The plain form is in Running an OpenRouter worker below.

Isolation and Landing

Every delegated build runs in its OWN git worktree, even a single sequential task (Chris, 2026-07-07): pass isolation: "worktree" to the Agent tool; for Codex, scripts/codex_arm.sh <label> <brief-file> [base-ref], which prepares the worktree and starts the run.

Prepare dependencies in the worker environment. Check the launcher and project instructions. Use a private install or copy where tools can modify dependencies. Shared writable symlinks let a worker damage another checkout. State the setup in the brief. A worker never edits the main working tree directly. After integration, run the affected gate against the merged change. Fix a failing guard instead of weakening it.

Worktrees are for CODE. A worker only writing tickets or docs doesn't need one (Chris, 2026-07-29) — no gate to run, no diff to review, nothing to conflict over, so the isolation buys nothing. Let it write in the main tree. What that costs you is git add -A: while any worker is in flight, commit explicit paths only, or a doc agent's in-progress file rides into an unrelated commit and is invisible until someone reads that commit later.

Never git merge --no-ff a worktree branch into main (Chris, 2026-07-09). Landing is always either a REBASE (rebase the worktree branch onto current main, then git merge --ff-only) or a SQUASH MERGE (git merge --squash <branch> then one commit). Both keep history linear, one real commit per landed change. If a worktree branch has several of its own commits (a build commit plus a hardening follow-up), squash them into the one landing commit rather than carrying the worktree's internal history onto main.

Land from the MAIN checkout, never from inside the worktree (2026-08-24, four times in one session). The rebase belongs in the worktree, because that is where the branch lives. The merge and the push do NOT. Run git merge --ff-only <branch> inside the worktree and git answers Already up to date, because HEAD there IS that branch; the following git push origin main then pushes the main tree's unchanged main ref and prints success. Nothing has landed, both commands look like they worked, and the only tell is a git log in the other directory. It happened on four separate tickets in one day to a coordinator who spotted it every time and repeated it anyway, because the rebase genuinely has to happen in the worktree and the hand carries on. Sequence: rebase in the worktree, cd back to the main checkout, merge and push there. If a --ff-only merge says Already up to date for a branch you know is ahead, you are in the wrong directory. Cleanup is part of accepting a worker, before the next dispatch or handoff. Once its change is reviewed, landed and the affected gate passes, preserve the commit/ref, report and required regression evidence outside the worktree. Confirm its processes have finished, then remove that owned worktree with git worktree remove; use git branch -d only for merged branches. Keep unmerged candidate refs and unresolved work. If cleanup must wait, record the reason and owner instead of silently accumulating directories. Workers leave cleanup to the coordinator.

Read-only investigations need no dependency copy. Coding workers need private writable dependencies; reuse download caches or supported copy-on-write clones. A completed worker's private dependency directory can transfer to one successor when package manifests, lockfile, runtime/platform and install configuration match; never share it between active workers. Otherwise remove reproducible dependencies/build caches after acceptance. --reflink=auto may silently make a full copy on unsupported filesystems. On9September2026,19 idle Storybook worktrees retained roughly12GB of dependencies; cleanup belongs to each task, not a later disk emergency.

A SHADOW's worktree is spent once it has been GRADED, not once it lands — because it never lands. The rule above says "after landing", and a shadow never lands, so it needs its own trigger. On 2026-08-07 a repo held 33 worktrees, 24 of them shadows, going back three weeks. The bench ledger is the record of a shadow run; the working directory is not. So the lifecycle is: arm runs → arm is graded into runs.jsonl → worktree goes.

Sweep with the script, not by hand — the same delete-the-setup logic that gave codex and the shadow their own one-command scripts. Cleaning up manually is exactly the friction that gets skipped:

scripts/sweep_worktrees.sh                 # dry run, shows what would go
scripts/sweep_worktrees.sh --yes           # do it
scripts/compress_logs.sh --yes             # gzip finished bench logs (dry run without --yes)

Bench logs are evidence, so they stay, but they stay gzipped. compress_logs.sh gzips every log in ~/vault/data/model-bench/logs/ that has been idle for a day and is not held open. On 2026-09-09 that directory held 35GB of plain JSONL and filled the disk. Run it with the sweep.

The sweep uses sentinels and commit age, which do not establish ownership or completion across sessions. Review its dry run before removing worktrees. It removes worktrees freely but only deletes merged branches — git branch -d refuses unmerged ones, so a graded shadow's diff survives as a ref, which costs nothing and keeps the evidence readable.

Before cleanup, read references/arm-safety.md and identify the worktrees this session owns. Clean up only those runs after their result and evidence are recorded.

For parallel fleets, treat landing as its own step. Keep divergence windows short: rebase/land completed branches frequently rather than letting 6–12 independent worktrees age against trunk. Enable and use git rerere where the repo has recurring conflict patterns; it records the conflict-resolution recipe and replays it when the same shape returns. Rerere is assistance, not authority: inspect the resolved diff, then rerun the AFFECTED gate after each merge before landing the next branch.

Running Codex

Run Astra (gpt-6-astra) through codex exec --yolo, never through pi (Chris, 2026-09-08). The Codex harness is tied to the model and gets more out of it than pi's openai-codex provider does. The same goes for every Codex model. Background a self-contained run against the worktree:

timeout 7200 codex exec --disable plugins --disable plugin_sharing \
  --yolo -C <worktree-dir> \
  -c model="gpt-5.6-sol" -c model_reasoning_effort="high" - < brief.txt

The trailing - reads the prompt from stdin (a scratchpad brief file — NOT a repo plan.md); --disable plugins --disable plugin_sharing keeps autonomous worker runs on the narrow code-editing surface even if the local Codex install has marketplace plugins enabled; --yolo grants danger-full-access + approval=never (codex 0.153); -C <dir> sets the working root. 2-hour cap — raised from 40 minutes (Chris, 2026-08-19), which a real multi-part ticket runs straight past. The cap is a guard against a runaway, not a budget: a run that hits it exits 124 and can leave unfinished work. Record a timeout as incomplete. For production work, recover the task as needed. For an experiment, stop at its declared budget and record a resumed attempt separately.

Run it as exactly that shape: one command, literal absolute paths, run_in_background: true. The allow rule Bash(codex exec *) in ~/.claude/settings.json is what lets this run without a permission prompt, and it matches each shell segment on its own. It strips a leading timeout (so no separate timeout rule is needed), but it cannot see past a variable assignment (S=/tmp/...;), a $VAR in a redirect target, a cd ... && prefix, or a trailing ; echo "exit=$?" >> log. Every one of those made the whole command fall to the classifier and prompt Chris (2026-09-09). Write the scratchpad path out in full for the brief and the log, and take the exit code from the background task notification instead of an echo.

codex exec resume has a DIFFERENT flag surface — do NOT copy the exec flags onto it: it takes [SESSION_ID] [PROMPT] plus -c/--last/--all, but NOT -C and NOT --yolo (passing either errors instantly), and it FILTERS sessions by cwd (so --last from a different dir finds nothing — run from the session's cwd, pass the SESSION_ID, or add --all). For a review-driven fix, prefer a FRESH codex exec with a self-contained brief (name the prior commit + files + exact changes) over resume — same result, none of the resume quirks; reserve resume for finishing a genuine mid-task timeout (exit 124, dirty tree).

Running an OpenRouter worker

An ordinary delegation to an OpenRouter model is ONE pi pass with the job boundary and no harness:

python3 ~/.claude/skills/delegate/scripts/pi_bench.py --plain \
  <label> <workdir> <brief-file> [model]

--plain keeps worker_rules.md (do not push, do not delegate, run the AFFECTED gate) and drops the coaching text, the review passes and the ledger row. It prints a token/wall/cost summary to stderr and the worker's final message to stdout. Without the flag the same command is a benchmark arm: coached, reviewed up to twice, and appended to the ledger. Background it and cap it with timeout the way the Codex command above does.

Review Before Merge

Review the surrounding surface, not just the diff. Delegated work reliably nails the spec but misses ADJACENT copy its change falsifies (a hardcoded default beside the new form, a docstring now wrong, a test it edited to match its own regression). Read outward from the diff before accepting — for Codex specifically, diff every touched test file against its pre-change version, not just skim for green.

A green suite does not prove the new thing is REACHED. Confirmed 2026-09-18, on two of six measured arms: each shipped a hang detector with passing unit tests, and neither ran on the command the ticket named. One registered it in a vitest project config, where vitest v4 never loads reporters from; the other wired a wrapper into the npm test script only, so a direct npx vitest run bypassed it. Tests written beside the code share the author's mental model and cannot see a wiring mistake. So for anything that must LOAD or FIRE — a reporter, a hook, a registration, a scheduled job, a config entry — the acceptance evidence is the artifact that proves it ran in the environment the ticket names, not a passing test. Run that probe yourself; a five-line probe reporter was what settled it.

Choose independent review based on the change's risk and uncertainty. Security or privacy boundaries, consequential architecture, and conflicting evidence warrant a fresh reviewer with a specific question. A routine bounded change does not automatically need separate review and smoke-test agents. The coordinator still reviews the diff, runs the affected gate, and obtains evidence that the changed behavior works. Delegate a separate runtime check when it adds evidence the existing checks cannot supply. Final acceptance and security judgment stay with the coordinator.

If the repo has a mutation-test command and the touched area is high-risk, run it before accepting agent-written tests. This is a targeted anti-gaming gate: mutation testing is too expensive for every slice, but valuable where a worker may have written tests that bless its own implementation rather than prove the behaviour.

Continuation and Parallelism

After a worker returns, review the complete result and send one consolidated correction brief if needed. Continue the same worker for a small correction in the same area when the harness supports it. A new substantial deliverable gets a fresh worker and a focused brief with the relevant commit, findings, and unresolved questions. Avoid inheriting the whole conversation.

Close the task once its result is accepted and complete the cleanup under Isolation and Landing. An idle worker with a completed report needs no nudge. If there is evidence of a stalled process or missing deliverable, inspect that evidence before resuming work. Use the current harness's supported continuation mechanism. For codex exec, follow the fresh-run and timeout guidance above.

Parallelize independent tasks as simultaneous worktree runs across any mix of workers; serialize only when two tasks must edit the same seam and the merge would be a rewrite rather than a resolution.

Delegation Log

For the next real job after a coordination change, record coordinator responses, worker follow-up dispatches, tokens by role and model, and accepted outcomes. Use existing session logs and the project delegation log. Distinguish cached input from other tokens and record missing measurements as unknown. Compare cost per accepted outcome, including corrections, rather than agent count. Ordinary tasks do not need a new benchmark harness or per-message ledger.

If the project keeps a delegation log (see its CLAUDE.md), append one entry per delegation — task, WORKER (opus/xhigh, sonnet, fable, codex), outcome, rework — failures as faithfully as wins. This is what makes a worker comparison honest instead of anecdotal.

Integration

  • /ralph — loads this skill before dispatching a ticket build; the ticket file is the worker's briefing.
  • Per-project policy — a project's own CLAUDE.md carries its rules (whether all non-trivial coding is delegated, where the delegation log lives); this skill owns the mechanics.

Launcher and worktree safety

Before changing a Delegate launcher script or sweeping worktrees, read references/arm-safety.md. It covers live-script edits, sentinel monitoring, and worktree ownership across sessions.

2.6 KB
3.8 KB
4.8 KB
2.2 KB
33.5 KB
3.9 KB
3.5 KB
1.6 KB
17.3 KB