review-diff

スキル：差分のレビュー

目的

現在の変更のみ（git diff：ステージ済み＋未ステージ、任意で未追跡ファイルも含む）を、次の5つの観点からレビューします：意図／影響、回帰／正確性、破壊的変更／互換性、副作用／冪等性、可観測性。orchestrate-code-review の集約用スコープステップに渡す、スコープのみの指摘リストを作成します。

---

主な目的

第一の目標：差分のスコープのみを対象に、5つの観点にわたる指摘リストを作成します（未追跡ファイルも含みます）。

成功基準（すべて満たす必要があります）：

1. ✅ 差分のスコープのみ：変更セットのみをレビューし、リポジトリ全体／アーキテクチャ／セキュリティ／言語固有のチェックは行いません
2. ✅ 5つの観点すべてを網羅：意図／影響、回帰／正確性、破壊的変更／互換性、副作用／冪等性、可観測性
3. ✅ 形式に準拠：specs/findings-list.md に従い、すべての指摘に場所／category=scope／重大度／タイトル／説明／提案を含めます
4. ✅ 正確な場所：すべての指摘で、具体的な file:line または @@ ハンクを示します
5. ✅ バグ修正の検証：バグ修正の差分では、修正の正確性を検証し、残存する問題や部分的な問題があれば指摘します

---

スコープの境界

このスキルが担当するもの：

• 現在の git diff（ステージ済み＋未ステージ）
• 変更セット内の未追跡ファイル（デフォルトで含め、ファイル全体の追加として扱います）
• 5つの観点にわたる分析：意図／影響、回帰／正確性、破壊的変更／互換性、副作用／冪等性、可観測性

このスキルが担当しないもの：

• リポジトリ全体またはスナップショット全体のレビュー → review-codebase
• オーケストレーションによるレビュー全体 → orchestrate-code-review
• アーキテクチャ／セキュリティ／パフォーマンス／テストに関する認知的観点 → 対応する認知的アトミックスキル
• 言語／フレームワーク固有の規約 → 対応するアトミックスキル

引き継ぎ先：指摘を出した後、集約のために orchestrate-code-review のスコープステップへ渡すか、修正の反復のために orchestrate-repair-loop へ渡します。

---

使用例

• コミット前／PR前のゲート：コミット前に、変更によって何が導入されるかを手短に確認します
• orchestrate-code-review のスコープステップとして：このスキルか review-codebase のどちらか一方を使い、両方は使いません
• 対象を絞ったレビュー：ユーザーが「変更だけを確認して」と指示した場合

---

動作

スコープの解決

• 分析対象：変更セット内のファイル。差分（ステージ済み＋未ステージ）に、デフォルトで含まれる未追跡ファイルを加えたものです
• 未追跡ファイルの扱い：呼び出し元からパスと全文を受け取り、ファイル全体の追加として扱います。同じ5つの観点のチェックリストを適用し、file:line を示します
• 分析対象外：変更されていないファイル、および変更セットの範囲外にあるファイル

5つの観点のチェックリスト

変更された各ファイルについて、次の観点から指摘を作成します。

1. 意図と影響：何が、なぜ変更されたか。呼び出し元／データ／設定／デプロイへの影響
2. 回帰と正確性：新たなバグや見落とされたエッジケースが生じていないか。バグ修正の差分で問題全体が解決されているか
3. 破壊的変更と互換性：API／データ／設定の契約が破られていないか。後方互換性、バージョン管理／非推奨化
4. 副作用と冪等性：意図しない副作用、データ破損、繰り返し実行時のリスク、冪等性の問題
5. 可観測性：本番環境でのデバッグに必要なログ、メトリクス、エラーメッセージが追加または修正されているか

特別なケース

• バグ修正の差分：修正が正しいことを検証し、残存する問題や部分的な問題があれば記録します
• 書式設定のみ／コメントのみの差分：「書式設定／コメントのみで、動作の変更なし」という軽微な指摘を1つ出します。コメントがコードと矛盾する場合は、提案を添えて指摘します

---

入力と出力

入力

• git diff：HEAD に対する現在のブランチのステージ済みおよび未ステージの変更
• 未追跡ファイル（デフォルトで含まれます）：パスと全内容

出力

• 指摘事項の一覧：標準形式（location / category=scope / severity / title / description / suggestion）
• すべての指摘事項に、ファイルと行番号、または @@ ハンクへの参照を含めること
• すべての指摘事項に、実行可能な提案を含めること

---

制約

厳守事項

• 差分の範囲外にあるファイルをレビューしないでください
• ファイルと行番号への参照がない指摘事項を出さないでください
• 曖昧な表現（種類も方向性も示さない「問題かもしれない」など）は使わず、削除してください
• セキュリティ／アーキテクチャ／言語／フレームワークのチェックは行わず、スコープの観点に限定してください

スキルの境界

ここでは行わないこと（ほかのアトミックスキルが担当します）：

• リポジトリレベル／スナップショットレベルのレビュー → review-codebase
• 全観点のオーケストレーション → orchestrate-code-review
• セキュリティ → review-security
• アーキテクチャ → review-architecture
• 言語／フレームワーク → 対応するアトミックスキル

---

セルフチェック

• 変更セット（差分と、含まれる未追跡ファイル）のみをレビューした
• 5 つすべての観点をカバーした
• すべての指摘事項が形式（6 フィールドすべて）に準拠している
• すべての指摘事項に、ファイルと行番号、または @@ ハンクへの参照がある
• すべての指摘事項に、実行可能な提案がある
• バグ修正の差分では、修正が正しいことを検証した

---

例

例 1：API の変更

• 入力：クエリパラメーターを追加し、レスポンスの形式を変更する差分
• 期待される結果：呼び出し元への影響を含む意図／影響、後方互換性のリスク、バージョニングや非推奨化などの破壊的変更への提案を網羅した指摘事項。正確な行または @@ ハンクを示すこと。セキュリティ／アーキテクチャに関する指摘はしないこと（それらは対応するアトミックスキルが担当します）

例 2：バグ修正

• 入力：ヌルポインターとエラーコードを修正する差分
• 期待される結果：修正内容を確認し、同様のヌルポインター／エラーコードの問題が残っていないかも確認すること。可観測性の観点（ログ／エラー）も含め、変更行を示すこと。category=scope

例 3：フォーマット／コメントのみ

• 入力：インデント／空白／コメントの変更のみを含む差分
• 期待される結果：指摘事項なし、または「フォーマット／コメントのみで、動作の変更なし」という軽微な指摘事項を 1 件出すこと。コメントがコードと矛盾している場合は、提案を添えて指摘事項を出すこと

例 4：変更セット内の新しい（未追跡）ファイル

• 入力：差分と未追跡ファイル（パスと全内容）
• 期待される結果：新しいファイルをファイル全体の追加としてレビューし、5 つの観点のチェックリストを適用すること。場所には行番号付きのパスを指定し、category=scope とすること