用途：把一份已写好规格的功能，拆成父 issue 下已有的子 issue 作为工作包，每个子 issue 交给一个 /implement 代理，在各自 worktree 上并行实现，由编排者负责整体推进与合并。规则零明确：不要自行切分或映射工作，子 issue 就是工作包，缺失或不清时停下询问负责人，不得自行发明工作包；偏离预设路径的正确交付也会被拒绝。
角色：编排者只读、可用 gh、可派生代理，不编辑 src/，负责排序、中继、阶段间验证、合并、清理与 ops 侧车；代理走完整 /implement 流程（原生领取、自己的 worktree、TDD、/code-review、自己的 PR），合并顺序、CI 观察、分支与 worktree 清理等机械收尾属于编排者。
账本：GitHub issue 即账本。发生相关事件或未经负责人决策时，编排者在父 issue、代理在子 issue 发评论，格式为 🤖 decision (bot) 开头，类型含 decision、question、blocker、progress，统一用 🤖 前缀；通过 gh issue comment N --body-file .temp/<f>.md 发布，不使用 heredoc。问题留在 issue 上，有容忍默认值时继续推进，不阻塞。
运行顺序：同步并拉取子 issue（git fetch && git pull --ff-only，确认 git branch --show-current，从 origin/main 起分支；子 issue 只能用 GraphQL 取，gh issue view 不渲染）；侦察与可行性（自行读接缝文件，对照当前行为 diff 规格，一次性外部设置如 webhook、OAuth、DNS、三方配置须对照当前提供方文档核实）；排序与热点（按 Blocked by 排序，共享文件热点串行或预先约定冲突姿态）；派生代理（每个子 issue 一个，提示词来自 package-prompt.md，顺序敏感规则写进原始提示）；中继与验证（代理的 /code-review 子级报告给编排者，需核对可观察状态，如 origin 分支、git diff --stat、修复是否在 diff 中）；合并（CI 绿后 gh run watch <id> --exit-status && gh pr merge <n> --squash --delete-branch 连成一条后台调用，第二个合并者需 rebase）；收尾（共享行文档只开一个最终 docs PR，不要按 ticket 开；无法触及的基础设施阻塞可记为终端状态并在 PR 上记 blocker；在父 issue 发布最终 🤖 汇总）。更多内容见 ops.md。
限制：规则严格依赖预先拆好的子 issue 与规格；编排者不得改源码；外部依赖与 provider 文档需自行核实；未提供具体安装命令、收费、平台与效果信息。