git-pr

PR と MR のワークフロー

GitHub と GitLab にまたがるプルリクエストおよびマージリクエストのワークフローに関する主要なスキルです。 作成、レビューに関する問い合わせ、コメントの処理、行を指定したコメント、マージまで、ライフサイクル全体を扱います。すべてのレシピで、トークン効率を高めるために最小限のフィールドセットを使用します。

gh v2.102.0 に対して検証済み（2026-09-30）：ここで使用しているすべての gh サブコマンドとフラグを、それぞれの --help で確認しています。glab：未検証 — 固定バージョンがまだないため、glab のフラグを使う前に glab <cmd> --help を確認してください。gh --version がより新しい場合、フラグの詳細を前提とする前に、v2.102.0 以降のリリースノートを確認してください。CodeRabbit CLI の固定バージョンは coderabbit スキルに記載されています。

コンテキストの確認（最初に実行）

PR のワークフローを開始する前に、現在の状態を検出します。これにより、適切な対応が決まります。

# Check if a PR exists for the current branch (allowlisted, zero approval)
gh pr view --json number,state,reviewDecision,reviewRequests,title 2>/dev/null

結果	次のアクション
PR が存在し、CHANGES_REQUESTED	未解決スレッドを取得します（「レビューコメントへの対応」を参照）
PR が存在し、REVIEW_REQUIRED または保留中の reviewRequests がある	レビューの状態を確認するか、レビュアーを待ちます
PR が存在し、ボットレビューが進行中：REST の requested_reviewers で保留中（Copilot は Copilot と表示）、または HEAD の CodeRabbit ステータスが Review in progress	自動レビューが進行中です。ホストで可能な方法で待機します（重要なルール 9）。再リクエストしないでください
PR が存在し、未解決のレビューコメントがある	まずコメントに対応します（「レビューコメントへの対応」）。未対応のコメントがある状態で、新しいレビューを依頼してはいけません
PR が存在し、APPROVED	CI の状態を確認するか、マージに進みます
PR が存在し、まだレビュー判断がない	自動レビューを行うリポジトリでは、まずボットのレビュー結果を確認します（bot_status、「ボットレビューループ」）。このクエリには、問題なし、またはレート制限されたレビューの結果は表示されません。その後、CI の状態やレビューの状態を確認するか、変更を追加でプッシュします
現在のブランチに PR がない	PR を作成します（「PR/MR の作成」を参照）

これにより、すでに PR がある場合に PR の作成を提案することを防ぎ、保留中のレビュー作業をすぐに把握できます。reviewDecision フィールドを確認すれば、個々のスレッドを取得しなくても、レビュアーが変更を要求しているかどうかを確実に判断できます。

自動レビューは任意の設定です。どちらか一方だと決めつけてはいけません（GitHub）： Copilot による自動コードレビューは、リポジトリ／組織のルールセットまたは作成者の個人用 Copilot 設定によって有効になるため、アカウント、組織、さらには同じ所有者が管理するリポジトリ間でも有無が異なります。有効な場合は、PR 作成時にすべてのドラフトではない PR で Copilot がリクエストされます（ドラフトがレビュー可能な状態に変更されたときも同様です）。そのため、作成直後の PR に保留中のボットリクエストがあったり、数分後にボットコメントが付いたりすることがあります。一方、別のリポジトリでは何も実行されない場合もあります。ルールセットの設定は読み取り専用で検出できます（gh api repos/{owner}/{repo}/rules/branches/{branch} で copilot_code_review ルールを確認。references/copilot-review-config.md を参照）。ただし、個人用設定には API がありません。そのため、ルールセットの確認結果が空でも、決めつけずに検出してください。まず保留中のリクエストまたは既存のボットレビューがあるかを確認し、どちらも見つからない場合にのみリクエストします。そうしないと、レビューが重複して実行されます。注意： 保留中のボットリクエストは gh api repos/{owner}/{repo}/pulls/{n}/requested_reviewers（ログイン名は Copilot）でしか確認できません。gh pr view --json reviewRequests にはボットレビュアーが表示されず、空のままです。

ボットレビューには費用（Copilot）またはクォータ（CodeRabbit）がかかるため、レビュー回数を計画的に使ってください。 再リクエストを含め、Copilot のレビューは毎回全額が課金されます。従来の年間プランではプレミアムリクエスト 13 回分（Pro では月に最大約 23 回のレビュー。すべてのプレミアム機能で共有される枠です）、現行プランでは AI クレジットがトークン量に応じて課金され、Actions の実行時間も消費します。CodeRabbit の PR レビューは、プランごとの 1 時間単位の枠を消費します。この枠は PR ごとではなく開発者ごとに設定されるため、開発者がオープンしているすべての PR で同じレビュー枠を共有します。課金対象のレビューを依頼する前に、プロジェクトのコードレビュー方針（以下）を確認してください。PR 側のレビューの前に、ローカルの CodeRabbit CLI レビューを使って、低コストで反復的に確認することを推奨します（coderabbit スキルを参照）。

