| name | pr-review-merge |
| description | TRIGGER: 自分が PR を作成した直後、またはオーナーが「PR 上げて」「PR 作って」「マージまでやって」と言ったとき。作成後は数分待ってレビュー(CI+コメント)を確認→必要なら修正→問題なければマージまで同一ターンで完走する。SKIP: PR を作らない変更(直 push 運用のブランチ等)、オーナーが「マージはしないで」と明示したとき(その場合は確認まででマージ保留). |
/pr-review-merge
PR 作成後の標準フロー。PR を作って放置しない。 作成後はこのフローを最後(マージ or 報告)まで同一ターンで完走する。
実行手順
1. PR を作成し、URL と番号を控える
gh pr create --base <target> --head <branch> --title ... --body ...(または既存 PR 番号)。
2. 数分待つ
CI とレビュー(人/bot/自動レビュー)が付くのを待つ。ポーリングはバックグラウンドで(会話を止めない):
# 数分後にチェックを促す待機(バックグラウンド)
( sleep 300 ) & # 実運用は Bash run_in_background / スケジュール待機機構を使う
待機中に他の作業を進めてよい。CI が早く終われば早めに次へ進んでよい。
3. レビューを確認(CI+コメント+マージ可否)
gh pr checks <num> # CI: 全部 pass か(fail/pending を見る)
gh pr view <num> --json reviews,comments,mergeable,mergeStateStatus
gh pr view <num> --comments # レビューコメント本文
確認軸:① CI が緑 ② レビュー指摘が無い(あれば対応) ③ コンフリクトが無い(mergeable)。
4. 問題があれば修正
- CI fail:原因を実機で再現・修正してコミット&push → checks 再確認。
- レビュー指摘:対応してコミット&push。対応内容を PR にコメントで残す。
- コンフリクト:rebase/merge で解消。
- 修正したら 手順 2〜3 をもう一度(再度 CI/レビューを待って確認)。
5. 問題なければマージ
gh pr merge <num> --squash --delete-branch # 既定は squash。プロジェクト規約があれば従う
不可逆操作なので、CI 緑・指摘なし・mergeable を確認してから実行する。
マージ可否に疑義がある(レビュー未着・CI 不明・大きめの変更)ときはマージせず、状態をオーナーに報告して指示を仰ぐ。
6. 報告
マージ結果(または現状:CI・レビュー・マージ可否)を必ずオーナーに報告する。失敗は失敗と正直に。
メモ
- 待ち時間(例:数分)はプロジェクトの CI 実行時間に合わせて調整する。
- 待ち時間中も webhook activity が届いたら即調査・対応する(待つ=放置ではない)。
gh が無い/権限が無い環境では、その旨を報告して手動マージを案内する。