delegate-skills

Create your fleet of lanes. One orchestrator, the right implementer for every job.

Discover the implementer CLIs already installed on your machine, organize them into lanes like feature, tests, and ui, then delegate by lane — or choose one implementer directly. Either way, you keep the review and the commit.

npx skills add amElnagdy/delegate-skills

Then ask your orchestrating agent to create the fleet:

Use $delegate-setup to discover my installed implementer CLIs and create a fleet for feature, tests, and UI work.

Or delegate directly:

Use $codex-delegate to have Codex implement the refactor in services/billing/, then review and commit it.

flowchart LR
  S["$delegate-setup<br/>discover → propose → approve"] --> F["Example fleet"]
  O["Your orchestrator"] --> F
  F -->|"feature"| A["OpenCode"]
  F -->|"tests"| B["Codex"]
  F -->|"ui"| C["Cursor"]
  A --> R["Review the diff<br/>Run the gates"]
  B --> R
  C --> R
  R --> L["You land the commit"]

Choose how you delegate

Create a fleet

Skill	Job
`delegate-setup`	Discover installed CLIs, propose fleet lanes, and write global or project config after you approve. Never dispatches work.

A fleet is your set of named lanes. Each lane binds a kind of work to one implementer and optional dials such as model, effort, or variant. Setup discovers what is available, proposes a compact fleet, shows you the complete configuration, and writes only after explicit approval.

Configuration can apply globally or to one repository. Once it is ready, dispatch with the matching *-delegate skill and --lane <name>. Explicit flags override lane dials, and the wrong implementer skill for a lane fails loud. Project config is content-bound to explicit setup approval, so cloned or edited project lanes fail closed until re-approved. See the delegate-fleet.v1 schema for paths, supported dials, and overlay behavior.

Delegate directly

Skip setup when you want one implementer or one-off dials. Pick the skill for a CLI you have:

Skill	Implementer CLI	Write access (default)	Read-only run	Resume
`aider-delegate`	Aider (`aider`) — any OpenAI-compatible endpoint, including a local or self-hosted model via `--api-base`	`--yes-always` with `--no-suggest-shell-commands`; no sandbox or permission modes; commits force-disabled ¹	`--read-only` (`--dry-run`)	`--resume-last` (chat history, per-worktree)
`agy-delegate`	Google Antigravity (`agy`)	Antigravity's own `permissions`; bypass opt-in	`--read-only` (`plan` mode)	`--resume-last`, `--conversation <id>`
`claude-delegate`	Claude Code (`claude`)	`acceptEdits` + explicit tool surface	`--read-only` (`plan` mode)	`--resume-last`, `--session <id>`
`cline-delegate`	Cline (`cline`)	`--auto-approve true` in act mode; upstream sandbox not configured by the relay	`--plan` + `--auto-approve false` (relay-enforced pair)	— (headless JSON resume unsupported)
`codex-delegate`	OpenAI Codex (`codex`)	`--sandbox workspace-write`	`--read-only`	`--resume-last`, `--session <id>`
`commandcode-delegate`	Command Code (`cmd`; `cmdc` on Windows)	`--yolo` — the only headless write state; no sandbox ²	`--read-only` (withheld tools + `plan`)	`--continue-last`, `--session <id>`
`cursor-delegate`	Cursor Agent (`cursor-agent`)	`--force`; `--no-force` withholds command approval	`--read-only` (plan mode)	`--resume-last`, `--session <id>`
`grok-delegate`	Grok Build (`grok`)	workspace-scoped; `--full-access` opt-in	`--read-only` — best-effort ³	`--resume-last`, `--session <id>`
`kimi-delegate`	Kimi Code (`kimi`)	`auto permission mode`, always	— ⁴	`--resume-last`, `--session <id>`
`opencode-delegate`	OpenCode (`opencode`)	agent `build` (`--model` required)	`--read-only` (agent `plan`)	`--resume-last`, `--session <id>`
`pi-delegate`	Pi (`pi`)	full local tools — no sandbox, no permission modes ⁴; project trust opt-in	`--read-only` (`read,grep,find,ls`)	`--resume-last`, `--session <id>`
`omp-delegate`	Oh My Pi (`omp`)	`--yolo` (`tools.approvalMode: yolo`); project `.omp` extras off unless `--approve`	`--read-only` (`read,grep,glob`)	`--resume-last`, `--session <id>`
`qoder-delegate`	Qoder (`qodercli`)	`auto` permission mode; bypass opt-in	`--permission-mode plan`	`--resume-last`, `--resume <id>`
`vibe-delegate`	Mistral Vibe (`vibe`)	`accept-edits`; `--full-access` opt-in	`--plan-only` (`plan` agent)	`--resume-last`, `--session <id>`
`copilot-delegate`	GitHub Copilot CLI (`copilot`)	`--allow-all-tools` opt-in; headless auto-deny otherwise	`--read-only` (`--mode plan`)	`--resume-last`, `--session <id>`
`warp-delegate`	Warp Agent CLI (`oz`)	full local tools — no sandbox, no permission modes ⁴	— ⁴	`--conversation <id>`
`zcode-delegate`	Z.AI ZCode (`zcode`) ⁵	`--mode yolo`	`--read-only` (`plan` mode)	`--resume-last`, `--session <id>`

Each skill name links to its SKILL.md, which owns that implementer's prerequisites, flags, and caveats. Building one for another CLI? Claim it first, then see CONTRIBUTING.md.

Install

Browse first:

npx skills add amElnagdy/delegate-skills --list

Install the package, the setup skill, or one implementer skill:

npx skills add amElnagdy/delegate-skills
npx skills add amElnagdy/delegate-skills --skill delegate-setup
npx skills add amElnagdy/delegate-skills --skill codex-delegate

To pin an installation, append an existing release tag as @vMAJOR.MINOR.PATCH. The Skills CLI installs by git ref, not by metadata.version in SKILL.md.

Install for a specific agent, or globally:

npx skills add amElnagdy/delegate-skills --skill codex-delegate --agent claude-code
npx skills add amElnagdy/delegate-skills --global

Works with any orchestrating agent the Skills CLI supports.

How delegation works

Whether you choose the implementer directly or through a fleet lane, every dispatch follows the same review-first loop:

Write a brief — self-contained task context; the implementer has no orchestrator chat history.
Dispatch it with the bundled relay.mjs.
Wait for completion — the relay writes a structured result.json.
Review the diff — re-run the project's gates yourself; pair with guard skills.
Land it — you commit, because committing belongs to the reviewer.

Use $claude-delegate to have a separate Claude Code session implement the parser fix, then review and commit it.
Use $opencode-delegate with --lane feature to implement the billing workflow, then review and commit it.
Use $codex-delegate to run this queue of migration tasks through Codex while I review each one.

Every relay speaks the same delegate-relay.result.v1 contract: status, exitCode, signal (with a host-killed hint when the OOM killer ends a run), the implementer's own final report, touchedFiles, and a session id where the CLI exposes one. Learn the loop once, swap the implementer freely.

You feel it when a bounded task — a migration, a mechanical refactor, a removal sweep — comes back as a clean diff with a structured report, and you land it after re-running the gates yourself instead of typing it all by hand.

What counts as an implementer skill

Four invariants hold for every *-delegate skill. They are also the bar for a new implementer:

A separate CLI edits a real working tree, and the diff is the deliverable. Not an API wrapper, not a gateway — an implementer whose work you can read with git diff.
The relay never commits. Committing belongs to the reviewer, always.
Node built-ins only. No dependencies, no network calls of its own, no credentials, no telemetry. The relay launches its implementer CLI and git, plus the platform process launcher where a Windows shim or a process-tree kill needs one.
Autonomy is stated in the CLI's own terms, and whatever it cannot enforce is said plainly — see the two footnotes above.

This is a loop, not a forwarder: a forwarder hands over one task and returns the output. Here you dispatch, poll, review, and land, across one task or a queue. It stays complementary to a vendor's own plugin or subagents — those coordinate inside one agent; this keeps the contract portable across orchestrators, with the commit on the reviewer.

