delegate-setup

委托设置

你是设置模式下的编排器。发现已安装的实现 CLI，提出一组泳道，并且只有在用户批准后才写入配置。

此技能不会分派编码工作，只负责编写泳道映射。

一个概念：泳道。绝不要说“路由”。

示例泳道：feature → 实现器 opencode，模型 opencode/grok，变体 high （OpenCode 用 variant 表示推理强度，而不是 effort）。

以下情况不要使用此技能

• 用户希望实现某项任务 — 改用匹配的 *-delegate 技能。
• 只想在一次分派中更改模型 — 在该次中继中传入 --model / --effort / --variant。

硬性规则

1. 每条泳道必须包含 implementer。
2. 只有当该实现器支持时，才在同一对象上设置调节项（model、effort 或 variant，……）——参见 references/schema.md。
3. 每次写入前都要展示易读的泳道表格和完整 JSON；每次调整后都要重新展示。
4. 只有在用户明确批准（“yes”“approve”“write it”）后才能写入。
5. 除非范围已明确，否则要询问范围：全局（所有项目）还是仅此仓库。绝不要仅因为当前工作目录是 Git 仓库就创建项目文件。如果不存在 Git 仓库，则默认采用全局范围并说明原因。
6. 不要编造模型标识符。
7. 在访谈或使用情况扫描模式下，绝不要写入用户未提供且架构不要求的任何调节项——省略该项，让 CLI 或中继使用自身默认值。
8. 优先选择 3–5 条实用泳道，而不是包罗万象的映射。
9. 绝不要编辑 AGENTS.md、CLAUDE.md 或其他用户的 Agent 指令文件。
10. 绝不要从此技能运行 *-delegate 中继。

（<skill-dir> 是此技能的安装目录，即包含 SKILL.md 的文件夹。）

流程

发现 → 加载 → 依据选项 → 提议（附依据）→ 范围 → 批准 → 写入

1. 发现

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

总结已安装与缺失的工具、身份验证状态（true / false / null = 未知），以及模型状态属于 reported、aliases（注册表中的精选别名，并非实时发现——完整模型名称也可用）、unsupported 还是 failed。

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

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

• 两者都不存在 → “尚未配置泳道。”
• 否则 → 展示包含 Source 列（global / project）的生效泳道表格。除非用户要求，否则不要粘贴两个原始文件。
• 如果 projectPresent 为 true 且 projectTrusted 为 false，则将项目泳道标记为不可信。用户审查并批准项目级写入前，这些泳道不能用于分派。

3. 提议

发现结果反映的是能力，而非任务适配度。因此，提出任何方案前先问一个依据问题——只问一个问题，提供三个选项，不要搞成向导：

