mcpField
R
relay-merge

relay-merge

github.com/sungjunlee开发043 次安装5 周前更新
代码仓库

关于 relay-merge

relay-merge 是在 relay-review 给出通过结论后完成受支持 GitHub 合并的技能。它会核对 PR、保留的工作树与持久化审查证据是否指向同一提交，再记录合并并处理清理。

主要功能

  1. 01只读合并资格检查
  2. 02核对 PR 与工作树的提交身份
  3. 03按指定方式显式合并 GitHub PR
  4. 04支持安全重试的授权与回执
  5. 05有条件清理关联工作树

适用场景

  1. 01Relay 审查通过后合并 GitHub PR
  2. 02恢复中断的合并或待处理的合并队列请求

安装

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

$npx skills add https://github.com/sungjunlee/dev-relay --skill relay-merge

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

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

references/
append-learnings.md
full-gate.md
legacy-score-reports.md
operator-emergencies.md
scripts/
append-learnings.js
finalize-run-terminal.js
finalize-run.js
gate-check.js
review-gate.js
run-full-gate-helpers.js
run-full-gate.js
sprint-owner.js
sprint-state-helpers.js
sprint-state.js

详细介绍

Relay 合并

仅用于 relay-review 记录通过判定后的受支持 GitHub 路径。本地 Reviewed Result 会通过规范恢复流程关闭，绝不会进入此技能。合并仍是操作员明确执行的操作；绕过评审和覆盖可变状态不属于 Relay 合约。

输入

  • 不可变的 Relay run.json 和仅追加的 events.jsonl。
  • 保留的运行工作树及其对应的确切未关闭 PR。
  • --run-id 或显式指定的 --run-dir。
  • 可选的不透明操作员身份、合并方法和操作 ID。

流程

1. 只读门禁
RUN_ID=<run-id-from-dispatch>
node "${RELAY_SKILL_ROOT:-skills}/relay-merge/scripts/gate-check.js" \
  --repo . --run-id "$RUN_ID" --json

门禁会调用规范的 Relay inspect，并在以下各项未能指向同一提交时默认拒绝：

  • 实时 GitHub PR 头提交和远程分支；
  • 保留工作树的 HEAD 和 Git 树；
  • 持久化 PR 事实；
  • 通过的验证事实；
  • 独立评审事实和冻结的 Done Criteria 哈希。

如果派生操作不是 merge，请遵循该操作。切勿根据 PR 评论、已退役状态或缺失的证据合成合并覆盖项。

2. 明确合并并清理
node "${RELAY_SKILL_ROOT:-skills}/relay-merge/scripts/finalize-run.js" \
  --repo . --run-id "$RUN_ID" --merge-method squash --json

finalize-run.js 会在获取运行锁后再次检查，签发持久化合并授权，调用 GitHub，重新验证确切的已合并 PR，并追加一条 merge_recorded 事实。随后，它会移除干净的关联工作树。对于已修改、已变更、未注册或仓库不匹配的工作树，会予以保留，而不会强行移除。 Finalize 不会调用 GitHub REST /user 端点；--actor 用于记录合并操作员。

授权和合并回执可确保在崩溃后重试时保持幂等。中断后，请使用相同操作员和方法重新运行同一命令。持久化授权值具有权威性；更改任一值都会在再次发出 GitHub 合并请求前失败。若操作员需要稳定且可外部记录的关联 ID，请使用 --operation-id <id>。--no-cleanup 会有意保留工作树；之后普通的重新运行会执行最终清理，而不会再次合并。

GitHub 可能会将请求纳入合并队列，同时 PR 仍保持未关闭状态。这会返回 status: merge_pending；重新运行时会读取持久化的待处理请求，而不会再次提交，只有在 GitHub 报告确切的已评审头提交已合并后，才会记录合并。

在外部调用前，Finalize 会立即 fsync 一条不可变的请求意图。如果崩溃后留下该意图，但 GitHub 无法证明确切的合并已完成，也无法证明请求已排入队列，Finalize 会以结果不明确错误失败，并要求进行规范恢复，以免冒险重复调用。

最终预检会重新检查不可变的已配置基准分支和源 SHA。GitHub 评审阶段会基于实时评审基准分支，以三点语义暂存补丁，因此评审前必须进行的基准分支更新不会将仅属于基准分支的路径归到该分支名下。如果基准提交在评审后前进，Finalize 要求已评审基准提交是其祖先，并将确切的已评审 Git 路径集与 GitHub 基准分支前进路径进行比较。无重叠时仍可合并；有重叠时则会以类型化错误失败，并要求将分支更新到当前基准分支，然后进行规范验证。随后重新评审时，会使用新的实时 PR 基准分支作为三点比较的左侧，因此只会暂存分支独有的更改。路径重叠仅为代理判断，因此不同路径之间的语义冲突不在此证明范围内。GitHub compare 会将文件证据限制为 300 条；达到此边界或提交分页不完整时，都会默认拒绝。

GitHub 合并 API 提供原子性的预期源 SHA 防护（--match-head-commit），但不提供预期基准分支的比较并交换。因此，请求前检测到基准分支重定向时会默认拒绝；而剩余的“检查后、请求前”基准分支竞态窗口（外部协作者在此期间更改 PR 元数据）属于有文档记录的 GitHub 平台威胁边界，并不意味着放宽源 SHA 或已配置基准分支不变量。 请求后会在恢复时重新检查合并队列／基准分支的变动，但 Relay 无法撤销外部已完成的合并。

3. 可选的合并后项目更新

append-learnings.js 和 dev-backlog 冲刺更新是独立的项目变更。只有在 finalize-run.js 返回 status: merged 后，才明确运行这些操作； 它们不属于合并事务的一部分。

有关由标记限定范围的经验写入器，请参阅 references/append-learnings.md；有关 恢复指南，请参阅 references/operator-emergencies.md。 串行执行的完整套件门禁指南见 references/full-gate.md。

评论

支持 Markdown