用途
Thermo-Nuclear Code Quality Review 用于对当前分支的改动执行一次异常严格的代码质量审查，聚焦实现质量、可维护性、抽象质量与代码库健康度。它的核心目标不是找出局部清理点，而是推动审查者以更大的野心审视代码结构，主动寻找“代码柔道”式动作：在保持行为不变的前提下，让实现显著更简单、更小、更直接、更优雅。
主要能力
该技能以一段基线提示词为起点，要求对当前分支的改动做深度代码质量审计，重新思考如何在不影响行为的情况下结构化或实现改动，以实质性地提升代码质量；改进抽象、模块化，减少意大利面式代码，提升简洁性与可读性；在存在清晰改进路径时，敢于重构部分代码库；并且极其彻底、严谨，做到“量两次，剪一次”。
在此基础上，它附加了若干不可妥协的审查标准：
- 对结构性简化保持野心，不停留在“这里可以更干净一点”，而是寻找让整条分支、辅助函数、模式、条件或层级彻底消失的机会，偏好让代码在事后看来“理所当然”的方案。
- 默认将 PR 把文件从 1000 行以下推到 1000 行以上视为强烈的代码质量异味，除非有非常强的理由；优先抽取辅助函数、子组件、模块或局部抽象，而不是让文件膨胀。
- 不允许现有代码中出现随机的意大利面式增长，对新插入到无关流程中的临时条件、零散特例或一次性分支保持高度怀疑，将其视为设计问题而非风格小瑕疵。
- 偏好清理设计，而不是仅仅接受“能跑”的代码；强烈偏好能整体移除活动部件的简化，而非把同样的复杂度四处扩散的重构。
- 偏好直接、朴素、可维护的代码，而非取巧或“魔法”式代码；对隐藏简单数据形状假设的通用机制保持怀疑，标记只增加间接性而不带来清晰度的薄抽象、恒等包装或直通辅助函数。
- 在影响可维护性时，强力推动类型与边界清洁：质疑不必要的可选性、unknown、any 或大量强制类型转换的代码，偏好显式类型模型或共享契约。
- 让逻辑留在规范层级并复用现有辅助函数，指出功能逻辑泄漏到共享路径或实现细节通过 API 泄漏的问题。
- 将不必要的顺序编排和非原子更新视为设计异味，在明显更清晰时推动并行执行或更原子的结构。
使用方式
该技能以提示词形式使用，基线提示词为：对当前分支的改动执行深度代码质量审计；重新思考如何结构化或实现改动，以在不影响行为的前提下实质提升代码质量；改进抽象、模块化，减少意大利面式代码，提升简洁性与可读性；保持野心，如果存在清晰的改进路径且涉及重构部分代码库，就去做；极其彻底、严谨，量两次，剪一次。
审查时对每个有意义的改动提出一系列主要问题，例如：是否存在让实现大幅简化的“代码柔道”动作？能否重新框定改动，使需要的概念、分支或辅助层更少？改动是改善还是恶化了局部架构？diff 是否在应有更好抽象的地方增加了分支复杂度？原本内聚的模块是否变得更耦合、更有状态或更难扫读？逻辑是否位于正确的文件与层级？改动是否让文件或组件超出健康的大小边界？是否存在重复条件暗示缺失的模型或辅助函数？实现是直接可读，还是依赖特例与偶然控制流？抽象是否真正物有所值，还是只是包装？diff 是否引入了掩盖真实不变量的类型转换、可选性或临时对象形状？逻辑是否位于规范层级，还是细节跨越了边界？编排是否比需要的更顺序化或更不原子？
该技能还列出了应积极标记的问题，包括：本可通过更清晰重构删除整类复杂度的复杂实现；只是搬动代码却未减少读者心智负担的重构；因 PR 导致文件越过 1000 行；新条件被硬塞进无关代码路径；一次性布尔值、可空模式或标志使现有控制流复杂化；功能特定逻辑泄漏进通用模块；隐藏简单结构的通用“魔法”处理；只增加间接性的薄包装或恒等抽象；不必要的类型转换、any、unknown 或可选参数；复制粘贴逻辑而非抽取辅助函数；在已很繁忙的函数中间实现狭窄边界情况；技术上通过测试却降低模块化或可读性的重构；很可能变成永久债务的“临时”分支；代码库已有规范工具却另写专用辅助函数；逻辑加在错误层级或包中；本可并行却顺序执行的异步流程；留下状态不够原子的部分更新逻辑。
适用场景
该技能适用于对代码改动进行严格的结构性质量审查，尤其是当改动可能引入抽象问题、巨型文件、意大利面式条件分支增长、边界与类型契约模糊、模块化退化或错失大幅简化机会时。它可用于审查 PR 或分支改动，并可通过 swarm 技能并行分派多个审查者。
限制
该技能强调不要用低价值的小问题淹没审查，如果存在更大的结构性问题，应优先给出少量高置信度的评论，而非一长串表面性备注。审查语气应直接、严肃、对质量要求高，但不粗鲁，也不把重大可维护性问题软化成温和建议。
输出格式要求分层，绝不写成单个庞大文件：将审查写入独立目录（例如 /tmp/<project>-thermo/），包含一份摘要报告以及每个子系统或审查者一份详细报告（01_<subsystem>.md、02_<subsystem>.md 等）。摘要应能一次读完，约 200 行，包含结论、每条发现以简短叙述段落呈现、建议的整改顺序，以及指向承载完整证据的详细文件的指针。详细文件承载深度内容：测量数据、产生这些数据的命令、验证状态以及完整的代码柔道提案。发现应以散文段落书写，点名文件与证据，然后用句子解释问题与补救措施，不要压缩成片段行、标签汤或摘要中的内联命令转储。当通过 swarm 技能并行分派审查者时，本节覆盖 swarm 的聚合规则：每个审查者的报告是交付物的详细文件，而非要丢弃的原始转储；判断合并到摘要中，细节保留在磁盘上并链接过去。
批准门槛方面，不能仅因行为看似正确就批准。批准的标准包括：没有明显的结构性退化；在可见路径存在时没有明显错失让实现大幅简化的机会；没有不合理的文件大小爆炸；没有因特例分支导致的明显意大利面式增长；没有明显取巧或魔法式抽象使代码更难理解；没有不必要的包装、类型转换或可选性变动掩盖真实设计；没有明显的架构边界泄漏或可避免的规范辅助函数重复；没有明显错失能实质提升可维护性的分解机会。以下情况视为推定阻塞，除非作者能清楚说明理由：PR 在存在可行代码柔道动作可删除复杂度时保留了大量附带复杂度；PR 把文件从 1000 行以下推到 1000 行以上；PR 增加了使现有流程更纠缠的临时分支；PR 通过在共享代码中散布功能检查来解决局部问题；PR 增加了不必要的抽象、包装或大量类型转换的契约使设计更间接；PR 在存在清晰规范归属时重复现有辅助函数或把逻辑放在错误层级。若这些条件不满足，应留下明确、可操作的反馈并推动更清晰的分解。