使用する場面

• PR または MR の作成 -- ワークフローの下書き、パターンの入力、タイトル形式
• PR/MR のレビューコメントへの対応 -- 「PR のコメントを修正」「レビューに対応」「フィードバックに対応」「レビューのスレッドを解決」
• コードレビューへの回答 -- レビュアーのコメントの評価、返信、スレッドの解決
• レビュー状況の確認 -- 承認、保留中のレビュアー、レビュー結果
• PR/MR データの照会 -- 変更されたファイル、コミット、ラベル、リンクされた Issue
• PR/MR へのコメントの投稿 -- 行に紐づくコメント、スレッドへの返信
• ボットレビューのラウンドの反復（GitHub のみ。Copilot、CodeRabbit）-- ボットに再レビューを依頼し、非同期レビューを待ち、コメントに対応して、有効なコメントがなくなるまで繰り返します（「Copilot のレビューを繰り返す」「3 ラウンド繰り返す」）
• Copilot のコードレビューの設定 -- 自動レビューのルールセット、レビューの労力、カスタム指示、課金／クォータの確認
• ツールの許可リストの設定 -- 読み取り専用コマンドの自動承認パターン

重要なルール

1. 生の API 呼び出しより、CLI サブコマンドを優先してください。 サブコマンドはページネーション、エラーの整形、リポジトリの検出を処理します。サブコマンドで対応できない操作（行コメント、スレッドの解決、GraphQL）に限り、gh api ／ glab api を使用してください。
2. gh では --json field1,field2 を使って出力を絞り込んでください。 これが効率化の仕組みです。基本的なクエリに --jq は必要ありません。実際に必要なフィールドだけを指定してください。
3. glab には --json field1,field2 に相当する機能がありません。 出力を絞り込んでトークンを節約するには、-F json | jq '{fields}' を使ってください。
4. このスキルに記載されているコマンドをそのまま使用してください。 以下のコマンドは、自動承認の許可リストのパターンに合うよう設計されています。フラグの順序を変えたり、想定外のフラグを追加したりすると、権限確認が表示される場合があります。
5. 完成した作業だけをプッシュしてください。1 ラウンドにつきプッシュは 1 回です。 自動レビューと auto_incremental_review が有効な場合（どちらもデフォルト）、git push はレビューのリクエストであり、その時点のブランチの内容がレビューされます。まずラウンド内のタスクをすべて終えてください。修正、テスト、ドキュメント、ローカルチェック（coderabbit review --committed）など、すべてをコミットしてから、1 回だけプッシュします。途中経過のプッシュは、変更する予定のコードに、開発者ごとの貴重なレビュー枠を使ってしまいます。変更が続いている間は PR をドラフトのままにしてください（ドラフトは自動レビューされないため、プッシュしてもレビュー枠は消費されません）。レビューのリクエストは、PR をレビュー可能な状態にする操作です。詳細な手順は references/bot-review-loop.md（「1 ラウンドにつき 1 回のプッシュ」）を参照してください。
6. レビューは、本文のみに記載された指摘事項に対応するまで完了ではありません。 スレッドにならないボットの指摘（CodeRabbit の細かな指摘、差分範囲外の指摘、重複、投稿失敗の分類）はレビュー本文に残り、スレッド検索では見つかりません。これらも確認し、ラウンドの完了を宣言する前に、申告されたコメント数と照合してください。
7. ボットのチェックが成功していても、レビューが完了したとは限りません。 CodeRabbit は各ラウンドをコミットステータスとして記録し、どちらの結果でもステータスは success になります。結果は description（Review completed または Review rate limited）にのみ記載されます。また、レート制限されたラウンドでは、レビューもスレッドもコメントも投稿されないことがよくあります。PR をレビュー済みと報告する前に、gh pr checks --json name,state,bucket,description で確認してください（このフィールドはデフォルトでは返されず、gh pr view --json statusCheckRollup では完全に除外されます）。
8. ローカルの CodeRabbit コマンドは、coderabbit review --committed --base {base} に、JSON Lines 出力用の --agent を付けたものだけです。 デフォルトはプレーンテキストです。--plain は絶対に渡さないでください。CLI v0.7 から v0.9.0 では受け付けられず（error: unknown option）、v0.9.1 では再び受け付けられますが、非表示の no-op です。--type <scope> は廃止されていませんが、非表示です。レビューは開始されるものの、--committed と併用すると失敗します。出力やスコープのフラグを記憶に頼って指定しないでください。CLI の仕様は coderabbit スキルが管理しています。v0.7 では誤ったフラグを指定すると終了コード 0 で使い方のテキストが表示されるため、出力の末尾を取得するラッパーはレビューが正常終了したと誤認していました（v0.8 では終了コードが 1 になります）。
9. 処理中のボットラウンドを、再開手段のないままターンを終えて放置しないでください。 自動レビューが有効なリポジトリでドラフトではない PR を作成すると、ラウンドが開始されます。ホストで許可されている方法で待機してください。ポーリングが許可されている場合は、bot_tick ループを実行します。ホストが自分でのポーリングを禁止している一方、PR モニター（Claude Code デスクトップアプリの Auto-fix など）が用意されている場合は、それを有効にするようユーザーに依頼し、検知できないケースも伝えてください。CodeRabbit のレビューが問題なしで完了した場合、レビューコメントは投稿されません。また、レート制限された場合は CodeRabbit ステータスの説明が Review rate limited に変わるだけなので、モニターがセッションを再開しないことがあります。その場合はユーザーが /git-pr を再実行し、ラウンドの結果を確認します。どちらも利用できない場合は、ラウンドが保留中で未処理であることと、結果が反映された後に /git-pr を再実行すれば処理されることを明確に伝えてください。詳細は references/bot-review-loop.md（「処理中のラウンドを待つ」）を参照してください。

