check-pr

PR を確認する

プルリクエスト（GitHub）、マージリクエスト（GitLab）、または保留中のチェンジリスト（Perforce）を分析し、レビューコメント、ステータスチェック、説明の完全性を確認して、見つかった問題への対応を支援します。

入力

• PR/MR/CL 番号（任意）：指定されていない場合は、現在のブランチの PR/MR、または p4 のデフォルトの保留中チェンジリストを検出します。

手順

0. プラットフォームを検出する

まず、.p4config ファイルまたは P4CLIENT／P4PORT 環境変数があるか確認し、ユーザーが Perforce のデポを使用しているかを判断します。

# Check for Perforce environment
if p4 info >/dev/null 2>&1; then
  VCS="perforce"
else
  # Fall back to git remote detection
  REMOTE_URL=$(git remote get-url origin)
  if echo "$REMOTE_URL" | grep -qi "gitlab"; then
    VCS="gitlab"
  else
    VCS="github"
  fi
fi

ホスト名に「gitlab」を含まないセルフホストの GitLab インスタンスでは、入力として --vcs gitlab を渡すことで上書きできます。Perforce の場合は、--vcs perforce を渡すことで上書きできます。

1. PR/MR/CL を特定する

番号が指定されている場合は、それを使用します。指定されていない場合は、次の方法で検出します。

GitHub：

gh pr view --json number -q .number

GitLab：

glab mr view --output json | jq '.iid'

Perforce：

# List pending changelists for the current user/client
p4 changes -s pending -u $P4USER -c $P4CLIENT

プラットフォーム間で異なる主なフィールド：

• GitHub：number、headRefName、headRefOid
• GitLab：iid、source_branch、sha
• Perforce：チェンジリスト番号（CL）、レビュー中の CL の shelved ファイル

2. PR/MR/CL の詳細を取得する

GitHub：

gh pr view <PR_NUMBER> --json title,body,state,reviews,comments,headRefName,statusCheckRollup
gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/comments
gh api --paginate "repos/{owner}/{repo}/issues/<PR_NUMBER>/comments?per_page=100"

GitHub の PR は Issue としても扱われるため、一般的な PR コメントは Issue のコメントエンドポイントにあります。Greptile は、新しいレビューやコメントを作成する代わりに、レビューサイクルごとに単一の一般的な PR コメントを編集する場合があります。PR に問題がないと判断する前に、updated_at の値を基準に、Greptile が作成した最新の一般コメントを必ず確認してください。「Prompt to fix all with AI」セクションも含めて確認します。

GitLab：

glab mr view <MR_IID> --output json
# Fetch discussions (inline diff comments are type "DiffNote"; general comments have null type)
glab api "projects/:fullpath/merge_requests/<MR_IID>/discussions"

GitLab では、必要に応じてディスカッションをページネーションで取得します（?per_page=100&page=N を追加します）。

Perforce：

# Get changelist description, files, and status
p4 describe -s <CL_NUMBER>

# Get shelved files (for in-review CLs)
p4 describe -S <CL_NUMBER>

# Get the diff of the shelved changelist
p4 diff2 //...@=<CL_NUMBER> //...@=<CL_NUMBER>

# List review comments (if using p4 review workflow)
p4 review -c <CL_NUMBER>

Perforce CL の主なフィールド：

• Change：チェンジリスト番号
• Status：pending、submitted、shelved
• Description：CL の説明／コミットメッセージ
• Files：CL 内のファイル一覧

3. 保留中のチェックが完了するまで待つ

分析を始める前に、すべてのステータスチェックが完了していることを確認します。チェックのいずれかが PENDING または IN_PROGRESS（GitHub）、あるいは running または pending（GitLab）の場合は、すべてのチェックが終了状態になるまで30秒ごとにポーリングします。

GitHub： gh pr view から statusCheckRollup をポーリングします。

GitLab：

glab api "projects/:fullpath/merge_requests/<MR_IID>/pipelines"

パイプラインのステータス：running、pending、success、failed、canceled、skipped。パイプラインに running または pending のステータスがなくなるまでポーリングします。

Perforce： Perforce には、ネイティブの CI チェック機能が組み込まれていません。チームがレビュー ツール（Swarm など）や、シェルブイベントによって起動する外部 CI を使用している場合は、該当するシステムを確認します。それ以外の場合は、すぐに分析を進めます。

4. PR/MR を分析する

すべてのチェックが完了したら、次の項目を評価します。

A. ステータスチェック

• すべての CI チェックに合格していますか？
• 失敗しているチェックがある場合は、チェック名と失敗理由を特定します。

B. PR/MR の説明

• 説明は完全で、チームの規約に沿っていますか？
• 必須セクションはすべて記入されていますか？
• 更新が必要な TODO やプレースホルダーはありますか？

C. レビューコメント

