change-impact-analysis

変更影響分析

使用するタイミング

• コード、設定、データ、依存関係の変更による影響を受ける機能、回帰テストの範囲、リリースリスクを特定する必要がある場合に、このスキルを使用してください。
• 既存の計画、結果、またはエビデンス一式をレビューし、実行可能な改善案を作成する場合に使用してください。
• コンテキストが不完全でも、範囲を限定した初回分析に価値がある場合に使用してください。

出力形式のオプション

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

使用方法

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

参照ファイル

• ドメイン固有の結果、有効な制御項目、エビデンスの不足を評価する際は、サニタイズ済みの入力、項目ごとのオラクル、再現可能な計算が記載された references/domain-decision-example.md を読んでください。

• 必ず prompts/change-impact-analysis.md を読んでください。このスキルの完全な実行仕様です。

• 評価または回帰テストでは、evals/eval.yaml と、evals/cases/ 以下の関連ケースを読んでください。

• references/、examples/、scripts/、output-formats.md は、該当するディレクトリが存在し、タスクで必要な場合にのみ読み込んでください。

ドメイン実行の要点

1. 変更のバージョンと対象範囲を確定し、変更されたファイル／シンボル／設定から、依存先、業務上の要件、テスト ID へとつながる型付きエビデンスのエッジを構築してください。各エッジにはソース／バージョンと、確認済み／候補／不明の状態を付けてください。
2. 直接および推移的な利用箇所をたどり、循環は重複排除してください。エビデンスで契約上の分離または利用者がいないと確認できた境界でのみ追跡を止め、その理由を記録してください。ディレクトリだけでは境界になりません。
3. 動的な登録、実行時設定、追跡できない依存関係は不明のままとしてください。リスクに応じた利用者の契約テスト／統合テストを提案してください。対応関係がないことは、影響がないことを意味しません。
4. 対象に含めるもの／除外するもの、最低限の検証、残存リスク、範囲を広げる条件を説明してください。この Skill はコード／データ／設定の変更全般を扱い、PR 固有の対応物は base/head/diff の識別を担当します。

中核となる制約

• 確認済みの影響と推定された影響を分けてください
• 変更されたファイルだけを基準にテストを選ばないでください
• 追跡できない依存関係はリスクとして明示してください
• エビデンスにないシステムの動作、フィールド、データ、メトリクス、根本原因を決して捏造しないでください。
• 重要な結論はエビデンスに結び付けてください。裏付けのない結論は仮説として示し、検証方法を記載してください。
• 業務への影響、発生可能性、または検出可能性に基づいて優先度を説明してください。

提出チェックリスト

• 直接的な影響、推移的な影響、データ互換性、API 契約、権限、実行時依存関係、ロールバック、可観測性を網羅した。
• 事実、仮定、不足情報、推奨事項を分けた。
• 優先度の高い項目に、優先度、エビデンスの根拠、担当者または次のアクションを付けた。
• 一般論ではなく、検証可能な判断基準を定めた。
• 許可されていない本番環境への書き込みや破壊的な操作を行わなかった。

よくある落とし穴

• 前提条件、期待される結果、エビデンスを示さずに確認項目を列挙する。
• 優先度をすべて高く設定し、トレードオフを避ける。
• ドメインに即した推論の代わりに、ツール名や一般論を用いる。
• 入力が不完全だとして拒否する、または不完全なエビデンスが確実な結論を裏付けているかのように扱う。

ベストプラクティス

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