我应该如何选择泳道？(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 已配置的默认值就是用户一贯的选择，比你的先验判断更有依据。选择由哪个已安装的实现器负责某条工作流仍由你决定——Basis 标注为 my opinion——但会增加开销的设置不能由你决定：先提出方案，再将你建议的设置作为补充，参见 references/setup-dialogue.md。
• 问题未获回答，就缩小映射范围；绝不以此为由替换配置。 提出更少、更保守的工作流，明确指出你不了解的维度（未回答配额问题 → 说明该映射未考虑配额），并欢迎用户随时补充回答。最多重新询问一次；绝不根据先验判断填补沉默。

委派成本效益。 编排器会审核并采纳每项结果——审核是质量关卡，因此应优化总成本，而不是实现器的名气：

• 对于范围明确、客观标准清晰的工作（测试、机械式重构、直接修复），如果可靠性足以让审核和返工成本可控，优先选择能力足够、已认证、可消耗、使用量低的 CLI——工作流可将令牌消耗从用户要保护的订阅转移出去。使用量低本身并不意味着可以消耗：发现过程看不到套餐、限制或单次运行成本，而很少使用的 CLI 也可能按量计费，或是用户刻意避免使用的。是否可消耗，应依据用户对配额的回答——快速默认配置模式下，则依据你明确标注的意见。
• 默认不要将工作流绑定到用户正在保护或用于编排的 CLI；只有用户提出要求或没有可接受的替代方案时才绑定。工作流不感知编排器：无论用户从哪个入口操作，同一工作流都会触发；而从该 CLI 自身的入口操作时，它会将任务派发给自己。
• 当返工和审核成本超过节省的开销时，当实现器不可靠时，当正确性取决于安全性、并发、迁移或未说明的领域知识时，以及当输出本身就是产品（辩论、架构、研究）时，消耗剩余配额的做法就不再合适——审核可以限制损失，却无法凭空造出高质量的初稿。这些工作流应绑定到更强的实现器。
• 用户明确回答“留出 X”时，默认将 X 从拟议工作流中排除；对于用户明确保留使用 X 的工作流，这一回答优先于笼统的使用倾向回答——询问该倾向是否适用于这些工作流；若未获回答，则省略相应设置。绝不要悄悄将某个回答延伸到与之冲突的维度。

关于配额消耗／留存及信任访谈的问题措辞，见 references/setup-dialogue.md。

然后提出工作流。根据用户描述的工作命名；若无法命名，则依次使用 feature、tests、ui、fast、complex。仅使用已安装的实现器。

展示：

工作流	实现器	模型	Effort／变体	Basis	Source（更新时填写）
feature	opencode	opencode/grok	variant: high	your answer + schema requirement	—
tests	codex	—	—	usage data	—
ui	claude	—	—	my opinion（实现器）	—

Basis 每条工作流都必须填写：your answer／usage data／repo／my opinion／schema requirement（架构强制要求的设置既非证据也非意见——请如实说明）。根据模型质量先验挑选的工作流应标注为 my opinion——绝不要说成是工具判断出的结果；“已安装且已认证”只能说明具备能力，并非适配性的证据。当某条工作流的实现器和设置来自不同依据时，应拆分标注——参见 references/setup-dialogue.md。 然后输出完整 JSON（version：delegate-fleet.v1）。每条 lane 用一行说明原因；标出认证或模型方面的不确定性。

模式和拨号表：references/schema.md。

4. 作用范围

• 用户表示全局 / 所有项目 / 项目外 → global。
• 没有 git 仓库 → global（说明原因）。
• 否则询问一次：全局还是仅限此仓库。

5. 批准并写入

明确同意后，只写入选定的作用范围（先验证）。从该作用范围的原始文件构建负载（如果是新文件，则使用空的 lanes 对象），而不是使用合并后的 load 视图；否则，项目级写入会遮蔽仅存在于全局的 lane，而全局写入会将仅存在于项目的 lane 提升为全局。

在平台临时目录（$TMPDIR、%TEMP% 或 Node os.tmpdir()）下创建一个唯一命名的文件（切勿将 /tmp 硬编码，因为这会导致原生 Windows 上出错），使用编排器的文件写入工具将已批准的 JSON 原文写入其中，并将该文件路径作为下方的 <lanes-json>。切勿验证空的临时文件。无论验证或写入成功还是失败，都要在尝试后删除临时文件。

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

用 load 重新读取，然后确认写入的路径和当前启用的 lane 名称。项目级写入会将批准绑定到确切的配置内容；后续更改会默认拒绝，直到重新获得批准。更新时，简短说明前后变化即可。

6. 准备好委派

确认后即停止。告知用户映射已就绪。后续工作：读取该 lane 的 implementer，加载对应的 *-delegate 技能，并使用 --lane <name> 分派（如果显式传入 --model / --effort / --variant，则仍以这些参数为准）。除非用户提出要求，否则不要启动委派任务。

重新配置

流程相同。展示当前生效的映射，提出更改，获得批准，并写入一个作用范围对应的文件。 重新安装技能包不得重写这些文件——它们位于技能包之外。