delegate-setup

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Delegate Setup

委托队列设置

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

你处于设置模式下的orchestrator角色。需发现已安装的implementer CLI，生成**队列组（fleet of lanes）**方案，仅在用户批准后写入配置。

本技能不负责分派编码工作，仅用于生成队列映射。

核心概念：lanes。禁止使用“路由”表述。

队列示例：feature → 实现者

opencode

，模型

opencode/grok

，变体

high

（OpenCode 使用

variant

表示推理强度，而非

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.

用户希望实现某个任务——请改用对应的
```
*-delegate
```
技能。
单次分派时临时修改模型——在该次中转时传入
```
--model
```
/
```
--effort
```
/
```
--variant
```
参数即可。

Hard rules

硬性规则

Every lane must include
```
implementer
```
.
Put dials on the same object (
```
model
```
,
```
effort
```
or
```
variant
```
, …) only if that implementer supports them — see references/schema.md.
Show a human-readable lane table and the full JSON before every write; re-show after every tweak.
Write only after an explicit approval (“yes”, “approve”, “write it”).
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.
Do not invent model identifiers.
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.
Prefer 3–5 useful lanes over a kitchen-sink map.
Never edit
```
AGENTS.md
```
,
```
CLAUDE.md
```
, or other user agent-instruction files.
Never run a
```
*-delegate
```
relay from this skill.

