mcpField
G
github-pr-merge

github-pr-merge

github.com/fvadicamo開発72279 回インストール7 週間前に更新
リポジトリ

github-pr-merge について

github-pr-mergeは、レビューへの返信、CI、マイルストーン、変更履歴を確認してGitHubのプルリクエストをマージするスキルです。確認手順、マージ方式、ブランチ処理、マージ後の整理も定めています。

主な機能

  1. 01未返信のレビューコメント確認
  2. 02テスト、Lint、CIの検証
  3. 03マイルストーンと変更履歴の確認
  4. 04マージ前のユーザー確認
  5. 05マージコミットとブランチ規則の適用
  6. 06マージ後のベースブランチ同期

活用シーン

  1. 01プルリクエストのマージ準備
  2. 02変更履歴の記載漏れの検出
  3. 03トピックブランチのdevelopへのマージ
  4. 04マージ後のマイルストーン確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/fvadicamo/dev-agent-skills --skill github-pr-merge

インストール後、Claude Code で/github-pr-mergeを入力して読み込まれたか確認します。

詳細

GitHub PR のマージ

マージ前チェックリストを検証し、マージ後のクリーンアップを行ってから、プルリクエストをマージします。

現在の PR

!gh pr view --json number,title,state -q '"PR #\(.number): \(.title) (\(.state))"' 2>/dev/null

基本的なワークフロー

1. コメントの状態を確認する

すべてのレビューコメントに少なくとも1件の返信があることを確認します。

REPO=$(gh repo view --json nameWithOwner -q '.nameWithOwner')
PR=$(gh pr view --json number -q '.number')

# Find unreplied comment IDs
gh api repos/$REPO/pulls/$PR/comments --jq '
  [.[] | select(.in_reply_to_id) | .in_reply_to_id] as $replied |
  [.[] | select(.in_reply_to_id == null) | select(.id | IN($replied[]) | not) | .id]
'

返信のないコメントがある場合:

  • マージ処理を停止します
  • ユーザーに次のように伝えます:"返信のないコメントが見つかりました:[IDs]。まず github-pr-review を実行してください。"
  • このスキルからコメントに返信することは絶対にしないでください
2. マイルストーンを確認する
gh pr view $PR --json milestone -q '.milestone.title // "none"'
  • マイルストーンが設定されている場合:ステップ5のチェックリスト概要に含めます
  • マイルストーンが設定されていない場合:未完了のマイルストーンがあるか確認し、ユーザーに警告します
gh api repos/$REPO/milestones --jq '[.[] | select(.state=="open")] | length'

未完了のマイルストーンがあるのに PR に設定されていない場合、チェックリストに次の警告を表示します。 - マイルストーン:⚠ 未設定(未完了のマイルストーンがあります)

マイルストーンが未設定でもマージをブロックしないでください。警告のみとします。

3. 検証を実行する

テスト、リンティングを実行し、CI チェックを検証します。続行する前に、すべて必ず成功している必要があります。

gh pr checks $PR
4. 変更履歴が完全であることを確認する

リポジトリに CHANGELOG.md がない場合はスキップします。それ以外の場合は、このマージで公開されるすべてのコミットが変更履歴に反映されていることを確認します。これにより、リリース昇格マージ(develop → main)で未記録のコミットが残らないようにします。

この PR がベースブランチに取り込むコミットと、追加される変更履歴の行を一覧表示します。

