blast-radius

影響範囲

変更をリリースする前に、別の場所で何が壊れるのかを見つけます。「X の影響範囲」「これで何が壊れる可能性があるか」や、まだ信頼できない小さな差分のレビューに使います。

差分レビューでは、変更が何をするかを確認します。これは、差分の範囲外で変更が何を壊すかを見つけます。

呼び出し元を列挙することが目的ではありません。エージェントなら、あとで grep できます。目的は、grep では見つからない破損を見つけることです。

自分の説明を鵜呑みにしない

もっともらしく聞こえる影響範囲の説明には、価値がありません。真実かどうかに関係なく、説得力があるように読めてしまいます。だから、説明文をそのまま返してはいけません。全体が依存する事実を1つか2つ見つけ、コードを実行して証明してください。

どの程度確信がありますか

変更の安全性が依存する事実ごとに、無理のない範囲で次のリストの下の段階まで確かめ、どの段階で止まったかを示してください。

1. 自分でそう言った。これだけでは価値がありません。
2. 該当行を示した。実在する file:line、またはライブラリ自体のソースです。
3. 問題が起きるケースが発生しないことを示した。失敗までの手順を追い、そこに至らないことを確認しました。
4. 実行した。実際のコードを呼び出し、間違っていれば明確に失敗するスクリプトまたはテストです。
5. 実行中のアプリで再現した。

通常、ステップ4では、アプリが同梱しているものと同じライブラリをインポートし、懸念している関数をそのまま呼び出す小さなスクリプトを使います。

手順

1. 変更を読みます。差分、その変更で追加、変更、削除されたシンボル、そして差分に明記されていない部分も含め、以前と動作がどう変わったかを確認します。gh pr view と git log で PR とコミットを取得します。
2. 安全である根拠となる事実を1つ見つけます。リスクがあるように見える変更の多くは、「この呼び出しは、すでに無効になったキャッシュ項目を削除するだけで、ほかには何もしない」のような1つの事実によって安全です。その事実を見つけてください。成り立つなら、リスクの大半を一度に取り除けます。可能性の長いリストではなく、ここに時間をかけてください。
3. grep で追えなくなる箇所を調べます。呼び出しているライブラリのソースを読み、固定されたバージョンとローカルパッチがあるかを確認します。処理がいつ実行されるかを把握します。マイクロタスク、アンマウントとティアダウン、Solid と React の違いなどです。シンボル検索では見つからないものを追ってください。API が返す JSON、DB カラム、ワイヤ形式、同じバイト列を読み取る別の言語、機能フラグ、3段階先のコードなどです。
4. 各リスクについて、誠実に評価します。実際に起きる可能性と、起きた場合の実際の損害を示します。確認できたリスクを残します。調査して問題がないと判断したものは、別に列挙します。実在する file:line を引用してください。検索して何も見つからないことも答えの1つです。呼び出し元や API を捏造してはいけません。
5. 1つの事実を証明します。実際のコードを実行するスクリプトまたはテストを書き、実行して、結果を貼り付けます。
6. 大規模な変更や影響範囲の広い変更では、複数のモデルで読み取り専用のサブエージェントを起動し、同じ質問をして、回答を統合します（code-review-panel スキルを参照）。モデルによって、異なる実際のバグが見つかります。

返す内容

• 変更内容。 変更された内容と、明白ではない部分も含めて説明します。
• 安全である根拠となる1つの事実。 その事実を述べ、どの段階まで確認できたかを示し、証拠を提示します。証明できなかった場合は、未証明と記載します。
• リスク。 それぞれについて、壊れ方、file:line、発生可能性と深刻度、確認方法を記載します。重要なリスクについては証拠を貼り付けます。
• 問題なしと判断した項目。 確認した内容と、問題ないと判断した理由を記載します。
• マージ前に行うこと。 実際のバグを検出できる、もっとも簡単なテストまたは再現手順を記載します。作成したスクリプトも含めてください。

実在するコードを引用し、平易な言葉で書いて、AI らしい冗長な表現は省きます。公開する場所に出す前に、非公開情報はすべて取り除いてください。

返信： 上記の説明を返し、安全である根拠となる1つの事実について、証明済みか未証明かを明記します。