プッシュ前レビュー
CIの自動レビュージョブを、プッシュやPR作成前にローカルでシミュレートします。
動作の仕組み
レビュー基準はCIワークフロー内に定義されており、ここには重複して記述しません。レビュープロンプトは、情報源から直接読み取ってください。
.github/workflows/bots.yml—reviewジョブのprompt:フィールド（Review this pull requestで始まるYAMLブロック）を見つけてください。これには、CIが使用する完全なレビュー基準、優先順位、ガイドラインが含まれています。
それらの基準を、以下に説明するローカル（PR前）レビュー用に適応させてください。
手順
1. CIレビュープロンプトを読む
.github/workflows/bots.yml を読み、review ジョブ内の anthropics/claude-code-action ステップからレビュープロンプトを抽出します。これが、何を探し、どのように優先順位をつけるかに関する主要なリファレンスです。
2. ローカルコンテキストを収集する
まだPRがないため、同等のコンテキストをローカルで収集します。
# ベースブランチを特定する（デフォルト: main）
git merge-base main HEAD
# 変更されたファイル
git diff main...HEAD --stat
# 関数コンテキストを含む差分（CIスクリプトが使用する -W フラグと同じ）
git diff main...HEAD -W
差分については、一度にすべてを読み込もうとせず、管理可能なチャンクで読んでください。テストや生成ファイル（uv.lock、カセットなど）よりも、「コア実装」ファイルを優先してください。
3. 関連するAGENTS.mdファイルを読む
ルートの CLAUDE.md（すでにシステムプロンプトに含まれています）に加えて、変更されたファイルが含まれるディレクトリのディレクトリ固有 AGENTS.md ファイルを読んでください。CIスクリプトは以下のパスをチェックします。
docs/AGENTS.mdpydantic_ai_slim/pydantic_ai/models/AGENTS.mdtests/AGENTS.md
変更されたディレクトリに関連するものだけを読んでください。
4. レビューを実行する
CIプロンプトのレビュー基準を、以下のローカル適応とともに適用します。
- PR固有のチェックをスキップ: PR説明、リンクされたIssue、重複PRチェック、以前のレビューコメントは考慮しません。
- 「このPRは存在すべきか」のチェックをスキップ: ユーザーがこれらの変更を行う意図があると仮定します。
- 発見事項はインラインコメントの代わりにテキストとして出力します。
重点領域（CIプロンプトの優先順位順）:
- パブリックAPI — 抽象化、クラス階層、メソッドシグネチャ、型安全性、後方互換性
- コンセプトと振る舞い — 設計判断、議論が必要なトレードオフ
- ドキュメント — トーン、パターン、完全性
- テスト — カバレッジ、スタイル、統合テストと単体テスト
- コードスタイル — AGENTS.mdルールへの準拠、慣用的なPython
大規模な手直しが必要な高レベルの問題がある場合は、それらに集中し、低レベルの細かい点は保留してください。
5. 発見事項を提示する
発見事項を優先度レベルごとに整理します。各発見事項について:
- 特定のファイルと行を参照する（
file:line） - 問題を簡潔に説明する
- 適切であれば修正を提案する
発見事項がない場合は、そのように述べてください。
コメントの品質
すべての発見事項は存在価値を示さなければなりません。レビューは決してノイズを追加してはいけません。
- アクション可能のみ: 各発見事項は、特定の変更を要求するか、議論が必要な懸念事項を示すか、具体的な改善を提案しなければなりません。肯定的な側面（「素晴らしい設計」「良い選択」）についてコメントしないでください。それらはノイズです。
- 簡潔: 発見事項あたり1〜3文でほぼ十分です。不要なリスト、小見出し、絵文字は使わないでください。
- 非反復: 同じ問題を、意味のある異なるコンテキストでない限り複数回指摘しないでください。
- 無駄を省く: アクションを必要としない観察でレビューを水増ししないでください。選択が正しいなら、言及しないでください。コードがプロジェクトのパターンに従っているなら、褒めないでください。変更または議論が必要なものだけに専念してください。
- 親しみやすく、お世辞ではない: 役立つプロジェクトメンテナーのトーンを使ってください。褒め言葉は不要、「素晴らしい仕事」も不要。明確で直接的なフィードバックだけを提供してください。
大規模な手直しが必要な高レベルの問題がある場合は、それらに集中し、低レベルの細かい点は完全にスキップしてください。それらは後で再検討する必要があります。