Delegate Setup

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

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