mcpField
R
relay-merge

relay-merge

github.com/sungjunlee開発043 回インストール5 週間前に更新
リポジトリ

relay-merge について

relay-merge は、relay-review が合格判定を記録した後に、対応する GitHub のマージを完了するスキルです。PR、保持されたワークツリー、永続化されたレビュー証拠が同じコミットを示すことを確認し、マージ記録と後処理を行います。

主な機能

  1. 01読み取り専用のマージ可否ゲート
  2. 02PR とワークツリー間のコミット照合
  3. 03方式を指定した GitHub の明示的マージ
  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 Merge

relay-review が合格判定を記録した後、サポート対象の GitHub ルートでのみ使用してください。 ローカルの Reviewed Result は正規のリカバリーを経てクローズし、このスキルには進みません。 マージは引き続きオペレーターによる明示的な操作です。レビューのバイパスや可変状態の上書きは Relay の契約に含まれません。

Inputs

  • 不変の Relay run.json と追記専用の events.jsonl。
  • 保持されている実行用ワークツリーと、そのワークツリーに対応する正確なオープン PR。
  • --run-id または明示的な --run-dir。
  • 任意の不透明なオペレーター ID、マージ方式、操作 ID。

Process

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 の事実を 1 件追記します。その後、クリーンなリンク済みワークツリーを削除します。ダーティ、変更済み、未登録、またはリポジトリが一致しないワークツリーは、強制削除せず保持されます。 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 の比較機能ではファイルの証拠が最大 300 件に制限されます。この上限への到達と、コミットのページネーションが不完全な場合は、安全側に失敗します。

GitHub のマージ API には、アトミックなソース SHA 期待値ガード（--match-head-commit）がありますが、ベースの期待値に対する compare-and-swap はありません。そのため、リクエスト前にベースの付け替えが検出された場合は安全側に失敗します。一方、チェック後からリクエスト前までに外部のコラボレーターが PR メタデータを変更する残存のベース競合は、弱められたソース SHA や設定済みベースの不変条件ではなく、文書化された GitHub プラットフォーム上の脅威境界です。 マージリクエスト後のマージキューまたはベースの移動は再開時に再確認されますが、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 対応