pr-review-mergelisted

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