プロバイダーの検出

git remote get-url origin

リモート URL に含まれる文字列	プロバイダー	CLI	PR 用語
github.com	GitHub	gh	PR
gitlab.com またはセルフホスト GitLab	GitLab	glab	MR

判別できない場合、または両方に該当する場合は、ユーザーに確認してください。

glab のレシピは GitLab のドキュメントに沿っていますが、実際のインスタンスではテストされていません。GitHub のレシピは実際にテストされています。GitLab 側のフラグや JSON の形式は、ドキュメントには記載されていますが未検証として扱ってください。無人のワークフローで利用する前に glab <command> --help を確認し、フィールドが存在すると決めつけずに -F json | jq を使うことを優先してください。

---

読み取り専用と書き込みの分類

• 読み取り専用（自動承認しても安全）：view、list、status、diff、checks、search
• 書き込み（ユーザーの承認が必要）：create、edit、merge、close、reopen、comment、review、approve

リファレンス：段階的な自動承認パターンについては、references/allowlist.md を参照してください。

---

PR/MR の概要（現在のブランチ）

GitHub：

gh pr view --json number,title,state,isDraft,reviewDecision,mergeable,baseRefName,headRefName

GitLab：

glab mr view -F json | jq '{iid:.iid,title:.title,state:.state,draft:.draft,merge_status:.merge_status,target:.target_branch,source:.source_branch}'

PR/MR の概要（番号指定）

GitHub：

gh pr view {number} --json number,title,state,isDraft,reviewDecision,mergeable,baseRefName,headRefName

GitLab：

glab mr view {iid} -F json | jq '{iid:.iid,title:.title,state:.state,draft:.draft,merge_status:.merge_status,target:.target_branch,source:.source_branch}'

レビュー状況

リファレンス：レビュー担当者ごとの状況、承認チェック、保留中のレビュー担当者など、高度なレビュー検索については、references/review-queries.md を参照してください。

GitHub：

gh pr view --json reviews,reviewRequests,latestReviews

GitLab：

glab mr view -F json | jq '{upvotes:.upvotes,reviewers:[.reviewers[]?.username]}'

承認の詳細情報（GitLab）：

glab api projects/{project_id}/merge_requests/{iid}/approvals | jq '{approved:.approved,approvers:[.approved_by[]?.user.username]}'

変更されたファイル

GitHub：

gh pr diff --name-only

GitLab：

glab mr diff

ファイル統計

GitHub：

gh pr view --json files

GitLab：

glab api projects/{project_id}/merge_requests/{iid}/changes | jq '[.changes[] | {path:.new_path,added:.diff | split("\n") | map(select(startswith("+"))) | length,removed:.diff | split("\n") | map(select(startswith("-"))) | length}]'

オープン中の PR/MR の一覧表示

GitHub：

gh pr list --json number,title,author,reviewDecision,updatedAt

GitLab：

glab mr list -F json | jq '[.[] | {iid:.iid,title:.title,author:.author.username,updated:.updated_at}]'

PR/MR のコミット

GitHub：

gh pr view --json commits

GitLab：

glab api projects/{project_id}/merge_requests/{iid}/commits | jq '[.[] | {sha:.short_id,title:.title}]'

PR/MR の検索

GitHub：

gh pr list --search "review-requested:@me" --json number,title,url

GitLab：

