Maintainer of this skill?
Automated security scan — not a certification.
by amElnagdy
Delegate a coding task to a separate coding agent CLI, review the diff, land the commit yourself — one per implementer.
# Add to your Claude Code skills
git clone https://github.com/amElnagdy/delegate-skillsGuides for using ai agents skills like delegate-skills.
Last scanned: 6/22/2026
{
"issues": [],
"status": "PASSED",
"scannedAt": "2026-06-22T09:49:30.639Z",
"npmAuditRan": true,
"pipAuditRan": true,
"promptInjectionRan": true
}See how delegate-skills compares with popular alternatives.
delegate-skills is an open-source ai agents skill for AI coding assistants such as Claude Code, Codex CLI, and ChatGPT, built by amElnagdy. Delegate a coding task to a separate coding agent CLI, review the diff, land the commit yourself — one per implementer. It has 2,559 GitHub stars.
Yes. delegate-skills passed SkillsLLM's automated security scan — a dependency vulnerability audit plus prompt-injection heuristics — with no high-severity issues. You can read the full report in the Security Report section on this page.
Clone the repository with "git clone https://github.com/amElnagdy/delegate-skills" and add it to your Claude Code skills directory (see the Installation section above).
delegate-skills is primarily written in JavaScript. It is open-source under amElnagdy on GitHub, so you can review or fork the full source.
Yes. SkillsLLM lists many other AI Agents skills you can browse and compare side by side. Open the AI Agents category from the badge at the top of this page, or use the Related Skills and comparison links further down to weigh delegate-skills against similar tools.
No comments yet. Be the first to share your thoughts!
From $49 · 30 days · terms & refunds
⚠️ Third-Party Software Notice
This skill is third-party open-source software developed and hosted independently on GitHub. SkillsLLM is an informational directory and does not control or maintain the underlying repository.
Any security checks, ratings, or warnings displayed by SkillsLLM are automated and limited in scope. They do not constitute a security certification or guarantee that the software is safe, error-free, or free from malicious code, vulnerabilities, compromised dependencies, or prompt-injection risks.
Review the source code, permissions, dependencies, and configuration before installing or running any third-party skill. Use is at your own risk. To the maximum extent permitted by applicable law, SkillsLLM is not liable for losses arising from third-party software.
Automated security scan — not a certification.
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"]
| 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.
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 1 |
--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 2 |
--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 3 |
--resume-last, --session <id> |
kimi-delegate |
Kimi Code (kimi) |
auto permission mode, always |
— 4 | --resume-last, --session <id> |
muse-delegate |
Muse Code (muse) |
--disable-approval (sandbox on); not --yolo 5 |
--read-only (--disable-write + --disable-shell) |
--session <id> (no headless --resume-last) |
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 4; 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 4 | — 4 | --conversation <id> |
zcode-delegate |
Z.AI ZCode (zcode) 6 |
--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 codex-background alongside th
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. ↩ ↩2 ↩3 ↩4
Write muse exec keeps Muse's sandbox on and passes --disable-approval so a headless run
cannot hang on a tool-approval prompt. --read-only adds --disable-write and --disable-shell.
--yolo is not the default and is not exposed. Upstream's launcher is Darwin/Linux only. Headless
resume is --session-id; muse resume is TUI-only. ↩
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. ↩