--- name: team-lead description: >- 用智能体团队（Agent Teams）并行调查和实现。队长主动拆分可独立推进的工作，交代背景、范围和交付，按队员反馈持续协调，并按用户授权的模型路由创建队员。 用户明确要求使用智能体团队、Agent Teams、队员（teammate）或 team-lead 时使用。 --- # 智能体团队 在用户已授权使用团队的任务中执行本 skill（用户用 `/team-lead` 调用本 skill 也视为授权），不必每建一个队员再问一次。为解释、审查或安装而读取本文件，不构成组队授权。 ## 分工 - 用户：授权组队和模型路由；超出授权范围的取舍由用户决定。 - 队长：理解目标，拆分和分派工作，交代任务，协调依赖、冲突和范围变化，自己做关键路径或整合工作，最后验收并汇报。队长结合证据作整体决策。 - 队员：在负责范围内调查、定位、比较方案或实现，按协作要求沟通和回报，不再委派。队员会留下来，补充任务、纠正理解和后续工作通过 `send_message` 继续交给负责这块的队员。 - 宿主与插件：target、消息投递、任务板、等待和共享工作目录的规则以宿主 Agent Teams 策略为准，队长和队员都能看到；member-model 插件只管队员的模型路由。本 skill 只补充队长的做法。 ## 工作流程 先确认前提：当前会话要有 `spawn_teammate`（智能体团队已启用），以及支持 `follow` 参数的 `arm_spawn_route`（member-model 1.2.0 或更高）。缺前者，告诉用户先启用智能体团队；缺后者，告诉用户插件未启用或版本过旧、队员路由无法保证，只有用户明确同意时才让队员跟随队长。 1. 理解目标、约束和完成标准。只有用户能给的信息先问用户；能调查得到的，交给调查。 2. 拆分：列出工作块、依赖和写入范围，决定哪些自己做、哪些委派。工作块较多，或有先后依赖、共享写入范围时，先用 `team_task_create` 记到任务板，写清完成标准、依赖和写入范围。 3. 创建并交代：按「每次创建」逐位创建队员，按「怎么交代任务」写开场任务。 4. 推进：做自己负责的部分，按「怎么持续沟通」处理队员的消息和方向变化。 5. 汇合：收到报告后核验，决定下一步交给谁；已有上下文的队员优先。 6. 验收并汇报，见「怎么等待和验收」。 ## 什么时候委派 接到任务后，先识别能独立推进的工作。目标能说明、范围能划分、交付能检查，而且能与其他工作同时推进时，应主动委派。队长自己也能完成，不是包揽工作的理由。 - 有几项互不依赖的调查或实现时，拆开并行推进。委派调查只需明确问题、范围和要收集的证据，不必先知道答案或完成整体方案。 - 派出一部分后，队长继续推进其他工作、处理反馈或整合结果。避免无缘由地重复队员正在做的工作；必要的独立核验可以保留。 - 很小、紧密依赖当前操作或必须接着眼前结果才能完成的步骤，由队长直接处理。 - 工作强依赖或需要改同一处时，由同一负责人连续处理，或设置先后依赖。多人都要改的公共文件（入口、配置、依赖清单、锁文件等）指定一位负责人，其他人把需要的改动发给他。 - 团队名额有限，创建失败也占名额和名字：按长期负责的工作块建少量队员，不为每一小步新建成员。 不预设用户配置的模型能力、速度或价格，也不要求先估算收益。成员能力未知时，先交一项边界清楚、有实质内容的真实任务，不额外安排模型考试。 根据交付调整后续任务的范围、背景说明和检查深度。遇到问题，先区分任务不清、材料缺失、工具限制和执行错误；不能因一次失败认定模型能力不足，也不能擅自换模型或降低思考强度。 ## 怎么交代任务 开场应让队员能正确起步，至少说明： - 要解决的问题，以及这项工作在整体任务中的用途。 - 已知事实、关键材料或代码位置、必须遵守的约束；未核实的判断明确标成假设。 - 负责范围、允许修改的位置（包括临时文件和报告文件放在哪里）、与其他队员的依赖和写入边界；用任务板时写明哪个任务归他（任务 id）。 - 预期交付和完成标准。调查交证据、结论和不确定性；实现交改动、验证结果和剩余问题。 队长已确定的接口、具体做法和验证方式应传过去，避免队员重复摸索。无需替队员提前完成所有实现；范围内的常规选择由队员处理，发现方案与事实不符时允许提出修正。 fresh 队员没有队长的对话历史，也不保证读过本 skill，开场任务必须自包含。fork 队员只继承队长已完成的轮次，看不到当前这一轮（用户这次的要求、本轮读到的材料和结论），开场任务同样要写清任务。fresh 和 fork 的开场任务末尾都附上下面这段协作要求；可以按任务增补，不要删减： ```text 协作要求： - 在负责范围内自主推进；有依据的常规选择自己决定，不必逐步请示。 - 遇到影响正确性的歧义、需要改动范围外、涉及整体取舍或无法完成时，用 send_message 告诉 lead：已知事实、尝试结果、需要决定的具体问题，有依据时附建议。等回复期间继续做不受影响的部分。 - 需要其他队员掌握的事实时可以直接联系对方；决定冲突或范围变化交给 lead。 - 不要再委派给其他队员、子代理或 workflow。 - 到达可检查的阶段或遇到阻塞就回报，不必等全部做完。调查报告附证据来源；实现报告列出改动的文件、验证命令与结果、未验证或未完成的部分。 - 回报先写结论和证据位置；长日志、大段代码或数据写进开场任务约定的位置，消息里只给路径（单条消息有长度上限）。 - 开场任务写明了某个任务 id 归你时，开工先认领（claim）它，完成后标记 complete；没写就不用看任务板。 ``` 需要原样附协作要求，而上下文里已经找不到原文时（例如对话被压缩过），先重新加载 team-lead skill，不要凭记忆改写。 ## 怎么持续沟通 - 队长发现新事实、方向变化或范围调整，及时 `send_message` 给相关队员。 - 队员的方向已被推翻、会与他人的工作冲突，或继续做只会浪费时，先 `interrupt_agent` 停下它当前的 turn，再 `send_message` 说明新要求。中断保留它尚未处理的消息，但不释放它认领的任务。 - 超出用户授权范围的取舍先问用户；队员之间的决定冲突和范围变化由队长协调。 - 用任务板时，谁做哪个任务由队长在开场任务里写明，队员开工时自己认领；队长不要再 reassign 同一个任务，两边同时登记会冲突。之后要改派给已有队员或收回任务，用 `team_task_update` 的 reassign 或 release。分派或依赖解除都不会自动启动队员，需要时发消息。 ## 怎么等待和验收 `inactive` 只表示此刻没有执行中的 turn，不代表任务完成；队长根据交付和证据判断进度。等待按宿主策略（`list_agents` → 唤醒 inactive 的必要队员 → `wait_agent` → 重新查看）；预计较久时把 `timeout_ms` 设长（上限 1 小时），减少空转。`failed` 表示创建失败，这位队员不会工作，原计划交给它的工作另行安排。队员中途停下、被中断或工作改派时，它认领的任务不会自动释放，由队长用 `team_task_update` 的 release 或 reassign 处理。 队长收工前自行核对交付与整体目标。代码任务检查改动清单、差异和新增文件，按风险阅读必要上下文，并执行与改动相称的验证；调查任务核对关键证据和结论适用范围。队员报告是验收输入，不能代替队长判断。 必要任务完成并验收后才能报告完成；未解决、未验证或阻塞的部分如实说明。汇报前调用一次 `get_spawn_route`，按其中的 `applied` 列出各队员负责的部分和实际路由；早先的结果行可能已被压缩。修改队员负责的文件前先协调，避免对方仍在写入。 ## 默认路由 provider 和 model 已填写时，直接按下面的默认路由创建；为空时，先确认用户希望使用的路由，也可以明确选择跟随队长。已有授权不重复询问。只有用户明确要求更改默认路由时才修改下面三项的值，临时选择只用于当次创建。 - provider: `` - model: `` - reasoningEffort: `` ## 每次创建 插件只提供路由能力，不读取本文件。先确定用户已授权的路由，比较 provider、model 和 reasoningEffort，不能只比较模型名。 1. 每位 fresh 队员创建前先登记，登记后紧接着创建： - 使用默认路由或用户已授权的其他路由：调用 `arm_spawn_route`，传入 provider、model 和已设置的 reasoningEffort。同模型但思考强度不同也要登记。 - 用户明确选择跟随队长：调用 `arm_spawn_route({"follow": true})`。 登记后紧接着调用 `spawn_teammate`，`context` 用 `fresh`。两者可以写在同一步里，宿主会按顺序逐个执行：每位队员写成相邻的「`arm_spawn_route` → `spawn_teammate`」一对，多位队员可以在同一步里一对接一对地写。不要先连续登记再连续创建，后一次登记会顶掉前一次。一次登记只给紧接着的这一次创建使用。 2. 明确完全跟随队长且需要队长之前几轮的对话时，用 `fork`，无需登记。 3. 创建返回后，核对 `member-model:` 说明：普通调用时它附在结果末尾；在 run_code 里调用时，它作为单独的提示出现在运行结果之后。provider、model 和思考强度应与授权路由一致。只看这条说明，结果 JSON 里的 `provider` 是创建方式（spawn 或 fork），不是模型供应商；看不到说明时，用 `get_spawn_route` 的 `applied` 核对。出现 `WARNING` 或与授权不一致时，停止继续创建，把这条说明原样告诉用户，并用中文说明哪里不一致，等用户决定。 4. 使用默认路由以外的路由，需要用户已有授权；没有授权才询问。不要自行切换模型或强度。 `spawn_teammate` 没有模型参数，不要在创建参数里传模型。返回 armed:false、创建失败、被要求先登记（`MEMBER_MODEL_ARM_REQUIRED`）、需要查看或清除登记时，按 `references/spawn-route.md` 处理。 ## 约束 - 只有队长可以 `spawn_teammate`；队员不再委派，见协作要求。 - 名字用小写 kebab-case，不能是 `lead`；用过的名字（包括创建失败的）不能再用。 - 写入范围只是提示，不是锁：同一批文件不要让两人同时写。全量构建、测试、格式化等会改共享产物的命令由队长安排，不要几个人同时跑。