blast-radius について
blast-radius は、変更が直接の呼び出し元以外に及ぼす影響を調べるコードレビュー用スキルです。実コードを実行して安全性の前提を検証し、確認済みと解消済みのリスクを分けて報告します。
主な機能
- 01呼び出し元以外への影響を追跡
- 02差分、シンボル、依存関係を調査
- 03コード実行で安全性の前提を検証
- 04確認済みと解消済みのリスクを分類
活用シーン
- 01コード変更のマージ前にリスクを評価
- 02影響が不明な小規模な差分をレビュー
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/blast-radiusを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yaml
詳細
影響範囲
変更をリリースする前に、別の場所で何が壊れるかを見つけます。「X の影響範囲」「これによって何が壊れる可能性があるか」や、まだ信頼できない小さな差分のレビューに使います。
how と why を補完します。how はコードが何をするかを説明します。why はその形になっている理由を説明します。影響範囲では、別の場所で何が壊れるかを説明します。
呼び出し元を列挙するのが目的ではありません。エージェントはそれならすぐに grep できます。目的は、grep では見つからない不具合を見つけることです。
自分の説明を鵜呑みにしない
もっともらしい影響範囲の説明でも、何の価値もありません。真実かどうかにかかわらず、説得力があるように読めてしまいます。ですから、説明をそのまま返してはいけません。全体が依存している事実を1つか2つ見つけ、コードを実行して証明してください。
どれくらい確信がありますか
変更の安全性が依存している事実ごとに、無理のない範囲で以下のリストをできるだけ下まで確認し、どの段階で止まったかを伝えてください。
- そう言った。これだけでは何の価値もありません。
- 該当する行を示した。実際の
file:line、またはライブラリ自体のソースです。 - 問題のケースが発生しないことを示した。失敗に至る手順を追い、そこに到達しないことを確認しました。
- 実行した。実際のコードを呼び出し、間違っていれば明確に失敗するスクリプトまたはテストです。
- 実行中のアプリで再現した。
通常、ステップ4では、アプリに同梱されるものと同じライブラリをインポートし、懸念している関数を直接呼び出す小さなスクリプトを使います。
手順
- 変更を読みます。差分、追加・変更・削除されたシンボル、そして差分に明記されていない部分も含め、以前と何が変わったかを確認します。
whyを指定して Skill ツールを呼び出し、ステップ2に従って PR とコミットを取得します。リポジトリに GitNexus インデックス（.gitnexus/が存在）があり、gitnexusがPATH上にある場合は、先に更新します（gitnexus analyze --index-only。インクリメンタルで、最新なら何もしません）。その後、マップを作成します。gitnexus detect-changesは差分を影響を受けるシンボルやフローと結び付け、gitnexus impact <symbol>は直接の影響範囲を示します。これは grep で見える範囲です。引き続き、見落とされる不具合を探すのが目的であり、証明には実際のコードを実行する必要があります。 - 安全である根拠となる事実を1つ見つけます。リスクがありそうに見える変更の多くは、「この呼び出しはすでに無効になったキャッシュエントリーを取り除くだけで、ほかには何もしない」のような単一の事実によって安全です。その事実を見つけてください。それが成り立てば、リスクの高いケースの大半を一度に解消できます。可能性を長々と列挙するのではなく、ここに時間を使ってください。
- grep では追えない範囲を調べます。呼び出しているライブラリのソースを読み、固定されているバージョンとローカルパッチを確認します。処理がいつ実行されるかを把握します。マイクロタスク、アンマウントとティアダウン、Solid と React の違いなどです。シンボル検索では見つからないものを追います。API が返す JSON、DB のカラム、ワイヤーフォーマット、同じバイト列を読み込む別の言語、機能フラグ、下流で3段階先にあるコードなどです。
- 各リスクについて正直に評価します。実際に起こる可能性と、起きた場合の実害を現実的に見積もります。確認できたリスクを残します。確認して解消したものは、別に列挙します。
whyと同じルールを適用します。実際のfile:lineを引用してください。検索しても何も見つからなかったことも回答になります。また、呼び出し元や API をでっち上げてはいけません。 - 1つの事実を証明します。実際のコードを実行するスクリプトまたはテストを書き、実行して、その結果を貼り付けます。
- 変更が大規模または広範囲に及ぶ場合は、
arenaを指定して Skill ツールを呼び出し、実行します。複数のモデルに同じ質問をして、回答をまとめます。モデルが異なれば、それぞれ異なる実際のバグに気付くことがあります。
提出する内容
- 何をしたか。 何が変わったか、わかりにくい部分も含めて説明します。
- 安全だといえる唯一の事実。 その事実を述べ、どのステップまで確認できたかを示し、証拠を提示します。証明できなかった場合は、未証明と記載します。
- リスク。 それぞれについて、どう壊れるか、
file:line、発生可能性と影響の大きさ、確認方法を示します。重要なリスクについては証拠を貼り付けます。 - 確認済み。 何を確認し、問題ないと判断した理由を示します。
- マージ前に。 実際のバグを検出できる、最も手軽なテストまたは再現手順を示します。作成したスクリプトも含めます。
Skill ツールを unslop で呼び出して記述してください。実際のコードを引用し、公開する前に個人情報や機密情報をすべて取り除いてください。
返信： 上記の報告書を提示し、安全性に関する唯一の事実を証明済み、または未証明として示してください。