用途 Blast-radius 用于回答“这个改动的影响面”“它可能破坏什么”，也适用于审阅一个你还不完全信任的小型 diff。它与 how、why 两个技能互补：how 说明代码做了什么，why 说明代码为何长成这样，blast-radius 关注它在别处会破坏什么。列出调用方不是它的工作，grep 一秒就能做到；它要抓的是 grep 看不到的破坏。
核心思路 不要信任自己的书面结论。一份读起来合理的 blast-radius 报告无论真假都显得可信，所以要找出整个判断所依赖的一两个事实，并用运行代码的方式证明它们。 安全事实的确定性分档（尽量做到越低越可靠，并说明停在哪一档）：你说过；你指到了具体 file:line 或库自身源码；你证明坏情况走不到（逐步推演失败路径）；你运行了脚本或测试（第 4 档通常是导入应用同款库并调用目标函数的小脚本）；你在运行中的应用里复现了。
使用步骤
- 读改动：diff、新增/修改/删除的符号、行为变化，包括 diff 没写明的部分。可用 why 技能的步骤拉取 PR 与提交。若仓库有 GitNexus 索引（存在 .gitnexus/）且 PATH 中有 gitnexus，先刷新：gitnexus analyze --index-only（增量，已最新时为空操作），再用 gitnexus detect-changes 把 diff 关联到受影响符号与流程，用 gitnexus impact <symbol> 得到直接影响面。这仍是 grep 可见层，你的工作还是它遗漏的破坏，证明仍要跑真实代码。
- 找出它之所以安全的那一个事实，比如“此调用只丢弃已失效的缓存项，不做别的”。若该事实成立，多数风险情况会一并排除。把时间花在这里，而不是一长串“也许”。
- 看 grep 止步之处：读所调用库的源码，检查锁定版本与本地补丁；理解运行时机（微任务、卸载与清理、Solid 与 React 的差异）；跟住符号搜索漏掉的东西：API 返回的 JSON、数据库列、线上格式、另一种语言读同一批字节、功能开关、下游三跳的代码。
- 诚实评估每个风险：给出真实的发生概率与代价，保留已确认风险，把查过并排除的单独列出（规则同 why）。引用真实 file:line；搜不到也是答案；不得编造调用方或 API。
- 证明那一个事实：写脚本或测试调用真实代码，运行并粘贴结果。
- 大范围改动可用 arena 技能，把同一问题交给多个模型并合并答案，不同模型能抓到不同的真实 bug。
交付内容 包含：它做什么、改了什么（含不明显的部分）；它之所以安全的那一个事实（说明达到哪档确定性并附证明，未证明就写 unproven）；风险（每个写明如何破坏、file:line、概率与严重度、如何检查，重要项附证明）；已排除项及原因；合并前最便宜的测试或复现（含你写的脚本）。用 unslop 技能撰写，引用真实代码，公开前清除任何私有内容。回复即为上述报告，安全事实要么被证明，要么标记为 unproven。
限制 资料未提供具体支持的代码语言、平台、仓库类型，也未说明收费、价格或使用门槛；部分步骤依赖可选的 GitNexus 索引与命令可用性。