需要配置委派通道（哪个实现器 CLI 处理哪类工作）时…

当用户要求设置、配置或重新配置委派通道/通道集群，或指定由哪个实现器处理功能/测试/UI 工作时使用；不用于派发具体编码任务。

适用场景

解决思路

1. 以编排者身份进入 setup 模式：发现已安装的实现器 CLI，提出通道集群方案，仅在用户批准后写入配置；本技能不派发编码工作，只编写通道映射。
2. 统一使用「lanes（通道）」这一概念，绝不说「routes」。
3. 运行 `node "<skill-dir>/scripts/discover.mjs"` 发现已安装与缺失的 CLI，汇总认证状态（`true`/`false`/`null`=未知），以及模型是 `reported`、`aliases`（注册表中的精选别名，非实时发现，完整模型名也可用）、`unsupported` 还是 `failed`。
4. 运行 `node "<skill-dir>/scripts/config.mjs" load --cwd "$PWD"` 加载现有有效映射：两者都不存在则提示「尚未配置通道」；否则展示带 Source 列（`global`/`project`）的有效通道表，除非被要求否则不要粘贴两个原始文件；若 `projectPresent` 为 true 而 `projectTrusted` 为 false，将项目通道标记为不可信（在用户审阅并批准项目写入前无法派发）。
5. 在提出方案前先问一个 grounding 问题（一问三选，不要做成向导）：如何挑选通道？(1) 快速默认——由你决定，不问问题；(2) 访谈——约四个关于工作分配的问题；(3) 使用扫描——重读各 CLI 本地会话文件夹（仅计数和日期，绝不读对话内容）让数据决定通道，若某 CLI 占主导则就其角色问一个问题；可同时选 2 和 3。
6. 快速默认模式：立即提出方案，完整映射合法、可含 dial，每条通道标注 `my opinion`，明确说明这是你的意见，并保持易于修改。
7. 访谈模式：先阅读 [references/setup-dialogue.md](references/setup-dialogue.md)，再问四个问题（关于分配策略，绝不问模型排名），每轮只问一个中等粒度问题。
8. 使用扫描模式：运行 `node "<skill-dir>/scripts/discover.mjs" --usage`，运行前告知用户这只是元数据；每个发现的 CLI 会获得 `usage: { sessions, lastUsed }`，`null` 表示未接探针（未知，而非未使用）。
9. 两者都选：先运行扫描，再只问数据无法回答的问题。
10. 在 git 仓库内，仓库信号（语言、测试比重、前端占比）是第四类证据，不改变菜单，但会喂给方案和 `repo` 依据。
11. 在访谈/使用扫描等证据模式下，每个 dial 都受门控：只根据用户回答设置，或 schema 要求时设置（opencode 通道要求 `model`）；省略总是安全的，因为每个 dial 都有用户已在使用的默认值，CLI 已配置的默认值是其既有选择，比你的先验更好。
12. 选择哪个已安装实现器获得通道仍由你决定（Basis 为 `my opinion`），但提高花费的 dial 不是：只在方案之后作为附录提供你的 dial 选择。
13. 未回答的问题只会缩小映射，绝不授权替代：提出更少、更保守的通道，点明你看不见的轴（如无配额回答则说明映射对配额盲），并邀请随时补充；最多重问一次，绝不用先验填补沉默。
14. 遵循委派经济学：编排者审阅并落地每个结果，审阅是质量门，因此优化总成本而非实现器声望；对边界清晰、有客观门控的工作（测试、机械重构、直接修复）优先使用有能力、已认证、可烧、低使用的 CLI，前提是其可靠性使审阅与返工仍经济。
15. 低使用本身不构成可烧：发现无法看到套餐、限额或单次成本，很少使用的 CLI 可能按量计费或被刻意回避；可烧来自用户的配额回答，或在快速默认中来自你标注的意见。
16. 默认避免把通道绑定到用户正在保护或用作编排入口的 CLI；仅当用户要求或无其他可接受替代时才绑定。通道对编排者是盲的：同一通道从用户驱动的每个席位触发，从该 CLI 自己的席位会派发给它自己。
17. 当返工与审阅成本超过节省、实现器不稳定、正确性依赖安全/并发/迁移/未言明的领域知识，或产出本身就是产品（辩论、架构、研究）时，剩余放置策略失效——审阅只能限制损害，不能制造好的首次尝试；这些通道应绑定更强的实现器。
18. 明确的「保留 X」回答默认将 X 从提议通道中移除，并在用户明确保留 X 的任何通道上覆盖笼统姿态回答——询问该姿态是否适用，未回答则省略该 dial；绝不把一个回答悄悄延伸到与之冲突的轴上。
19. 提出通道方案：按用户描述的工作命名，回退到 `feature`、`tests`、`ui`、`fast`、`complex`；只使用已安装的实现器。
20. 展示人类可读的通道表，列包括 Lane、Implementer、Model、Effort / variant、Basis、Source（若为更新）；每条通道的 Basis 必填：`your answer` / `usage data` / `repo` / `my opinion` / `schema requirement`（schema 强制的 dial 既非证据也非意见，要说明）；基于模型质量先验挑选的通道标为 `my opinion`，绝不呈现为工具决定的结果；「已安装且已认证」是能力，不是适配证据；当通道的实现器与 dial 来源不同时拆分标签。
21. 随后展示完整 JSON（`version`: `delegate-fleet.v1`），每条通道一行理由，标出认证或模型不确定性。
22. 确定作用域：用户说全局/所有项目/项目外 → `global`；无 git 仓库 → `global`（并说明）；否则问一次：全局还是仅此仓库。
23. 在明确同意后，只写入所选作用域（先校验）；从该作用域的原始文件（或新建时为空 `lanes` 对象）构建载荷，而不是从 `load` 的有效合并视图构建，否则项目写入会遮蔽仅全局的通道，全局写入会提升仅项目的通道。
24. 在平台临时目录（`$TMPDIR`、`%TEMP%` 或 Node `os.tmpdir()`；绝不硬编码 `/tmp`，它在原生 Windows 上会失败）下创建唯一命名文件，用编排者的文件写入工具把**确切批准的 JSON** 写入其中，并以该已填充路径作为 `<lanes-json>`；绝不校验空的临时文件；校验/写入尝试后无论成败都删除临时文件。
25. 运行 `node "<skill-dir>/scripts/config.mjs" validate "<lanes-json>"`，再运行 `node "<skill-dir>/scripts/config.mjs" write --scope global "<lanes-json>"`，或 `write --scope project --cwd /path/to/repo "<lanes-json>"`。
26. 用 `load` 重新读取，确认写入路径和生效通道名；项目写入将批准绑定到确切配置内容，后续更改会失败关闭直到重新批准；更新时简短的前后对比即可。
27. 确认后停止，告知用户映射已就绪；后续工作：读取通道的 `implementer`，加载对应 `*-delegate` 技能，用 `--lane <name>` 派发（显式传入的 `--model` / `--effort` / `--variant` 仍然优先）；除非用户要求，否则不要启动委派任务。
28. 重新配置时走同一流程：展示当前有效映射，提出更改，批准，写入一个作用域的文件；重装技能包不得重写这些文件，因为它们位于包外。

适用边界 · 注意事项

• 用户想要实现某个任务——应改用匹配的 `*-delegate` 技能。
• 单次派发上的临时模型更改——在该次 relay 上传入 `--model` / `--effort` / `--variant`。
• 不要编辑 `AGENTS.md`、`CLAUDE.md` 或其他用户代理指令文件；不要从本技能运行任何 `*-delegate` relay。