neo-code-review

コードレビュー

以下の読み取り専用ワークフローに従います。根拠に基づく、対応可能な指摘のみを報告してください。

次の場合に実施

• ユーザーがコード、PR、差分、コミット、セキュリティ、パフォーマンス、テスト、保守性のレビューを依頼した場合。
• ファイル間でコードやロジックが重複しているか、ハードコードされた値を一元管理すべきか、ユーザーが尋ねた場合。
• AI エージェントがコード、テスト、設定、スクリプトの変更を終え、引き継ぐ前。

ワークフロー

1. レビュー範囲を定義する

   • ユーザーが提示したファイルまたはコードスニペットを、主なレビュー範囲とします。
   • ユーザーが範囲を指定せず、現在のディレクトリが Git リポジトリの場合は、次を実行します。

     uv run skills/neo-code-review/scripts/git-diff-reviewer.py --working-tree
     

   • ステージ済みの変更のみを対象とする場合は --staged を、コミット範囲を対象とする場合は --commit <range> を使用します。
   • 周辺のコード、関連するテスト、既存の契約を確認します。レビュー可能な入力がない場合は、その旨を報告して終了します。
   • 作業ツリーをレビューする場合は、ヘルパーが出力した追跡対象の差分と、無視対象ではない未追跡ファイルをそれぞれ個別の入力として含めます。

2. レビュー規則を読み込む

   • コードを評価する前に、review-checklist.md を読みます。
   • 変更内容から実際の言語、フレームワーク、影響を受ける動作を特定します。ファイル名から未確認の規則を推測しないでください。

3. ファイル間の一貫性スキャンを実施する

   • レビュー対象と、関連するリポジトリのソースファイルおよび設定ファイルから比較対象を組み立てます。rg --files とリポジトリの無視ルールを使用します。明示的に対象範囲に含まれていない限り、依存関係、ベンダー、キャッシュ、生成物、圧縮済みファイル、ビルド出力、カバレッジ出力を除外します。
   • 変更またはレビュー対象の関数、クラス、検証ルールと認可ルール、状態遷移、リクエストまたはクエリの構築、エラー処理、URL、ルート、タイムアウト、再試行回数、しきい値、正規表現、機能フラグ、エラーメッセージなど、特徴的なリテラルを一覧にします。
   • 比較対象から完全一致および類似一致を検索し、一致箇所をそれぞれ文脈の中で読みます。動作が一致する場合は、名前や書式の違いを無視します。ビジネスルール、入力、副作用、失敗時の動作が実質的に同じ場合は、名前が変更されたコピーや、配置がわずかに変更されたコピーも重複として扱います。
   • 意味のある重複のみを報告します。対象となるのは、実装のコピー、重複したビジネスロジックや検証ロジック、挙動が異なるセキュリティロジックや状態ロジック、繰り返し使われる重要なハードコード設定です。共通キーワード、一度だけ使用される通常のリテラル、テストフィクスチャ、スナップショット、生成ファイル、ベンダーコードだけに基づく一致は報告しません。
   • ファイル間の指摘にはすべて、両方のファイルパスと行番号を記載します。保守性、差異の発生、セキュリティ、動作に及ぼす具体的なリスクを説明し、共有ヘルパー、定数、設定元、その他の信頼できる唯一の情報源を具体的に提案します。
   • ユーザーがコードスニペットまたは特定のファイルのみを提示し、リポジトリのコンテキストがない場合は、## Validation にファイル間の検証ができなかったことを記載します。リポジトリ内の一致や行番号を捏造してはいけません。

4. リスクを分析する

   • 正確性、リグレッション、セキュリティ、データ整合性、リソースのライフタイム、並行処理、リスクの高いテスト不足を優先します。
   • 🔴 Critical Issues には、セキュリティの脆弱性、データ損失、誤った動作、認可の回避、重大なリグレッションのみを含めます。
   • 🟡 Suggestions には、対応可能で、影響と修正方針が明確な、ブロッキングではない問題のみを含めます。
   • 通常のロジック重複やハードコード設定は 🟡 Suggestions に分類します。ハードコードされた秘密情報、または実証可能なセキュリティ上・動作上の欠陥につながる重複は 🔴 Critical Issues に分類します。
   • 好みの問題、根拠のない推測、根拠によって該当すると確認できないチェックリスト項目は報告しません。

5. 簡潔なレポートを作成する

   • 英語で記述し、src/user.ts:42 のようにファイルパスと行番号をそのまま記載します。
   • 次の構成を使用します。すべての重大度セクションを残し、指摘がないセクションには None と記載します。

     ## 🔍 レビューの概要
     - **ステータス**: `🟢 納品可能`、`🟡 修正を推奨`、`🔴 納品不可`、または `⚪ レビュー可能な変更なし`
     - **対象範囲**: 確認したファイルまたは変更内容。
     
     ## 🔴 重大な問題
     - **場所**: `path:line`
       - **問題**: 具体的な動作上の不具合。
       - **影響**: 検証可能な結果。
       - **修正**: 具体的な修正方針。修正内容を明確にする場合に限り、コードを含めます。
     
     ## 🟡 提案
     - **場所**: `path:line`
       - **種類**: 重複したロジック、重複したハードコード値、または該当するその他のカテゴリ。
       - **根拠**: 一致する場所と、各ファイルにおける関連する動作または値。
       - **推奨事項**: 具体的で、対応を妨げない改善案。
     
     ## 🟢 良い点
     - 変更によって直接裏付けられる良い点のみを列挙します。
     
     ## 検証
     - 複数ファイル間の比較対象範囲と、利用できないリポジトリのコンテキストを記載します。
     - 実行したテスト、ビルド、チェックを列挙します。実行しなかったものも明記します。
     

6. 納品ゲートを適用する

   • 自動レビューで 🔴 重大な問題 が見つかった場合、レビュー対象範囲を確定できない場合、またはスキルを読み込めない場合は、完了を宣言したり引き継いだりしないでください。
   • 指摘事項を修正した後、必須のチェックを再実行し、変更内容を再レビューしてください。