# delegate-skills: Orchestrate Multiple Coding CLIs from a Single Agent

> delegate-skills is an MIT-licensed skill pack that lets a Claude Code or other MCP-compatible orchestrator discover, configure, and dispatch coding tasks to external CLIs such as Aider, Codex, Cursor, and 14 others. The user reviews the diff and lands the commit; the skill handles only the dispatch and handoff.

**amElnagdy/delegate-skills** — Delegate a coding task to a separate coding agent CLI, review the diff, land the commit yourself — one per implementer.

- Repository: https://github.com/amElnagdy/delegate-skills
- Website: https://www.skills.sh/amelnagdy/delegate-skills
- Stars: 2,278 · Forks: 187
- Language: JavaScript
- License: MIT
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/amelnagdy-delegate-skills

## The Problem delegate-skills Solves

When multiple AI coding CLIs are installed on a single machine, choosing which one to use for a given task is a manual decision made outside any agent session. An orchestrator running as Claude Code might hand off a refactor task to Codex, then separately decide to use Aider for a test-writing task, but that routing is ad hoc. There is no shared configuration that says which tool handles which type of work, and the developer must switch context manually each time.

delegate-skills introduces a fleet model to this problem. A fleet is a named set of lanes, and each lane binds a category of work to one implementer CLI with optional configuration dials like model choice or effort level. Once the fleet is set up, the orchestrator dispatches work to a lane by name rather than to a specific CLI directly. The skill resolves which CLI a lane maps to and invokes it.

The user's role is preserved at the review and commit step. The README states the design clearly: one orchestrator, the right implementer for every job. The delegate-setup skill discovers which CLIs are installed, proposes a compact fleet configuration, and writes the config only after explicit approval. It never dispatches work during setup.

Installing the skill pack requires one command:

```bash
npx skills add amElnagdy/delegate-skills
```

This installs all skills in the pack, including delegate-setup and each implementer-specific delegate skill.

## Fleets, Lanes, and the Setup Skill

The fleet configuration follows the delegate-fleet.v1 schema documented in skills/delegate-setup/references/schema.md. A fleet has named lanes, and each lane names one implementer and optionally sets dials such as model, effort, or variant. Configuration can apply globally or to a single repository as a project-scoped config.

The setup skill, delegate-setup, is the starting point. The README documents how to trigger it:

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

delegate-setup inspects the machine for installed CLIs, proposes a fleet matching the named work categories to detected tools, shows the complete configuration, and writes only after explicit approval. It makes no changes and dispatches no work during the setup run.

Project-scoped configuration is content-bound to the setup approval, meaning a cloned or manually edited project config file will fail closed until re-approved. This prevents accidentally running with a fleet config that was copied from another project or modified outside the setup flow.

Global config applies to all repositories on the machine. Project config overrides global config for the repository where it is placed. The schema documents the exact paths, supported dials, and overlay behavior.

## The Implementer Skill Table: 18 CLIs Covered

The README lists 18 implementer-specific delegate skills, each wrapping one CLI. The coverage includes Aider (any OpenAI-compatible endpoint, including local or self-hosted models via --api-base), OpenAI Codex, Claude Code, Cursor Agent, Cline, Grok Build, GitHub Copilot CLI, Kimi Code, OpenCode, Aider, Google Antigravity, Mistral Vibe, Z.AI ZCode, Pi, Oh My Pi, Command Code, Warp Agent CLI, and Qoder.

Each skill has a documented write-access mode (the default for running implementations) and a read-only mode (for reviewing without making changes). Most also support resuming a previous session by passing a session ID or requesting the last session. The table in the README specifies exactly which flags each CLI uses for each mode.

There are notable differences in sandboxing. OpenAI Codex's write mode uses --sandbox workspace-write, which restricts what the process can reach. Command Code's headless mode has only two states with nothing between: a read-only run that withholds write tools, and --yolo (aliased as --dangerously-skip-permissions) which allows every tool the process can reach with no path restriction. The README notes that for Command Code, a path list in the brief is guidance, not containment.

Cline also lacks a sandbox: the upstream Cline sandbox is not configured by the relay. Pi and Warp Agent CLI similarly have full local tool access with no sandbox or permission modes.

## Dispatching Work After Fleet Setup

After fleet setup, dispatching work to a specific implementer uses the lane-based dispatch syntax. The README example shows:

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

This invokes the codex-delegate skill, which runs Codex against the specified path, presents the diff to the orchestrator for review, and the orchestrator then runs any required gates before the user lands the commit.

