orchestrate

在 worktree 上通过并行 /implement 子 Agent 实现预先定义的功能。

规则零

绝不自行拆分或规划工作。父级 issue 的子 issue 就是工作包：获取它们，并将每个子 issue 的原文交给一个 /implement Agent。若缺少子 issue 或内容不明确 → 停下并询问负责人；不要自行编造工作包。必须忠实遵循流程 — 即使交付成果正确，只要不是按预先定义的路径完成，也会被拒收。

角色

• 协调者（你）：只读操作 + gh + 启动 Agent。绝不编辑 src/。你的工作：安排顺序、传递信息、在各阶段之间验证、合并、清理、运维旁路任务（见 ops.md）。
• Agent：执行完整的 /implement 流程 — 原生认领、使用自己的 worktree、TDD、/code-review、创建自己的 PR。不要在这里重复这些工作。
• 机械性收尾工作（合并顺序、CI 监控、分支/worktree 清理）由协调者负责。Agent 的工作到“PR 已打开 + 报告”为止。

台账

GitHub issue 就是台账。每当发生相关事项或在没有负责人参与的情况下作出决策时，都要发布简要评论 — 协调者在父级 issue 上发布，每个 Agent 在自己的子 issue 上发布：

🤖 decision (bot): <one line>
<2–4 lines: why, link>

类型：decision | question | blocker | progress。始终添加 🤖 前缀；决策必须明确标注 (bot)。通过 gh issue comment N --body-file .temp/<f>.md 发布（heredoc 会被阻止）。将问题发布在 issue 上；如果存在宽松默认值，就继续运行 — 不要因此阻塞。

运行顺序

1. 同步并获取子问题。 git fetch && git pull --ff-only（主检出目录的分支可能已偏离——通过 git branch --show-current 验证；始终从 origin/$(node .agents/skills/verify/scripts/default-branch.mjs) 创建分支）。然后获取子问题——只能使用 GraphQL，gh issue view 不会显示它们：

   gh api graphql -f query='query{ repository(owner:"$OWNER",name:"$REPO"){ issue(number:$N){ subIssues(first:50){ nodes{ number title state } } } } }'
   

   切勿仅凭 CLI 输出就断言某项 GitHub 功能不存在。完成条件：已列出所有子问题及其「阻塞关系」，或已询问负责人。
2. 勘察并评估可行性。 亲自阅读接口文件——Agent 的总结可能遗漏 API 缺口。在启动受影响的包之前，对照当前行为检查规范。规范可能由 AI 编写：任何一次性的外部设置步骤（webhook、OAuth 应用、DNS、第三方配置）都必须先对照当前提供商文档核实，再让 Agent 写入文档——例如，webhook 需要 SECRET，而不是 token；projects_v2_item 事件仅适用于组织 webhook。发现缺口 → 在台账中记录为 question。完成条件：每项外部环境假设都已核实或记录在台账中。
3. 安排顺序并标记热点。 根据每个工单的「阻塞关系」安排顺序。标记涉及共享文件的热点（例如，一份 ADR 需要接受多个工单的修订）：将它们串行处理，或在提示词中预先约定冲突处理方式（「共享文件的改动只做增量添加；后合并者先 rebase」）。「仅新增文件」＝可并行；「涉及共享文件」＝单人负责。
4. 启动 Agent。 每个子问题启动一个 /implement Agent，提示词根据 package-prompt.md 编写。与顺序相关的规则（PR 前 rebase、冲突处理方式、合并顺序）必须写入初始提示词——执行过程中发送的消息可能与 Agent 的 push 同时发生，导致送达太晚。
5. 转达并验证。 Agent 的 /code-review 子 Agent 会向你报告，而不是向它报告——及时转达结论和修复清单；转达环节也可作为你的 QA 检查点。空闲 ≠ 完成：收到任何「已完成」信号后采取行动前，先验证可观察状态——分支已推送到 origin、git diff --stat、修复确实出现在 diff 中（而不只是确认消息）。每次转达后，都要预期还会有一轮往返。提醒时说「完成剩余步骤」，切勿说「现在 push」——催促过急会让 Agent 跳过自己的 QA。
6. 合并。 仅在 CI 通过后执行：在一次后台调用中串联 gh run watch <id> --exit-status && gh pr merge <n> --squash --delete-branch && <cleanup>。合并顺序由你负责；后合并者先 rebase。完成条件：每个子问题都恰好有一个已合并的 PR，并附带 Closes #<sub>。
7. 收尾。 共享行文档只用一个最终文档 PR（当前重点是 CLAUDE.md）——绝不按工单分别提交。无法访问的基础设施阻塞项（Neon/Vercel 控制台仅负责人可访问）可作为合理的终止状态：在 PR 上将其记录为 blocker，并附上证据和负责人需采取的操作。在父问题上发布最终的 🤖 统计。

从较早归档的运行记录中查找补救方法、部署诊断、Projects v2 限制及破坏性脚本规则：ops.md。