delegate-setup is the setup-skill exception: it discovers CLIs and writes an approved fleet map, but never dispatches coding work.

Full checklist: CONTRIBUTING.md.

Requirements

For a *-delegate skill, its implementer CLI authenticated as you would at the terminal. Each implementer skill's SKILL.md carries its own install and login commands.
delegate-setup requires no implementer CLI; it discovers whichever ones are available.
Node 18+ and git.
An orchestrating agent that can run shell commands and read files.
Shell examples assume bash/zsh (macOS/Linux, or Git Bash/WSL on Windows).

Trust and validation

This package is intentionally inspectable:

All skill content is Markdown, plus small Node scripts. Each *-delegate skill has exactly one scripts/relay.mjs. The delegate-setup utility ships discover.mjs / config.mjs / lane.mjs (and a shared implementer table) instead of a relay — it never dispatches coding work.
Those scripts make no network calls of their own, read or write no credentials, send no telemetry, and have no dependencies (Node built-ins only). Relays launch an implementer CLI and git, plus the platform process launcher/termination utility where a Windows shim or process-tree kill requires one. Discover may invoke installed CLIs for --version / model list probes (those CLIs may contact their own services). Read the script before you run it.
None of the relays ever commit — committing is always the orchestrator's job, after review.

Verification status — claims here are backed by runs, not assumptions.

True of every relay: argument handling, exit codes, result.json shape, supported resume mappings, and signal reporting are verified, along with each implementer-specific guard.

Per skill — platform, CLI version, and what the run exercised:

aider-delegate — Windows, aider 0.86.2: contract-tested against the shared smoke matrix, plus live headless --message-file runs against a stub OpenAI-compatible endpoint on loopback. Those runs covered: an applied edit left uncommitted, with a pre-existing dirty file still uncommitted, proving --no-auto-commits/--no-dirty-commits; no .gitignore written, proving --no-gitignore; a --read-only (--dry-run) run that left the target file byte-identical; an endpoint returning 401, where aider exits 0 and the relay reports failed with litellm.AuthenticationError; aider_unavailable/127 writing a result file; and usage errors exiting 2 without one. Review follow-ups were re-verified the same way: a successful run whose report says OPENAI_API_KEY three times still reports completed; a reused --out-dir seeded with another run's final.txt and result.json publishes neither; a plain exit 7 carries an error; and a --read-only run over a modified .aider.conf.yml plus generated history and tags-cache warns about exactly the config file. Not run against a hosted provider model or a real local inference server, and not run on macOS or Linux.
agy-delegate — Windows 10, native, agy 1.1.12: headless --print write run editing one briefed file; --read-only --effort high run whose brief ordered an immediate file write, in a directory the permission rules allowed: agy refused, wrote nothing, and result.json reported effort high, readOnly true, readOnlyViolation false; argument validation for a bad --effort value and for --read-only combined with --dangerously-skip-permissions, both exiting 2; resume by --conversation with a delta brief. macOS, agy 1.0.16: headless edit run, --print= delivery, absolute --add-dir workspace pin.
claude-delegate — macOS, claude 2.1.220: write run under acceptEdits; plan mode refusing an edit, with the Git tripwire true on a violation and false on a clean run; --session/--resume-last resume; claude_unavailable/127 and usage errors exiting 2 without a result file; deny rules and the shell sandbox blocking git commit, git push, git -C <dir> push, a nested claude, and a $HOME write.
cursor-delegate — Windows, cursor-agent 2026.07.23-e383d2b: write run under --force; plan-mode --read-only touching nothing; --session <id> resume applying a delta brief; usage errors exiting 2. A maintainer-run native macOS plan-mode smoke against the same version captured model, session, and usage with no touched files.
grok-delegate — macOS, grok 0.2.101: streaming-json report capture, file-based brief delivery, resume; read-only is best-effort by measurement, hence the violation flag.
kimi-delegate — macOS, kimi 0.24.0: headless -p edit run, stream-json parsing, and both resume paths — the relay's --session/--resume-last, which drive Kimi's own --session and --continue.
pi-delegate — macOS: stdin brief delivery, explicit provider and model selection, JSON session/provider/model/usage capture, and a --read-only run leaving a clean tree. Write, --session, and --resume-last runs are contributor-reported.
omp-delegate — contract-tested, live run pending: stdin brief delivery, omp --mode json argv (--yolo, --tools read,grep,glob, --no-extensions --no-skills --no-rules, --thinking), session header / message_end parsing, --approve omitting the project-trust flags, --continue resume, assistant stopReason: error reported as failed, omp_unavailable/127, and bounded --version preflight. Native Windows launch is a native omp.exe (no shell:true); that path is contract-tested via the smoke matrix's compiled fake, not against a live Oh My Pi install.
qoder-delegate — macOS, qodercli 1.0.47, by the contributor: Lite edit run, accept_edits, explicit model and 32768-token context window, no commit.
commandcode-delegate — macOS, cmd 1.26.0: live edit run verified. A relay dispatch against a throwaway git repository had Command Code fix a remainder-dropping bug in a money-splitting function and add three tests; the project gate was re-run independently by the orchestrator (2 tests before, 5 passing after), the diff matched the brief with no writes outside the two named files, and HEAD was untouched — the relay does not commit, and the run did not either. A second dispatch with --session <id> verified resume through the relay: a one-line delta brief amended exactly the comment it named, with the session id from the first run. A --read-only dispatch verified the other direction, returning readOnlyViolation: false on a clean tree. Also verified negatively: separate live runs confirmed --tools-all and --permission-mode auto-accept leave the headless write gate closed and only --yolo opens it.

Live running surfaced a CLI limitation the relay now handles. cmd ends a run with a run_end event embedding the whole conversation, then exits with process.exit, discarding whatever is still queued in its stdout pipe: both write runs lost their result line entirely (one cut ~8 KB into run_end, the other losing its last ~780 events). So nothing load-bearing is read from that tail — sessionId comes from run_start, the first line of the stream, and the report from the last message_end or its streamed deltas — the event log is written in batches so the relay drains the pipe as fast as it can, resultLine reports complete/truncated/absent so a consumer knows which fields are trustworthy. A complete non-success result converts a zero child exit to relay exit 1, while a lost result line falls back to the process exit code. Smoke cases pin that contract. On a long run the report itself can land in the discarded region. The diff is the deliverable, and a thin report means missing information, not a failed run.

Native Windows launch is contract-tested against the installed cmdc.cmd shape, including stdin brief delivery and the cmd.exe collision guard. A live native Windows Command Code run remains unverified; upstream recommends WSL for stable Windows use.
warp-delegate — macOS, oz 0.2026.05.27.15.44.stable_01: live edit run verified. A relay dispatch against a throwaway git repository had Warp add a function plus four assertions across two files; both project gates were re-run independently by the orchestrator, the diff matched the brief, and HEAD was untouched. Verified end to end: version preflight, launch, ndjson parsing (run_started → runId/runUrl, conversation_started → conversationId), report extraction from {"type":"agent","text":…} events with agent_reasoning excluded, touchedFiles, and status: "completed" / exit 0. A second dispatch with --conversation verified resume: a delta brief saying only "the function you just added" — never naming it — produced exactly the right edit, with resumed: true and the conversation id preserved. Also observed on a prior run: touchedFiles: [] on a clean tree and exit 1 → status: "failed". Two caveats are documented in the skill rather than fixed, because they are Warp's behaviour and not the relay's: finalMessage is the agent's full narration rather than a distinct final-message event, and --cwd governed shell commands while the agent's file tool resolved bare relative paths against $HOME. --no-snapshot, --profile, --skill, and --mcp are contract-tested only.
zcode-delegate — Windows, zcode 0.16.1: read-only (plan) run leaving a clean tree with the Git tripwire false; write run under yolo creating the briefed file and reporting it in touchedFiles; --session resume with an attached delta brief, which recalled the earlier turn; single-document --json parsing; --version preflight; discovery resolving the CLI from the app bundle rather than PATH; and environment-variable auth under all three names ZCode accepts — against an isolated home whose config carried no apiKey, a keyless run failed first, then ZAI_API_KEY, ZCODE_API_KEY, and ANTHROPIC_API_KEY each completed the same read-only dispatch. Contract-tested: build/edit rejection, the missing-CLI path, tolerance of the AI SDK banner that ZCode can print on stdout ahead of the JSON (observed in direct CLI probes; exercised in the suite by the fake), and the timeout matrix. The abort matrix is POSIX-only — Windows delivers no catchable SIGTERM — so for this relay it first runs in CI. zcode-delegate is also absent from the shared read-only tripwire scenario matrix, which runs claude and grok only — its tripwire helpers are parity-enforced byte-identical, but no zcode-specific worktree-state run is recorded. No macOS or Linux run is recorded.
codex-delegate — macOS, codex codex-cli 0.150.1: fresh workspace-write dispatch against a throwaway repo created the briefed file and reported it in touchedFiles, with status: "completed" and exit 0; a --read-only dispatch left the tree clean (touchedFiles: []) and returned a threadId; a follow-up --session <id> resume against that thread was asked to recall a word from the first turn without it being named again — the delta brief said only "the word you picked a moment ago" — and it answered correctly, confirming the resumed turn saw pri

