Multi agent driven
Agent skills I use day to day (lowband / handoff / multi-agent-driven / ctx-* family)
npx -y skills add keli-wen/skills --skill multi-agent-drivenAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
3 things to look at
- 20 days oldThe repository was created 20 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
把当前任务派发给多个 subagent——但先检查这次拆分到底值不值。触发语：「multi-agent this」「fan out」「用多智能体做」「派发出去」，或任务能拆成真正独立的子任务时。按上下文耦合度拆解，spawn prompt 用 handoff 的纪律写成任务契约。
SKILL.md
5.6 KB, ~2.0k tokens by cl100k_base, as published. Nobody here has run it
multi-agent-driven
把当前任务变成一次有编排的多智能体执行——但只在拆分真正划算时才拆。你始终是编排者：拆解、派发、整合。不要自己做子任务。
语言：跟随用户的语言。
关卡：这次拆分值得吗？
多智能体的代价是真金白银：agent 比普通聊天多烧数倍 token，多智能体系统再多一个量级；而且每次交接都要交「通信税」——subagent 返回的摘要会藏掉它行动背后的隐式决策，编排者下发的指令也会在传递中丢失微妙之处。
- 先榨干单上下文：把指令写清楚、压缩上下文、收窄工具集。很多「需要多智能体」的问题，其实是单 agent 的上下文管理没做好。
- 只在真实信号出现时才拆：当前上下文在退化（失败探索的噪声污染后续决策）、信息空间大到一个 agent 覆盖不过来、或工具集大到选择准确率下降且能按专业领域切开。
- 拿不准就不拆。拆错的代价（信息损耗加决策不一致）通常大于不拆的代价（上下文略显臃肿）。从能用的最简单方案开始，有证据支持时再加 agent。
步骤
- **沿上下文耦合度拆，不沿功能拆。**agent 之间的边界必须画在共享上下文最少的地方。永远不要按工作阶段拆（一个实现、一个测试、一个审查）——那恰好切在耦合度最高的地方，整个执行变成传话游戏。低耦合的切片适合拆：互不依赖的搜索路径、文档消化、黑盒验证、独立的研究角度。高耦合的工作留在一个 agent 里（通常是你自己）：核心实现、架构决策、任何其选择会悄悄约束别人的工作。
- 按任务类型选模式：
- 调研 / 排查 → 不同角度的并行 explorer（按来源、按子系统、按时间窗）；告诉每个先广后精
- 多处实现 → 先摸清完整工作清单，再一处一个 agent；会并行改同一仓库时用 worktree 隔离
- review / 审计 → 按维度并行找问题，每个发现再配一个对抗式验证者
- 设计决策 → 2–3 个不同侧重的独立方案 agent（MVP 优先、风险优先、用户优先），再加一轮评审
- debug → 并行假设检验者，每人负责证伪一个假设
- 以上任何一种 → 几乎都值得加一个黑盒验证 subagent：它只需要验收标准和产出物，是最便宜也最稳的拆分。
- spawn prompt 写成任务契约（handoff 纪律）：明确的目标、按引用给的输入（路径 / issue / URL，不粘贴正文）、期望的输出形状、边界（不许碰什么），agent 可能选错工具时给一句工具提示。模糊的委派只会产出重复或跑偏的工作。
引用还是内联，是一个能力上的 tradeoff。引用只在接收方能解引用时成立——它得有读取/搜索工具和访问权限；引用的收益在内容大、持久、或只需要一部分时最明显：subagent 只拉自己要的那部分、按需拉取、读到的还是最新版。反过来这四种情况用内联：接收方没工具、片段比一次读取还便宜、必须钉死精确版本、信息只存在于这段对话里——没落盘的上下文引用不到，要么内联要么先落盘（
to-ctx）。一句话：持久的用引用，增量的用内联。 投入和复杂度挂钩并写进契约：简单查证就一个 agent 几次工具调用；对比类 2–4 个 agent；只有真正复杂的工作才配得上十个以上。 契约不是完整的handoff，大多数派发也不需要 handoff——handoff 交接的是「任务连同它积累的状态」的所有权，契约委派的是一个切片，所有权还在你手上。只有当子任务的状态多到可能活得比这次执行长时，才把契约升级成真正的handoff：它在某个 branch / worktree 上干活、可能被另一个 session 接着做；它需要在中断后可恢复；或者它的结果要继续传给下一个 agent。 - 派发：互相独立的 agent 并行出发；有依赖的阶段做流水线，不设人为的等待关卡。两个层面同时并行：多个 agent 同时跑，每个 agent 内部多个工具调用同时发。优先用平台原生编排（Claude Code 用 Agent 工具或 Workflow；其他平台就顺序调 subagent）。
- 整合：自己读结果，先专门排查跨 agent 的不一致——subagent 看不到彼此的隐式决策，各自正确的产出组合起来照样可能冲突（不兼容的结构、重复的工作、相互矛盾的假设）。裁决冲突、验证合并后的结论（重跑测试、抽查断言），汇报一个整合过的结论，不是一堆 agent 输出的堆叠。
规则
- 会约束多个子任务的决策（数据结构、接口、命名、方案取向）由你在派发之前定好，并写进每一份受影响的契约——永不留给 subagent 各自发挥。
- 每次派发都写明覆盖范围：包含了什么、丢掉了什么。不许静默截断。
- subagent 的结果是主张，不是事实。整合前先验证：重跑测试、重开文件、重查引文。
- 依赖方向单向：本 skill 可以用
handoff；永不调用面向用户的 skill。