| 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 が無い／権限が無い環境では、その旨を報告して手動マージを案内する。
