mcpField
M
merge-open-prs

merge-open-prs

github.com/jssblck开发01.7k 次安装1 天前更新
代码仓库

关于 merge-open-prs

merge-open-prs 是按仓库合并策略逐个处理开放 PR 的开发技能，面向负责批量合并的维护者。它先固定工作集，再安排顺序、检查门槛，并在每次合并后复核剩余 PR。

主要功能

  1. 01快照并固定待处理 PR 集合
  2. 02按依赖与影响范围安排合并顺序
  3. 03检查仓库合并门槛与策略
  4. 04逐个验证并通过 Forge 合并
  5. 05核验默认分支结果并报告

适用场景

  1. 01按既定顺序处理多个开放 PR
  2. 02处理 PR 冲突与必要的分支更新
  3. 03确认合并后的默认分支验证结果

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/jssblck/agents --skill merge-open-prs

安装后在 Claude Code 中输入/merge-open-prs确认已加载。

附带文件agents/openai.yaml

详细介绍

合并未合并的 PR

记录未合并 PR 的快照。这份列表就是工作集。通过代码托管平台逐个合并每个 PR，并按能让后续 PR 更新到默认分支的顺序进行。不要将彼此独立的 PR 组合成一个堆栈，也不要用一个合并后的 PR 替换工作集。

常规规则：

  • 工作集不会扩大。 快照之后创建的 PR 一律忽略。每次合并后，将剩余的未合并 PR 与工作集进行比较；绝不合并额外的 PR。
  • 仓库的合并策略决定新鲜度要求。 每次合并后，重新检查剩余的 PR。只有遇到冲突、依赖项变更，或仓库明确要求保持新鲜度时，才更新分支。仅基分支发生变动，不会使未更改 PR head 上已通过的检查失效。
  • 每个 PR 都必须通过代码托管平台合并。 绝不要合并到本地默认分支后再推送，也不要直接推送到默认分支。只在 PR 自己的分支上进行本地 Git 操作，并在之后移除临时工作树。

1. 创建工作集快照

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}'

读取每一页。如果用户指定了 PR，则以这些 PR 作为工作集；否则，所有未合并的 PR 都属于工作集。记录编号、head SHA 和 head 分支。

除非只有一个显而易见的 PR，否则请创建文件重叠映射：

gh pr view <n> --json files,headRefName,headRefOid,baseRefName,isDraft,reviewDecision,statusCheckRollup,isCrossRepository,maintainerCanModify
gh pr diff <n>

尚未准备就绪的 PR（草稿、请求了更改）仍属于工作集。使其满足合并条件；不要将其移出工作集，也不要在收到用户指示前，在尚未答复的更改请求存在时合并它。

如果工作集为空，请停止。

2. 选择合并顺序

文件互不重叠的 PR 无论按什么顺序合并都不会产生文本冲突，因此应根据语义和可验证性排序。优先级如下：

  • 小型、独立的 PR 优先（配置调整、依赖项升级、能帮助验证后续 PR 的工具）。
  • 先合并基础 PR，再合并依赖它的 PR：如果一个 PR 调用了另一个 PR 新增的内容，则先合并依赖项。
  • 共享状态的 PR 最后合并：版本常量、迁移编号或已签入的生成产物，都会与此前已合并的内容叠加。
  • 其他情况按影响范围排序，从最小的开始。

如果某个 PR 的基分支是工作集中的另一个 PR，则先合并其父 PR。现有的基分支链可作为排序依据。用户指定的顺序优先。开始前说明合并顺序，并为每个 PR 给出一句理由。

3. 了解门槛要求

gh repo view --json mergeCommitAllowed,squashMergeAllowed,rebaseMergeAllowed
gh api repos/{owner}/{repo}/branches/{branch}/protection   # may 404 even when gated
gh api repos/{owner}/{repo}/rulesets

在 gh pr merge 上明确传入仓库的合并方法。规则集和经典保护是分开的；请分别检查两者是否要求通过检查、审核，以及严格的最新状态策略。

4. 合并每个 PR

在临时工作树中操作。按顺序处理每个 PR：

  1. 获取更新。记录默认分支的最新提交。
  2. 如果此 PR 的目标分支是工作集中的另一个 PR，等待该父 PR 合并。若 GitHub 尚未自动调整目标分支，则使用 gh pr edit <n> --base <default-branch> 调整。
  3. 根据仓库策略检查此 PR 是否需要更新目标分支。使用 resolve-pr-conflicts 在其分支上解决冲突。确认 isCrossRepository 和 maintainerCanModify 与你将要更新的远程仓库相符。除非已获授权，否则重写不属于你的分支前，必须先获得明确批准，并披露每次重写。
  4. 推送任何必要的更新。草稿 PR 会阻止合并：先运行 gh pr ready；若草稿是有意设置的，需遵循用户指示。
  5. 使用仓库自身的检查验证此 PR：构建、格式检查、代码检查，以及其影响范围内的测试。使用 babysit 等待此 PR 的所有必需检查通过。若无法基于当前默认分支使 PR 达到可合并状态，请停止并询问。
  6. 重新读取 head SHA、可合并状态和仓库门禁。新的 head 需要通过自己的检查。只有在仓库策略要求或出现新冲突时，才需要再次更新目标分支。然后：
gh pr view <n> --json headRefOid
gh pr merge <n> <verified-method-flag> --delete-branch --match-head-commit <sha>

合并队列会将 PR 加入队列并自行选择合并方式；等待其合并后再开始处理下一个 PR。

如果队友向工作集分支推送了提交，请检查并保留他们的更改，并验证新的 head。只有在所有权或预期的解决方式不明确时才询问。已关闭的 PR 无法再合并：报告此情况，并继续处理互相独立的 PR。如果有人合并了工作集中的 PR，请继续处理剩余 PR。

只有在获得明确批准并在报告中披露的情况下，才能使用 --admin。

最后一个 PR 合并后，在默认分支上验证仓库要求的集成结果。如果 CI 运行提供了所需证据，则使用该结果；对于未覆盖的风险，运行额外的本地检查。移除工作树。

5. 报告

  1. 工作集中的 PR、作为后续到达而忽略的 PR，以及文件是否有重叠。
  2. 合并顺序及每项的原因。任何未合并的工作集 PR，以及未合并的原因。
  3. 已解决的冲突、已重写的分支，以及任何绕过操作。
  4. 默认分支的变更，以及你对此采取的措施。
  5. 运行了哪些检查、哪些检查通过，包括在最终默认分支上的检查。
  6. 最终默认分支 SHA 和仍处于打开状态的 PR。

如果请求还包括发布后续操作，则在合并提交的 CI 通过后使用 $tag-release。

评论

支持 Markdown