glab mr list --reviewer=@me -F json | jq '[.[] | {iid:.iid,title:.title,url:.web_url}]'

---

PR/MR の作成（書き込み — 手動承認）

アクション	GitHub	GitLab
ドラフトを作成	gh pr create --draft --fill	glab mr create --draft --fill
タイトルを指定して作成	gh pr create --title "feat: ..." --body "..."	glab mr create --title "feat: ..." --description "..."
作成して Copilot レビューを依頼	gh pr create --title "..." --body "..." --reviewer @copilot (gh >= 2.88)	該当なし

**本文は簡潔にしてください。**タイトルは Conventional Commits（git-commit スキル）に従います。本文は、変更内容とその理由を数文または簡潔な箇条書きで記述してください。差分の言い換えや、リポジトリの PR テンプレートで必須とされるもの以外の定型セクションは不要です。

ドラフトではない GitHub PR を作成した後、ボットのレビューを依頼する前に gh api repos/{owner}/{repo}/pulls/{n}/requested_reviewers を確認してください。Copilot の自動レビューが設定されたリポジトリでは、すでにレビューが進行中のことがあり（gh pr view --json reviewRequests には表示されません）。自動レビューが設定されていないと分かっているリポジトリでは、作成後に編集する手順を省略し、作成時に --reviewer @copilot を指定してください。不明な場合は通常どおり作成し、検出処理に判断を任せてください。

**作成後にレビューが進行中なら、それは次のステップであり、ターンの終了ではありません。**CodeRabbit の場合、HEAD の CodeRabbit ステータスに Review in progress と表示されます（bot_requested は両方の表示場所を確認します）。ホストで許可されている方法で待機してください（重要ルール 9）。PR モニターを使い、自分でポーリングしない場合は、新しい PR を報告するメッセージでユーザーにモニターを有効にするよう依頼してください。

マージ（書き込み -- 手動承認）

アクション	GitHub	GitLab
スカッシュマージ	gh pr merge --squash --delete-branch	glab mr merge --squash --remove-source-branch
リベースマージ	gh pr merge --rebase --delete-branch	glab mr merge --rebase --remove-source-branch

---

レビューコメントの処理

参照：すべてのコマンドパターンと例を含む、詳細で方針を定めたワークフローについては、references/pr-comment-workflow.md を参照してください。

このワークフローには、明確に分かれた2つのフェーズがあります。決して混在させないでください。

フェーズ1：分析と修正（ローカル作業、GitHub API への書き込みなし） -- フェッチは承認不要です。git commit／git push は書き込み操作のため、人による確認のチェックポイントとして扱います

1. 未解決のレビュー スレッドをすべて、インラインの --jq フィルターを使った単一の GraphQL クエリでフェッチし、その後ボットのレビュー 本文 を取得します -- スレッドだけではレビュー全体ではありません（下記参照）
2. 各スレッドについて、参照されたパスと行のファイルを読み、コードベース（パターン、規約、CLAUDE.md、git log）を調査して、コメントが妥当かどうかを確認します
3. 批判的に検討し、受け入れる前に各コメントを実際のコードに照らして検証します。レビュアーが間違っていることもあります。
4. 修正を説明したり、コードを読めば分かる内容を言い換えたりするコードコメントを追加せずに、必要なコード修正をすべて行います
5. 修正をコミットし（変更に必要な数だけコミットします）、一連の作業全体で一度だけプッシュします -- コミットメッセージには変更内容そのものを記述し、レビュープロセスには言及しません（「レビューのフィードバックに対応」、ボット名、ラウンド番号などは記載しません。git-commit スキルを参照）

すべての指摘がスレッドになるわけではありません（CodeRabbit）。 細かい指摘（profile: chill の場合）、差分範囲外の指摘、重複コメント、投稿に失敗したコメントはレビュー 本文 にしか存在しません。reviewThreads では返されないため、レビューが対応済みに見えても実際には未対応であることがよくあります。ボットのレビュー本文を取得し、それらの項目もトリアージして、トップレベルのボットスレッドを、レビューで申告された Actionable comments posted: N と照合します -- コマンドについては references/bot-review-loop.md を参照してください。

フェーズ2：返信と解決（1つにまとめたコマンド、承認1回） 6. すべての返信とすべての解決を、&& で連結した単一のコマンドにまとめます 7. まず REST で返信し、次にエイリアスを使った単一の GraphQL ミューテーションで、対応済みのスレッドをまとめて解決します 8. 「要議論」のスレッドは未解決のままにします。また、返信した CodeRabbit のスレッドは、却下したものも含めてすべて未解決のままにします。CodeRabbit の返信では、HEAD で修正を再確認するか、こちらの理由を検討したうえで、スレッド自体を解決します。これが再レビューに代わる確認となります（references/bot-review-loop.md の「スレッド内で修正を確認」を参照）。10分以内に返信がない場合に限り、自分で解決し、確認済みとして数えないでください

