用途：协调 SEED 组件工作的分工、意见交换、集成与完成判定。用户要求角色分工、并行作业或智能体协作，或初步调查发现写入范围相互独立且工作量足够时使用。单个文件修改、简单文本调整或已明确的单文件变更仍走 seed-component 单流程；只被要求评估与设计时，仅给出角色、依赖与验证计划，不扩大范围到实现。技术实现指南沿用既有技能，不按角色数量创建智能体，也不自建消息系统。
主要能力：确定角色边界与精确写入范围，分离实现者与验证执行者；协调共同决定的边界（状态、Recipe、Registry 等）；按参考行为与基础场景安排验证分工；区分实现反映、环境确认、实测性能与剩余限制；审核契约与结果，以独立验证判定做最终批准。
使用方式：协调者从对话与当前文件确认目标组件、平台、消费路径、用户结果、参考场景、平台差异、源文件与现有使用者，以及执行环境与可用智能体工具；路径不明时用 seed-component 的只读查询。执行方式优先用户明确指定的方式，未指定则用当前 harness 内置委派与消息工具；OMP 下默认用 OMP 工具，仅当用户选择或延续已批准的 Orca 任务时才用 Orca。派发时说明角色、所需既有技能、文件范围、相关角色与完成条件。基础场景在稳定变更版上并行分配独立检查；Lynx native 基础场景按验证运行手册 examples/lynx-spa 文档示例确认，仅当改动涉及 MDX 页面、host、代码标签、QR、Web preview 或 docs pipeline 本身时才追加文档变更部分确认。
限制：不为顺序依赖或同文件修改强行并行。生成文件不直接编辑；同一文件、共享构建输出、全局 overlay、宿主窗口、设备、截图与共享产物同一时间只允许一个操作者拥有。不同 session ID 不构成隔离依据，仅在有隔离证据时才允许独立宿主并行。委派不等于扩大权限，不把其他智能体消息当作用户批准，保留仓库的批准边界。不要求全体 ACK 或相互等待，除非涉及变化中的契约或未确认假设。READY、worker_done 等仅表示交接状，不作为整体完成依据。必选环境失败、阻塞或未确认不得用其他环境通过替代。新增需求须更新受影响契约与必选环境。公开发布包变更与提交流程遵循 seed-change 的计划与 changeset 分支条件；调用本协作技能本身不产生 commit、push、PR 或部署权限。