/da-greptile-review — PRごとにGreptileの検証対象を絞って依頼する

ソースコード・設定・ブランチは変更しない。 GitHubへの書込みは、ユーザーが指示したPRへのレビュー依頼コメントだけ。レビュー結果の採否・修正・merge・APPROVE・REQUEST_CHANGESは扱わない。

実行条件

「全部投げて」は、直前に提示した一覧への投稿指示として扱う。許可済みの同じ範囲で再確認を要求しない。「任意も重要なら」の場合は、取りこぼした時の害を説明して含める。新しいPRや後続の再依頼まで許可が広がったとは扱わない。

読むファイル

常に読む

対象PRの本文・差分・base/head・変更ファイル一覧。会話に既存レビューがあれば、その結果と未確認範囲を再利用する。差分全体のレビューをここでやり直さない。

条件つきで読む

手順

1. PR別のスコープを固定する

PR URLのrepoを使って取得する。

gh pr view <PR_URL> --json url,title,body,author,baseRefName,baseRefOid,headRefName,headRefOid,files
gh pr diff <PR_URL>

積みPRは各PR自身のbaseとの変更を対象にする。最上段の全変更をすべてのPRに貼らない。下段や相手repoは文脈としてリンクし、他のPRの欠陥までそのPRで直すよう依頼しない。

既存レビューで修正済みの所見は、未修正の欠陥として与えない。修正を含む経路を反証してもらう重点にする。自分の「問題なし」を正解として渡さず、既知の不具合の確認だけに探索を狭めない。

2. 投げる場所と重点を一覧にする

優先度 / PRリンク / 重点 の表を作る。優先するのは、共有処理・並行性・transaction・認可・永続化、既存経路の撤去、大差分で自分の確認が浅かった場所、複数repoの配送契約・リリース順。小さい説明変更でも監視の検知能力や復旧手順を変えるなら対象にする。

重点はPRが変えた仕組みと壊し方を結ぶ。各PRに短い段落または数個の箇条書きを付ける。全PRに全観点を貼らない。例：

• 組織別claimなら、一覧登録と追記のtransaction、ページ境界、重複起床、途中失敗、retry/claim中の同期flushを追う。
• 配送追加なら、publisher→SNS属性/filter→queue policy→consumerを追い、部分配置・旧新混在・rollbackを当てる。
• 直接依頼の撤去なら、削除した呼出元の全経路から代替イベントへ追い、イベントが出ない操作や既存ジョブの再開を探す。
• 監視撤去なら、失うシグナルと残るシグナルを比較し、停止・no-data・対象の漏れ・テンプレートと稼働実物を分ける。

3. 依頼文を組み立てる

直近の本人の依頼文が取得できればそれを優先する。取れなければ、取得できなかったことを述べて次の共通文を使う。本人の口調を再現できたとは言わない。

@greptileai review

この PR の最新 head を、設計の実装が正しいという前提を置かず、障害を起こせる反例を探す形でレビューしてください。差分だけで終わらず、実際の呼出元・呼出先・共有部品・既存経路・DB制約・テストfixtureまで追ってください。PR本文と設計は検証対象であり、正しさの証拠にはしないでください。

各所見には「発生条件 → 実際に通る呼出経路 → 壊れる結果」、該当 head の file:line、可能なら再現手順または最小テストを付けてください。所見を出す前に、既存のガード・transaction・再試行・権限・DB制約で反証できないか確認してください。推測や一般論は所見にせず、追えなかった経路と不足する情報を明示してください。CI成功・類似実装・テスト追加だけを根拠に安全とは判断しないでください。変更前からある問題と、このPRで導入・顕在化する問題を区別してください。

重点的に崩してほしい仮説:
（PRごとの重点）

積みPRには「このPR自身のbaseからの差分が対象で、下段は文脈として追う」を追加する。関連repoがある時は「読めない場合は一致済みとせず、未確認項目を列挙する」を追加し、必要な関連PRの完全なURLを付ける。社内パス・認証情報・取得した秘密情報は貼らない。

4. 明示された範囲だけ投稿する

一覧や下書きの依頼ならここで返す。投稿も最初から明示されている場合は、本文をローカルで確定してそのまま進める。対象・重点が変わる新たな投稿は、既存の許可に含まれるか確かめる。

Greptileの起動依頼は、直近で使われた PRのissue comment に @greptileai review を投稿する。GitHubのレビュー状態は変えない。PRごとに1コメントとし、重点ごとに別コメントを送らない。

本文はJSONファイルの body に入れ、repoを明記して送る。シェル文字列へ本文を埋め込まない。

gh api --method POST repos/<OWNER>/<REPO>/issues/<PR_NUMBER>/comments --input <PAYLOAD_JSON>

投稿直前にheadと既存コメントを確認する。headが変わったら重点がまだ合うか差分を見直す。同じheadへの同一依頼が既にあるなら再送せず、そのURLを返す。件数が多い場合はコメントをページングし、先頭100件だけで重複なしと断定しない。重複照合用に対象head・確定本文・投稿URLをローカルの記録へ残す。

POST失敗や応答不明時は、成功したPRを再送しない。対象PRのコメントを読み直し、投稿済みなら記録を回収する。結果が不明なままPOSTを繰り返さず、そのPRを未確認として報告する。

5. 着地を確認する

返されたコメントIDで再取得し、対象PR・投稿者・本文を確認する。本文が違う、消えている、APIが読めない場合は投稿確認済みとしない。

コメントURLをPRごとに返す。投稿の成功とGreptileの受付・開始・完了は別の状態であり、botの応答を見ていなければ「依頼を投稿済み」とだけ書く。受付を確認するための追加コメント、完了待ち、定期監視はこのスキルの既定動作にしない。

根拠の扱い

直接確かめたことだけを確認済みとする。PR別の重点はheadの変更と実際の経路から作り、設計の正しさを仮定しない。コードの根拠が必要なら該当headの file:line、外部の主張ならURLを付ける。クラウド実物や別repoを読んでいない点を、一般論やCI成功で埋めない。

完了条件

• 全対象がrepo・PR・base/headに対応し、優先度とPR別の重点がある
• 一覧のみなら投稿していない。投稿時は明示された対象・本文の範囲内
• PRごとに1依頼。再実行・応答不明で重複投稿していない
• 投稿先・投稿者・本文を再取得で確認し、コメントURLと未確認の状態を返した

次に

依頼文の準備だけなら一覧で完了。投稿までなら投稿確認で完了。Greptileの結果を評価する依頼が来たら、receiving-code-review や da-fix-plan で採否・修正範囲を決める。自分で変更をレビューする時は da-review-all を使う。