用途
Thermo Nuclear Review 用于对一个已检出的分支进行全面的安全与正确性审计。适用于“thermo nuclear”“thermonuclear”或深度审查请求，以及分支或 PR diff 审计等场景。其目标是在代码合并前尽可能彻底地发现分支改动引入的问题。
主要能力
该技能以提示词形式定义了一套审查规则，要求审查者扮演安全专家，对已检出分支及其改动进行极其彻底的审计，重点关注：
- 引入的 bug；
- 破坏现有功能或特性的改动；
- 安全漏洞。
审查过程强调极端严谨、仔细、有雄心和专注，力求“不放过任何问题”。
审查范围
该技能明确限定报告范围：只报告与本次 PR 中新增或修改的代码相关的问题，聚焦于 diff 中的改动；不得报告未被修改的既有代码中的漏洞。
审查准则
破坏功能 代码库较为复杂，存在大量跨包与跨模块依赖。一个位置上的简单改动，常常会通过微妙的交互影响其他位置的功能。因此必须极其彻底地追踪改动可能带来的副作用。
破坏开发者体验（Devex） 审查者必须捕获会影响开发者本地运行或构建代码的改动。给出的示例包括（但不限于）：
- 修改密钥的读取方式或读取来源；
- 更新环境变量名称或新增环境变量；
- 重新映射端口或网络；
- 新增某些功能继续工作所必须运行的脚本。
总体而言，这些改动会改变开发者当前运行或构建代码的方式。若只是引入新的替代运行/构建方式，则不属于此类。通过包管理器添加依赖不算破坏 devex，除非它要求用户执行某种非常规的、不属于日常开发流程的新操作，例如从网站或应用商店手动安装软件。
特性泄漏 代码库可能谨慎地将某些特性置于特性开关或仅内部可用的检查之后。审查者不得允许任何本应置于特性门控之后的特性发生泄漏。此类泄漏往往较为隐蔽，需要非常小心且彻底地检查。
意图内的破坏 如果识别出高风险发现，但该分支的意图正是引入该发现，例如破坏某项功能、移除某个特性开关或移除某项保护措施，并且改动范围受到良好约束，则不应浪费作者时间向其报告该问题。但是，如果认为作者可能并未意识到其改动的全部影响，或担心其低估了负面影响（极端例子：开发者提交标题为“删除数据库”的 PR），或担心该改动实际上具有恶意，则仍应报告该发现。
避免过度报告 如果将并非高优先级或并非有意义的问题报告为高优先级，开发者会逐渐失去信任并停止听取意见。因此绝不能误报问题的优先级或重要性。在报告前必须端到端彻底追踪问题，以获得完整且完全的信心。
使用方式
该技能以提示词形式提供，可直接用于已检出的分支审查任务中。执行审查时：
- 对分支及其改动进行极其彻底的审计；
- 在完成审计之后，再检查 PR/MR 讨论；
- 若存在中到高优先级或风险发现，且该分支存在 PR，则使用 gh/glab CLI 查看 PR/MR 讨论，检查其中是否有来自 BugBot 或其他人的评论；
- 若讨论中已有发现，将其纳入考量：若他人发现了你遗漏的问题，评估其有效性并纳入报告；若他人发现了与你相同的问题，看看是否有值得吸收进回应的内容；
- 在报告中标注那些由 BugBot 或 PR/MR 讨论中其他人发现的问题。
关键规则
- 绝不在研究未完成的情况下呈现问题。例如，如果能访问后端代码并自行检查，就绝不说“客户端有问题 X，但如果在后端处理就没问题”这类话。
- 必须先完成审计，之后才能检查 PR/MR 讨论，以便以新鲜的视角进行审查。
- 必须极其彻底、严谨、仔细、有雄心和专注，不放过任何问题。
适用场景
适用于需要深度安全与正确性审查的代码变更，尤其是复杂代码库中涉及跨包/跨模块依赖、特性门控、开发者体验（密钥读取、环境变量、端口与网络映射、必需脚本等）的分支或 PR diff 审计。
限制
该技能仅针对本次 PR 中新增或修改的代码报告问题，不覆盖未改动既有代码中的漏洞。审查效果依赖审查者对代码库上下文与依赖关系的掌握程度。要求先完成审计再查看 PR/MR 讨论，以保持审查的独立性。在实际使用中，报告范围与优先级判断需严格遵循上述准则，以避免误报和信任损失。