…

delegate-setup

name: delegate-setup description: >- Configure delegation fleet lanes: which implementer CLI handles which kind of work, with optional model and effort (or variant) dials. Discovers installed CLIs, proposes a lane map for user approval, and writes global or project config only after explicit yes. Use when the user asks to set up, configure, or reconfigure delegation lanes, a fleet of lanes, or which implementer handles feature/tests/ui work — not for dispatching a coding task to an implementer. license: MIT compatibility: Requires Node 18+. No implementer CLIs are required — the skill discovers what is available. metadata: version: 0.5.0

Delegate Setup

You are the orchestrator in setup mode. Discover installed implementer CLIs, propose a fleet of lanes, and write configuration only after the user approves.

This skill does not dispatch coding work. It only authors the lane map.

One concept: lanes. Never say “routes.”

Example lane: feature → implementer opencode, model opencode/grok, variant high (OpenCode uses variant for reasoning intensity, not effort).

When NOT to use this

The user wants a task implemented — use the matching *-delegate skill instead.
A one-off model change on a single dispatch — pass --model / --effort / --variant on that relay.

Hard rules

Every lane must include implementer.
Put dials on the same object (model, effort or variant, …) only if that implementer supports them — see references/schema.md.
Show a human-readable lane table and the full JSON before every write; re-show after every tweak.
Write only after an explicit approval (“yes”, “approve”, “write it”).
Ask scope unless already clear: global (all projects) vs this repo only. Never create a project file just because cwd is a git repo. If there is no git repo, default to global and say so.
Do not invent model identifiers.
In interview or usage-scan mode, never write any dial the user did not give you and the schema does not require — omit it, so the CLI’s or relay’s own default applies.
Prefer 3–5 useful lanes over a kitchen-sink map.
Never edit AGENTS.md, CLAUDE.md, or other user agent-instruction files.
Never run a *-delegate relay from this skill.

(<skill-dir> is this skill’s install directory — the folder that contains this SKILL.md.)

Flow

discover → load → grounding menu → propose (with Basis) → scope → approve → write

1. Discover

node "<skill-dir>/scripts/discover.mjs"

Summarize installed vs missing, auth (true / false / null = unknown), and whether models were reported, aliases (curated aliases in the registry, not live discovery — full model names also work), unsupported, or failed.

2. Load existing (effective map)

node "<skill-dir>/scripts/config.mjs" load --cwd "$PWD"

Neither present → “No lanes configured yet.”
Otherwise → table of effective lanes with a Source column (global / project). Do not paste both raw files unless asked.
If projectPresent is true and projectTrusted is false, label the project lanes untrusted. They cannot dispatch until the user reviews and approves a project write.

3. Propose

Discovery reports capability, never task fit. So ask one grounding question before proposing anything — one question, three options, not a wizard:

How should I pick the lanes? (1) Quick defaults — I decide, no questions. (2) Interview — about four questions on how you want work allocated. (3) Usage scan — I re-read your CLIs’ local session folders (counts and dates only, never the conversations) and let the numbers place your lanes — if one CLI dominates, expect one question about its role. Happy to do 2 and 3 together.

Quick defaults → propose immediately.
Interview → the four questions (allocation policy, never model rankings) and how to ask them (one medium per round) live in references/setup-dialogue.md — read it before you ask.
Usage scan → node "<skill-dir>/scripts/discover.mjs" --usage. Tell the user it is metadata only before running it. Each discovered CLI gains usage: { sessions, lastUsed }; null means no probe is wired — unknown, not unused.
Both → run the scan first, then ask only what the numbers cannot answer.
Inside a git repo, repo signals (languages, test weight, frontend share) are a fourth source of evidence. They do not change the menu; they feed the proposal and the repo basis.

That menu is also the consent surface — the option chosen sets how much of the map is yours to decide:

Quick defaults — the user hired your opinion. A full map is legitimate, dials included; label every lane my opinion, say plainly that the map is your opinion, and keep it cheap to revise.
Interview / usage scan — evidence modes, so every dial is gated (rule 7): set one only from the user’s answer, or where the schema requires it (opencode lanes require model). Omitting is always safe — every dial has a default the user already lives with, and a CLI’s configured default is their standing choice, better evidence than your priors. Choosing which installed implementer gets a lane is still yours — Basis my opinion — but a dial that raises spend is not: offer your dial picks only as an addendum after the proposal, see references/setup-dialogue.md.
An unanswered question shrinks the map; it never licenses a substitution. Propose fewer, more conservative lanes, name the axis you are blind on (no quota answer → say the map is quota-blind), and invite the answer anytime. Re-ask once at most; never backfill silence with priors.

Delegation economics. The orchestrator reviews and lands every result — the review is the quality gate, so optimize total cost, not implementer prestige:

Prefer capable, authenticated, burnable, low-usage CLIs for bounded, objectively gated work (tests, mechanical refactors, straightforward fixes) when their reliability keeps review and rework economical — lanes push token burn away from the subscriptions the user is protecting. Low usage alone does not establish burnable: discovery cannot see plans, limits, or per-run cost, and a rarely-used CLI may be metered or deliberately avoided. Burnable comes from the user's quota answer — or, in quick defaults, from your labeled opinion.
Avoid binding a lane to a CLI the user is protecting or orchestrates from, by default; bind it only when the user asks for it or no acceptable alternative exists. Lanes are orchestrator-blind: the same lane fires from every seat the user drives from, and from that CLI's own seat it dispatches the CLI to itself.
Surplus placement breaks down when rework and review cost exceed the savings; when the implementer is flaky; when correctness rides on security, concurrency, migrations, or unstated domain knowledge; and when the output is the product (debate, architecture, research) — review limits damage, it does not manufacture a good first attempt. Bind those lanes to stronger implementers.
An explicit "spare X" answer removes X from proposed lanes by default, and overrides blanket posture answers on any lane the user explicitly retains for X — ask whether the posture applies there; omit the dial if unanswered. Never silently stretch one answer across an axis it conflicts with.

Question phrasings for the burn/spare and trust interview live in references/setup-dialogue.md.

Then propose the lanes. Name them after the work the user described; fall back to feature, tests, ui, fast, complex. Installed implementers only.

Show:

Lane	Implementer	Model	Effort / variant	Basis	Source (if updating)
feature	opencode	opencode/grok	variant: high	your answer + schema requirement	—
tests	codex	—	—	usage data	—
ui	claude	—	—	my opinion (implementer)	—

Basis is mandatory on every lane: your answer / usage data / repo / my opinion / schema requirement (a dial the schema forces is neither evidence nor opinion — say so). A lane you picked from model-quality priors is my opinion — never present it as something the tooling determined, and “installed and authenticated” is capability, not evidence of fit. When a lane’s implementer and its dials come from different places, split the label — see references/setup-dialogue.md.

