multi-agent-coordinatorlisted

# Multi-Agent Coordinator - 多代理协调专家 ## 与 bensz-collect-bugs 的协作约定 - 因本 skill 设计缺陷导致的 bug，先用 `bensz-collect-bugs` 规范记录到 `~/.bensz-skills/bugs/`，不要直接修改用户本地已安装的 skill 源码；若有 workaround，先记 bug，再继续完成任务。 - 只有用户明确要求“report bensz skills bugs”等公开上报时，��用本地 `gh` 上传新增 bug 到 `huangwb8/bensz-bugs`；不要 pull / clone 整个仓库。 目标：把“复杂开发任务”拆成可并行的独立任务，分派给子代理执行，并在任务间做质量门禁（代码审查 + 轻量测试），最后聚合成一致的可交付结果。 为满足社区推荐的 `SKILL.md` 500 行以内约束：完整细节/长示例已下沉到 `awesome-code/agents/multi-agent-coordinator/references/legacy-skill-full.md`。 ## 核心原则（Subagent-Driven Development） - 任务拆分要原子：每个任务有明确输入/输出/验收标准 - 每个任务用“全新子代理”：降低上下文污染与确认偏差 - 任务之间强制门禁：至少一次代码审查；必要时补回归测试 - 若上游分析已把某个 agent 标记为 `required`，该 agent 必须真的进入调度链；缺失时停止推进 - 结果必须可聚合：统一术语、接口约定、日志口径与错误处理风格 ## 何时使用 - 用户给出明确实施计划/任务清单，需要并行推进 - 任务跨度大（多文件/多模块/多领域），单线程容易遗漏或拖慢 - 需要严格质量门禁（合并前必须审查、必须验证） ## 输入 - 计划来源：用户文字 / `PLAN.md` / issue 列表 / TODO 列表 - 约束：时间、兼容性、目录边界、不可破坏性要求 - 验收：测试要求、性能目标、行为回归标准 ## 输出 - 一个可执行的“任务编排表”（任务 → 负责人子代理 → 依赖 → 验收） - 一份 `dispatch_manifest`，明确哪些 agent 属于 `required / preferred / optional` - 一组 `dispatch_receipts` 或缺失说明，证明 required agent 是否真的被调用 - 每个任务的结果摘要（改动点、风险、验证） - 最终聚合报告（P0/P1/P2 风险 + 下一步） ## 工作流 1. 读取计划并生成任务清单 - 将大任务拆成 3-15 个原子任务 - 为每个任务写清：目标、范围、验收、风险、依赖 2. 选择协调模式 - orchestrator：默认；中心协调器分派任务并统一口径 - peer-to-peer：小团队/低耦合；允许子代理互相同步但必须记录决定 - pipeline：强依赖链；按阶段推进（例如：设计→实现→测试→文档） 3. 分派任务（可并行） - 先读取上游 `dispatch_gate` - 若 `dispatch_gate.can_proceed = false`，立即停止，不要绕过 required agent 继续执行 - 若 `dispatch_gate.can_proceed = true`，