dsh-agent-lead

多 Agent 并行开发项目时，最常见的失控是这样的：主 Agent 既规划又亲自改文件，子 Agent 之间互相踩脚，同一段代码被两个写者同时重写，验收变成走过场。dsh-agent-lead 的带队模式把角色一刀切开——开启 /lead 后，主 Agent 的 write、edit、str_replace_editor 被直接拒绝，它只剩理解、拆解、分发、验收和监工；所有改动类工作必须通过 assign 派给后台 subagent 执行。每次派活都会弹出模型选择框，用哪个模型、花多少钱，是你而不是框架的决定。

插件的核心机制是 scope 地盘契约加四步派活决策链。每个 subagent 创建时必须声明一句话职责摘要和文件/目录路径清单，写入会话级台账；派活前主 Agent 必须调 lead_status 查看地盘地图，系统自动做路径重叠检测，冲突时 assign 直接报错并列出重叠方。决策链六条规则按优先序一票否决：单一写者、返工归原主、独立评审必须新人、同域延续优先复用、独立新域必新建、污染即退役——从"要不要新建"到"怎么写完整任务书"都有据可循。

适合的场景是：你在用 dsh 做中等以上复杂度的多文件改动，希望有人（AI）帮你盯着全局但不希望它越权动手，也希望子任务之间不产生幽灵冲突。如果你是单人开发者、对模型成本敏感、且已经习惯用 subagent 拆分工作，带队模式会把你脑子里的"派工单"变成一套可审计的流程。