Then the complete JSON (version: delegate-fleet.v1). One line of why per lane; flag auth or model uncertainty.

Schema and dial table: references/schema.md.

4. Scope

User said global / all projects / outside the project → global.
No git repo → global (say so).
Else ask once: global vs this repo only.

5. Approve and write

On explicit yes, write only the chosen scope (validate first). Build the payload from that scope’s raw file (or an empty lanes object if new) — not from the effective merged load view, or a project write will shadow global-only lanes and a global write will promote project-only ones.

Create a uniquely named file under the platform temporary directory ($TMPDIR, %TEMP%, or Node os.tmpdir(); never hard-code /tmp, which breaks on native Windows), write the exact approved JSON into it with the orchestrator's file-writing tool, and use that populated path as <lanes-json> below. Never validate an empty temp file. Remove the temp file after the validation/write attempt, whether it succeeds or fails.

node "<skill-dir>/scripts/config.mjs" validate "<lanes-json>"
node "<skill-dir>/scripts/config.mjs" write --scope global "<lanes-json>"
# or:  write --scope project --cwd /path/to/repo "<lanes-json>"

Re-read with load, then confirm the path written and the active lane names. Project writes bind approval to the exact config content; later changes fail closed until re-approved. On update, a short before/after is enough.

6. Ready to delegate

Stop after confirming. Tell the user the map is ready. For later work: read the lane’s implementer, load that *-delegate skill, and dispatch with --lane <name> (explicit --model / --effort / --variant still win when passed). Do not start a delegate task unless they ask.

Reconfigure

Same flow. Show the effective current map, propose changes, approve, write one scope’s file. Reinstalling the skills package must not rewrite these files — they live outside the package.

aider-delegate

name: aider-delegate description: >- Delegate a coding task to Aider (`aider`) as a background implementer, then review its diff and land it yourself. Use this whenever the user wants to hand implementation work to Aider - phrasings like "have Aider do X", "delegate this to aider", "run it through Aider", or "use Aider to implement/fix/refactor" - or wants to run a queue of coding tasks through Aider while staying the reviewer. This includes asking Aider to drive a local or self-hosted OpenAI-compatible endpoint ("have Aider use my local model", "run Aider against llama.cpp / Ollama / vLLM / LM Studio"), which Aider reaches via `--api-base`. DO NOT USE for local-model or coding requests that do not name Aider, for tasks small enough to do inline, or when the user wants the code written directly without delegating. license: MIT compatibility: Requires the `aider` CLI (`python -m pip install aider-chat`), Node 18+, and git. Aider must be able to authenticate to a model before dispatch - export the provider key it expects (`OPENAI_API_KEY`, `ANTHROPIC_API_KEY`, …) or set it in Aider's own config; a local OpenAI-compatible endpoint still needs a non-empty `OPENAI_API_KEY`. The orchestrating agent must be able to run shell commands and read files. Shell examples assume bash/zsh (macOS/Linux, or Git Bash/WSL on Windows). metadata: version: 0.5.0

Aider Delegate

You are the orchestrator. Hand a bounded coding task to a separate implementer - Aider - then review what it produced and land it yourself. You write the brief and own the judgment; Aider does the typing in its own run; you verify and commit.

The loop needs only a shell command and file access, so any comparable orchestrator can drive it.

The one thing to know about Aider

Aider commits by default. Two of its defaults would destroy the reviewable diff this skill exists to produce:

--auto-commits (default True) - Aider commits its own edits after each exchange.
--dirty-commits (default True) - Aider commits your pre-existing uncommitted work before it starts editing.

The relay always passes --no-auto-commits and --no-dirty-commits, and neither is configurable through it. If you ever drive aider by hand instead of through the relay, pass both yourself, or the work lands as commits you never reviewed. The relay also passes --no-gitignore, because Aider otherwise writes .aider* into .gitignore on startup and dirties the tree you are about to read.

When NOT to use this

The task is small enough to do inline; delegation overhead is not worth it.
The aider CLI is not installed, or no model is configured for it.
You want the implementer to manage its own commits. Aider can, but this skill deliberately turns that off - the diff is the deliverable.

Prerequisites (check once)

Install Aider - python -m pip install aider-chat, or the standalone installer from the Aider install docs.
Configure a model. Aider reads provider keys from the environment (OPENAI_API_KEY, ANTHROPIC_API_KEY, …) or its own config; see Aider's model docs.
Confirm aider --version succeeds.
Work in, or point --cd at, the target git repository.

Choose the model

Aider uses its own configured model when --model is omitted. Pass --model <name> to pick another.

Local and self-hosted models

Aider talks to any OpenAI-compatible endpoint, so this is also the skill for delegating to a model running on the user's own hardware - llama.cpp's server, Ollama, vLLM, LM Studio, or anything else that serves the same API. Pair --model with --api-base:

node "<skill-dir>/scripts/relay.mjs" --brief brief.txt --cd /path/to/repo \
  --model openai/<served-model-name> --api-base http://127.0.0.1:<port>/v1

Three things differ from a hosted provider:

The openai/ prefix is required. It tells Aider to speak the OpenAI protocol to your endpoint; the part after it is whatever name your server reports, not a provider catalog name.
A placeholder key is still needed. Export any non-empty OPENAI_API_KEY. The client library requires the header even when the server ignores its value.
Ask for a smaller edit format. Local models often fail Aider's default diff format, which requires exact search/replace blocks. --edit-format whole trades tokens for reliability; keep the brief's scope tight with --file so whole-file rewrites stay cheap.

A local endpoint that is not running looks like a hang, not an error: Aider retries the connection until the relay's --timeout watchdog fires and reports status: "timeout". Confirm the server is up before dispatching a long brief.

Staying offline

