mcpField
B
blast-radius

blast-radius

github.com/scottwaterテスト・品質151 回インストール1 週間前に更新
リポジトリ

blast-radius について

blast-radius は、差分が変更ファイルの外で引き起こす障害を追跡するコードレビュー用スキルです。実行可能なチェックで安全性を裏付けるか、証拠の不足を明示します。

主な機能

  1. 01変更から外部利用者や境界まで追跡
  2. 02証明段階に沿った安全性の評価
  3. 03根拠を示した到達可能なリスクの評価
  4. 04マージ前の絞り込んだテストを提案

活用シーン

  1. 01サブシステムをまたぐ変更のレビュー
  2. 02ライフサイクル、スキーマ、依存関係の確認
  3. 03回帰経路の特定と検証

インストール

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

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

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

詳細

影響範囲

差分が、変更対象のファイル以外に引き起こしうる不具合を見つけます。結果が有用なのは、主要な安全性に関する主張が、コード、実行可能なチェック、または明確に名付けられたエビデンスの不足によって裏付けられている場合に限られます。

関連する分岐がある場合は、how を使って実行時の動作を追跡し、why を使って過去の制約を確認してください。

証明の段階

安全性にとって重要な主張は、リポジトリと利用可能なツールで可能な限り、次の段階を下へたどって検証してください。

  1. 断言。 根拠のない、もっともらしい説明。
  2. ソース。 具体的な file:line、固定された依存関係のソース、スキーマ、またはプロトコル定義。
  3. トレース。 障害が影響を受ける境界に到達するかどうかを示す、段階的な経路。
  4. 実行可能なチェック。 本番経路を呼び出し、主張が誤っていれば失敗するスクリプトまたはテスト。
  5. 実行時の再現。 稼働中のシステムで再現された動作。

段階1と2は手がかりとして扱ってください。安全性にとって重要な主張が段階4に到達できない場合は、未証明とし、より強い証明を妨げた要因を説明してください。

ワークフロー

1. 変更範囲を定義する

差分を読み、追加、変更、削除されたシンボルや動作をすべて特定します。タイミング、順序、デフォルト値、シリアル化、エラー処理など、暗黙的な変更も含めてください。差分に判断の背景がない場合は、関連するコミットや根拠を確認します。

完了条件: 変更された動作すべてについて、変更前と変更後の説明が明確になっていること。

2. 安全性を支える主要な事実を見つける

変更を安全にする1つか2つの事実を特定します。例として、冪等性の保証、呼び出し元の不変条件、互換性の約束、ライフサイクルの順序制約などがあります。実行可能なチェックで誤りを証明できる形で、それぞれの事実を記述してください。

完了条件: 列挙した事実のいずれかを反証すると、具体的な障害経路が明らかになること。

3. シンボル検索を超えて追跡する

直接の呼び出し元と、シンボル検索では見落とされる境界をたどります。

  • 固定された依存関係の動作とローカルパッチ。
  • タスクキュー、コールバック、ティアダウン、ライフサイクルの順序。
  • API、スキーマ、データベース、ファイル、ワイヤ形式。
  • 同じデータを利用する他の言語やサービス。
  • フラグ、設定、キャッシュ、下流のジョブ。

現在と以前の名前、値、形式の両方を検索します。該当がないことが重要なエビデンスになる場合は、該当なしとなった検索も記録してください。

完了条件: 変更された動作すべてが、外部の利用者まで追跡されているか、または影響を封じ込める境界が検証されていること。

4. リスクを評価する

リスク候補ごとに、次の点を示します。

  • 障害の仕組み。
  • 引用を添えた、影響を受ける呼び出し元または境界。
  • 根拠を伴う発生可能性と影響。
  • リスクを確認または否定するための最も手軽なチェック。

確認済みのリスクと、問題なしと判断した候補を分けてください。到達可能な障害経路がない、推測にすぎないリスクは除外します。

完了条件: 残したリスクすべてについて、変更から観測可能な障害までの経路に引用が添えられていること。

5. 安全性を支える主要な事実を証明する

製品で使用されるものと同じコードをインポートして実行する、焦点を絞ったスクリプトまたはテストを優先します。実行して、コマンド、結果、関連する出力を記録してください。手間が少なく、実質的に強い証拠が得られる場合は、実行時に再現してください。

変更範囲が広い場合は、独立した依存関係領域ごとにレビューを分割し、結果を照合します。実行環境が対応している場合に限り、並列レビュー担当者を利用してください。この手法は、特定のエージェントやモデルに依存してはなりません。

完了条件: 安全性を支える主要な事実すべてについて、証明の段階と、実用上得られる最も強いエビデンスが示されていること。

出力

変更点

明白でないタイミング、形式、ライフサイクルへの影響も含め、動作の違いを説明します。

安全性を支える主要な事実

各事実について、証明の段階、エビデンス、ステータス(proven または unproven)を示します。

確認済みのリスク

到達可能な障害のみを列挙します。場所、発生可能性、影響、およびチェックまたは緩和策を含めます。

問題なしと判断した候補

調査によって除外した、もっともらしいリスクを挙げ、除外の根拠となったエビデンスを引用します。

マージ前

実際の境界を保護する、最小限のテストまたは再現手順を用意します。調査中に作成したスクリプトがあれば、それも含めます。

完了条件: レビュー担当者が検証結果を再現し、確認済みのリスクと不確実な点を区別でき、残っているすべての不足箇所を把握できます。

コメント