この順序が重要です。先に修正をプッシュすれば、レビュアーは返信を読む際に変更を確認できます。修正を実際にプッシュする前に、「修正済み」と主張するコメントへ返信してはいけません。

未解決スレッドを取得（承認ゼロ）

GitHub -- $(...)置換を使う1つのコマンドです。1行で生成し、変数の代入（OWNER=...、REPO=...）を前に付けないでください。どちらも許可リストとの照合に失敗します。

gh api graphql -f query="{ repository(owner: \"$(gh repo view --json owner --jq '.owner.login')\", name: \"$(gh repo view --json name --jq '.name')\") { pullRequest(number: $(gh pr view --json number --jq '.number')) { reviewThreads(first: 100) { totalCount pageInfo { hasNextPage endCursor } nodes { id isResolved isOutdated path line startLine comments(first: 20) { nodes { id fullDatabaseId body author { login } } } } } } } }" --jq '.data.repository.pullRequest.reviewThreads | {total: .totalCount, nextCursor: (if .pageInfo.hasNextPage then .pageInfo.endCursor else null end), unresolved: [.nodes[] | select(.isResolved==false)]}'

未解決スレッドと、取得が完了したことを証明する2つの数値を返します。reviewThreadsは独自にページネーションを行いません -- nextCursorがnullでない場合、101件目以降のスレッドが存在し、未解決のコメントが含まれている可能性があります。対応済みと判断する前に、reviewThreads(first: 100, after: \"{nextCursor}\")で再実行し、結果を統合してください。

レスポンスフィールドの対応関係（重要 -- IDを誤ると、エラーが表示されないまま失敗します）：

フィールド	形式	用途
スレッドの.id	PRRT_...（ノードID）	resolveReviewThreadミューテーション
コメントの.fullDatabaseId	"2949637341"（文字列）	REST返信エンドポイント
コメントの.id	PRRC_...（ノードID）	通常は不要

GitLab（REST）：

glab api projects/{project_id}/merge_requests/{iid}/discussions --paginate | jq '[.[] | select(.notes[0].resolvable==true and .notes[0].resolved==false) | {id:.id,path:.notes[0].position.new_path,line:.notes[0].position.new_line,body:.notes[0].body,author:.notes[0].author.username}]'

返信して解決（1つのバッチコマンド）

GitHub -- すべてのREST返信とバッチGraphQL解決ミューテーションを、&&で連結した1つのコマンドにまとめます。返信にはfullDatabaseId（文字列。databaseIdは非推奨）を使用し、解決にはスレッドのid（PRRT_ノードID）を使用します。以下の例は人間とCopilotのスレッド向けです。CodeRabbitのスレッドでは、返信はすべて行いますが、却下されたものも含め、すべてのスレッドをミューテーションから除外してください。CodeRabbitは各返信に回答し、スレッド自体を解決するためです（ステップ8）。

gh api repos/{owner}/{repo}/pulls/{pr}/comments/{fullDatabaseId_1}/replies -f body="Fixed in {sha} -- {explanation}" && \
gh api repos/{owner}/{repo}/pulls/{pr}/comments/{fullDatabaseId_2}/replies -f body="Addressed in {sha}" && \
gh api graphql -f query="
mutation {
  t1: resolveReviewThread(input: {threadId: \"PRRT_thread1\"}) { thread { isResolved } }
  t2: resolveReviewThread(input: {threadId: \"PRRT_thread2\"}) { thread { isResolved } }
}"

CodeRabbitのスレッドだけのラウンドでは、返信のみを行い、ミューテーションは実行しません。

GitLab：

glab api projects/{id}/merge_requests/{iid}/discussions/{disc_1}/notes --method POST --field "body=Fixed in {sha}" && \
glab api projects/{id}/merge_requests/{iid}/discussions/{disc_1} --method PUT --field "resolved=true" && \
glab api projects/{id}/merge_requests/{iid}/discussions/{disc_2}/notes --method POST --field "body=Addressed" && \
glab api projects/{id}/merge_requests/{iid}/discussions/{disc_2} --method PUT --field "resolved=true"

---

コードレビュー方針（慣例）

レビューの設定は、エージェント指示ファイル内の Code Review Policy セクションで宣言します。レビューを依頼する前に、必ずそのセクションを確認してください。スコープは2つあり、より具体的なものが優先されます。

1. リポジトリの方針 -- プロジェクトの AGENTS.md または CLAUDE.md。AGENTS.md を推奨します。Copilot コードレビュー自体がルートの AGENTS.md を読み取るため、1つのファイルでエージェントとレビュー担当の両方に指示できます。
2. ユーザー全体の方針 -- ユーザーのグローバルエージェント指示（Claude Code：~/.claude/CLAUDE.md）。リポジトリ全体でのデフォルトのフローとして使用します。

どちらのレビュー担当も任意です。 実際に利用できるもの（CodeRabbit アプリのインストール状況／CLI の認証状況、Copilot のルールセットまたは確認された自動レビュー）を検出し、レビュー担当が存在する、利用料金が支払われている、または追加すべきだと決めつけないでください。Reviewer: none も有効な方針です。この場合は人間によるレビューのみとなります。例：

## Code Review Policy
- Reviewer: coderabbit            # coderabbit | copilot | both | none
- CodeRabbit plan: team until 2026-10-20, then essentials   # free | essentials | team | advanced | enterprise
- Copilot billing: legacy         # legacy (premium requests) | credits
- Local review: coderabbit review --committed --base main   # run before every push; --agent for JSON lines, no --plain
- PR review rounds: ask           # ask | loop <= N

CodeRabbit のプランを明記してください -- API からは分かりません。 coderabbit usage で分かるのはリポジトリに含まれる利用枠と請求期間であり、プランではありません。また、PR API にもプランは記載されません。そのため、エージェントにプランが伝えられていないと、処理できない枠に PR を過剰に割り当てるか、利用可能な枠を使わずに放置することになります。プランによって、1時間あたりの利用枠の上限が決まります（Free は開発者あたり PR レビュー1件、Essentials は5件、Team は8件、Advanced は10件です。Essentials と Team は2026年9月までそれぞれ Pro と Pro+ でした。また、旧プランを継続している Pro+ では10件です。表は coderabbit スキルにあります）。ただし、公正利用のスロットリングにより、有効なレートはこの上限を下回ります。開発者が過去24時間または7日間の移動期間中に行ったレビュー数に基づくため、レビューの多い週には、Essentials の開発者が1時間あたり1～2件に制限されます。現在の値を確認できる方法は2つあります。投稿された各レビュー内の実行設定ブロック（プラン名も記載されます）と、@coderabbitai rate limit コメントです。後者はレビューを消費せず、残りの利用枠と次の利用可能時刻を返すため、ループを開始する前に使える低コストの確認方法です。また、利用枠によって、一度にドラフト以外にできる PR の数と、ローカル CLI レーンで行う反復回数も決まります。トライアルの終了日も同様に記録してください。Advanced で機能するキューも、トライアルが終了した朝には Essentials で停止します。プランが未申告の場合は、推測するのではなく下限を推定してください。references/bot-review-loop.md の bot_bucket には、すべてのオープン PR における直近のラウンドが記録されており、過去1時間の完了数は実際の利用枠の下限となります。

どちらのスコープにも方針がない場合は、保守的な対応をデフォルトとしてください。 自動レビューが実行された場合は、そのラウンドを処理します。ホストが許す方法で待機してください（重要なルール9）。その後、課金対象となる再レビューを依頼する前に確認を求め、ラウンドの指摘内容の質を踏まえて推奨してください（実質的な問題が大半を占める場合は、次のラウンドも有益となる可能性が高く、ノイズが大半を占める場合は終了します）。自動レビューがないリポジトリでは、事前の確認なしに課金対象のレビューを開始しないでください。明示的に依頼された場合に限り、ループを実行してください。

Bot Review Loop（GitHub）

参照：ループ全体については references/bot-review-loop.md を参照してください。ボットごとの設定ブロック（Copilot、CodeRabbit）、bot_status／bot_tick ドライバー、ポーリングとホストに応じた待機、終了ロジックを確認できます。 参照：Copilot のレビュー設定については references/copilot-review-config.md を参照してください。課金モデルと利用枠の確認、自動レビューのルールセットの検出／管理、カスタム指示、Copilot CLI によるローカルレビューのオプションを確認できます。 GitHub レビューボット（Copilot、CodeRabbit）はGitHub 専用で、非同期（レビューごとに数分）に動作し、処理をブロックすることはありません。レビューの state は常に COMMENTED です。ボットごとのループは同じで、異なるのは識別情報（絞り込み対象のログイン名）、再リクエストのトリガー、検出可能な失敗／レート制限／レビューに問題がない場合の通知のみです。ボットごとの設定ブロックで指定します。有効化の判定は一部のみ可能です（Copilot の自動レビュー用 ruleset は読み取れますが、個人設定の自動レビューとボット全体の利用可否は読み取れません。上記の Context Check を参照してください）。そのため、リモートが GitHub 以外の場合や再リクエストが失敗した場合、bot_tick は 5 で終了します。リクエストが受理されたものの応答がない場合は 3 で終了します（応答が遅い場合と、ボットがサイレントに利用不可の場合があります）。

有効なコメントがなくなるまで反復します。ボットの設定と bot_status／bot_tick ドライバーを読み込みます。1 ラウンドは次のとおりです。

1. 必要な場合のみ再リクエストして待機する -- bot_tick {N} はまず未解決のボットスレッドを確認します（それらに対応し、そのスレッドを無視して再リクエストしてはいけません）。次に HEAD でのレビューを確認します（クリーンな CodeRabbit レビューではレビューオブジェクトが投稿されません。「対応が必要なコメントはありません」というウォークスルーテキスト、または「Review finished.」という確認メッセージがクリーンであることを示すものであり、失敗やレート制限ではありません）。続いて HEAD の CodeRabbit コミットステータスを確認します。ラウンドが拒否された場合でもステータスは success です（Review rate limited は HEAD が一度もレビューされていないことを意味します）。その後、REST の requested_reviewers に保留中のリクエストがあるか確認します（ドラフトではない PR の作成時に自動レビューされるのが通常なので、ラウンド 1 では再リクエストがまったく不要な場合があります）。これらのいずれにも該当しない場合に限り、再リクエストします（Copilot：gh >= 2.88 では gh pr edit {N} --add-reviewer "@copilot"。プッシュ時に自動で再レビューされることはありません。CodeRabbit：@coderabbitai review コメントを投稿します）。その後、非同期レビューをポーリングします（ホストがポーリングを許可している場合）。それ以外の場合は、PR モニターまたはユーザーに待機を委ねます（重要ルール 9）。戻り値は 0 クリーン／2 クリーンでない／3 再試行／4 失敗（すでに約 5 分のクールダウン後に再リクエスト済み。ポーリングするには再実行）／5 該当なし／6 レート制限／7 スレッド内で修正が確認済み（CodeRabbit が HEAD で各修正を再確認したか、チャットで各理由を受け入れ、スレッドを解決済みにしました。再リクエストは不要です。修正で追加されたコードはローカル CLI の手順で確認し、大規模な PR では、投稿する代わりにユーザーに @coderabbitai full review を 1 回依頼してください）。
2. 盲目的に修正せず、検証する -- 未解決の各コメントと、レビューの本文のみのすべての分類（nitpick、差分範囲外、重複、投稿失敗。調査チェックリスト）を評価します。ボットの指摘は文脈外だったり、古くなっていたりする場合があります。有効な指摘は修正します（それぞれコミットし、各ラウンドでプッシュは 1 回。メッセージには変更内容を記載し、ボット名やラウンドは記載しません）。無効な指摘には理由を返信して解決します。ただし CodeRabbit の指摘は例外です。CodeRabbit のすべてのスレッドに返信し、CodeRabbit 自身が解決できるよう開いたままにします（フェーズ 2、ステップ 8）。すべてのレビュアーの指摘を解消するには、有効なボットごとにループを 1 回実行し、上記のコメントワークフローで人間のスレッドにも対応します。
3. 終了する -- ボットにコメントがなくなったとき、有効なコメントが 0 件のとき（再リクエストしても同じ指摘が再び表示されるだけです）、レビューが約 3 回連続で失敗した後（exit 4 は一時的な失敗です。たとえば「Copilot encountered an error」の場合、bot_tick は約 5 分のクールダウンと再リクエストを挟んで再試行します。構造的な問題なのは失敗が繰り返される場合だけです。PR が大きすぎる、バイナリファイルが含まれる、クォータなどが原因なので、エスカレーションしてください）、レート制限が発生したとき（exit 6：CodeRabbit -- tick が出力した BOT_WAIT_UNTIL に基づいてスケジュールします。通知元のコメントは編集で消されることがあるためです。これは読み取り可能な場合に出力された時間枠であり、そうでなければ跳ね返された時点から約 10 分後です。再試行が再び跳ね返された場合のみ、間隔を倍にします。まず bot_bucket を確認してください。跳ね返された後に同じバケットを使う別の PR がレビューされていれば、共有バケットはすでに利用可能です。その後、新しいトリガーを投稿してください。キューには入っていないため、@coderabbitai full review を指定します。跳ね返されたラウンドでもコミットはレビュー済みとして記録されるため、通常の review は何もしません。跳ね返されてもレビュー回数は消費されず、期限も変わりませんが、キューにも入りません。そのため、トリガーを繰り返すのではなく、@coderabbitai rate limit で確認してください（レビュー回数は消費せず、次に利用可能な日時を報告します。ただし PR コメントなので、他のコメントと同様に書き込み許可が必要です）。または、Copilot もリポジトリをカバーしている場合はこのボットをスキップしてください。Copilot -- レビュー実行の CI ログにある、一般的な「encountered an error」コメントの背後に記録された、週単位のハード上限が原因の場合は、ログに記録されたリセット日より前に再リクエストしてはいけません。原因と日付をユーザーに伝えてください）、利用不可になったとき（exit 5）、ラウンド上限に達した後（デフォルトは 5、または「loop 3」）、または前回のラウンドから HEAD に変更がない場合に終了します。 ラウンドは課金対象であり、自動レビュー対象のリポジトリではプッシュが1ラウンドに相当します -- Copilot の各ラウンドではレビュー1回分が課金されます。CodeRabbit の各ラウンドでは、PRごとではなく開発者ごとに割り当てられた時間単位のクォータを消費します。すべてのオープンPRが同じレビュー枠を共有するため、複数のPRを同時に進めている場合は、待機中のPRをドラフトのままにしてください（自動レビューの対象外です。レビュー可能にする操作がレビュー依頼となります）。一度に1つずつレビュー可能にしてください -- 参考資料の「複数のPRを1つのバケットに順番に通す方法」と「1ラウンドにつきプッシュ1回」を参照してください。明示的なループ指示や寛容なコードレビューポリシーがない場合は、自動レビューのラウンドが発生したら処理し、その後は再依頼する前に確認してください（指摘の質に基づいて提案します）。自律的なループは、ユーザーから依頼された場合に限ります。

CodeRabbit：最初のフルレビュー後は、スレッドがループの中心です。 そのラウンドの修正を一度プッシュし、すべてのスレッドに返信してください -- 「Fixed in {sha}」、一部反映したこと、または変更しなかった理由を伝え、回答によってスレッドを解決してもらいます。これはレビューではなくチャットなので、PRレビュー枠を消費しません（references/bot-review-loop.md の「スレッド内で修正を確認」を参照）。デフォルトでは、それ以上のレビューを依頼しないでください。修正で追加されたコードは、ローカルCLIの手順で確認します。大規模なPRの場合に限り、ユーザーに @coderabbitai full review を1回提案してください。新しいコミットを対象とするフルレビューでは、スレッドだけでは見つけられない問題が見つかることがあります。投稿するのは、ユーザーが承諾した場合のみです。

IDに関する注意点： 各ボットのログイン名は、RESTでは末尾に [bot] が付き、GraphQLのスレッドでは付きません（Copilot：copilot-pull-request-reviewer[bot] / copilot-pull-request-reviewer。RESTのインラインコメントでは Copilot も使用されます。CodeRabbit：coderabbitai[bot] / coderabbitai）。インターフェースに応じて適切な名前で絞り込んでください。

---

行に紐づくコメント（作成）

参考資料：単一行、複数行の範囲、返信、編集／削除、レビューの一括送信などのパターンの全容については、references/line-comments.md を参照してください。

GitHub：

gh api repos/{owner}/{repo}/pulls/{pr}/comments \
  -f body="{comment}" -f path="{file}" -F line={line} -f side=RIGHT \
  -f commit_id="$(gh pr view {pr} --json headRefOid --jq .headRefOid)"

GitLab：

glab api projects/{project_id}/merge_requests/{iid}/discussions --method POST \
  --field "body={comment}" \
  --field "position[base_sha]={base_sha}" \
  --field "position[head_sha]={head_sha}" \
  --field "position[start_sha]={base_sha}" \
  --field "position[position_type]=text" \
  --field "position[new_path]={file}" \
  --field "position[new_line]={line}"

---

読み取り専用APIエンドポイント

参考資料：両プロバイダーの読み取り専用RESTおよびGraphQLエンドポイント（PRデータ、イシューのタイムライン、レビュースレッド）の全一覧については、references/api-readonly.md を参照してください。

---

glab と gh の主な違い

項目	gh	glab
MRの説明フラグ	--body	--description
ソースブランチの削除	--delete-branch	--remove-source-branch
JSON出力	--json field1,field2（フィルター済み）	-F json（リソース全体）
jqによるフィルタリング	--jq '.expr'（ネイティブ）	| jq '.expr' にパイプ
作成時のスカッシュ	--squash	--squash-before-merge
GraphQL	gh api graphql -f query='...'	非対応（RESTのみ）
スレッドの解決	GraphQLミューテーション	PUT /discussions/:id に resolved=true を指定
承認モデル	レビュー状態（APPROVED、CHANGES_REQUESTED）	承認ルールと承認／取り消し
ページネーション	--paginate（サブコマンドとapi）	--paginate（apiのみ）、-P（サブコマンド）

---

許可リスト

参考資料：読み取り専用の全操作を網羅した、段階別の Bash(command:*) パターンについては、references/allowlist.md を参照してください。Claude Code の settings.json または OpenCode の設定で自動承認しても安全です。