delegate-skills

A package of Agent Skills that each drive a different coding-agent CLI as an implementer while the orchestrating agent keeps the review and the commit. Every skill has the same shape: a brief written for a session that has no chat history, one scripts/relay.mjs that launches the CLI headlessly and polls it, four reference documents, and a result.json that speaks one shared contract — status, exit code, signal, the implementer’s own final report, the files it touched, and a session id where the CLI exposes one. Seventeen implementers ship today, from Claude Code, Codex and Cursor to Antigravity, Grok, Kimi, Qoder, Copilot, Warp and Command Code; a separate utility skill, delegate-setup, discovers which of those CLIs are installed and writes the fleet lanes. Nothing in the package commits, and where a CLI cannot be stopped from writing, that is stated in a footnote rather than smoothed over.

Who built itA personal account with a long contributor tail. The owner’s account carries 285 of the repository’s 390 commits — authored under two names, Ahmed Nagdy and Ahmed Mohammed, that share its verified emails — and 25 people have landed changes, the busiest with 23, 10 and 7 commits. Almost all of the work is co-signed: 99 commit trailers credit a model or a tool, most often Claude Fable 5, Claude Opus 5 and Cursor, and 377 of the 390 commits resolve to a GitHub account.

1. 01

   One skill per implementer, and a claim rule written after two wasted builds

   The repository was created on 2026-06-14 and its first commit added a single skill, codex-delegate, with the package scaffolding around it. Three months later it ships seventeen implementer skills plus delegate-setup, across 390 commits that thin out sharply at the end: 5 in June, 151 in July, 197 in August and 37 in September. The contribution record is wide for a personal repository — 102 pull requests of which 71 were merged, 38 issues of which 25 are closed, and 25 contributors, the busiest after the owner holding 23, 10 and 7 commits. CONTRIBUTING.md opens by explaining why it has a rule at all: two people had independently built the same delegate skill, twice, and both times somebody’s work was wasted, so an implementer is claimed in an issue before it is written. The claim template makes the claimant state the CLI’s exact non-interactive command, what a relay can parse out of its output, and how its autonomy is set, and says plainly that a claim is “not an assignment, not exclusive”. The merge checklist then decides between competing pull requests: the one satisfying more of it merges, ties break on verification evidence and then on the earlier claim, and the losing pull request’s distinct improvements are pulled in and credited by number in the commit that lands them.

2. 02

   Seven annotated tags in twelve days, and a unit of shipping that is one directory

   Releases here are git tags, not GitHub releases: there are seven of them and none is a published release object. All seven fall inside twelve days — v0.2.0 on 2026-08-04 at 18:07, v0.3.0 at 19:51, v0.3.1 at 20:33 and v0.4.0 at 21:55, four tag cuts in a single evening, then v0.4.1 the next morning, v0.4.2 on 2026-08-08 and v0.5.0 on 2026-08-16; September’s 37 commits produced none. CONTRIBUTING.md prescribes the ritual: land on master, set every skill’s metadata.version to the same semver, create an annotated tag and push it, because installers pin with npx skills add amElnagdy/delegate-skills@v0.2.0 rather than reading frontmatter. The two JSON contract ids, delegate-fleet.v1 and delegate-relay.result.v1, are versioned separately and bump only when a shape breaks. What makes the packaging decision load-bearing is that a skill is installed one directory at a time, with no bundler and no dependency graph, so skills/<name>-delegate/ has to load standalone — a plain cross-directory import would hard-crash a single-skill install. That constraint is why each of the relays carries its own copy of the shared helpers, and why a byte-parity test exists to police the copies instead of a shared source directory.

