pre-pr-greptile

PR 前の Greptile レビュー

PR 前のレビューゲートです。Greptile は独自のクラウドでコミット済みブランチの差分をレビューします（Claude のトークン消費はほぼ $0、月間無料枠を超えた後はレビューあたり約 $1）。このスキルは結果をトリアージし、PR を進めます。これはゲートであり、盲目的な自動化ではありません。レビュー結果は検証され、リスクのある指摘は自動適用せず、提案として扱います。

Greptile 公式の cli-review スキル（whoami → 主に --json を使用し、代替として --agent を使用、指摘を重大度順にランク付け）を踏襲し、その greploop のクリーンになるまで反復する考え方をローカル CLI に適用しています（greploop 自体はローカルレビューではなく、gh 経由で PR ボットを動かします）。

前提条件

• 事前確認（Greptile 公式の cli-review を踏襲）： git rev-parse --show-toplevel （リポジトリ内にいることを確認）→ command -v greptile（CLI が存在することを確認）→ greptile whoami （認証を確認）。Greptile には --fix／適用コマンドはありません。指摘を出力するだけで、修正はエージェントが適用します（ファイルを自ら編集する公式の greploop スキルと同じです）。
• 認証（エージェント／ラップされたシェルから greptile login を実行しないでください）。 対話なしで greptile whoami を実行して確認します。未認証の場合は停止し、ネイティブターミナルで greptile login を実行するようユーザーに伝えてください（ラップされたシェルや対話なしのシェルでは、ブラウザー OAuth のコールバックが不安定で、形式不正な redirect_uri により失敗します）。ヘッドレス環境での代替手段：export GREPTILE_API_KEY=…、または echo "$GREPTILE_API_KEY" | greptile login --api-key（キーを CLI 引数として渡さないでください。シェル履歴やプロセス一覧に残ります）。
• greptile がインストールされていること（command -v greptile）。存在しない、停止中、またはレート制限中の場合は停止し、ユーザーに状況を伝えてください。ハングさせたり、黙って PR を開いたりしてはいけません（「フェイルオープン」を参照）。

流れ

1. 作業をコミットした状態で、フィーチャーブランチを使います。 トランク／ベースブランチ（testing、main、develop）にいる場合は、まず feature|bugfix|hotfix/<ticket>-slug を作成します。Greptile はブランチとベースとの差分をレビューするため、作業をコミットしておく必要があります。すべてのコミットに SSH 署名を付けてください（--no-gpg-sign、--no-verify は絶対に使わないでください）。
2. ベースブランチを明示的に解決します。main だと決めつけないでください。 この組織では PR のターゲットは testing（トランク）ですが、リポジトリごとに確認してください。greptile review はリポジトリのデフォルトブランチを使いますが、それが誤っている場合があります。意図した PR のベースに合わせるには -b <base> を渡してください。
3. レビューを実行します。 greptile review -b <base> --json（優先。jq 'keys' で構造を確認してください。JSON スキーマは文書化されていないため、フィールド名をハードコードしないでください）。JSON の取得に失敗した場合は、greptile review -b <base> --agent（プレーンテキスト）に切り替えます。
4. レビューを信頼する前に、レビューがこのブランチのものか必ず確認してください。 レビューで参照されたファイルと git diff <base>...HEAD --name-only（三点リーダーはマージベース、つまり PR の差分）を比較します。レビューのファイルは、ブランチの差分に含まれるファイルの部分集合である必要があります。重複がない場合、またはレビューが約 10 秒未満で返ってきた場合（キャッシュヒット）は、古いレビュー／別リポジトリのレビューです。破棄して新たにもう一度だけ実行し、それでも不一致なら停止して状況を報告してください。検証されていないレビューに基づく修正は絶対に適用しないでください。(この確認手順が設けられたのは、最初の greptile レビューで、まったく別のリポジトリのキャッシュ済みレビューが返された事例があったためです。)
5. 指摘をトリアージします（検証済みのレビューのみ）。 重大度順に並べ、それぞれを次のように分類します。
   • 機械的／低リスク（未使用のインポート、誤字、null ガードの不足、ドキュメント／テストの不足）：直接修正しても安全です。
   • 高リスク（認証、暗号、インジェクション、データ損失、並行処理、またはロジック／動作の変更全般）：自動適用しないでください。差分を提案し、事前にユーザーから明示的な承認を得てください。
   • 誤検知／意図に反する指摘： 適用しないでください。理由を記録します（PR の本文または後のスレッド返信に記載します）。些細な指摘を黙らせるために、正確性やセキュリティを損なってはいけません。
