pr-test-impact-analysis

PR テスト影響分析

使用する場面

• プルリクエストの差分、依存関係、過去のリスクから、必要十分な最小限のテスト範囲を導き出す必要がある場合に使用します。
• 既存の計画、結果、エビデンス一式をレビューし、実行可能な改善案を提示する場合に使用します。
• コンテキストが不完全でも、範囲を限定した初回の分析に価値がある場合に使用します。

出力形式の選択肢

• レビュー、実行、段階的な改善には、デフォルトで Markdown を使用します。
• ユーザーがテーブル、CSV、JSON、チケットの各フィールドを求めた場合は、リスク、エビデンス、優先度、境界に関する情報を保持します。
• 機械処理される出力の場合は、まずスキーマ、列挙値、必須フィールドを確認します。

使用方法

1. prompts/pr-test-impact-analysis.md を読み、その入力仕様、実行ルール、最低限のカバレッジ、出力順序に従います。
2. スコープ、環境、バージョン、制約、エビデンス、成功基準など、判断に影響するコンテキストのみを追加します。
3. 入力を監査し、確認済みの事実、作業上の仮定、未解決の質問を分けます。
4. リスクとエビデンスの強さに基づいて優先順位を付け、そのまま実行またはレビューできる成果物を作成します。
5. 情報が不足している場合は、範囲を限定した初回分析を提示し、どの結論が裏付けられていないかを明記します。

参考ファイル

• ドメイン上の結果、妥当なコントロール、エビデンスの不足を調整する場合は、サニタイズ済みの入力、項目ごとのオラクル、再現可能な計算を確認するために references/domain-decision-example.md を読みます。

• 必ず prompts/pr-test-impact-analysis.md を読みます。このファイルには、このスキルの実行仕様がすべて記載されています。

• 評価または回帰テストでは、evals/eval.yaml と evals/cases/ 内の該当するケースを読みます。

• references/、examples/、scripts/、output-formats.md は、これらのディレクトリが存在し、タスクで必要な場合にのみ読み込みます。

ドメイン実行の要点

1. リポジトリ、base、head の SHA と差分の範囲を固定します。ソースファイル／シンボル／スキーマ／設定の変更を確認します。名前だけでは影響の根拠にならず、異なる HEAD で得られた結果をまとめることはできません。
2. 変更されたシンボル→直接／推移的な利用元→検証要件→テスト ID／レイヤー／実行バージョンの対応関係をマッピングします。エッジには確認済み／候補／不明のラベルを付け、エビデンスで確認された分離境界でのみ調査を終了します。
3. 削除または弱体化されたテストについては、その検証要件が独立した保護を維持しているか確認します。残存するテスト一覧だけから選ぶと、失われたカバレッジが見えなくなる場合があります。
4. 動的な依存関係やマッピングが不明な場合は、不足を明記したうえで、契約テスト／統合テストの候補を保守的に追加します。範囲の候補、実行済みテスト、満たされた検証要件を分け、範囲拡大／エスカレーションのトリガーを列挙します。

主な制約

• ファイル名だけから推測しないでください。
• テストの選定根拠となるエビデンスを提示してください。
• リスクが高く、エビデンスが弱い場合は、範囲を拡大してください。
• エビデンスにないシステムの動作、フィールド、データ、メトリクス、根本原因を決して捏造しないでください。
• 重要な結論をエビデンスに結び付けます。裏付けのない結論は仮説として示し、検証方法を記載します。
• ビジネスへの影響、発生可能性、または検出可能性を用いて優先度を説明します。

提出前チェックリスト

• 変更の意図、直接的および推移的な影響、公開インターフェース、データ変更、設定、セキュリティ、ロールバック、テストの不足を網羅した。
• 事実、仮定、不足事項、推奨事項を分けた。
• 高リスク項目に優先度、エビデンスの根拠、担当者または次のアクションを示した。
• 一般論ではなく、検証可能な判断基準を定めた。
• 許可されていない本番環境への書き込みや破壊的な操作を行わなかった。

よくある落とし穴

• 前提条件、期待される結果、エビデンスなしにチェック項目を列挙する。
• すべてを高優先度にして、優先順位の判断を避ける。
• ドメインに即した推論の代わりに、ツール名や一般論を使う。
• 不完全な入力を理由に対応を拒む、または不完全なエビデンスから確実な結論が得られるかのように装う。

ベストプラクティス

• ビジネス上の損失、安全上の問題、リリースの阻害につながる可能性が最も高いパスから着手します。
• 最小限の検証可能な実験で不確実性を減らし、再現条件を記録します。
• 成果物を実行可能にし、別のエンジニアが独立してレビューできるようにします。