需要一次性合并全部开放 PR 或指定 PR…

当被要求合并所有开放 PR 或一组指定 PR 时，按快照工作集逐个通过 GitHub/forge 安全合并并报告。

适用场景

解决思路

1. 先对开放 PR 做快照；该列表就是工作集。通过 forge 一次一个地合并每个 PR，顺序要保证后续 PR 仍能更新到默认分支；不要把相互独立的 PR 组装成 stack，也不要用一个合并 PR 替代工作集。
2. 工作集不增长：快照之后新开的 PR 忽略。每次合并后，将剩余开放 PR 与工作集比对；绝不合并额外 PR。
3. 用仓库合并策略控制 freshness：每次合并后重新检查剩余 PR。仅因冲突、依赖变更或仓库明确的新鲜度要求才更新分支；仅因 base 移动不会使未变更 PR head 上已通过的检查失效。
4. 每个 PR 都必须通过 forge 落地。绝不合并到本地默认分支再 push，也绝不直接 push 到默认分支；本地 git 操作只允许在 PR 自己的分支上，在临时 worktree 中进行，结束后移除。
5. 运行快照命令：`gh api --paginate 'repos/{owner}/{repo}/pulls?state=open&per_page=100' --jq '.[] | {number,title,headRefName:.head.ref,headRefOid:.head.sha,baseRefName:.base.ref,isDraft:.draft}'`。
6. 读取每一页。如果用户指定了具体 PR，这些就是工作集；否则所有开放 PR 都是。记录编号、head SHA 和 head 分支。
7. 除单个显而易见的 PR 外，构建文件重叠图：`gh pr view <n> --json files,headRefName,headRefOid,baseRefName,isDraft,reviewDecision,statusCheckRollup,isCrossRepository,maintainerCanModify` 和 `gh pr diff <n>`。
8. 未就绪的 PR（draft、要求修改）仍留在工作集。使它变为可合并；不要丢弃它，也不要在未获用户指示时越过未处理的 requested changes 合并。
9. 如果工作集为空，停止。
10. 文件不重叠的 PR 在任何顺序下都不会文本冲突，因此按语义和可验证性排序。优先级顺序：小而独立的 PR 在前（配置调整、依赖升级、有助于验证后续 PR 的工具）。
11. 基础先于依赖：当一个 PR 调用另一个 PR 新增的内容时，先合并被依赖者。
12. 共享状态 PR 最后：版本常量、迁移编号或已检入的生成产物会与所有已落地内容叠加。
13. 否则按爆炸半径从小到大排序。
14. 如果某个 PR 的 base 是另一个工作集 PR，先合并父 PR。已有 base 链就是该顺序的证据。用户指定的顺序优先。开始前说明顺序以及每个 PR 的一行理由。
15. 了解 gate：`gh repo view --json mergeCommitAllowed,squashMergeAllowed,rebaseMergeAllowed`；`gh api repos/{owner}/{repo}/branches/{branch}/protection`（即使有门禁也可能 404）；`gh api repos/{owner}/{repo}/rulesets`。
16. 在 `gh pr merge` 上显式传入仓库的合并方法。Rulesets 和 classic protection 是分开的；两者都要检查 required checks、required reviews 和 strict up-to-date policy。
17. 在临时 worktree 中工作。按顺序对每个 PR 执行：fetch，并记录默认分支 tip。
18. 如果该 PR 的 base 是另一个工作集 PR，等到父 PR 已合并。若 GitHub 尚未自动处理，用 `gh pr edit <n> --base <default-branch>` 重定向 base。
19. 按仓库策略检查该 PR 是否需要 base 更新。若冲突，在其分支上按 resolve-pr-conflicts 技能（`../resolve-pr-conflicts/SKILL.md`）解决。
20. 确认 `isCrossRepository` 和 `maintainerCanModify` 与你将要更新的 remote 匹配。除非已获授权，重写你不拥有的分支前要获得明确批准；每次重写都要披露。
21. 推送任何需要的更新。Draft 会阻塞：先用 `gh pr ready`，如果 draft 是有意为之，则需用户指示。
22. 用仓库自己的检查验证该 PR：build、format、lint，以及针对其爆炸半径的 tests。使用 babysit 技能（`../babysit/SKILL.md`）等待该 PR 上每个必需检查变绿。如果该 PR 在当前默认分支上无法变为可合并，停止并询问。
23. 重新读取 head SHA、可合并性和仓库门禁。新的 head 需要自己通过检查。base 移动只有在仓库策略或新冲突要求时才需要再次更新。然后运行：`gh pr view <n> --json headRefOid` 和 `gh pr merge <n> <verified-method-flag> --delete-branch --match-head-commit <sha>`。
24. Merge queue 会把 PR 排入队列并选择自己的方法；等到它落地后再开始下一个 PR。
25. 如果队友推送到工作集分支，检查并保留他们的更改；尽可能协调，并验证新的 head。只有在所有权或预期解决方案不清楚时才询问。
26. 已关闭的 PR 不再可合并：报告它，并继续处理独立 PR。
27. 如果某人合并了某个工作集 PR，继续处理剩余 PR。
28. `--admin` 仅在明确批准时使用，并在报告中披露。
29. 最后一个合并后，验证默认分支上仓库要求的集成结果。当其提供所需证据时使用它的 CI run；对未覆盖风险运行额外本地检查。移除 worktree。
30. 报告：工作集 PR、作为后来到达而被忽略的 PR，以及文件是否重叠。
31. 报告：每个 PR 的合并顺序及理由。任何未合并的工作集 PR，以及原因。
32. 报告：已解决的冲突、被重写的分支、任何 bypass。
33. 报告：默认分支移动以及你对此做了什么。
34. 报告：你运行了什么、什么通过了，包括最终默认分支上的结果。
35. 报告：最终默认分支 SHA 和剩余开放 PR。
36. 如果请求串联发布，在合并提交上的 CI 变绿后使用 `$tag-release`。

适用边界 · 注意事项

• 不适用于非 GitHub 或无 gh CLI/forge 权限的环境；本技能依赖 gh 和 forge，无法在纯本地或其它代码托管平台直接执行。
• 不适用于用户要求把多个独立 PR 组装成 stack，或用单个合并 PR 替代工作集的场景。
• 不适用于需要绕过 required checks/reviews 或无明确批准直接 push 默认分支的场景（`--admin` 仅在有明确批准并披露时可用）。