6. 修正を適用する際は、SDD ゲートに注意してください。 本番ソース（.py/.ts/.vue/…）を編集すると、グローバルな sdd_gate PreToolUse フックが作動します。このフックは、リポジトリが OpenSpec プロジェクトで、アクティブな変更がない場合に処理をブロックします。これは PR 時点では通常の状態です（すべてのタスクが - [x]）。本番ソースの修正がブロックされた場合は、その旨を伝え、対応をユーザーに委ねてください（タスクを未完了のままにする、変更を再開する、手動で適用する、など）。SDD_HOOKS_DISABLED=1 を自動設定しないでください。ユーザーが徹底している仕様優先の方針を損なうことになります。docs/、テスト、.claude/、openspec/ 以下の修正は対象外なので、自由に適用できます。
7. 修正を再コミットします（署名付き。PR の履歴をきれいに保つため、--fixup と autosquash、または小規模で的を絞ったコミットを優先してください）。その後、greptile review を新たに再実行し、手順 4 の差分との一致確認をやり直します。--resume はクラッシュ／中断したレビューを続行する場合にのみ使います。新しいコミットを再レビューする機能ではないため、修正適用後には絶対に使わないでください。
8. 収束するまで繰り返します。レビューは最大 3 回です。 些細な指摘／誤検知だけになった場合、または指摘が再発した場合（修正で解消できなかったため、人の判断が必要です）は早めに終了します。課金対象のレビュー（初回、再実行、古いレビューへの再実行を含む）の回数を数えてください。無料枠の後は 1 回あたり約 1 ドルかかるため、むやみに再実行しないでください。3 回後も問題が解消されない場合は、停止し、PR を作成せず、残った指摘を報告してください。
9. 正しい gh アカウントを確認してから、プッシュし、PR を作成します。 gh auth status を実行します。アカウントが切り替わっていた場合は、gh auth switch --user <correct-account> を実行してください（誤ったアカウントでは、プッシュ／gh pr create が 404 の「Repository not found」になります）。ブランチに署名付きで git push してから、gh pr create --base <base> を実行します。Claude／Anthropic の共同作成者トレーラー、「Generated with Claude Code」フッター、--no-verify は使用しないでください。ベースブランチをフィーチャーブランチにマージしてはいけません。

「クリーン」の定義

同意した未解決の指摘がゼロであることです。軽微な指摘、提案、記録済みの誤検知はブロック要因になりません。スキップした指摘の理由を記録して、同じ誤検知への対応を繰り返さず、免除を記録した状態でゲートを通過できるようにします。

フェイルオープン／フェイルセーフ

ゲートによってデッドロックが発生したり、黙って回避されたりしてはなりません。greptile が見つからない、（このシェルで）認証されていない、エラーが発生している、またはレート制限されている場合は、停止して判断をユーザーに委ねてください。ハングも、黙って PR を作成することもしてはなりません。ユーザーがレビューをスキップするよう明示的に指示した場合はそれに従い、PR の本文に greptile の事前チェックをスキップしたことを記載してください。

ガードレール

• 差分一致チェック（ステップ 4）に失敗したレビューに基づいて、処理を進めてはなりません。10 秒未満で返る場合は疑わしいものとして扱ってください。
• セキュリティや動作を変更する指摘を自動適用してはなりません。承認を得るために提案してください。
• ループを進めるために SDD ゲートやコミット署名を回避してはなりません。
• 修正は最小限にとどめ、対象の範囲内にしてください。無関係な軽微な指摘に対応するために、ブランチの範囲を不必要に広げないでください。
• 任意の PR 作成後の要約コメントで、修正しないと判断したセキュリティ上の問題に関する推論を公開してはなりません。解決済みの項目だけにするか、機密性の高い詳細を削除してください。
• 自動修正を適用するたびに、この環境で設定されている PostToolUse フックと Stop test_gate も実行されます。その所要時間を考慮し、それらのテストも「クリーン」の一部として扱ってください。

コマンド

greptile whoami                      # auth check (never `greptile login` from a wrapped shell)
greptile review -b testing --json    # primary: machine-readable, explicit base
greptile review -b testing --agent   # fallback: plain text for agents
git diff testing...HEAD --name-only  # the diff the review MUST match (step 4)
greptile review show <id>            # reopen a past review
gh auth switch --user <account>      # fix account drift before push / gh pr create