Lead Orchestration 是 fusengine/claude-plugins 仓库中的一个技能，定位为主会话（LEAD）在多智能体协作场景下的编排方法。它适用于这样的情形：你作为主会话收到一个需要动用多个智能体的请求，需要负责受理、路由、写任务书、跟进、处理阻塞、验证、沉淀经验和汇报。资料说明该技能存在的动因是负责人反复替主会话干活，例如追问进度、重述被漏掉的部分、发现主会话声称已完成但实际存在的视觉缺陷、亲手输入本可由主会话执行的步骤；技能中的每一步都对应上述一种失败模式。
主要能力与流程分为九个阶段。受理（Intake）：把请求重述为带编号、带名称的清单，覆盖负面约束（如“不要动 X”）和负责人发来的参考物（原型图、文件、样式）；任务途中负责人发来消息视为对清单的追加，应补充该部分、通知运行中的智能体并继续，只有明确要求停止才停。路由（Route）：按任务拆分，一个任务一个智能体，任务拥有它需要的所有文件；两个任务若需改同一文件，则合并或串行（后者在磁盘上验证前者后才开始）；还需根据项目检测选择领域智能体及其要加载的技能，主会话只加载 lead-orchestration（规划时加 apex-methodology），不自行应用领域技能；派发前往文件夹前先用 ls -lT <folder> 与 date 检查修改时间，约 5 分钟内被修改视为繁忙，不派人前往；并以一行说明预算（智能体数量、预计时长）。任务书（Brief）：按 brief-template.md 填写上下文、确切文件、负责人原话引用、护栏、所需证明和报告格式，要求零上下文智能体也能执行；受保护路径仅在负责人点名时写入任务书，并引用其原句。委派（Delegate）：主会话不编辑项目文件，只编辑自己的记忆与草稿；任何改动（哪怕一行技能或规则）都交给智能体，唯一例外是对已定位且已测量的缺陷在两次委派失败后由主会话亲自阅读并修复；外部执行器（Kimi / Codex / Cursor）只写代码，从不 push、PR、合并、打标签或发布，发布走 fuse-ai-pilot:commit 智能体。跟进（Follow）：按固定节奏轮询每个运行中的执行器（输出文件、修改时间、记录），主动向负责人给出一行状态（完成/受阻/下一步）；停滞即自上次轮询以来磁盘无新输出，通过 SendMessage 指明下一步；恢复同一智能体而非另起重复任务；重启上限为两次失败的委派后转为自查修复，其他受阻任务超过规则 08 的 3 轮周期则带根因说明上报负责人，不做重启循环；消息不会停止智能体，需用 TaskStop 并确认修改时间冻结。阻塞（Blocks）：交还前先尝试所有被授权的路径，如用移入废纸篓代替删除（mv <f> ~/.Trash/）、用可脚本化来源代替被拦截站点、用页面自身文件/CDN 链接或 API 代替反爬页面、用真实浏览器会话代替普通抓取；钩子或门禁拒绝时，先读其源码并照其提示执行，再判断是否为缺陷；只有 CAPTCHA、密码或钩子要求负责人输入的审批才交回，并给出一行需输入的确切文本。验证（Verify）：打开真实交付物，如截图、抽帧、针对真实目标（开发服务器、数据库、已安装版本，而非清单或隔离夹具）的运行时；逐项勾选清单；代码改动后跑一次 sniper，在任何根因判断、完成/已验证声明、不可逆操作或第二次修复前跑 challenger；未证实的部分写“未验证”，已证实的要连同证据一起声明为保证。学习（Learn）：负责人的每次纠正，当轮在源仓库中失败的那个技能/智能体里写一行，仅在负责人要求时同步到市场；持久偏好记入记忆。汇报（Report）：用负责人的语言，第一行给答案（完成/未完成/受阻），总共不超过 10 行，给一条建议和下一步，若某一选择明显更优则不给选项菜单；交付物放在负责人可见的路径，而非仅隐藏目录。
资料还列出关键规则：任务书即授权，其中的可逆步骤无需再问；不得编造负责人未说明的上限、路径或约束；智能体简短的正面结论不具全局性，需复核其是否覆盖被点名缺陷；与你的测量相矛盾的负责人判断以负责人为准，并传播到所有已派发的任务书。参考文件包括 brief-template.md（撰写任务书）与 worked-examples.md（真实会话中的差与好主会话行为）。资料中未提供安装命令、收费或价格信息。