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/main 创建分支）。然后获取子议题——只能使用 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 功能不存在。完成标准：列出所有子议题及其「Blocked by」边，或已询问负责人。
2. 调研并评估可行性。 亲自阅读接口文件——Agent 的摘要会遗漏 API 缺口。在启动受影响的包之前，先比较规范与当前行为。规范可能由 AI 编写：任何一次性外部设置步骤（Webhook、OAuth 应用、DNS、第三方配置）都要先对照服务提供商的最新文档核实，再让 Agent 将其写入文档——例如，Webhook 需要的是 SECRET，而不是令牌；projects_v2_item 事件仅适用于组织级 Webhook。发现缺口时，将其记入台账中的 question。完成标准：每项外部环境假设都已核实或记入台账。
3. 排序并标出热点。 根据每个工单的「Blocked by」排序。标出共用文件热点（例如，多个工单都要修改同一份 ADR）：将这些修改串行处理，或在提示词中提前约定冲突处理方式（「共用文件的修改应采用增量方式；后合并的分支需要变基」）。「仅新增文件」＝可并行；「修改共用文件」＝单一写入者。
4. 启动 Agent。 每个子议题启动一个 /implement Agent，提示词根据 package-prompt.md 编写。与顺序相关的规则（合并前变基、冲突处理方式、合并顺序）要写进原始提示词——执行过程中的消息可能与 Agent 的推送同时发生，因而迟到。
5. 转达并验证。 Agent 的 /code-review 子 Agent 会向你汇报，而不是向它汇报——及时转达审查结论和修复清单；转达过程也兼作你的 QA 检查点。空闲不等于完成：在对任何「已完成」信号采取行动之前，先验证可观察状态——分支位于 origin 上、git diff --stat 的结果，以及修复确实出现在差异中（而不只是得到确认）。每次转达后，都要预期还有一轮往返。提醒时说「完成剩余步骤」，绝不要说「现在推送」——仓促行事的 Agent 会跳过自己的 QA。
6. 合并。 仅在 CI 通过后执行：在一次后台调用中串联 gh run watch <id> --exit-status && gh pr merge <n> --squash --delete-branch && <cleanup>。合并顺序由你负责；后合并的分支需要变基。完成标准：每个子议题都恰有一个已合并 PR，且该 PR 包含 Closes #<sub>。
7. 收尾。 共用文档只提交一个最终文档 PR（当前重点是 CLAUDE.md）——绝不按工单分别提交。无法访问的基础设施阻塞项（Neon/Vercel 控制台仅负责人可访问）是合理的终止状态：在 PR 上将其记为 blocker，并附上证据和负责人需要执行的操作。在父议题上发布最终 🤖 统计。

从更早的归档运行中提取经验、部署诊断、Projects v2 限制和破坏性脚本规则：ops.md。