No account or provider registration is involved: Aider is a pip install, the endpoint is yours, and OPENAI_API_KEY only has to be non-empty. The relay pins the flags that would otherwise reach the network on their own - --no-check-update, --no-analytics (Aider's own default is random, which opts some sessions in by itself), and --no-detect-urls, without which Aider offers to scrape any URL in the brief and --yes-always accepts that offer silently.

--no-suggest-shell-commands closes the remaining path by which a run could reach the network without being asked to. What stays outside the relay's control is the brief itself: instructions that tell Aider to install a package or call an API will still be carried out, and --auto-lint runs the repository's own tooling. Offline here means nothing in the dispatch path reaches out on its own - not that a sandbox is stopping it.

The loop

Run these five steps per task. Steps 1, 4, and 5 require judgment; 2 and 3 are mechanical.

1. Write the brief

Aider sees only the text you send plus the files in its editing scope - no chat history or shared context. Include the goal, current state, what to change, what to leave untouched, the project's actual gates, and a report contract. Keep one task per brief. See references/writing-the-brief.md.

2. Dispatch

Use the bundled helper. It wraps Aider's headless --message-file mode, captures the run, and writes result.json. (<skill-dir> is the installed folder containing this SKILL.md.)

node "<skill-dir>/scripts/relay.mjs" --brief brief.txt --cd /path/to/repo
# choose a model:                        add --model <name>
# point at an OpenAI-compatible server:  add --api-base <url>
# scope the edit surface:                add --file <path> (repeatable), --read <path> for context only
# dry run, no files modified:            add --read-only
# continue the previous chat:            add --resume-last  (delta brief only)
# hard time limit (watchdog):            add --timeout 2h  (the 30m default suits short runs; implementation briefs routinely need 1-2h)
# see all options:                       node .../relay.mjs --help

The child process's cwd pins the workspace. The brief is delivered with --message-file, so it never rides argv: it stays out of the host process list and clear of the OS argument size cap. The relay writes artifacts under the system temp dir by default and never commits. See references/dispatch-and-poll.md.

3. Wait for completion

The helper blocks until Aider finishes. Run it with the orchestrator's background-command facility, or background it in the shell and poll for result.json. A pre-run usage error exits 2 and writes no result; a missing aider exits 127 and writes status: "aider_unavailable".

Trust process state and the working tree over a progress display. Completion means the process exited and result.json exists. Aider's report is the finalMessage field in result.json (also printed in full on stdout between the report markers).

Aider exits 0 even when it never reached a model, so the relay scans the run for Aider's own endpoint and authentication errors and reports status: "failed" when it finds one. Treat a failed status with an error mentioning the endpoint as a configuration problem, not a coding failure.

4. Review - do not trust the self-report

Treat Aider's final message and gate claims as claims:

Re-run the project's gates yourself.
Read the diff against the brief, starting with touchedFiles.
Run relevant guard skills if installed.
Round-trip migrations and grep for dangling references after removals or renames.

Aider's --auto-lint is on by default, so it may have already run a linter and fixed its own complaints. That is Aider's lint, not your gates - run yours anyway. See references/review-and-land.md.

5. Land it

The implementer edits the working tree; the orchestrator commits. Commit only after the gates pass and the diff holds. If rework is needed, send a delta brief with --resume-last, then review again.

Autonomy and permissions

The relay passes --yes-always, Aider's own term for auto-confirming every prompt, because a headless run cannot answer one. Understand what that consents to in advance. Auto-confirmation applies to every prompt Aider would otherwise raise, and Aider's prompts are not limited to file edits: left at its defaults it also offers to run shell commands it has suggested, and --yes-always would accept those with nobody reading them. The relay therefore pins --no-suggest-shell-commands, which removes that path.

What remains is not a sandbox, and nothing here pretends otherwise. Aider has no permission modes and no isolation: within its file scope it edits freely, and --auto-lint (on by default) runs whatever linter the repository configures. A brief that tells Aider to run a command still gets a command run. Delegation is the authorization; if a run must not be able to touch the host, run it in a container or a throwaway worktree, because no flag in this relay will give you that.

File selection is not a security boundary. --file, --read, and --subtree-only set what Aider puts in its chat context, which is a scoping and token-cost decision. They do not confine what it can reach. See references/writing-the-brief.md.

--read-only maps to Aider's --dry-run, which performs the run without modifying files. The relay does not independently verify that claim - it reports what git status --porcelain shows and warns if a --read-only run left the tree changed. touchedFiles and the diff, not a flag, are the guarantee.

Resume

Aider has no session ids. Its resume unit is the chat history file it keeps in the repository (.aider.chat.history.md), so --resume-last maps to Aider's --restore-chat-history and --history-file pins a specific one. Because that history lives in the repo, resume is per-worktree, not per-user: two clones of the same project do not share it.

Authorization model

Delegation is something the human opts into. Once they have ("run this queue", "proceed"), committing verified, gate-passing work is the agreed contract. Two limits remain: surface, don't absorb (report Aider's design decisions, defensible-but-unasked turns, and non-blocking nitpicks) and stop for scope changes (if correct completion needs going beyond the brief, ask instead of expanding the mandate). See references/review-and-land.md.

References

references/writing-the-brief.md - structure, report contract, real gates, file scope, and delta briefs.
references/dispatch-and-poll.md - flags, artifacts, result.json, polling, and failure recovery.
references/review-and-land.md - review checklist, the commit boundary, and rework through Aider's chat history.
references/multi-task-queues.md - sequential queues, constraint carry-forward, progress tracking, and the final coherence pass.

agy-delegate

name: agy-delegate description: >- Delegate a coding task to the Google Antigravity CLI (`agy`) as a background implementer, then review its diff and land it yourself. Use this whenever the user wants to hand implementation work to Antigravity or agy - phrasings like "have Antigravity do X", "delegate this to agy", "run it through agy", or "use Antigravity to implement/fix/refactor" - or wants to run a queue of coding tasks through agy while staying the reviewer. DO NOT USE for tasks small enough to do inline, or when the user wants the code written directly without delegating. license: MIT compatibility: Requires the `agy` CLI installed and authenticated, Node.js, and git. The orchestrator must be able to run shell commands and read files. Shell examples assume bash/zsh (macOS/Linux, or Git Bash/WSL on Windows). metadata: version: 0.5.0

Antigravity Delegate

You are the orchestrator. This skill lets you hand a bounded coding task to a separate implementer - the Google Antigravity CLI (agy) - then review what it produced and land it yourself. You write the brief and own the judgment; Antigravity does the typing in its own conversation; you verify and commit.

Nothing here is specific to one orchestrating agent. The loop needs only the ability to run a shell command and read a file, so any comparable agent can drive it. It is designed for and run on Claude Code; treat other orchestrators as designed-for, not yet proven.

When NOT to use this

The task is small enough to just do inline - delegation overhead is not worth it.
The agy CLI is not installed or not authenticated. Install it from Antigravity's CLI docs and run the first-launch setup.
You want to write the code yourself, or you only need Antigravity's opinion on code you wrote (a --read-only dispatch covers review without edits, but a plain review may not need delegation at all).

Prerequisites (check once)

agy help succeeds. If not, install the Antigravity CLI and complete first-launch setup.
agy models succeeds. That proves the CLI can authenticate and list the available model labels.
You are in (or will point --cd at) the target git repository.

These checks do not prove that a headless write will be approved. In --print mode, Antigravity cannot prompt for a write permission and may auto-deny it. The relay detects that denial instead of reporting completion.

Choose the implementer model

agy has a configured default model, so --model is optional. Use it when the human has a preferred Antigravity model label for the task. Otherwise let Antigravity use its own current default rather than guessing.

The loop

Run these five steps per task. Steps 1, 4, and 5 are your judgment; 2 and 3 are mechanical.

1. Write the brief

Antigravity sees only the text you send plus what it can inspect in the workspace - no chat history, no shared context. Everything the task needs goes in the brief: the goal, the current state, what to change, what to leave untouched, the project's actual gate commands, and a report contract. Tell Antigravity it will not commit (you will). Keep one task per brief. Full guidance and a template: references/writing-the-brief.md.

2. Dispatch

