Loom Orchestration 是 Loom 体系中的编排规则技能，适用于需要派生多个子智能体、或作为某个 loom 阶段主智能体运行的工作场景。资料明确说明：单智能体会话不需要加载此技能；它应在派生子智能体或运行 loom 阶段之前加载。该技能以规则条文形式组织，覆盖会话启动、计划与阶段执行、提交与完成、子智能体前置声明、子智能体结构选择、模型分配与等待收割等环节。
在会话启动方面，规则要求先阅读 Knowledge Brief，在 .loom/work/signals/ 中确认会话 ID，扫描 EXECUTION PLAN 块并按规则派生；若没有信号，则询问用户。
在计划与阶段执行方面，仅在用户明确请求 loom 编排（如“use loom”“loom run”“create a loom plan”）或使用 /loom-plan-writer 时才创建 Loom 计划，且计划一律通过 /loom-plan-writer 编写，计划机制以 loom plan verify 为准，禁止凭记忆编写 loom YAML。执行阶段时，信号文件会携带该阶段的任务与完成清单（记忆记录、接线验证、小型对抗式代码审查、提交步骤），该清单具有约束力，须执行到底。
在提交与完成方面，提交须同时满足三项条件：所有子智能体、协调者、团队与 Workflow 均已返回并被吸收；完整门禁（构建、测试、lint、格式、验收）在完整代码树上通过，并由 loom-verifier 在一轮中报告；小型对抗式代码审查已返回、所有发现已修复且门禁再次通过。计划版本 2 的阶段中，loom stage complete 会强制第三项条件。交接不是提交未验证工作的理由。提交使用 git add 指定文件后运行 loom stage commit <stage-id> -m "type(scope): description"，并用 loom request status <id> --wait 90 等待，禁止直接运行 git commit。完成只能针对已稳定阶段，且是会话的最后一个动作；完成后继续工作被视为丢失的工作。
在子智能体结构方面，默认采用扁平扇出（不超过约 6 个工作任务）；任务超过约 6 个且落在 2-4 个互不相交领域时可用两层协调结构；需要智能体间消息或动态任务发现时才用智能体团队。规则强调分组任务：小任务交给一个子智能体而非每任务一个，避免两个子智能体写同一文件，并要求每个提示携带文件所有权表、声明技能、读回执等信息。
在等待与收割方面，规则要求先派生所有 worker 并记录其 ID，然后通过一次 loom subagents watch 绑定全部 worker，按退出码区分成功、超时、失败、重复等待、身份未知和挂起等情形；仅退出 0 允许完成。收割每个 worker 的终端报告只能一次，不得轮询 list 或 harvest。子智能体是一次性的，需要后续工作应重新派生。
在模型分配方面，规则将委派视为成本决策：主智能体仅在自己修改不超过 20 行、涉及最多 2 个已读文件、无需进一步探索且一条命令可验证时才自行修改，否则委派。模型按每个子智能体的具体工作选择，默认向下选择：haiku 用于机械性编辑、样板与简单单元测试；sonnet 或 codex 用于常见实现与集成测试；opus 用于主流架构与算法实现，困难调试时以 effort: xhigh 派生；fable 仅用于视觉/UI 设计、委派修复后仍存活的缺陷或极难的算法设计。升级须基于证据，失败一次后升一级，不得基于直觉升级。
限制方面：该技能仅适用于 Claude 子智能体（codex 转发有独立规则）；loom subagents watch 在 loom 阶段之外不可用，需要 LOOM_STAGE_ID、LOOM_SESSION_ID 和 LOOM_WORK_DIR，缺失时退出码为 5；禁止给子智能体派生传 name（团队场景除外）。资料未提供该技能的安装命令、收费模式、平台支持范围或具体效果数据。