3. 03

   The relay never commits, and one implementer had to be stopped from doing it

   The organising rule is a division of labour: the implementer edits a real working tree and writes a structured result.json, then stops; the orchestrating agent re-runs the project’s own gates against the diff and makes the commit itself. The README states it as an invariant — the relay never commits, because committing belongs to the reviewer — and the same rigidity is applied to what a skill is allowed to claim. Three others sit beside it: a separate CLI must edit a real working tree so that git diff is the deliverable, the scripts use Node built-ins only with no dependencies, no network calls of their own, no credentials and no telemetry, and each CLI’s autonomy is described in that CLI’s own terms. The rule has a documented edge case that is not an exception to it: Aider commits by default, its --auto-commits and --dirty-commits both default to true, and the second will commit a user’s pre-existing uncommitted work before it starts editing. The relay therefore always passes --no-auto-commits and --no-dirty-commits and exposes neither as an option. The framing that ties it together is in the README: this is a loop, not a forwarder — a forwarder hands over one task and returns the output, whereas here you dispatch, poll, review and land, across a single task or a queue.

4. 04

   Seventeen CLIs, each described in its own terms, including where it cannot be restrained

   Seventeen implementer CLIs do not offer the same safety primitives, and the documentation declines to pretend otherwise. Command Code’s headless mode has two states and nothing between them: a -p run withholds the write, edit and shell tools, and --yolo allows every tool the process can reach, while --permission-mode auto-accept and --tools-all do not lift the write gate — so a brief’s list of paths is guidance rather than containment, and a container is the only real boundary. Kimi, Pi and Warp have no CLI-enforced read-only mode, so touchedFiles and the diff are what the reviewer checks against, not a guarantee. Grok cannot be prevented from writing headlessly; the relay reports a tri-state readOnlyViolation tripwire for detected Git-visible changes, and the footnote says it neither enforces nor attributes them. ZCode is stranger still: its CLI ships inside the desktop app, and of its four documented modes only plan and yolo work headlessly, because build and edit block every write tool and exit 0 having changed nothing — so the relay rejects those two rather than reporting a green run. Maintaining them individually is most of the work, and the disagreements are documented too: the OpenCode relay probes the installed CLI version before every dispatch, because 2.x passes a reasoning variant as model#variant while 1.x still takes --variant.

5. 05

   Ten near-identical relays, and the sampling error that changed the plan

   By early August the repository held ten relay.mjs files sharing 80 to 90 percent near-verbatim code; docs/plans/relay-core-dedup.md records how that was handled. Its own conclusion is that the problem is drift, not duplication: the shared helpers had quietly diverged, and a byte-check on 2026-08-04 found a null-guard in killChild present only in the Claude relay while nine others would throw, and the duration parser on a BigInt variant in eight of ten, with Antigravity and Pi on the Number variant. The document also keeps the failure of its own first version: that version had diffed the Claude relay against the Codex one and assumed the other eight matched Claude, when they matched Codex — which turned its supposedly behaviour-free batch into a behaviour change in nine files. The adopted shape was to reconcile the divergent bodies once, carrying the strongest behaviour forward — only Vibe had bounded the git status probe, and the canonical body now bounds it for all ten — then add a roughly sixty-line parity test asserting byte-equality, plus an isolated-install check that copies one skill directory alone into a temporary directory and runs relay.mjs --help there. The plan explicitly refuses a generator and shared fragments, leaves the one-off atomic-write copy inlined, and gives its reasons for each refusal so they can be revisited rather than relitigated.

6. 06

   What the failure reports produced, and what the project refuses to absorb

   The issues are concrete about how delegation breaks. Number 126 describes an implementer that exits normally while leaving a detached grandchild holding the stdio pipes: exit fires, close never does, and because every relay settles on close, the run produces no result.json at all — and the wall-clock watchdog is no help, either hanging with no timeout set or reporting a timeout for a run that succeeded. Number 125 is a disagreement kept in the open: a claim that Codex’s version preflight costs about four seconds per dispatch on Windows, answered with 126 to 163 milliseconds measured across eight runs, and a request for the other machine’s setup. Scope is defended just as explicitly. A proposal for a persistent orchestration layer above the fleet was closed with the reply that this repository ships one skill per CLI implementer plus delegate-setup, and that such a layer belongs in its own project; a second utility that would dispatch across implementers and fail over was closed the same way, citing the rule against inventing another utility; and issue 88 stays open as the design thread for that layer, where the proposer’s fleet of Claude, Codex, OpenCode and Antigravity lanes drew an answer from a companion project doing the same thing. The last commit is a merge on 2026-09-20; implementer pull requests for Devin, Kiro, Kilo and Muse are still open.