mcpField
B
blast-radius-audit

blast-radius-audit

github.com/marcellocurtoテスト・品質363 回インストール1 日前に更新
リポジトリ

blast-radius-audit について

blast-radius-audit は、コード変更を読み取り専用で調べるテストスキルです。変更された契約の利用箇所を追跡し、証拠に基づいてリスクを評価します。

主な機能

  1. 01変更された契約の洗い出し
  2. 02直接・間接の利用箇所の追跡
  3. 03コード、テスト、プローブによるリスク確認
  4. 04証拠と状態に基づくリスク分類
  5. 05監査全体の判定

活用シーン

  1. 01プルリクエストの互換性リスク確認
  2. 02変更された設定項目の利用箇所確認
  3. 03ブランチのデプロイ前のリスク評価
  4. 04編集ファイル外への影響の監査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/marcellocurto/skills --skill blast-radius-audit

インストール後、Claude Code で/blast-radius-auditを入力して読み込まれたか確認します。

詳細

Blast Radius Audit

変更が編集対象外のファイルの動作にどのような影響を及ぼすかを特定し、安全性の前提となる事実を確認します。

これは監査です。ユーザーから別途依頼がない限り、リポジトリのファイルを編集したり、永続的なテストを追加したり、修正を適用したり、コミットしたり、本番環境や外部システムに触れたりしないでください。読み取り専用の調査と、元に戻せるローカルコマンドの実行は問題ありません。一時的な調査用ファイルは、チェックアウトしたコードをインポートできる状態で、作業ツリーの外に置き、作業後に削除してください。

1. 変更されたコントラクトを列挙する

ユーザーが指定したプルリクエスト、ブランチ、コミット、または作業中の変更を監査します。指定がない場合は、現在のブランチをデフォルトブランチと比較し、未コミットの変更も監査します。ベースとヘッドのコミット、およびマージベースを記録し、ベースにのみ存在するコミットが含まれないように git diff <merge-base>..<head> を読みます。

差分全体、コミットメッセージ、関連するテスト、リポジトリの指示を読みます。そのうえで、編集箇所からは明らかでないものも含め、変更によって変わるすべてのコントラクトを列挙します。

  • 関数や型のシグネチャ、戻り値の形式、スローされるエラー、および呼び出し側が照合するエラーメッセージ
  • 保存データ:データベースの列、シリアライズ形式、キャッシュキー、イベント、ファイル、エクスポート
  • 外部インターフェース:HTTP または RPC のレスポンス、CLI の出力とフラグ、公開パッケージエクスポート
  • 設定キー、環境変数、機能フラグ、デフォルト値
  • タイミング:処理の順序、再試行、トランザクション、起動と終了、後で実行される処理や複数回実行される処理
  • 移動、緩和、削除された権限チェック、検証、その他のチェック
  • ホットパスのコスト:クエリ数、ペイロードサイズ、大規模なコレクションを走査するループ

2. 利用箇所を見つける

変更された各コントラクトについて、それに依存するものを見つけます。シンボル名だけでなく、列名、イベント名、設定キー、ルートパスなどのリテラル値でも検索してください。多くの利用箇所は文字列を通じてコントラクトを参照するためです。直接の呼び出し元だけでなく、生成コード、依存性注入、プラグイン、リフレクション、マイグレーション、フィクスチャ、スクリプト、ドキュメント、他のサービスやリポジトリ、ロールアウト中も稼働している旧バージョンも調べます。

検索しても結果がないからといって、コントラクトが使われていないことの証明にはなりません。どこを調べたかを記載してください。

結論がライブラリやランタイムの動作に依存する場合は、インストールされているバージョンと、そのコードまたはドキュメントを確認します。

3. 各リスクを確認する

リスクとして挙げるには、変更から利用箇所に至る妥当な経路が必要です。その経路がない懸念は列挙しないでください。

各リスクについて、変更が安全であるために必要な条件を述べ、最も低コストで信頼できる方法で確認します。方法には、コードや文書化されたコントラクトを読む、経路を追跡する、既存のテストを実行する、一時的な調査用コードを実行するなどがあります。調査用コードは実際のコードと依存関係のバージョンを使い、前提が誤っている場合に明確に失敗する必要があります。モックを使った調査では、リリースされる経路について何も証明できません。すでに得られた証拠を繰り返すためだけに、確認を再実行しないでください。

各リスクに、次のいずれかのステータスを付けます。

  • 確認済み: 問題が発生し得ます。条件を述べ、再現したのか、コードを読んで確認したのかを明記します。
  • 未解決: 確認または否定するために必要な具体的な事実が不足しています。その事実と、結論を出すために必要な確認を明記します。
  • 否定: 証拠により、監査対象のシナリオでは問題が発生し得ないことが示されています。

4. 報告

次のうち、最初に該当する判定を選びます。

  • 重大なリスク:確認済みのリスクが、ユーザー、データ、互換性、パフォーマンス、運用に影響する場合。
  • 未検証:未解決のリスクが重大である可能性がある場合。
  • 封じ込め済み:残るリスクがすべて否定されているか、軽微であると確認されている場合。これは、調査した範囲にのみ当てはまります。

次の形式を使い、報告する内容がないセクションは省略します。

**Verdict:** Material risk | Unverified | Contained, with one sentence on why.

**Changed contracts:** the contracts from step 1 that have consumers outside the diff.

**Risks**, confirmed and unresolved, most severe first:

- **Status: what breaks.** The conditions, who is affected, and the evidence. The next check or fix direction, plus detection and rollback when they matter.

**Ruled out:** only concerns a reviewer would likely raise, each with its evidence in one line.

**Before merge:** checks or decisions still needed.

コメント