diff-inspector について
diff-inspectorは、プルリクエストの作成前やマージ前にコード変更を確認するエージェントスキルです。レビュー範囲を定め、技術面とドキュメントのリスクを調べ、根拠、重大度、ファイル位置を添えて報告します。
主な機能
- 01差分の範囲を特定して確認
- 02セキュリティ、データ、並行処理をレビュー
- 03契約、互換性、テストを確認
- 04関連ドキュメントとエージェント成果物を調査
- 05根拠に基づき重大度を分類
活用シーン
- 01プルリクエスト作成前の変更レビュー
- 02マージ前の差分確認
- 03変更された契約の生成元と利用側を追跡
- 04検証が必要な潜在的問題を調査
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ timlai666/ skills --skill diff-inspectorインストール後、Claude Code で/diff-inspectorを入力して読み込まれたか確認します。
詳細
レビューのタイミング
プルリクエストを作成する前と、マージする前にレビューしてください。関連する差分に変更がなければ前回の結果を再利用し、変更があれば再度レビューしてください。
レビュー範囲の確定
ユーザーの入力、現在の作業ツリー、プルリクエスト、またはマージ先から、関連するコードの差分を特定してください。必要に応じて、リポジトリの既存の Git 状態、規約、タスクのコンテキストを確認してください。確認後もレビュー範囲またはベースが不明な場合は、ユーザーに質問してください。
レビュー手順
- 範囲を確認する: 差分を依頼内容と照らし合わせ、意味のある範囲の逸脱や要件の欠落があれば報告してください。
- コードをレビューする: 以下の技術的な確認項目に沿って、差分全体をレビューしてください。
技術的なレビュー
差分全体をレビューしてください。該当する各項目について、以下を確認してください。
- SQL とデータの安全性: クエリが信頼できない値を安全に処理し、処理範囲に上限があり、データの整合性を保っていることを確認してください。
- 競合状態と状態管理: 並行処理、確認後に実行する処理、共有状態、非同期処理が、アトミック性と一貫性を保っていることを確認してください。
- 認証とセキュリティ: 変更されたエントリーポイントで、認証、認可、所有権、トークンの有効性、入力検証が適切に適用されていることを確認してください。該当する場合は、シークレットの取り扱い、直接オブジェクト参照の不備、権限昇格、XSS、コマンドインジェクション、SSRF、パストラバーサルを確認してください。
- エラー処理: 部分的な失敗、タイムアウト、クリーンアップ、復旧を含め、障害が適切に通知され、処理されることを確認してください。
- パフォーマンスとリソース: 処理量の無制限な増加、リソースリーク、N+1 クエリ、インデックスの欠落、回避可能な二次的計算量の処理、負荷の高いループ、重い依存関係、フェッチのウォーターフォールを確認してください。
- 保守性: 不要な複雑さ、ロジックの重複、不明瞭な責務、抽象化の漏れ、変更内容の理解、テスト、拡張の難しさを確認してください。
- データ移行: 元に戻せない移行、スキーマ変更によるロック、外部キーのインデックス欠落、安全でないバックフィル、依存するコードより先にスキーマを削除していないかを確認してください。
- 完全性と互換性: 状態、フィールド、パス、識別子、スキーマ、設定など、変更された共有コントラクトごとに、以下を確認してください。
- まず、パスのプレフィックス、ファイル名のパターン、フィールド名、コマンド名、リゾルバー関数など、安定したコントラクトの断片を使って、対象ツリー全体を検索し、関連する箇所をすべて洗い出してください。
- 差分に含まれないファイルも含め、各値の生成元をすべての利用箇所までたどり、各利用箇所から具体的な生成元までさかのぼってください。値を計算するか、名前の付いた共有リゾルバーを呼び出す場合に限り、利用箇所に具体的な生成元があるとみなします。文章中のプレースホルダー、例、以前のツールから受け取ることを前提とした状態は、具体的な生成元には該当しません。
- 両側で使われている正確な値または導出ロジックを比較してください。対応漏れのある箇所、実装の欠落、重複または異なる導出があれば報告してください。
- API コントラクト: 上記の互換性確認の手順に沿って、互換性のないレスポンス、デフォルト値のない必須入力の追加、エラー形式の変更、ページネーションの動作を確認してください。
- テスト: 変更された公開動作、異常系や境界ケース、失敗経路、回帰防止をテストで検証していることを確認してください。分離性の違反や不安定なパターンも確認してください。
根拠と重大度
具体的な失敗シナリオが関連コードまたは観察された動作によって確認できる場合に限り、問題を Findings に記載してください。根拠に基づく懸念があるものの決定的な事実が不足している場合は、独立した Needs investigation セクションに記載し、不足している事実とその検証方法を示してください。
- P0: 重大またはブロッキングです。セキュリティ侵害、データ損失、サービス停止、その他マージ前に修正が必要な障害を引き起こす可能性があります。
- P1: 深刻です。誤った動作や重大なリグレッションを引き起こす可能性が高く、通常はマージ前に修正する必要があります。
- P2: 中程度で、影響範囲が限定されています。対処可能ですが、リスクが許容できる場合はマージ後に対応してもかまいません。
各指摘では、次の点を示してください。
- 該当するファイルと行を記載する
- 発生条件と影響を説明する
- 影響に基づいて P0、P1、P2 を割り当てる
CONFIRMEDと明記する- 影響に見合った対応を推奨する
推測やスタイル上の好みを不具合として報告しないでください。
指摘の形式:[P0/P1/P2] [CONFIRMED] file:line - 発生条件、影響、説明、推奨する対応
調査の形式:[NEEDS INVESTIGATION] file:line - 観察された根拠、起こり得る障害、不足している事実、検証手順。影響は確定した不具合の重大度を割り当てず、条件付きで説明してください。
敵対的サブエージェント
差分が大規模である、複数のコンポーネントにまたがる、または認証、認可、決済、機密データ、マイグレーション、並行処理、重要なユーザーワークフローなど、影響の大きい動作に関わる場合は、敵対的サブエージェントを実行してください。
You are an adversarial reviewer. Review the established diff.
Think like an attacker and a chaos engineer. Find ways this code will fail in
production — not style issues, not missing tests, actual breakage or security holes.
Apply the relevant Technical review checks from this skill independently.
Include file and line references, the failure trigger, evidence, and impact.
Use the Evidence and severity rules: CONFIRMED findings receive P0/P1/P2;
NEEDS INVESTIGATION concerns go in a separate section with missing facts
and verification steps. Do not classify uncertainty as a confirmed defect.
ドキュメントとガイダンスの整合性
差分の影響を受けるドキュメントと配布用ガイダンスを、リポジトリのルートと、影響を受けるパッケージ、モジュール、サブツリーの両方で確認してください。該当する場合は、次のものを含めてください。
- README ファイル、アーキテクチャガイド、コントリビューションガイド、API リファレンス、その他の説明用ドキュメント
- パッケージまたはモジュール固有のドキュメント
- プロジェクトの慣例で必要とされる場合、または変更がユーザーに影響する場合の変更履歴とリリースノート
AGENTS.mdやCLAUDE.mdなど、リポジトリで作業するエージェント向けの運用規約- インストール可能なエージェントスキル、プロンプト、テンプレート、サンプル、プラグインメタデータ、その他リポジトリが配布するエージェント向け成果物
動作、インターフェース、セットアップ、設定、インストール、マイグレーション、必須の成果物、ワークフロー、引き継ぎルール、ツールの使用方法、デプロイ上の制約の変更が、影響を受けるすべてのドキュメントまたは成果物に反映されているか確認してください。
リポジトリがインストール可能なスキルやその他のエージェント向け成果物を配布している場合、それらを製品の成果物として扱ってください。手順、サンプル、参照情報、メタデータ、パッケージングが変更後の動作と引き続き整合しているか確認してください。
不整合はそれぞれ、変更されたコードと影響を受けるドキュメントまたは成果物の両方を参照して報告してください。
最終出力
確認済みの指摘を P0 から P2 の順に先頭に記載し、その後に、根拠はあるものの調査が必要な懸念を記載してください。技術面、ドキュメント面、敵対的レビューの結果を、障害シナリオと影響箇所に基づいて確認・重複排除し、異なる原因と最も強い根拠は維持してください。
次の構成を使用してください。
## Diff Inspector
Scope: [CLEAN / DRIFT / MISSING]
Reviewed: [diff source and scope]
Adversarial review: [RUN — Trigger: reason]
### Findings
- [P0/P1/P2] [CONFIRMED] file:line - trigger, impact, description, and recommended action
### Needs investigation
- [NEEDS INVESTIGATION] file:line - observed evidence, possible failure, missing fact, and verification step
### Scope differences
- [include only when scope drift or missing requirements exist]
敵対的レビューを実施した場合に限り、Adversarial review の行を含めてください。確認済みの指摘がない場合は、No confirmed findings. と記載してください。調査が必要な懸念は別に報告してください。空のセクションは含めないでください。