agy-delegate

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

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:

Footnotes

1. 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. ↩

2. 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 t ↩ ↩² ↩³ ↩⁴