blast-radius について
blast-radiusは、コード変更が直接の呼び出し元以外に及ぼす影響を調べるスキルです。見落としやすい依存関係を追い、実行可能なテストやスクリプトで安全性の前提を検証します。
主な機能
- 01間接的な依存関係の追跡
- 02ライブラリのソースと固定バージョンの確認
- 03リスクの発生可能性と影響の評価
- 04テストやスクリプトによる安全性の検証
- 05確認済みリスクと解消済み事項の区別
活用シーン
- 01小規模なコード変更の影響評価
- 02設計前の既存コードに関する前提確認
- 03マージ前の根拠に基づく調査結果の準備
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/blast-radiusを入力して読み込まれたか確認します。
詳細
影響範囲
変更をリリースする前に、ほかの箇所で何が壊れるかを見つけます。「X の影響範囲」「これで何が壊れる可能性があるか」と尋ねられたときや、まだ信頼できない小さな差分をレビューするときに使います。設計前にも実行してください。リリース前だけではありません。概要に既存コードについての断定（「エンドポイント X を公開する」など）がある場合、その断定は仮説であり、設計を決めるのは利用箇所の調査です。
how と why を補完するものです。how はコードが何をするかを教えてくれます。why はなぜそのような形になっているかを教えてくれます。影響範囲の調査は、ほかの箇所で何が壊れるかを教えてくれます。
呼び出し元を列挙することが目的ではありません。エージェントはそれなら後から grep で調べられます。目的は、grep では見つからない問題を明らかにすることです。
自分の説明を鵜呑みにしない
もっともらしく聞こえる影響範囲の説明には価値がありません。正しいかどうかにかかわらず、説得力があるように読めてしまいます。だから、説明をそのまま返してはいけません。全体が依存する事実を一つか二つ見つけ、コードを実行して証明してください。
どの程度確信がありますか
変更の安全性が依存する事実ごとに、無理のない範囲で以下のリストをできるだけ下まで進め、どこで止まったかを伝えてください。
- あなたがそう述べた。単独では価値がありません。
- 該当行を示した。実際の
file:line、またはライブラリ自体のソースです。 - 問題のあるケースが起きないことを示した。失敗に至る手順を追い、そこに到達しないことを確認しました。
- 実行した。実際のコードを呼び出し、間違っていたら明確に失敗するスクリプトまたはテストです。
- 実行中のアプリで再現した。
通常、ステップ 4 は、アプリが出荷するものと同じライブラリをインポートし、懸念している関数そのものを呼び出す小さなスクリプト一つで済みます。
手順
- 変更を読む。差分、追加・変更・削除されるシンボル、そして差分に明記されていない部分も含め、変更後に何が異なるのかを確認します。PR とコミットをたどるには、
whyのステップ 2 を使います。 - それが安全である根拠となる事実を一つ見つけます。危険そうに見える変更の多くは、「この呼び出しはすでに破棄されたキャッシュエントリーだけを削除し、それ以外は何もしない」のような一つの事実によって安全だとわかります。その事実を見つけてください。成り立つなら、危険そうなケースの大半を一度に解消できます。可能性を長々と列挙するのではなく、ここに時間を使ってください。
- grep で追えなくなる箇所を調べます。呼び出しているライブラリのソースを読み、固定されたバージョンとローカルパッチがあるか確認します。処理がいつ実行されるのかを突き止めます。マイクロタスク、アンマウントとティアダウン、Solid と React の違いなどです。シンボル検索では見つからないものも追います。API が返す JSON、DB のカラム、ワイヤ形式、同じバイト列を読み込む別の言語、フィーチャーフラグ、さらに下流の 3 段階先にあるコードなどです。
- それぞれのリスクについて、正直に評価します。実際に起こる可能性と、起きた場合の実際のコストを示してください。確認できたリスクを残します。調べて問題ないと判断したものは、別途一覧にします。
whyと同じルールに従います。実際のfile:lineを引用してください。何も見つからないという検索結果も回答になります。呼び出し元や API を決してでっち上げないでください。 - 根拠となる事実を一つ、証明します。実際のコードを実行するスクリプトまたはテストを書いて実行し、何が起きたかを貼り付けます。
- 大規模または広範囲な変更の場合は、
arenaとして実施します。同じ質問を複数のモデルに尋ね、回答をまとめます。モデルによって、実際のバグを別々に見つけられます。
提出する内容
- 何をするか。 変更内容を、明白でない部分も含めて説明します。
- 安全である根拠となる事実。 その事実を述べ、どのステップまで確認できたかを示し、証拠を提示します。証明できなかった場合は、未証明と記載します。
- リスク。 それぞれについて、どのように壊れるか、
file:line、発生可能性と影響の大きさ、確認方法を示します。重要なリスクについては、証拠を貼り付けます。 - 問題なしと判断した項目。 確認した内容と、問題ないと判断した理由を示します。
- マージ前に。 実際のバグを検出できる、最も手軽なテストまたは再現方法を示します。作成したスクリプトも含めます。
unslop を通して書き、実際のコードを引用し、公開する前に非公開情報をすべて取り除いてください。
回答： 上記の説明を返し、安全性の根拠となる事実を証明するか、未証明と記載してください。