what-could-break 是一个面向代码变更的风险分析技能，其用途不是简单列出调用方，而是找出 grep 无法揭示的破坏点，并针对一项关键事实给出可运行的证明。资料建议在“设计之前”而不只是“合并之前”使用：当任务对既有代码作出断言（例如“X 已经处理了 Y”“直接把 X 设为公开即可”）时，该断言只是假设，真实使用者的普查结果才决定设计。
主要能力围绕变更阅读与风险排查展开。使用时机包括：在任何多文件修改或共享路径修改之前，例如 API 载荷、配置、存储数据、其他应用读取的客户端、提示词或策略文件；当用户询问“这可能破坏什么”或“X 的影响范围”时；对于不放心的小型差异；以及当任务简报对既有代码作出断言、需要先验证再设计时。
使用方式分为五步。第一步，不信任自己的书面分析，找出整个变更依赖的一到两个事实，并沿验证阶梯尽可能低成本地推进，同时说明停在哪一级。阶梯依次为：你说如此（单独没有价值）；你指向它（真实的文件与行号，或锁定版本的库源码）；你走查过（逐步追踪坏情况且未到达）；你运行过（脚本或测试调用真实代码，错了就大声失败）；你亲眼看到（在运行中的应用、服务或设备上复现）。第四级通常是一个小脚本，导入生产运行的同一模块，用你担心的输入调用你担心的确切函数。第二步，阅读变更：差异、新增/修改/删除的符号、行为变化以及差异未明说的内容；用 git log -S 和 git log -L 查看旧形态为何存在，看似无意义的守卫往往有提交解释它阻止的事故。第三步，找出使变更安全的那一个事实，例如“只丢弃已过期的缓存条目”“没有客户端读取该字段”；若找不到，说明变更尚未被理解。第四步，在 grep 停止的地方继续查找：按字面值、字段名、错误文本和旧行为搜索，而不只是重命名后的符号；随后逐项手工检查同一规则的两份副本、提示词与智能体文件中的旧规则、所有其他客户端、线上传输格式、存储状态、环境与密钥、独立重启的进程、时序与并发、锁定版本的库源码、生成与随附代码、编码旧行为的测试与夹具、可观测性配置。第五步，为那个事实编写运行真实代码的脚本或测试，运行并粘贴结果；无法运行时在事实旁标注“未经证实”；对于大范围变更，按子系统重复第三到第五步。
适用场景包括：评估 API 响应删除字段、把辅助函数改为公开、小型但可疑的差异、任务简报中的既有代码断言等。资料给出两个示例：其一，删除 API 响应中的字段时，关键事实是没有客户端读取 legacy_total，需跨所有客户端仓库搜索，并编写脚本用昨天真实请求重放新序列化器，断言没有响应收缩掉旧客户端仍解析的字段；其二，“直接把这个辅助函数设为公开”时，把“已无副作用”当作假设，阅读后在同一进程内运行两次并比较状态。
限制与安全注意事项：风险必须有真实发生机会和真实代价，否则不应列入；搜索没有结果也是答案，应写下搜索而非声称风险不存在；该技能不替代特定环境测试与专家评审；报告与留下的脚本中不得包含机密和私有数据。证明脚本会运行真实生产代码路径，应只在本地或授权测试环境运行，绝不能针对生产数据存储；该技能按设计是只读的，检查差异并运行检查，不改变状态，也不应用于应用修复。内容改编自 stas4000/what-could-break（MIT），并包含改编自 Lauren Tan 的 pstack 的材料（MIT）。