delegate-setup – Writing & Content skill for AI agents

Delegate Setup

When to Use

• You want to configure which implementer CLI handles which kind of work (fleet lanes).
• You need to discover installed implementers and write lane config after user approval.

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

1. Every lane must include implementer.

2. Put dials on the same object (model, effort or variant, …) only if that implementer supports them — see [references/schema.md](references/schema.md).

3. Show a human-readable lane table and the full JSON before every write; re-show after every tweak.

4. Write only after an explicit approval (“yes”, “approve”, “write it”).

5. 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.

6. Do not invent model identifiers.

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

8. Prefer 3–5 useful lanes over a kitchen-sink map.

9. Never edit AGENTS.md, CLAUDE.md, or other user agent-instruction files.

10. 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. Verify runtime availability, then discover

This is a docs-only tree: scripts/discover.mjs, config.mjs and lane.mjs are absent. Do not run the example commands against nonexistent paths or fabricate discovery/trust results. If a separately installed runtime exists, inspect its verified revision, license and behavior before using it. Otherwise produce the proposed table/JSON only, clearly marked unvalidated, and stop before config writes that depend on the missing validator/approval-hash mechanism.

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](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](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](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](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](references/schema.md).

4. Scope

• User said global / all projects / outside the project

… (full content is in the download package)