With a fleet configured, the orchestrator can dispatch by lane instead of by a specific CLI name. A task routed to the feature lane goes to whichever CLI was assigned to that lane during setup. A task routed to the tests lane goes to the tests-assigned CLI. This allows swapping which CLI handles a lane type by updating the fleet config without changing the dispatch instructions.

The README describes a gate step before landing the commit: the orchestrator reviews the diff and runs any gates (tests, lint, type checks) that the project requires. This is a deliberate design: the implementing CLI handles the edit, the orchestrator handles review and verification, and the developer lands the commit. The implementing CLI is never given permission to commit directly under the default configuration.

## Permission Modes, Sandboxing, and Security Considerations

The README documents the write-access default and read-only mode for each CLI, alongside whether a bypass or full-access opt-in exists. Several patterns emerge from this table that matter for teams using delegate-skills in shared codebases.

For Claude Code, write access uses acceptEdits with an explicit tool surface, and read-only switches to plan mode. This is the most controlled of the supported CLIs from a permission standpoint. Cursor Agent uses --force for writes and --no-force to withhold command approval.

For CLIs without sandbox support (Pi, Warp Agent CLI, Command Code in yolo mode), the implementing CLI can access any file the process user can reach. The README notes this explicitly. Teams deploying delegate-skills in environments with sensitive files outside the repository directory should verify the write mode of each CLI before assigning it to a lane.

The worktree isolation mode, referenced in the schema documentation, provides an alternative: delegate work can run in a git worktree rather than the main checkout. The README notes this in the context of Command Code's containment behavior. The schema documentation at skills/delegate-setup/references/schema.md covers the full isolation options.

## Limitations: What the Fleet Model Cannot Do

delegate-skills does not provide version-locked or reproducible builds of the CLIs it invokes. Each CLI is called as it is installed on the machine. If a CLI is updated between sessions, the behavior of the delegate skill may change, because the --flags and modes the skill uses must match the CLI version installed.

The fleet configuration is per-machine and per-repository. A developer who works on multiple machines needs to run delegate-setup on each one separately. The README notes that project-scoped configuration is content-bound to setup approval, so copying config files between machines requires re-approval on each.

Cline's Headless JSON resume is listed as unsupported in the README table. This means Cline sessions cannot be resumed by session ID the way most other CLIs can, which affects workflows where a long implementation task might need to be paused and continued.

The alternative to using delegate-skills is invoking each coding CLI directly, with no shared lane routing or fleet configuration. This works well for developers who use only one CLI or who make the routing decision themselves at each task boundary. delegate-skills provides value specifically when two or more CLIs are in regular use and the routing decision should be codified rather than made ad hoc.

## Conclusion

Teams running multiple coding agent CLIs that want a structured way to route feature work, test generation, and UI changes to different tools are the right audience. Developers who only use a single CLI do not benefit from the fleet model. Before setting up a fleet, verify that the CLIs for your intended lanes are installed on the machine, because delegate-setup will only propose lanes for tools it can detect. The last push was on 2026-09-20.

## FAQ

### What implementer CLIs does delegate-skills support?

The README lists 18 CLIs with dedicated delegate skills: Aider, OpenAI Codex, Claude Code, Cursor Agent, Cline, Grok Build, GitHub Copilot CLI, Kimi Code, OpenCode, Google Antigravity, Mistral Vibe, Z.AI ZCode, Pi, Oh My Pi, Command Code, Warp Agent CLI, Qoder, and xAI's grok CLI. Each has a documented write mode and a read-only mode.

### Do I need all 18 CLIs installed to use delegate-skills?

No. The delegate-setup skill discovers which CLIs are installed on the machine and only proposes lanes for tools it can detect. A minimal fleet can use a single CLI across all lanes. Uninstalled CLIs are ignored during setup.

### What is a fleet lane in delegate-skills?

A lane is a named category of work bound to one implementer CLI with optional configuration dials such as model choice or effort level. For example, a feature lane might route to OpenCode while a tests lane routes to Codex. Dispatching to a lane abstracts away the specific CLI, so the assigned CLI can be changed by updating the fleet config without changing dispatch instructions.

## Sources

- [amElnagdy/delegate-skills on GitHub](https://github.com/amElnagdy/delegate-skills)
- [Issues](https://github.com/amElnagdy/delegate-skills/issues)
- [License: MIT](https://github.com/amElnagdy/delegate-skills/blob/master/LICENSE)
- [Project website](https://www.skills.sh/amelnagdy/delegate-skills)
- [README](https://github.com/amElnagdy/delegate-skills/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/amelnagdy-delegate-skills