Send the brief to Antigravity with the bundled helper. It wraps agy --print, captures the run, and writes a structured result.json - so your only job is "run a command, read a file." (<skill-dir> below is this skill's installed directory - the folder containing this SKILL.md.)

node "<skill-dir>/scripts/relay.mjs" --brief brief.txt --cd /path/to/repo
# choose a model label:                 add --model "<label from agy models>"
# reasoning effort (low, medium, high): add --effort high
# read-only (plan mode — no edits):     add --read-only
# enable Antigravity terminal sandbox:  add --sandbox
# resume the most recent conversation:  add --resume-last  (delta brief only)
# see all options:                      node .../relay.mjs --help

The helper starts a fresh Antigravity project by default and passes --add-dir <repo> (the --cd path, absolute) so agy has an explicit workspace. It does not pass --dangerously-skip-permissions by default. Mechanics, flags, and the result.json shape: references/dispatch-and-poll.md.

3. Wait for completion

The helper blocks until Antigravity finishes, so back it with whatever your orchestrator offers and resume when it returns:

Claude Code: run the Bash call with run_in_background: true; you are notified on completion.
Plain shell / other agents: run it in the foreground for short tasks, or background it and poll the result file.

Do not trust progress trackers over reality: a run is finished when result.json is written and the process has exited. Read the working tree, not a status line. The implementer's full report is the finalMessage field in result.json (also printed in full on stdout between the report markers).

4. Review - do not trust the self-report

Antigravity's result.json includes its own final message and any gate claims. Re-verify, don't accept:

Re-run the project's gates yourself (the test/lint/build commands from step 1).
Read the diff against the brief: did Antigravity do what was asked, nothing more and nothing less? touchedFiles in the result is your starting point.
Run the relevant guard skills on the diff if you have them installed.
For schema/migration changes, round-trip them; for removals, grep for dangling references.

Full checklist: references/review-and-land.md.

5. Land it

The implementer edits the working tree; the orchestrator commits. Only after the gates pass and the diff holds:

Commit the verified work yourself, with a clear message.
If it needs changes, send a delta brief with --resume-last and review again.

Permission model

Antigravity owns its own permission policy. The relay does not bypass it by default. Use --dangerously-skip-permissions only when the human explicitly accepts that Antigravity may auto-approve tool permission requests. --read-only runs agy in plan mode (--mode plan), removing write and edit paths, and is mutually exclusive with --dangerously-skip-permissions. Use --sandbox when you want Antigravity's terminal sandbox enabled for the run. Antigravity's own help says --dangerously-skip-permissions auto-approves all tool permission requests without prompting, including a request to act outside the sandbox. Do not treat --sandbox as an enforced boundary when the flags are combined; treat the run as full access. If headless --print auto-denies a write, the relay reports status: "failed" and exits non-zero. The relay fingerprints the working tree before and after a --read-only run to report readOnlyViolation in result.json. Settings allow-rules are not documented here as a fix because they have not been demonstrated to apply to this headless path. Do not add the bypass flag without explicit human approval.

Authorization model

Delegation is something the human opts into. Once they have ("run this queue", "proceed"), committing verified, gate-passing work is the agreed contract. Two limits on that mandate: surface, don't absorb (report Antigravity's design decisions, defensible-but-unasked turns, and non-blocking nitpicks rather than silently keeping them) and stop for scope changes (if correct completion needs going beyond the brief, ask - don't expand the mandate yourself). The full treatment is in references/review-and-land.md.

References

references/writing-the-brief.md - how to write a brief Antigravity can execute blind: structure, XML blocks, the report contract, and real gate commands.
references/dispatch-and-poll.md - relay.mjs flags, the result.json contract, backgrounding per orchestrator, and recovery when a run misbehaves.
references/review-and-land.md - the review checklist, the commit boundary, and the rework cycle via --resume-last.
references/multi-task-queues.md - running a sequential queue: carrying constraints forward, progress tracking, and the end-of-run coherence check.

claude-delegate

name: claude-delegate description: >- Delegate a coding task to a separate Claude Code CLI process or another Claude session as an implementer, then review its diff and land it yourself. Use only when the user explicitly asks to delegate implementation to Claude Code, another Claude session, or the `claude` CLI — for example, "have another Claude implement this", "delegate this to Claude Code", or "run this queue through a separate Claude session." Do not trigger merely because the current orchestrator is Claude, and do not use when the user asks the current Claude to implement directly without delegation. license: MIT compatibility: Requires the `claude` CLI (Claude Code) installed and authenticated, Node 18+, and git. The orchestrating agent must be able to run shell commands and read files. Claude's shell sandbox requires macOS, Linux, or WSL2; native Windows launch is pending verification. metadata: version: 0.5.0

Claude Delegate

You are the orchestrator. Delegate one bounded coding task to a separate implementer — a Claude Code CLI session — then review what it produced and land it yourself. You write the brief and own the judgment; the separate Claude session edits the working tree; you verify and commit.

This skill is not a signal for the current Claude to implement directly. Use it only after the human explicitly asks for delegation to another Claude Code process or session.

When not to use this

The human asked the current agent to implement the task directly.
The task is small enough to do inline and the human did not request delegation.
The claude CLI is missing or unauthenticated (claude auth status).
The task needs a stronger host boundary than Claude Code's tool permissions and shell-only sandbox provide. Use an isolated container or VM for that requirement.

Prerequisites

claude --version succeeds.
claude auth status reports an authenticated session. On macOS the live credentials sit in the login Keychain; when the orchestrator's own sandbox blocks Keychain access (Codex's sandbox does), claude falls back to a possibly stale credentials file and reports loggedIn: false even though the login is valid. Re-run the check — and the dispatch itself — with that sandbox escalated or outside it before concluding the CLI is unauthenticated.
The target repository is the directory passed with --cd.
On Linux/WSL2, Claude's sandbox dependencies are installed. The normal relay profile is configured to fail when the sandbox is unavailable instead of silently running shell commands unsandboxed. Existing merged settings can still affect the effective boundary.

The loop

1. Write the brief

The separate session has no orchestrator chat history. It receives the brief on stdin and can inspect the target working tree.

Claude Code automatically discovers the target project's CLAUDE.md and normal local Claude configuration because the relay does not use --bare. It does not generically auto-load AGENTS.md. Read AGENTS.md yourself and copy every load-bearing constraint and the real gate commands into the brief. Tell the implementer not to commit. Keep one task per brief.

Template and details: references/writing-the-brief.md.

2. Dispatch

node "<skill-dir>/scripts/relay.mjs" --brief brief.txt --cd /path/to/repo
# review/diagnosis only:                 add --read-only
# continue the latest session:           add --resume-last
# continue the recorded session:         add --session <id>
# choose limits:                         add --max-turns 40 --max-budget-usd 10
# hard relay deadline:                   add --timeout 2h
# inspect every option:                  node .../relay.mjs --help

<skill-dir> is this installed skill directory, the folder containing this SKILL.md.

The relay runs claude -p --output-format stream-json --verbose, sends the brief through stdin, and writes artifacts under the system temp directory by default. It never uses --bg or --bare, and it never commits. See references/dispatch-and-poll.md.

3. Wait

The relay blocks until Claude exits. Use the orchestrator's background-command facility, or run it in the foreground and wait. Completion means the process exited and result.json exists.

A pre-run usage error exits 2 and writes no result.json.
A missing claude exits 127 and writes status: "claude_unavailable".
Timeout and caught relay signals terminate the whole implementer process tree and preserve an outcome artifact.

Read finalMessage, touchedFiles, resultSubtype, and the raw artifact paths from result.json.

4. Review

Treat the implementer's report and gate outcomes as claims:

Review edits to existing tests before a green gate means anything.
Re-run the project's actual gates yourself.
Read the complete diff against the brief, starting with touchedFiles.
Inspect untracked and staged content as well as the ordinary diff.
Run relevant guard skills if installed.

Full checklist: references/review-and-land.md.

5. Land

The orchestrator commits only after the gates pass and the diff holds. For rework, resume the same Claude session with a delta brief:

echo "Keep the implementation, replace the mocked DB test with the migrated fixture, and remove the
unused import." | node "<skill-dir>/scripts/relay.mjs" --session <id> --cd /path/to/repo

Review a resumed run exactly like the first run.

Permission profiles

The normal profile is deliberately explicit:

acceptEdits permission mode.
Built-in tools restricted to Read, Glob, Grep, Edit, Write, and the platform shell.
On macOS, Linux, and WSL2, Claude's shell sandbox is enabled with startup failure on missing dependencies and no unsandboxed retry. Commands that stay sandboxed are auto-approved so ordinary gates can run headlessly. The sandbox governs shell processes and their children only; merged local or managed sandbox settings can add effective paths or exclusions.
Configured MCP discovery and Claude.ai connectors are disabled, all MCP tools are denied, and skills, commands, and Claude's Agent tool are unavailable to the child. Project CLAUDE.md, hooks, normal authentication, session persistence, and other local settings still load.
String rules deny common direct shell forms of git commit, git push, and nested claude, plus any command containing claude-delegate. Aliases, scripts, and wrappers can bypass them, so they are only a speed bump; the brief's no-commit instruction and orchestrator review remain the boundary.

Native Windows does not support Claude's shell sandbox. The relay restricts the tool surface and pre-approves PowerShell so the run remains non-interactive, but that shell is not OS-isolated. Native claude.exe and npm claude.cmd launch paths are implemented; Windows verification is pending.

--read-only uses plan mode with only Read, Glob, and Grep. It removes edit, write, and shell paths, then compares parsed git porcelain and fingerprints the working-tree identity and index entries of Git-visible paths that were already dirty. readOnlyViolation is true when either signal proves a change, false when coverage is complete and detects none, and null when coverage is incomplete. This is a reporting tripwire, not an OS boundary: ignored paths and perfect restores are outside it, local hooks can write, and concurrent changes cannot be attributed to Claude.

--dangerously-skip-permissions is an explicit opt-in to Claude's bypassPermissions mode. The restricted tool surface, direct commit/push deny rules, and supported-platform shell sandbox remain, but direct file tools can cross normal permission boundaries. Use it only with the human's explicit acceptance.

Complementary to native Claude features