BASE=$(gh pr view $PR --json baseRefName -q .baseRefName)
HEAD=$(gh pr view $PR --json headRefName -q .headRefName)
git log --oneline origin/$BASE..origin/$HEAD
git diff origin/$BASE...origin/$HEAD -- CHANGELOG.md
  • リリースされる動作を変更するすべてのコミット(feat/fix/perf、動作に影響する refactor)には、対応する変更履歴の行が必ず必要です。リリースされる動作を変更しない純粋な chore/docs/test のコミットは省略してもかまいません。
  • リリース昇格マージの場合は、バージョンが更新されていること(一番上の ## [x.y.z] エントリーが新しいこと)と、マニフェストのバージョンと一致することも確認します。
  • 動作を変更するコミットが1つでも変更履歴から漏れている場合は、停止します。 未記録のコミットを報告し、マージ前に変更履歴とバージョンを更新するようユーザーに依頼します。このスキルから変更履歴を編集することは絶対にしないでください。
5. ユーザーに確認する

必ずチェックリストの概要を表示し、マージ前に確認を求めます。

Pre-merge checklist:
- Comments: all replied
- Tests: passing
- Lint: passing
- CI: green
- Milestone: v0.1.0 (or ⚠ not assigned)
- Changelog: complete (or n/a)

Ready to merge PR #X. Proceed?
6. マージを実行する

まずマージの方向を確認します。これにより、ヘッドブランチを削除できるかどうかが決まります。

gh pr view $PR --json baseRefName,headRefName -q '"\(.headRefName) -> \(.baseRefName)"'

ブランチ削除のルール:

  • トピックブランチ → develop(ヘッドが feature/fix などのブランチ):ブランチは役目を終えています。削除を提案し、--delete-branch を付けてマージします。
  • develop → main(またはヘッドが長期運用ブランチの場合):ヘッドブランチは絶対に削除しないでください。develop と main は永続的なブランチです。--delete-branch は省略し、削除を提案しないでください。
# Add --delete-branch ONLY for a topic branch merging into develop.
gh pr merge $PR --merge --delete-branch --body "$(cat <<'EOF'
- Key change 1
- Key change 2
- Key change 3

Reviews: N/N addressed
Tests: X passed (Y% cov)
Refs: Task N, Req M
EOF
)"

develop → main のマージでは、同じコマンドを --delete-branch なしで実行します。

マージ戦略:常に --merge(マージコミット)を使用し、スカッシュやリベースはしないでください。

7. マージ後のクリーンアップ

常に develop ではなく、マージを受け取ったブランチ(PR のベース)を同期します。

BASE=$(gh pr view $PR --json baseRefName -q .baseRefName)
git checkout "$BASE" && git pull origin "$BASE"
8. マイルストーンの完了を確認する

PR にマイルストーンが設定されていた場合、すべての項目がクローズされたかどうかを確認します。

MILESTONE=$(gh pr view $PR --json milestone -q '.milestone.number // empty')
if [ -n "$MILESTONE" ]; then
  gh api repos/$REPO/milestones/$MILESTONE \
    --jq '"Open: \(.open_issues) | Closed: \(.closed_issues) | \(.title)"'
fi
  • open_issues == 0 の場合:ユーザーに伝え、マイルストーンをクローズするか確認します
gh api repos/$REPO/milestones/$MILESTONE --method PATCH --field state="closed"
  • open_issues > 0 の場合:残っている未完了項目の数を報告します。対応は不要です。
  • ユーザーの明示的な確認なしに、マイルストーンを絶対に自動でクローズしないでください。

マージメッセージの形式

簡潔で見やすい git ログの形式:

- Key change 1 (what was added/fixed)
- Key change 2
- Key change 3

Reviews: 7/7 addressed (Gemini 5, Codex 2)
Tests: 628 passed (88% cov)
Refs: Task 8, Req 14-15
  • 変更点は最大3~5項目
  • レビューの概要、テスト結果、タスク参照はそれぞれ1行
  • 見出し(##)や冗長なセクションは使用しない
  • 全体で約10行以内

重要なルール

  • 必ずマージ前にテスト、Lint、CI チェックを実行します
  • 必ずすべてのレビューコメントに返信があることを確認します
  • 必ずマージ前にマイルストーンの割り当てを確認します(未設定の場合は警告しますが、処理は続行します)
  • 必ず(CHANGELOG があるリポジトリでは)今回のマージで公開される、動作を変更するすべてのコミットが CHANGELOG に記載されていることを確認します。記載漏れがあれば停止して報告します
  • 必ずマージを実行する前にユーザーの確認を得ます
  • 必ずマージコミット(--merge)を使用し、squash や rebase は行いません
  • develop にトピックブランチ(feature/fix など)をマージする場合に限り、必ずマージ時にヘッドブランチを削除します
  • 絶対にdevelop や main を削除しません。develop → main のマージでは --delete-branch を省略し、削除を提案しません
  • 必ずマージ後にマイルストーンの完了状況を確認し、未完了項目数を報告します
  • テスト、Lint、CI チェックに失敗した状態で絶対にマージしません
  • ユーザーの確認を絶対に省略しません
  • 明示的なユーザーの確認なしにマイルストーンを絶対にクローズしません
  • このスキルでは PR コメントに絶対に返信しません。代わりに github-pr-review を使用します
  • 未返信のコメントがある場合はマージを停止し、レビュー用スキルを使うようユーザーに案内します

コメント