delegate-skills: one orchestrator, one implementer CLI per lane, and you keep the commit
Delegate a coding task to a separate coding agent CLI, review the diff, land the commit yourself — one per implementer.
At a glance
- What is it?
- delegate-skills is a set of agent skills that hands a coding task to a separate coding agent CLI, then leaves the diff review and the commit to you. It is aimed at engineers already running an orchestrating agent who want several implementers on tap without giving any of them the last word.
- Who is it for?
- Adopt delegate-skills if you already drive an orchestrating agent and want a per-lane mapping to whichever implementer CLIs are installed on your machine, with review and commit staying in your hands. Do not adopt it if you want a single CLI that owns the whole change, or if you work in a repository where project config cannot be re-approved after every edit.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap delegate-skills fills between your orchestrator and the implementer CLIs
Most teams now have more than one coding agent CLI installed. Codex, Claude Code, Cursor Agent, Aider, OpenCode and a dozen others coexist on the same laptop, and each has its own flags for write access, read-only runs and session resume. Picking one per task by hand means remembering which flag combination is safe, and it means the orchestrating agent has no stable way to say "send this to the tests implementer".
delegate-skills is a collection of skills, not a wrapper binary. The README describes two modes. In fleet mode, a setup skill discovers the implementer CLIs already installed, proposes named lanes such as feature, tests and ui, and writes configuration only after explicit approval. In direct mode, you skip setup and invoke the skill for one CLI, for example asking your orchestrator to use $codex-delegate. The audience is narrow and specific: people who already run an orchestrating agent and want delegation to be a named, reviewable step rather than an ad hoc shell command.
Lanes, dispatch skills and the fail-closed project config
A fleet is a set of named lanes. Each lane binds a kind of work to one implementer plus optional dials such as model, effort or variant. The README's own diagram shows the flow: delegate-setup discovers, proposes and waits for approval, then the orchestrator dispatches by lane to OpenCode, Codex or Cursor, each of which returns a diff that goes through review and gates before you land the commit.
Two mechanisms are worth calling out because they are the actual design decisions here. First, explicit flags override lane dials, and invoking the wrong implementer skill for a lane fails loud rather than silently substituting. Second, project config is content-bound to explicit setup approval, so cloned or edited project lanes fail closed until re-approved. That second choice has a real cost: any change to a checked-in lane file disables it until someone runs setup again. The README points to the delegate-fleet.v1 schema for paths, supported dials and overlay behavior, which is where the detail lives.
The per-implementer table is the most useful part of the documentation. It states, for each CLI, the default write access, the read-only invocation and whether resume is supported. Aider, for instance, runs with --yes-always and --no-suggest-shell-commands and has commits force-disabled. Command Code has only two headless states according to the README: a -p run withholds the write, edit and shell tools, and --yolo skips approvals. Kimi Code has no documented read-only run.
Installing delegate-skills and delegating your first task
The README gives a single install command through the skills CLI. It is an npx invocation, so there is no global binary to manage:
npx skills add amElnagdy/delegate-skillsAfter that, the setup path is a prompt to your orchestrating agent rather than a command. The README's example asks the agent to discover installed implementer CLIs and create a fleet for three kinds of work:
Use $delegate-setup to discover my installed implementer CLIs and create a fleet for feature, tests, and UI work.What you should see is a proposal: the discovered CLIs, a compact set of lanes, and the complete configuration shown before anything is written. Setup never dispatches work, and per the README it writes only after you approve. If you would rather not create a fleet, the direct route names one implementer and one task:
Use $codex-delegate to have Codex implement the refactor in services/billing/, then review and commit it.Either way the shape is the same: the implementer produces a diff, you review it and run your gates, and the commit is yours. Nothing in the README suggests the skills commit on your behalf, and for Aider the README states commits are force-disabled.
Where delegate-skills is the wrong tool
The write-access defaults are the sharp edge. Several implementers run with no sandbox and no permission modes at all: the README marks Pi, Warp Agent CLI and Command Code that way, with Command Code's only headless write state being --yolo. Aider has no sandbox or permission modes either. If your threat model requires a permission boundary between the agent and your filesystem, the delegate skill for those CLIs cannot give you one, because the underlying CLI does not have one to configure.
Read-only is also uneven. Kimi Code and Warp Agent CLI have no documented read-only run, and Grok Build's read-only mode is described as best-effort. So a lane that assumes read-only enforcement will not get it uniformly across implementers. Cline is another boundary case: the README says headless JSON resume is unsupported, so the resume column is empty for it.
The fail-closed project config is a genuine friction point rather than a safety feature you can ignore. Content-binding means a teammate cloning the repository, or you editing a lane, invalidates the lanes until setup runs again. For a solo repository that is a minor annoyance. For a team checking lanes into a shared repo, it is a recurring step that the README does not document a rollback or bypass for.
delegate-skills compared with a single agent CLI that owns the change
The obvious alternative is to pick one coding agent CLI and let it do the whole job, including the commit. That is what Claude Code, Codex or Cursor Agent do on their own, and it is simpler: one set of flags, one session model, one place where the diff appears. The difference in approach is who holds the review gate. A single CLI tends to run to completion, and the review happens after the fact against a commit that already exists.
delegate-skills inverts that. The implementer is a subprocess-like step that returns a diff, and the commit is a deliberate act by you. That is worse if you wanted the agent to finish the work end to end, and better if you want every change to pass through your eyes before it enters history. The fleet layer adds a second difference: instead of one model for everything, a lane can bind routine test work to a cheaper or faster implementer and UI work to a different one, with the wrong skill for a lane failing loud rather than quietly running.
A second alternative is writing your own shell wrapper around each CLI. That gives you full control and no schema to satisfy, but you reimplement the discovery, the lane naming and the per-CLI flag matrix yourself, and you lose the content-bound approval behavior unless you build it.
Maintenance, upgrade cost and the MIT licence
The repository is not archived, and the last push was on 2026-09-16, one day before this review. That is a recent push, so the project is being touched, though a single recent push does not by itself say anything about release cadence, and no releases were retrieved.
The upgrade cost is structural rather than versioned. There are no releases to track, so updates arrive as commits to the skills directory. Because the project is a set of skills rather than a library, an update can change the flags a delegate skill passes to an implementer CLI, and those flags are tied to whatever version of that CLI you have installed. The README's table is the contract you should re-read after an update, particularly the write-access column. If an upstream CLI changes its own permission model, the delegate skill for it is the thing that needs to catch up.
The licence is MIT, which permits use, modification and redistribution with the licence and copyright notice preserved. That is permissive and unsurprising for a skills collection. Nothing here is legal advice, and if you vendor the skills into a commercial product you should read the LICENSE file in the repository rather than this summary.
Editorial conclusion
Adopt delegate-skills if you already drive an orchestrating agent and want a per-lane mapping to whichever implementer CLIs are installed on your machine, with review and commit staying in your hands. Do not adopt it if you want a single CLI that owns the whole change, or if you work in a repository where project config cannot be re-approved after every edit. Before relying on it, verify that each implementer CLI you plan to use is installed and that the write access its delegate skill defaults to (for example --sandbox workspace-write for codex-delegate or --force for cursor-delegate) is one you are willing to run unattended.
Frequently asked questions
What are delegation skills in delegate-skills?
They are agent skills that hand a coding task to a separate coding agent CLI and leave the diff review and the commit to you. The README splits them into a setup skill that discovers installed CLIs and writes fleet configuration after approval, and per-implementer skills such as codex-delegate and cursor-delegate that dispatch one task.
What tasks can you delegate with delegate-skills?
The README's examples are a refactor in services/billing/ and lanes for feature, tests and UI work. Setup proposes lanes that bind a kind of work to one implementer plus optional dials such as model, effort or variant, and dispatch happens by lane name.
How do you install delegate-skills?
The README gives one command, npx skills add amElnagdy/delegate-skills. After that you either prompt your orchestrating agent to run $delegate-setup and approve the proposed fleet, or invoke an implementer skill such as $codex-delegate directly.
Does delegate-skills commit the changes for me?
No. The README's flow ends with you landing the commit after reviewing the diff and running the gates. For Aider specifically, the README states commits are force-disabled.
Why do my project lanes stop working after an edit?
Project config is content-bound to explicit setup approval, so cloned or edited project lanes fail closed until they are re-approved. The README describes this as deliberate behavior and points to the delegate-fleet.v1 schema for the details.
Community notes