• 対応が必要なインラインのコードレビューコメント
• ボットのレビューコメント（例：GitHub の greptile-apps[bot]、GitLab の Greptile ボットユーザー、リンターなど）
• 人間のレビュー担当者によるコメント
• Perforce： p4 review または外部レビュー ツールからのレビューコメント

D. 一般コメント

• PR/MR のディスカッションコメント
• GitHub の場合は Issue のコメントエンドポイントを確認し、updated_at を使って、ボットコメントがその場で編集されていないか確認します。Greptile が最後に編集した要約には、新しいインラインコメントがなくても対応が必要な項目が含まれている場合があります。
• ボットコメント（デプロイプレビューなど）：通常は情報提供のみ
• Perforce： CL の説明には、明確な概要、変更対象ファイルの理由、およびテストに関する記録を含める必要があります。

5. 問題を分類する

見つかった各問題を、次のように分類します。

カテゴリ	意味
対応が必要	コード変更、テストの改善、または修正が必要です
情報提供のみ	検証メモ、質問、または対応を必要としない参考情報です
対応済み	後続のコミットによって解決済みと思われる問題です

6. 調査結果を報告する

次のサマリーテーブルを提示します。

領域	問題	状態	必要な対応
ステータスチェック	CI ビルドが失敗しています	失敗	src/api.ts の型エラーを修正する
レビュー	「null チェックを追加」— @reviewer	対応が必要	ガード節を追加する
説明	テスト計画に TODO のプレースホルダーがあります	対応が必要	テスト計画を記入する
レビュー	「問題ありません」— @teammate	参考情報	なし

7. 問題を修正する（依頼された場合）

対応が必要な項目がある場合：

1. まだ切り替えていない場合は、PR/MR のブランチ（git）に切り替えるか、正しい CL（Perforce）でファイルが開かれていることを確認します。
2. 問題を修正するか、ユーザーに確認します。
3. 了承された場合は修正を行い、次の操作を実行します。

GitHub/GitLab: コミットしてプッシュします。

git add <files>
git commit -m "address review feedback"
git push

Perforce: ファイルを編集用に開き、変更を加えて、再シェルブします。

p4 edit <file>
# make changes
p4 shelve -f -c <CL_NUMBER>

8. レビュースレッドを解決する

コメントに対応したら、該当するレビュースレッドを解決します。

Perforce — Perforce には「スレッドを解決する」という標準機能はありません。代わりに、CL の説明を更新するか、使用中のレビュー ツール（Swarm など）で返信して、コメントに対応済みのマークを付けます。p4 review を使用する場合：

# Mark files as reviewed after addressing feedback
p4 review -c <CL_NUMBER>

GitHub — 未解決のスレッド ID を取得します（必要に応じてページネーションします。GraphQL リファレンスを参照）：

gh api graphql -f query='
query($cursor: String) {
  repository(owner: "OWNER", name: "REPO") {
    pullRequest(number: PR_NUMBER) {
      reviewThreads(first: 100, after: $cursor) {
        pageInfo { hasNextPage endCursor }
        nodes {
          id
          isResolved
          comments(first: 1) {
            nodes { body path }
          }
        }
      }
    }
  }
}'

hasNextPage が true の場合は、残りのスレッドを取得するために -f cursor=ENDCURSOR を指定して繰り返します。

次に、対応済みまたは参考情報に該当するスレッドを解決します。

gh api graphql -f query='
mutation {
  resolveReviewThread(input: {threadId: "THREAD_ID"}) {
    thread { isResolved }
  }
}'

エイリアス（t1、t2 など）を使用して、複数の解決処理を 1 つの mutation にまとめます。

GitLab — 未解決のディスカッションを取得します（GitLab API リファレンスを参照）：

glab api "projects/:fullpath/merge_requests/<MR_IID>/discussions?per_page=100"

"resolved": false のディスカッションを絞り込みます。各ディスカッションの id を収集します。

各ディスカッションを個別に解決します（GitLab には一括解決機能がありません）。

glab api --method PUT \
  "projects/:fullpath/merge_requests/<MR_IID>/discussions/<DISCUSSION_ID>" \
  --field resolved=true

未解決のディスカッション ID ごとに繰り返します。

9. 複数の PR/MR/CL

一連の PR/MR/CL を確認する場合は、順番に処理します。

Perforce — 複数の変更リストを一度に確認するには：

p4 changes -s pending -u $P4USER -c $P4CLIENT -l

出力形式

次の内容をまとめます。

• PR/MR/CL のタイトルまたは説明と現在の状態
• 検出されたプラットフォーム（GitHub / GitLab / Perforce）
• ステータスチェックの概要（成功／失敗／保留中）。Perforce の場合は N/A
• 見つかった問題の合計数
• 対応が必要な項目とその説明
• 無視できる項目とその理由
• 推奨される次の手順