Claude subagents, agent teams, and background sessions are useful when the current Claude environment is already the orchestrator and native coordination is the goal. This skill is complementary: it provides a cross-orchestrator contract — self-contained brief → dispatch → artifacts → review → land — and keeps the commit with the orchestrator.

References

references/writing-the-brief.md — context, CLAUDE.md versus AGENTS.md, real gates, report contract, and delta briefs.
references/dispatch-and-poll.md — flags, profiles, artifacts, result.json, polling, and failure recovery.
references/review-and-land.md — generated-code review, the commit boundary, and session rework.
references/multi-task-queues.md — sequential queues, progress tracking, constraint carry-forward, and final coherence.

cline-delegate

name: cline-delegate description: >- Delegate a coding task to the Cline coding agent CLI (`cline`) as a background implementer, then review its diff and land it yourself. Use this whenever the user wants to delegate implementation work to Cline - phrasings like "have Cline implement X", "delegate this to cline", "run it through Cline", or "use cline to implement/fix/refactor" - or wants to run a queue of coding tasks through Cline while staying the reviewer. DO NOT USE for tasks small enough to do inline, or when the user wants the code written directly without delegating. license: MIT compatibility: Requires the `cline` CLI installed and authenticated with `cline auth`, Node 18+, and git. The orchestrator must be able to run shell commands and read files. metadata: version: 0.5.0

Cline Delegate

You are the orchestrator. Delegate a bounded coding task to a separate implementer - the Cline coding agent CLI - then review what it produced and land it yourself. You write the brief and own the judgment; the implementer makes changes in its own session in a clean working tree; you verify and commit.

The loop needs only a shell command and file access, so any comparable orchestrator can drive it.

When NOT to use this

The task is small enough to do inline; delegation overhead is not worth it.
The cline CLI is not installed or authenticated.
You require the relay to configure a sandbox. Cline exposes sandbox controls, but this relay leaves them to the CLI environment; use --plan when the run must be read-only.

Prerequisites (check once)

Install cline (npm or bundled binary; the relay probes cline --version).
Authenticate: run cline auth (interactive sign-in), or configure ANTHROPIC_API_KEY / an OpenAI-compatible base URL.
Confirm cline --version succeeds.
Work in, or point --cd at, the target git repository.

Choose the model (optional)

Cline picks a default model. To choose another, pass the separate --model <id> or --provider <name> (e.g. anthropic, openai-native, openrouter). The relay accepts letters, digits, and . _ : / - only (the value reaches a shell on Windows).

The loop

Run these five steps per task. Steps 1, 4, and 5 require judgment; 2 and 3 are mechanical.

1. Write a brief

Cline sees only the text you send. It cannot read your conversation: the brief must stand alone with the goal, current state, what to change, what to leave untouched, the project's real gates, and a report contract. Keep each brief to a single task. Write it to a file and pass it as the relay's --brief. See references/writing-the-brief.md.

2. Dispatch

Use the bundled relay. It runs cline --json -v, streams the brief on stdin behind a fixed positional instruction, captures the JSON event stream, and writes result.json.

node "<skill-dir>/scripts/relay.mjs" --brief brief.txt --cd /path/to/repo
# choose a model / provider:        add --model <id>  --provider <name>
# read-only planning pass:          add --plan   (forces --auto-approve false)
# deny approval-required tools:     add --auto-approve false
# hard time limit (watchdog):        add --timeout 2h   (the 30m default suits brief runs; most implementation briefs should be 1-2h)
# see all options:                   node .../relay.mjs --help

The child's cwd pins the workspace. The relay writes artifacts under the system temp dir by default and never commits. See references/dispatch-and-poll.md.

3. Wait for completion

The relay blocks until cline finishes. Run it with the orchestrator's background-command facility, or background it in the shell and poll for result.json. A pre-run usage error exits 2 and writes no result; a missing cline exits 127 and writes status: "cline_unavailable".

Completion means the process exited and result.json exists - trust process state and the working tree, not the progress display. Cline's final message is the finalMessage field of result.json.

4. Review - do not trust the self-report

Re-run the project's gates yourself.
Read the diff against the brief, starting with touchedFiles.
Run relevant guard skills if installed.

See references/review-and-land.md.

5. Land it

If the work is good, commit it. The relay never commits - the diff and result.json are the record; run git status and git diff first to confirm exactly what changed. If the group has a PR flow, make the commit and push a branch; let human review happen. If the diff is wrong or incomplete, re-dispatch a corrected brief in a fresh run and review again.

Autonomy and permissions

The relay explicitly passes Cline's --auto-approve, defaulting to true in act mode. Cline plan mode can request a switch to act mode, so --plan forces --auto-approve false; the relay rejects --plan --auto-approve true. That pair is the read-only gate. Cline also exposes sandbox through --data-dir / CLINE_SANDBOX, but the relay does not configure or override it. Plan-first for anything risky, then review the plan before a separate act-mode dispatch. Malformed or malicious briefs remain dangerous in act mode because commands run as the current user.

Authorization model

Delegation is something the human opts into. Once briefed, cline works as a tool you approved use of. The boundary is: do not accept conclusions from the self-report; verify everything on disk. For anything touching credentials, production data, or irreversible operations, stop and ask the human first instead of encoding it in a brief.

References

references/writing-the-brief.md - structure, scope, gates, brief delivery.
references/dispatch-and-poll.md - flags, artifacts, result.json, and failure recovery.
references/review-and-land.md - what to verify before calling the diff done, at the end of a run.
references/multi-task-queues.md - sequential queues, constraint carry-forward, progress tracking, and the final coherence pass.

codex-delegate

name: codex-delegate description: >- Delegate a coding task to the OpenAI Codex CLI as a background implementer, then review its diff and land it yourself. Use this whenever the user wants to hand implementation work to Codex — phrasings like "have Codex do X", "delegate this to Codex", "run it through Codex", or "use Codex to implement/fix/refactor" — or to run a queue of coding tasks through Codex while staying the reviewer. Prefer it over a one-shot Codex forwarder (such as the codex-rescue agent) when the user will review the diff and commit it themselves. DO NOT USE for tasks small enough to do inline, or when the user wants the code written directly without delegating. license: MIT compatibility: Requires the `codex` CLI (OpenAI Codex) installed and authenticated, Node 18+, and git. The orchestrating agent must be able to run shell commands and read files. Shell examples assume bash/zsh (macOS/Linux, or Git Bash/WSL on Windows). metadata: version: 0.5.0

Codex Delegate

You are the orchestrator. This skill lets you hand a bounded coding task to a separate implementer — the OpenAI Codex CLI — then review what it produced and land it yourself. You write the brief and own the judgment; Codex does the typing in its own sandbox; you verify and commit.

Nothing here is specific to one orchestrating agent. The loop needs only the ability to run a shell command and read a file, so it works the same whether you are Claude Code, OpenCode with a selected model, or any comparable agent. (It is designed for and run on Claude Code; treat other orchestrators as designed-for, not yet proven.)

When NOT to use this

The task is small enough to just do inline — delegation overhead is not worth it.
The codex CLI is not installed or not authenticated (run codex login).
You want to write the code yourself, or you only need a review (use Codex's own review command).

Prerequisites (check once)

codex --version succeeds. If not, install (npm i -g @openai/codex) and codex login.
Confirm which codex is on PATH. Multiple installs are common (e.g. a current npm/nvm copy and a stale Homebrew one). command -v codex shows the active one and codex --version its version — an old binary predates flags this skill relies on (codex exec --json, -o, exec resume). The relay also records the version it ran into result.json, so a stale binary is visible after the fact.
You are in (or will point --cd at) the target git repository.

The loop

Run these five steps per task. Steps 1, 4, and 5 are your judgment; 2 and 3 are mechanical.

1. Write the brief

Codex sees only the text you send — no repo memory, no chat history, no shared context. Everything the task needs goes in the brief: the goal, the current state, what to change, what to leave untouched, the project's actual gate commands (discover them from the repo's CLAUDE.md/AGENTS.md/Makefile — do not assume), and a report contract. Tell Codex it will not commit (you will). Keep one task per brief. Full guidance and a template: references/writing-the-brief.md.

