用途
Thermo-Nuclear Code Quality Review 用于对当前分支的代码变更执行一次异常严格的审查，聚焦于实现质量、可维护性、抽象质量与代码库健康度。它不是常规的风格检查，而是以“结构性简化”为首要目标的深度审计。
主要能力
该技能从一段核心提示开始：对当前分支变更做深度代码质量审计，重新思考如何在不影响行为的前提下重构/实现变更，以实质性提升代码质量；改进抽象与模块化，减少意大利面式代码，提升简洁性与可读性；要雄心勃勃，如果存在明确的改进路径且涉及重构部分代码库，就去执行；要极其彻底与严谨，“量两次，切一次”。
在此基础上，它附加了一系列不可协商的标准：
- 对结构性简化保持雄心：不要止步于“这里可以更干净一点”，要寻找让整个分支、辅助函数、模式、条件或层完全消失的机会；优先选择那种事后看来“不可避免”的方案；假设通常存在一种“代码柔道”动作，能更有效地利用现有架构并让变更大幅更简单优雅；如果存在删除复杂度而非重排复杂度的路径，就强力推动。
- 文件大小控制：不允许一个 PR 在没有极强理由的情况下把文件从 1k 行以下推到 1k 行以上；默认视其为强烈的代码质量异味；优先抽取辅助函数、子组件、模块或局部抽象，而不是让文件膨胀超过 1000 行；若 diff 跨过该阈值，明确询问是否应先分解；只有存在令人信服的结构性理由且结果文件仍组织清晰时才可豁免。
- 禁止无序的意大利面增长：高度怀疑新增的临时条件、分散的特殊情况或插入无关流程的一次性分支；如果变更在随机位置添加“奇怪的 if 语句”，将其视为设计问题而非风格小瑕疵；优先把逻辑推入专用抽象、辅助函数、状态机、策略对象或独立模块，而不是纠缠现有路径；即使代码技术上能跑，也要指出让周围代码更难推理的变更。
- 偏向清理设计，而不是接受能跑的代码：如果行为可保持不变而结构能显著更干净，就推动更干净的版本；不要给留下更混乱代码库的“能跑”实现盖章；强烈偏好移除活动部件的简化，而非只是把同样复杂度分散到各处的重构；偏好直接、朴素、可维护的代码，而非取巧或魔法代码；警惕隐藏简单数据形状假设的泛型机制；标记薄抽象、恒等包装或直通辅助函数。
- 类型与边界清晰度：当影响可维护性时，强力推动类型与边界整洁；质疑不必要的可选性、unknown、any 或大量 cast 的代码，当存在更清晰的类型边界时；偏好显式类型模型或共享契约，而非松散形状的临时对象；如果分支依赖静默回退来掩盖不清晰的不变量，询问边界是否应显式化。
- 逻辑归属正确层：把逻辑保留在规范层并复用现有辅助函数；指出功能逻辑泄漏到共享路径或实现细节通过 API 泄漏；偏好现有规范工具/辅助函数而非定制的临时实现；把代码推向正确的包、服务或模块，而不是将架构漂移正常化。
- 编排与原子性：当更清晰的结构显而易见时，将不必要的顺序编排和非原子更新视为设计异味；如果独立工作被无理由串行化，询问是否应并行运行；如果相关更新可能让状态半应用，推动更原子的结构；不过度关注微优化，但要标记可避免的、让实现更脆弱的编排复杂度。
使用方式
技能以一段核心提示为基础，要求对当前分支的变更执行深度代码质量审计，并附加上上述明确审查规则。审查过程中，对每一个有意义的变更提出一组“主要审查问题”：是否存在让代码大幅更简单的“代码柔道”动作；能否重构以减少所需的概念、分支或辅助层；变更改善还是恶化了局部架构；diff 是否在应有更好抽象处增加了分支复杂度；原本内聚的模块是否变得更耦合、更有状态或更难扫读；逻辑是否位于正确的文件与层；是否让文件或组件超出健康大小边界；重复条件是否暗示缺失的模型或辅助函数；实现是否直接可读，还是依赖特殊情况与偶然控制流；抽象是否真的物有所值，还是只是包装；diff 是否引入 cast、可选性或临时对象形状来模糊真正的不变量；逻辑是否位于规范层，还是 diff 跨边界泄漏细节；编排是否比需要的更顺序或更不原子。
适用场景
适用于需要极其严格地审查分支变更实现质量、可维护性与结构健康度的场合，尤其关注抽象质量、巨型文件与意大利面式条件增长。适合在代码评审中推动“代码柔道”式重构、防止文件越过 1000 行、阻止临时分支和魔法抽象蔓延。
限制
资料未提供该技能的具体运行环境、依赖、安装命令、收费方式或平台支持信息，这些内容暂未提供。