規約のレビュー
コード変更が正しく動作するかどうかだけでなく、このリポジトリに適合しているかをレビューします。正確性よりも再現性を重視し、人間がトリアージするための、証拠に基づいたもっともらしい矛盾点を積極的に表面化します。これには、バグ修正に焦点を当てたレビューでは見落とされるような、軽微なスタイルやパターンの不一致も含まれます。
これは読み取り専用のレビューです。ファイルの変更、ファイルを書き込むフォーマッターの実行、コメントの投稿は行わないでください。
手順
- 差分を特定する。 要求されたターゲットを使用します。それ以外の場合は、ステージングされた変更とステージングされていない変更を検査します。存在しない場合は、現在のブランチを、確立されたベースブランチに対するマージベースと比較します。比較対象が不明な場合はその旨を明記します。
- ローカルガイダンスを読む。 該当する
AGENTS.md、CONTRIBUTING.md、スタイル/アーキテクチャドキュメント、および関連するリンター/テスト設定を確認します。これらのドキュメントが文書化されていない規約をカバーしていると想定しないでください。 - 差分の外にある先行例を積極的に検索する。 新規または変更された実装の選択ごとに、以下を検査します。
- まず同じコンテキスト: 隣接するコード、兄弟ファイル、含まれているUI領域（例：ツールバー、ヘッダー、ダイアログ）、同じパッケージ/モジュール、または近隣のテスト — それらが異なる機能を実装している場合でも同様です。
- 次に同じ動作: 同等のUIコントロール、操作、ヘルパー、またはテストの他の実装。
- 最後に広範な方向性: ローカルの慣行が不明確な場合の、リポジトリ全体のパターンと文書化された移行。 可能な場合は、複数の代表的な例を比較します。機能的に類似した他の場所での実装よりも、同じUI領域、モジュール、またはアーキテクチャ上の境界からの先行例を優先します。異なるコンテキストでの実装は、同じ規約が両方のコンテキストに適用される場合にのみ、反例として扱います。
- 規約の不一致を意図的に探す:
- UI: 確立された領域内でのコンポーネントシステムの混在。隣接するUIとは異なるコントロール、構成、スタイリング、プロパティ、またはイベントパターンの選択。
- コード: 既存のヘルパー/ラッパーのバイパス、異なる状態管理またはエラーハンドリングのイディオムの使用、命名/型/インポートの規約、または一貫性のないファイル配置。
- テスト: 一貫性のないフィクスチャ/セットアップ、命名、構造、ロケーター、またはアサーションスタイル。説明のない必要性なしに、ターゲットを拡大する既存のE2Eセレクターまたはアサーションへの変更。
- 変更範囲: 同じことを行うための2つ目の方法の導入、または差分内の無関係なスタイルの書き換え。
- 見かけ上の不一致に挑戦する。 不一致を報告する前に、実装、呼び出し元、およびテストから、変更されたコードの実際の責任と意図を確立します。関連する用語やAPIが現れたという理由だけで規約を適用しないでください。引用された規約が、テスト対象の動作、実装メカニズム、またはテストの場所のいずれを統治しているかを判断し、それがこの変更に適用される理由を説明します。文書化された移行、意図的な例外、または真に異なる要件がその選択を説明しているかどうかを確認します。例が矛盾する場合は、一律のルールをでっち上げるのではなく、不確実性を報告します。
報告の閾値
ルールを宣言することよりも、候補を見つけることに積極的であること。比較対象となる特定の先行例や文書化されたポリシーがある場合は、軽微で議論の余地のある逸脱も報告します。実行時の欠陥、高い重大度、または複数の同一の例の証拠を必要としません。
明示的に文書化されていなくても、強く裏付けられた推論された規約を報告します。それらを「推論」とラベル付けし、裏付けとなる証拠を引用します。
- 明確な不一致: 直接適用可能なガイダンスまたは強力なローカルの先行例。
- 可能性のある不一致: 具体的だが限定的/矛盾した先行例。人間によるレビューに値する。不確実性を明確に特定します。
規約をでっち上げたり、無関係なコードを証拠として引用したり、1つの偶発的な例を普遍的なルールに変えたりしないでください。純粋なフォーマッター/リンターの些細なこと、リポジトリの証拠がない好み、変更範囲外の既存の問題、および$review-agentが処理する一般的な正しさ/セキュリティ/パフォーマンスのバグはスキップします。均一性を強制するために広範なリファクタリングを要求しないでください。
例: ツールバーにトグルが追加された場合、そのツールバーの他のコントロールと、他の場所にあるトグルの両方を検査します。Quasarベースのツールバーで異なるコンポーネントシステムを使用することは、正しく機能していても、発見事項に値する可能性があります。これはローカルな規約を見つけるための方法であり、Quasarを必須とする一律のルールではありません。
出力
異なる、証拠に裏付けられた候補をすべて報告します。影響の少ないものも含みます。同じ問題の重複するインスタンスはマージします。単に重大度だけでなく、メンテナーにとっての関連性の高い順に並べます。
各発見事項について以下を提供します:
- 場所: 変更されたファイルと行。
- 規約の証拠: 正確な既存のファイル/場所または文書化されたルール。「文書化」または「推論」とラベル付けします。
- 不一致: 何が異なり、なぜそれが一貫性にとって重要なのか。
- 提案: 最小限の合理的な調整。不確実な場合は提案として表現します。
- 信頼度:
高、中、低。中/低の場合は不確実性を説明します。
明確な不一致を可能性のある不一致から分離します。どちらにも証拠に裏付けられた候補がない場合は、「規約に関する発見事項はありません。」と記載します。スタイル上の理由や手動レビューで却下される可能性があるという理由だけで、もっともらしいケースを黙って破棄しないでください。