blast-radius について
変更が直接の呼び出し元以外に及ぼす影響を追跡するコードレビュー用スキルです。コーディングエージェントに重要な安全上の前提や下流の動作を調べさせ、テストやスクリプトで主張を検証してからリスクを報告します。
主な機能
- 01呼び出し元以外への間接的な影響を追跡
- 02ライブラリのソースと実行タイミングを確認
- 03具体的なリスクを評価して記録
- 04テストやスクリプトで重要な前提を検証
- 05確認済みリスクと解消済みの懸念を区別
活用シーン
- 01コード変更の影響を評価
- 02影響が不確かな小さな差分をレビュー
- 03マージ前に安全上の前提を検証
- 04変更に伴うリスクと確認事項を記録
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/blast-radiusを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yaml
詳細
影響範囲
太字またはバッククォートで示されたスキル名、あるいは /<name> として実行されるスキルは、このスキルのディレクトリの隣にある ../<name>/SKILL.md ファイルです。接頭辞なしで指定された原則名は、../principle-<name>/SKILL.md です。そのファイルを読み、指示に従ってください。pstack スキルのほとんどはユーザー専用なので、スキルツールでは読み込めません。
変更がリリースされる前に、別の場所で何を壊すかを見つけます。「X の影響範囲」「何を壊す可能性があるか」や、まだ信用できない小さな差分のレビューに使います。
how と why を補完するものです。how はコードが何をするかを教えます。why はその形になっている理由を教えます。影響範囲では、別の場所で何を壊すかを調べます。
呼び出し元を列挙するのが仕事ではありません。エージェントなら、それはすぐに grep できます。仕事は、grep では見つからない破損を見つけることです。
自分の説明をうのみにしない
影響範囲の説明は、もっともらしく聞こえるだけでは価値がありません。それが正しいかどうかにかかわらず、説得力があるように読めてしまいます。だから、説明をそのまま返してはいけません。全体が依存している1つか2つの事実を見つけ、コードを実行して証明してください。
どの程度確信できるか
変更の安全性が依存する事実ごとに、手間のかからない範囲で次のリストをできるだけ下まで進み、どこで止まったかを伝えてください。
- そう述べただけ。単独では価値がありません。
- 該当行を示した。実際の
file:line、またはライブラリ自体のソースを示します。 - 問題のケースが起こり得ないことを示した。失敗する手順を追い、処理がそこに到達しないことを確認します。
- 実行した。実際のコードを呼び出し、間違っていれば明確に失敗するスクリプトまたはテストを用います。
- 実行中のアプリで再現した。
通常、ステップ4では、アプリが同梱するものと同じライブラリをインポートし、懸念している関数を正確に呼び出す小さなスクリプトを1つ書けば十分です。
手順
- 変更を読みます。差分、追加・変更・削除されたシンボル、そして差分からは明らかでない部分も含め、動作がどう変わったかを確認します。PR とコミットを確認するには、
whyのステップ2を使います。 - それが安全である根拠となる事実を1つ見つけます。危険に見える変更の多くは、「この呼び出しは、すでに無効になったキャッシュエントリを削除するだけで、ほかには何もしない」のような単一の事実によって安全です。その事実を見つけてください。正しければ、危険に見えるケースの大半を一度に解消できます。起こり得ることを長々と列挙するのではなく、ここに時間をかけてください。
- grep では追えなくなる先を調べます。呼び出しているライブラリのソースを読み、固定されたバージョンとローカルのパッチを確認します。処理がいつ実行されるかを確認します。マイクロタスク、アンマウントとティアダウン、Solid と React の違いなどです。シンボル検索では見落とすものを追跡します。API が返す JSON、DB のカラム、ワイヤ形式、同じバイト列を読む別の言語、機能フラグ、さらに3段下流のコードなどです。
- リスクごとに誠実に評価します。実際に起こる可能性と、起きた場合の実際の損害を示します。確認できたリスクを残します。確認したうえで問題がないと判断したものは、別に列挙します。
whyと同じルールを適用します。実際のfile:lineを引用してください。何も見つからない検索も答えになります。呼び出し元や API を捏造してはいけません。 - その事実を証明します。実際のコードを実行するスクリプトまたはテストを書いて実行し、結果を貼り付けます。
- 大規模な変更や広範囲に影響する変更では、
arenaとして実行します。複数のモデルに同じ質問をし、回答を統合します。モデルによって異なる実際のバグが見つかることがあります。
返す内容
- 何をするか。 変更内容と、明らかでない部分も示します。
- 安全性の根拠となる1つの事実。 その事実を述べ、どのステップまで確認できたかを示し、証拠を提示します。証明できなかった場合は、未証明と記載します。
- リスク。 それぞれについて、どう壊れるか、
file:line、発生可能性と影響の大きさ、確認方法を示します。重要なリスクについては証拠を貼り付けます。 - 問題なしと確認したもの。 何を確認し、なぜ問題ないかを示します。
- マージ前に。 実際のバグを検出する最も手軽なテストまたは再現方法を、作成したスクリプトも含めて示します。
unslop を通して記述し、実際のコードを引用してください。公開する前に、非公開情報をすべて取り除いてください。
返信： 上記の説明を返します。ただし、安全性の根拠となる1つの事実は、証明するか、未証明と記載してください。