(

<skill-dir>

is this skill’s install directory — the folder that contains this

SKILL.md

每个队列必须包含
```
implementer
```
。
仅当实现者支持时，才在同一对象中添加参数（
```
model
```
、
```
effort
```
或
```
variant
```
等）——详见 references/schema.md。
每次写入前，必须展示易读的队列表格以及完整JSON；每次调整后需重新展示。
仅在用户明确批准（如“yes”、“approve”、“write it”）后才可写入配置。
除非范围已明确，否则需询问配置范围：全局（所有项目）还是仅当前仓库。不得仅因当前目录是git仓库就创建项目配置文件。若当前无git仓库，默认使用全局配置并告知用户。
不得自行编造模型标识符。
在访谈或使用扫描模式下，不得写入任何用户未提供且架构未要求的参数——需省略该参数，以便CLI或中转工具使用自身默认值。
优先提供3–5个实用队列，而非包含所有内容的映射表。
不得编辑
```
AGENTS.md
```
、
```
CLAUDE.md
```
或其他用户Agent指令文件。
不得通过本技能运行
```
*-delegate
```
中转命令。

（

<skill-dir>

为本技能的安装目录——即包含此

SKILL.md

的文件夹。）

Flow

流程

discover → load → grounding menu → propose (with Basis) → scope → approve → write

发现 → 加载 → 基础选项菜单 → 生成方案（附依据） → 确认范围 → 批准 → 写入

1. Discover

1. 发现

bash

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

bash

node "<skill-dir>/scripts/discover.mjs"

总结已安装/未安装的CLI、认证状态（

true

false

null

= 未知），以及模型状态：

reported

（已上报）、

aliases

（注册表中的精选别名，非实时发现——完整模型名称同样有效）、

unsupported

（不支持）或

failed

（失败）。

2. Load existing (effective map)

2. 加载现有（生效映射）

bash

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.

bash

node "<skill-dir>/scripts/config.mjs" load --cwd "$PWD"

无任何配置 → 提示“尚未配置任何队列。”
已有配置 → 展示生效队列表格，包含来源列（
```
global
```
/
```
project
```
）。除非用户要求，否则请勿粘贴原始配置文件内容。
若
```
projectPresent
```
为true且
```
projectTrusted
```
为false，需将项目队列标记为未信任。此类队列需用户审核并批准项目写入后才可分派任务。

3. Propose

3. 生成方案

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.

Question phrasings for the burn/spare and trust interview live in 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.

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.

发现操作仅报告能力，不涉及任务适配。因此在生成方案前需询问一个基础问题——一个问题，三个选项，而非向导式流程：

我应如何选择队列？(1) 快速默认——由我直接决定，无需额外提问。 (2) 访谈模式——通过约四个问题了解你对工作分配的需求。 (3) 使用扫描——我将重新读取CLI的本地会话文件夹（仅统计数量和日期，绝不读取对话内容），根据数据分配队列——若某一CLI占主导地位，会额外询问其角色。也可同时选择2和3。

快速默认 → 立即生成方案。
访谈模式 → 四个问题（仅涉及分配策略，不涉及模型排名）及提问方式（每轮一个问题）详见 references/setup-dialogue.md——提问前需先阅读该文档。
使用扫描 → 执行
```
node "<skill-dir>/scripts/discover.mjs" --usage
```
。运行前需告知用户仅读取元数据。每个已发现的CLI会新增
```
usage: { sessions, lastUsed }
```
字段；
```
null
```
表示未配置探测——状态未知，而非未使用。
同时选择 → 先执行扫描，再询问数据无法回答的问题。
若处于git仓库中，仓库信号（语言、测试占比、前端占比）是第四个参考依据。该信号不改变选项菜单，仅用于生成方案和
```
repo
```
依据。

该菜单同时也是授权界面——用户选择的选项决定了你可自主配置的范围：

快速默认 → 用户认可你的判断。完整映射方案（含参数）均合法；需为每个队列标记
```
my opinion
```
，明确告知用户该方案为你的建议，并说明可随时修改。
访谈/使用扫描 → 基于证据模式，因此所有参数均需受限（规则7）：仅可根据用户回答或架构要求设置参数（如opencode队列要求
```
model
```
）。省略参数始终是安全的——每个参数均有用户已在使用的默认值，CLI的配置默认值是用户的既定选择，比你的预设更具参考性。选择哪个已安装的实现者对应队列仍由你决定——依据为
```
my opinion
```
——但会增加成本的参数需作为方案附加项提供，详见 references/setup-dialogue.md。
未回答的问题会缩小方案范围；绝不能自行填补空白。生成更少、更保守的队列，说明你无法确定的维度（如无配额回答→说明方案未考虑配额），并邀请用户随时补充回答。最多重新询问一次；不得用预设值填补沉默。

委托经济性。编排器负责审核所有结果——审核是质量关卡，因此需优化总成本，而非实现者的权威性：

对于有明确边界、客观可验证的工作（测试、机械重构、简单修复），优先选择有能力、已认证、可消耗、低使用率的CLI，只要其可靠性能控制审核和返工成本——队列可将token消耗从用户需保护的订阅服务转移出去。仅低使用率不足以判定为可消耗：发现操作无法查看计划、限制或单次运行成本，低使用率的CLI可能按次计费或被用户刻意避免。可消耗性需来自用户的配额回答——或在快速默认模式下，标记为你的判断。
默认避免将队列绑定到用户需保护或用于编排的CLI；仅当用户要求或无合适替代方案时才绑定。队列是编排器无关的：无论用户从哪个终端操作，同一队列都会触发；从该CLI自身终端操作时，会将任务分派给CLI自身。
当返工和审核成本超过节省的费用、实现者不稳定、正确性依赖安全、并发、迁移或未明确的领域知识，或输出本身就是产品（辩论、架构、研究）时，多余的分配策略会失效——审核只能减少损失，无法生成优质的首次结果。此类队列需绑定更可靠的实现者。
若用户明确表示“预留X”，则默认将X从方案队列中移除，并覆盖用户针对X保留的任何队列的通用策略回答——需询问该策略是否适用于该队列；若未回答则省略参数。不得将一个回答盲目应用于冲突的维度。

关于消耗/预留和信任访谈的提问措辞详见 references/setup-dialogue.md。

随后生成队列方案。根据用户描述的工作类型命名队列；若无明确描述则使用

feature

、

tests

、

ui

、

fast

、

complex

。仅使用已安装的实现者。

展示格式：

队列	实现者	模型	工作量/变体	依据	来源（若更新）
feature	opencode	opencode/grok	variant: high	用户回答 + 架构要求	—
tests	codex	—	—	使用数据	—
ui	claude	—	—	我的判断（实现者）	—

依据为每个队列必填项：

your answer

（用户回答）/

usage data

（使用数据）/

repo

（仓库信号）/

my opinion

（我的判断）/

schema requirement

（架构要求）（架构强制要求的参数既非证据也非判断——需明确说明）。若你基于模型质量预设选择队列，需标记为

my opinion

——绝不能将其展示为工具自动判定的结果，“已安装且已认证”仅代表能力，不代表适配性。若队列的实现者和参数来自不同来源，需拆分标签——详见 references/setup-dialogue.md。

随后展示完整JSON（

version

delegate-fleet.v1

）。每个队列需附带一行说明；标记认证或模型的不确定性。

架构和参数表格：references/schema.md。

4. Scope

4. 确认范围

User said global / all projects / outside the project →
```
global
```
.
No git repo →
```
global
```
(say so).
Else ask once: global vs this repo only.

用户明确要求全局/所有项目/项目外 → 使用
```
global
```
。
无git仓库 → 使用
```
global
```
（需告知用户）。
其他情况 → 询问一次：全局还是仅当前仓库。

5. Approve and write

5. 批准与写入

On explicit yes, write only the chosen scope (validate first). Build the payload from that scope’s raw file (or an empty

lanes

object if new) — not from the effective merged

load

view, or a project write will shadow global-only lanes and a global write will promote project-only ones.

Create a uniquely named file under the platform temporary directory (

$TMPDIR

%TEMP%

, or Node

os.tmpdir()

; never hard-code

/tmp

, which breaks on native Windows), write the exact approved JSON into it with the orchestrator's file-writing tool, and use that populated path as

<lanes-json>

below. Never validate an empty temp file. Remove the temp file after the validation/write attempt, whether it succeeds or fails.

bash

node "<skill-dir>/scripts/config.mjs" validate "<lanes-json>"
node "<skill-dir>/scripts/config.mjs" write --scope global "<lanes-json>"

收到明确同意后，仅写入选定范围的配置（需先验证）。从该范围的原始文件（若为新配置则使用空

lanes

对象）构建负载——不得使用生效的合并

load

视图，否则项目写入会覆盖仅全局的队列，全局写入会提升仅项目的队列。

在平台临时目录（

$TMPDIR

、

%TEMP%

或Node的

os.tmpdir()

；绝不要硬编码

/tmp

，否则在原生Windows系统中会失效）下创建唯一命名的文件，使用编排器的文件写入工具将用户批准的精确JSON写入该文件，并将该路径作为下方的

<lanes-json>

。不得验证空临时文件。无论验证/写入成功或失败，均需删除临时文件。

bash

node "<skill-dir>/scripts/config.mjs" validate "<lanes-json>"
node "<skill-dir>/scripts/config.mjs" write --scope global "<lanes-json>"

or: write --scope project --cwd /path/to/repo "<lanes-json>"

或： write --scope project --cwd /path/to/repo "<lanes-json>"


Re-read with `load`, then confirm the path written and the active lane names. Project writes bind
approval to the exact config content; later changes fail closed until re-approved. On update, a short
before/after is enough.


使用`load`重新读取配置，然后确认写入路径和生效队列名称。项目写入会将批准与精确配置内容绑定；后续修改需重新批准才可生效。若为更新操作，展示简短的前后对比即可。

6. Ready to delegate

6. 准备就绪

Stop after confirming. Tell the user the map is ready. For later work: read the lane’s

implementer

, load that

*-delegate

skill, and dispatch with

--lane <name>

(explicit

--model

--effort

--variant

still win when passed). Do not start a delegate task unless they ask.

确认完成后停止操作。告知用户队列映射已准备就绪。后续工作流程：读取队列的

implementer

，加载对应的

*-delegate

技能，使用

--lane <name>

分派任务（传入的

--model

--effort

--variant

参数仍优先生效）。除非用户要求，否则不得启动委托任务。

Reconfigure

重新配置

Same flow. Show the effective current map, propose changes, approve, write one scope’s file. Reinstalling the skills package must not rewrite these files — they live outside the package.

流程与首次配置相同。展示当前生效的映射方案，生成修改建议，获得批准后写入对应范围的配置文件。重新安装技能包不得覆盖这些文件——它们存储在技能包外部。