Pull Request を読み解く

見る場所を固定する

GitHub の PR には、だいたい次があります。全部を一度に理解しなくて大丈夫です。役割だけ先に固定します。

• Conversation: 議論、要約、自動コメント
• Commits: 保存ポイントの並び
• Files changed: 実際の差分（最重要）
• Checks / Actions: テストやビルドなどの自動確認
• Deployments（あれば）: プレビューや本番反映の状態。スマホの PR レビュー画面にも表示されます

Files changed の読み方

緑色は追加、赤色は削除、という見た目が多いです。文章や設定なら、そのままでも読めます。プログラムでも、『ファイル名』と『変更の量』だけでも異常検知はできます。

『このファイルを変えた理由を説明して』と Agent や作者に聞くのは、正規のレビュー行為です。

Checks が落ちたら

Checks は自動の門番です。赤だからといって、あなたが悪いとは限りません。環境の問題や、もともと脆いテストの場合もあります。

取りうる行動は、『ログを Agent に読ませて修正させる』『詳しい人に共有する』『本番影響のない実験なら一旦止める』です。赤のまま強引にマージできる設定でも、慣れるまでは控えてください。

• Agent 作成 PR（Teams）: 自動で直しにいくことがあります。止まっていたら `@cursor CI を直して`
• スマホ: 失敗した Check から『Fix with Agent』
• 自分や同僚の PR: `@cursor この CI を直して`（誰の変更かを確認してから）
• 一時的な失敗でコード修正が不要なとき: GitHub の PR 画面から Checks / Actions を再実行（Cursor GitHub アプリは PR から CI 再実行を扱う権限も持ちます）
• 調査だけ先に: アプリや Web から新しい Agent を起動し、『PR #123 の失敗 CI を調査。まだ直さない』と頼む（公式の入門例。Fix with Agent とは別の入口）

どの Check が何を見ているか

Checks の名前だけでは、何を保証しているか分かりにくいことがあります。型チェック、テスト、プレビューデプロイ、セキュリティ検査など、チームごとに意味が違います。

GitHub では Bugbot の実行が `Cursor Bugbot` という Check になります（Bitbucket は `cursor-bugbot`、Azure DevOps は `cursor-bugbot/review`）。指摘があるときの既定の結論は失敗ではなく中立（neutral）です。ブランチ保護でこの Check を必須にしても、『Bugbot が走ったこと』は保証しますが、指摘そのものではマージを止めません。未解決の指摘を失敗扱いにする設定は、組織によっては別です（公式 Bugbot）。

Bugbot Autofix がオンだと、`Cursor Bugbot Autofix` という別の Check も出ることがあります。こちらは CI が赤のときの `@cursor autofix` とは別です。

Deployments タブがあれば、プレビュー URL や反映状態もここで確認できます。分からなければ、『この赤い Check は何を見ていますか？』と詳しい人に聞くのも立派なレビューです。

マージボタンの選択肢

GitHub では、Checks が通ったあとに Merge の横で Squash and merge などが選べることがあります。Squash は、Agent が何度も保存ポイント（コミット）を付けても、本線へ入るときは1つにまとめる方式です。

チームごとに『Squash 必須』『Merge commit 禁止』などのルールがあることが多いです。分からなければ、マージ前に詳しい人へ確認するか、review-and-merge レッスンの Squash 節を見返してください。

Merge がグレー表示のときは、Checks の色より先に review-and-merge 冒頭のマージブロック図（6原因）を確認してください。behind・コンフリクト・承認・保護・権限のどれかで止まっていることが多いです。

『マージできるまで Agent に任せたい』ときは、GitHub の auto-merge（自動反映）・Agent の Subscriptions（イベント待ち再開）・`@cursor autofix`（CI 自動修正）の3道具の使い分けと、review-and-merge のマージまで任せるレシピ節で組み合わせ方を整理しています。

本線より遅れている（behind）とき

PR を開いているあいだに本線（main）へ別の変更が入ると、『This branch is behind』『本線より遅れています』のような表示が出ることがあります。あなたの変更が悪いわけではなく、取り込み順の問題です。

GitHub の PR 画面や Cursor for iOS のレビュー画面では、Update branch（ブランチ更新）で本線の最新を取り込めます。取り込み後に Checks が再実行されることもあるので、赤が出たら上の3択図どおりに進めてください。

コンフリクト（同じ箇所を両方が触っている）と表示されたら、自分で直すより Agent に『main の最新を取り込んでコンフリクトを解消して』と頼む方が安全なことが多いです。

下書き（Draft）の PR は Ready for review（Ready 化）が必要なことが多く、スマホアプリからも Ready 化・公開（Publish）・Close ができます。Automations の Draft / Ready トリガーと混同しないよう、人が見るタイミングと自動化のタイミングを分けて考えましょう。