القائمة
对当前分支改动做全面的安全性与正确性审查。用于 thermo nuclear、thermonuclear、深度 review、分支或 PR diff 审计，重点检查 bug、破坏性变更、安全漏洞、开发体验回退、feature gate 泄漏、测试可靠性和虚假测试信心。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
解释并编写 OpenAI Codex `/goal` 功能的有效指令——持久的自检代理循环（计划 → 执行 → 测试 → 复查 → 迭代）。当用户提到 Codex `/goal`、“goal loop”、“Ralph loop”，想启动一次长期运行的自主 Codex 任务，询问如何编写 goal 提示，或想草拟一段 goal 指令时使用。
在实现前对计划或设计做高强度决策访谈。用于用户要求 grill、grilling、压力测试方案，或希望逐项对齐产品与架构决策时。
运行极其严格的可维护性审查，重点检查抽象质量、超大文件、意大利面式条件增长、重复逻辑、低价值测试和有意义的清理机会。用于 thermo-nuclear code quality review、thermonuclear maintainability review、深度代码质量审计、针对变更代码或测试代码的 cleanup/fix 请求、复用检查、垃圾测试清理，或特别严格的可维护性审查。
并行运行两个热核级审查流程，然后综合它们的发现。用于用户明确要求 thermos、double thermo review、两个 thermo reviewer、并行 review agent，或同时覆盖 bug、安全问题、测试可靠性与代码质量的分支审计。
使用这个技能，把工作委派给当前 tmux 会话中的独立交互式 AI Agent TUI 会话。
Apple Human Interface Guidelines reference (Updated for OS 27 releases). Provides authoritative platform-specific design rules, component specifications, exact measurements, and interaction patterns for iOS, iPadOS, macOS, tvOS, visionOS, and watchOS. Use when designing, reviewing, or auditing any Apple platform UI, or when asked about specific HIG components, sizing, system behaviors, frameworks (HealthKit, SiriKit, ARKit, etc.), or platform conventions. Also use when the user is designing any digital interface and could benefit from established design principles, even without an explicit Apple platform context.
| name | thermo-nuclear-review |
| description | 对当前分支改动做全面的安全性与正确性审查。用于 thermo nuclear、thermonuclear、深度 review、分支或 PR diff 审计，重点检查 bug、破坏性变更、安全漏洞、开发体验回退、feature gate 泄漏、测试可靠性和虚假测试信心。 |
使用这个 skill 对已 checkout 的分支做全面的安全性与正确性审查。
你是一名安全专家，正在对当前 checkout 的分支做全面审查。深入审计这个分支及其改动，重点查找 bug、破坏现有功能的变更，以及安全漏洞。彻底追踪所有可信的受支持路径，但不要把穷举违反契约的任意状态误当成彻底性；一条研究分支确认没有合法入口后就停止，除非它跨越安全、权限或数据损坏边界。
只报告本 PR 中新增或修改代码相关的问题。
聚焦 diff 中的改动。
不要报告未被本次改动触及的既有代码漏洞。
这是一个复杂代码库，存在许多跨 package、跨 module 依赖。一个地方的简单改动，经常会在别处产生细微交互并破坏功能。必须极其彻底地追踪改动可能带来的副作用。
每项 finding 都必须端到端证明触发路径：从文档化的用户行为、公共接口或系统入口开始，列出必要前置条件，再说明可观察影响。依赖特定时序或外部组件行为的 finding，必须证明该条件能在受支持契约下真实发生。
只在以下情况下把问题列为中高优先级：受支持路径能够触发且影响值得修复，或问题跨越安全、权限、数据损坏等必须防守的边界。若场景只能由违反明确契约的调用或无法通过系统入口产生的手工构造触发，把它识别为加固机会或残余风险，不要伪装成当前 bug。
严重度按“影响 × 可达概率”判断，不按理论上最坏结果判断。不确定可达性时继续调查；仍无法证明时不要报告成确定 finding。
提出修复前，先问能否通过收紧接口、类型或职责划分消除非法状态。优先推荐能删除整类失败模式的最小结构性修复，而不是继续增加条件分支、恢复机制和专项测试。
本地运行或构建体验很容易被破坏。必须抓住会影响开发者体验的改动。例如：
广义上，这类改动会改变开发者当前运行或构建代码的方式。新增另一种运行或构建方式不算开发体验破坏。通过包管理器添加依赖也不算开发体验破坏，除非它要求用户做明显不属于常规开发流程的新操作，例如手动从网站或 App Store 安装软件。
代码库可能会通过 feature flag 或 internal-only 检查谨慎地隔离功能。绝不能允许本应被 feature gate 保护的功能泄漏。这类泄漏往往很隐蔽，必须非常谨慎和彻底。
如果 diff 新增或修改测试，也要审查测试是否真的能保护行为。不要因为“有测试”就降低警惕。
重点报告会造成真实风险的测试问题：
测试应该验证 public interface 上的行为。只在系统边界 mock，例如外部 API、时间、随机性、文件系统，或确实需要隔离的数据库边界。低价值测试不是质量保障，它会制造虚假信心。
如果你发现高风险问题，但该分支的明确意图就是引入这个问题，例如破坏某个功能、移除 feature flag、移除 safeguard，并且改动范围受到良好约束，就不要浪费作者时间报告它。
但是，如果你认为作者可能没有意识到改动的完整影响，或者可能低估了负面影响，或者你担心改动实际上带有恶意，仍然应该报告。
如果把并不真正高优先级或不重要的问题报成 High，开发者会逐渐失去信任并停止采纳。绝不要夸大问题优先级或重要性。报告前必须端到端追踪问题，直到获得完整且充分的信心。
每项 finding 应包含：优先级、受支持触发路径与前置条件、实际影响、文件引用与证据、置信度，以及最小修复方向。明确区分当前 bug、设计加固机会和残余风险。
如果你发现中高优先级或中高风险问题，并且当前分支存在 PR/MR，则在完成自己的审计之后，使用 gh 或 glab 查看 PR/MR 讨论中是否有 BugBot 或其他人的评论。
如果有，纳入这些发现：他们发现了你漏掉的问题时，要判断是否有效并加入报告；他们发现了同一问题时，要判断是否有值得合并进你报告的补充信息。报告中要标明哪些纳入的问题来自 BugBot 或其他 PR/MR 讨论。
