企业官网建设流程全解析

delegate-skills 舰队配置实战：用 delegate-setup 建立 feature/tests/ui 三条委派车道指南

【免费下载链接】delegate-skillsDelegate a coding task to a separate coding agent CLI, review the diff, land the commit yourself — one per implementer.项目地址: https://gitcode.com/gh_mirrors/de/delegate-skills

delegate-skills是一个开源的 AI 编码委派技能包：把编码任务委派给独立的编码代理 CLI 执行，你负责审阅 diff 并亲自提交。delegate-setup是它的舰队（fleet）配置入口——自动探测你机器上已安装的编码代理 CLI，为feature/tests/ui三条委派车道（lanes）生成配置建议，并在你明确批准后写入配置文件。本指南带你从安装到首次按车道委派，全程走完一遍。

1️⃣ 先搞懂核心概念：fleet 与 lane

在配置之前，先用 30 秒理解两个词（详见 README.md）：

• lane（车道）：把"某一类工作"绑定到"一个执行者 CLI"，并可附带可选的调节旋钮（dials），如模型、推理力度、超时等。例如tests → codex，ui → cursor。
• fleet（舰队）：一组命名的车道。你的编排代理（orchestrator）按车道名派活，不再关心背后是哪个 CLI。

delegate-setup只做一件事：画出这张车道图。它从不真正派发编码任务，也不修改AGENTS.md等指令文件——这是 skills/delegate-setup/SKILL.md 中写明的硬规则。

$delegate-setup（发现 → 提案 → 批准） ──► 你的舰队 你的编排代理 ──────────────────────────► 你的舰队 feature → OpenCode ─┐ tests → Codex ─┼─► 审阅 diff、重跑测试门禁 → 你亲自提交 ui → Cursor ─┘

2️⃣ 30 秒安装：让 delegate-setup 就位

delegate-setup 本身不要求任何编码代理 CLI 已安装——它负责帮你发现哪些已经可用。只需 Node 18+ 和 git，以及一个能执行 shell 命令的编排代理。

# 只安装配置技能（推荐新手） npx skills add amElnagdy/delegate-skills --skill delegate-setup # 或直接安装整个技能包（含 17 个 implementer 技能） npx skills add amElnagdy/delegate-skills

之后只需对编排代理说一句话：

使用 $delegate-setup 发现我安装的编码代理 CLI，并为我创建一个覆盖 feature、tests、ui 的舰队。

3️⃣ 配置流程：发现 → 提案 → 批准 → 写入

整个流程是discover → load → 定基调菜单 → 提案 → 选作用域 → 批准 → 写入，由三个小脚本支撑（只用 Node 内置模块，无网络、无遥测，运行前可先阅读源码）：

发现报告会告诉你三件事：哪些 CLI 已安装、登录是否生效（true/false/null表示未知）、模型列表是实时探测还是仅有内置别名。未登录的 CLI 不建议绑定车道。

4️⃣ 车道怎么定？三种"定基调"方式

提案前，delegate-setup 会问一个问题，给你三个选项——这是它的设计特色，不是走迷宫式向导：

1. Quick defaults（快速默认）：它替你决定，并给每条车道标注my opinion（我的判断），方便你后续修改。
2. Interview（访谈）：约 4 个问题，只谈"工作量分配策略"，不让你排模型——例如：你委派最多的工作类型是什么？哪些付费订阅可以消耗、哪些要保留？四个问题的完整问法见 setup-dialogue.md。
3. Usage scan（使用扫描）：运行discover.mjs --usage，只统计各 CLI 本地会话的数量和日期（绝不打开会话内容），让数字帮你定位车道。

💡 未回答的问题只会让车道图变小，不会替你脑补答案——这是它"保守失败"（fail closed）的设计哲学。

5️⃣ 完整示例：feature/tests/ui 三条车道的配置长什么样

批准后写入的配置遵循delegate-fleet.v1结构（完整字段说明见 schema.md）：

{ "version": "delegate-fleet.v1", "lanes": { "feature": { "implementer": "opencode", "model": "opencode/grok", "variant": "high" }, "tests": { "implementer": "codex", "effort": "medium" }, "ui": { "implementer": "claude" } } }

注意两点：每条车道的implementer是唯一必填项；不认识的旋钮（比如给 opencode 写effort）会在validate阶段直接报错，防止配错。17 个执行者的键名与各自支持的旋钮清单都在 implementers.mjs 中。

6️⃣ 配置文件写在哪：global 还是 project 作用域

写入前必须选作用域，两者存放位置不同：

项目车道按"整车道替换"覆盖全局车道；并且项目配置带信任哈希——批准只绑定当时的精确内容，克隆或事后改动的配置会"失败关闭"，必须经 delegate-setup 重新审阅批准后才能派活。这套机制保证团队克隆仓库后不会意外执行陌生的车道。

写入命令本身很直接（校验在前、原子写后）：

node config.mjs validate config.json node config.mjs write --scope global config.json # 或：node config.mjs write --scope project --cwd /path/to/repo config.json

7️⃣ 配置就绪：用 --lane 按车道委派工作

车道写好之后，任何*-delegate技能都能带上--lane <名称>派活。例如用 Codex 处理测试车道：

使用 $codex-delegate 加 --lane tests 为 services/billing 补充单测，然后审阅并提交。

分发时 lane.mjs 会做三件事：

1. 找不到该车道 → 直接报错，不会静默走默认；
2. 车道绑定的执行者与当前技能不一致（比如ui车道绑的是 claude，你却用$codex-delegate）→大声失败，提示你换对技能；
3. 显式传入的--model/--effort等标志优先于车道旋钮，方便临时微调。

完整的派活循环始终是：写 brief → 分发 → 等result.json→ 审阅 diff 并重跑门禁 →由你提交。每个 relay 都不提交代码，提交权永远留在审阅者手里（各技能细节见 skills/codex-delegate/ 等目录下的 references 文档）。

8️⃣ 三个让配置更安全的要点 ✅

• 一次别建太多车道：官方建议 3–5 条有用的车道，好过"厨房水槽"式全量图。
• 保护你的配额：访谈中明确"哪些订阅要保留"，把高成本车道留给确实复杂的工作；省 token 的前提是返工成本可控。
• 随时可重配置：同一套流程再走一遍即可——先展示当前生效的车道图，再提案变更、批准、写入。重装技能包不会动这些文件，它们独立存放在技能包之外。

📚 延伸阅读

• 配置技能主文档：skills/delegate-setup/SKILL.md
• 车队结构定义：skills/delegate-setup/references/schema.md
• 访谈问法与依据标注规则：skills/delegate-setup/references/setup-dialogue.md
• 贡献与新执行者清单：CONTRIBUTING.md
• 配置行为测试：test/relay/delegate-setup.mjs

配好 feature、tests、ui 三条车道之后，你只需要记住车道名——背后的执行者换谁，都由你审阅 diff 时说了算。

【免费下载链接】delegate-skillsDelegate a coding task to a separate coding agent CLI, review the diff, land the commit yourself — one per implementer.项目地址: https://gitcode.com/gh_mirrors/de/delegate-skills