2. Dispatch

Send the brief to Codex with the bundled helper. It wraps codex exec, captures the run, and writes a structured result.json — so your only job is "run a command, read a file." (<skill-dir> below is this skill's installed directory — the folder containing this SKILL.md, i.e. the directory you loaded the skill from. Claude Code prints it as "Base directory for this skill" when the skill loads; on other orchestrators use that same directory — if unsure where it landed, run find ~ -name relay.mjs -path '*codex-delegate*' and substitute the directory above it.)

node "<skill-dir>/scripts/relay.mjs" --brief brief.txt --cd /path/to/repo
# read-only (review/diagnosis, no edits):   add --read-only
# isolated review (skip ambient MCP/user config): add --ignore-user-config
# continue the exact Codex session:         add --session <threadId>  (from result.json; send only the delta brief)
# fallback when no thread id is available:  add --resume-last
# hard time limit (watchdog):               add --timeout 2h  (default: off; implementation runs routinely need 1-2h)
# see all options:                          node .../relay.mjs --help

The helper defaults to a write-capable (workspace-write) sandbox and writes its artifacts to a temp dir, so the repo under review stays clean. It never commits — see step 5. Mechanics, flags, and the result.json shape: references/dispatch-and-poll.md.

3. Wait for completion

The helper blocks until Codex finishes, so back it with whatever your orchestrator offers and resume when it returns:

Claude Code: run the Bash call with run_in_background: true; you are notified on completion.
Plain shell / other agents: run it in the foreground for short tasks, or background it and poll the result file — … & in bash/zsh (including Git Bash/WSL), or your shell's equivalent (Start-Job in PowerShell, start /b in cmd). The run is done when result.json exists with a status. (A pre-run usage error — bad args or an empty brief — instead exits with code 2 and a stderr message and writes no result file, so check the exit code too. A missing codex binary exits 127 but does write a result.json with status codex_unavailable.)

4. Review — do not trust the self-report

Codex's result.json includes its own summary and gate claims. Re-verify, don't accept:

Re-run the project's gates yourself (the test/lint/build commands from step 1). Never take "gates passed" on faith.
Read the diff against the brief: did Codex do what was asked, nothing more (scope creep) and nothing less? touchedFiles in the result is your starting point.
Run the relevant guard skills on the diff if you have them installed (clean-code-guard, test-guard, etc. from guard-skills) — this skill produces the work; those skills judge it.
For schema/migration changes, round-trip them; for removals, grep for dangling references.

Full checklist: references/review-and-land.md.

5. Land it

Because Codex's sandbox cannot reliably write .git (it varies by version, OS, and path), the orchestrator commits. Only after the gates pass and the diff holds:

Commit the verified work yourself, with a clear message.
If it needs changes, send a delta brief with --session <threadId> from the prior result.json (use --resume-last only when no thread id is available), and review again.

Read-only second opinions

The relay doubles as a clean way to get an adversarial second opinion with no write risk: dispatch --read-only with a brief that lists the agreed points, then each contested point with both positions, and ask Codex to defend or concede each — deliverable in its final message, touching no files. Any delegation skill whose implementer offers a read-only mode supports the same use, but check how hard that mode's guarantee is first: Codex's sandbox enforces it, while Grok's is best-effort and only flagged after the fact (readOnlyViolation) — for those implementers, verify touchedFiles came back empty instead of assuming no edits.

Authorization model

Delegation is something the human opts into. Once they have ("run this queue", "proceed"), committing verified, gate-passing work is the agreed contract — that is the whole point. Two limits on that mandate: surface, don't absorb (report Codex's design decisions, defensible-but-unasked turns, and non-blocking nitpicks rather than silently keeping them) and stop for scope changes (if correct completion needs going beyond the brief, ask — don't expand the mandate yourself). The full treatment is in references/review-and-land.md.

If you have the openai-codex plugin

The official openai-codex Claude Code plugin is excellent and complementary — codex-delegate builds on the same codex CLI, it doesn't replace the plugin. They point in different directions:

The plugin's codex:codex-rescue agent is a forwarder: it hands one task to Codex and returns the output. It deliberately does not poll, review, or commit.
The plugin's review command and stop-review gate run the inverse direction: Codex reviews your work.
codex-delegate is the orchestration loop in the other direction: you drive Codex to implement across one task or a queue, and you review and land each result. That loop — brief → dispatch → poll → review → commit, with the orchestrator owning the commit — is what the plugin leaves to you, and what this skill encodes.

If you have the plugin installed, its companion CLI is an optional alternative dispatch backend; the bundled relay.mjs is the default because it adds no install of its own beyond t

…

Aider is the one implementer here that commits by default. Its --auto-commits and --dirty-commits both default to True, the second of which commits your pre-existing uncommitted work before editing. The relay always passes --no-auto-commits and --no-dirty-commits, and neither is configurable through it. ↩
Command Code's headless mode has two states and nothing between them: a -p run withholds the write, edit, and shell tools, and --yolo (alias --dangerously-skip-permissions) allows every tool anywhere the process can reach. --permission-mode auto-accept and --tools-all do not lift the write gate. So an implementation run is full-trust with no path restriction — the brief's path list is guidance, not containment. A worktree isolates the checkout, while a container or another OS-enforced sandbox is required when writes outside the target tree are unacceptable. touchedFiles is a review aid based on git status; it cannot show ignored files or writes outside the repository. ↩
grok cannot be prevented from writing headlessly. The relay reports a tri-state readOnlyViolation tripwire for detected Git-visible changes; it does not enforce or attribute them. ↩
No CLI-enforced read-only mode. touchedFiles and the diff are what you review against, not a guarantee: they are post-run git status in the workspace, so they cannot show ignored files, reverted edits, or writes outside the repository. ↩ ↩² ↩³ ↩⁴
ZCode ships its CLI inside the desktop app — there is no zcode on PATH, no npm package, and the public docs cover only the GUI. The relay resolves it from --zcode-path/ZCODE_CLI, then PATH, then the installed app bundle. Of ZCode's four documented modes only plan and yolo work headlessly: build and edit have no permission client there, so they block every write tool and exit 0 having changed nothing, and the relay rejects them rather than report that as success. ZCode offers --disallowed-tools but no --allowed-tools, so capability can be subtracted, never enumerated. Where zcode login fails with OAuth response is not valid JSON, the key comes from ZCODE_API_KEY / ANTHROPIC_API_KEY / ZAI_API_KEY instead. ↩

Delegate Skills

Skill 详情

delegate-skills

Choose how you delegate

Create a fleet

Delegate directly

Install

How delegation works

What counts as an implementer skill

Requirements

Trust and validation

delegate-setup

Delegate Setup

When NOT to use this

Hard rules

Flow

1. Discover

2. Load existing (effective map)

3. Propose

4. Scope

5. Approve and write

6. Ready to delegate

Reconfigure

aider-delegate

Aider Delegate

The one thing to know about Aider

When NOT to use this

Prerequisites (check once)

Choose the model

Local and self-hosted models

Staying offline

The loop

1. Write the brief

2. Dispatch

3. Wait for completion

4. Review - do not trust the self-report

5. Land it

Autonomy and permissions

Resume

Authorization model

References

agy-delegate

Antigravity Delegate

When NOT to use this

Prerequisites (check once)

Choose the implementer model

The loop

1. Write the brief

2. Dispatch

3. Wait for completion

4. Review - do not trust the self-report

5. Land it

Permission model

Authorization model

References

claude-delegate

Claude Delegate

When not to use this

Prerequisites

The loop

1. Write the brief

2. Dispatch

3. Wait

4. Review

5. Land

Permission profiles

Complementary to native Claude features

References

cline-delegate

Cline Delegate

When NOT to use this

Prerequisites (check once)

Choose the model (optional)

The loop

1. Write a brief

2. Dispatch

3. Wait for completion

4. Review - do not trust the self-report

5. Land it

Autonomy and permissions