Onevium 核爆级代码质量审查
对真实变更做高强度、证据驱动的可维护性审查。目标不是挑更多毛病，而是找出少量会让代码库长期变差的结构性问题，以及能直接删除复杂度的重构路径。
审查边界
- 默认只审查并报告，不修改代码、不提交、不推送；只有用户明确要求修复时才实施更改。
- 以实际 diff 为中心，按需读取上下文、调用方、既有抽象和测试；不要根据文件名或局部片段猜测问题。
- 尊重用户指定的基线和范围。未指定时，优先使用 PR 的目标分支；没有 PR 上下文时，再以仓库默认分支的合并基点和未提交变更确定范围。
- 只评价本次变更引入或实质放大的问题。既有问题可作为背景，但不要伪装成本次变更的发现。
- 所有重构建议都要说明必须保持的行为，以及如何验证行为没有变化。
执行流程
- 建立审查范围：确认基线、diff、变更文件和用户是否只要审查。
- 绘制影响路径：追踪入口、核心状态、边界、持久化或外部副作用和测试，不把审查停留在逐行 diff。
- 加载量表：执行正式审查时读取 reference.md，逐项检查结构简化、分支增长、抽象、类型边界、归属层、文件规模和编排一致性。
- 寻找“代码柔道”：优先寻找能删除概念、分支、包装层或特殊模式的重新建模方式；不要满足于把同一份复杂度搬到更多文件。
- 反证每个发现：检查是否存在既有约定、生成代码、声明式数据或性能与兼容性约束，使表面问题其实合理。
- 按证据输出：只保留高置信度、可定位、可行动的发现；不用品味偏好和低价值格式意见充数。
核心判断
- 这次变更能否用更少的概念、状态、分支或层次表达？
- 是否把功能特例散落进原本通用的流程，导致局部修复变成全局耦合？
- 新抽象是否真正降低理解成本，还是只增加转发、包装和命名？
- 类型、可空性、转换或静默回退是否掩盖了本应明确的不变量？
- 逻辑是否位于真正拥有该概念的层，并复用了代码库里的唯一权威实现？
- 文件变大是否反映职责扩散？“超过约 1000 行”只是一条强信号，不能脱离内容类型机械判定。
- 异步步骤是否无必要地串行？相关更新是否可能留下难以恢复的半完成状态？只有能同时提升正确性和清晰度时才建议并行或原子化。
输出契约
先给发现，再给结论。每个发现必须包含：
- 严重级别和标题：使用
[P0]至[P3]，标题直接写出结构性后果。 - 证据位置：给出最小文件和行号范围，并说明本次 diff 如何触发问题。
- 影响机制：解释复杂度、耦合或维护风险如何产生，避免只给结论。
- 优先修复方向：提出能保持行为的最小结构调整；没有可靠方案时明确说出未知点。
- 验证方式：指出应运行或补充的测试、检查或不变量。
结尾使用以下三种结论之一：
- 阻塞：存在 P0/P1，或有证据表明结构退化会显著扩大后续风险。
- 有条件通过：只有非阻塞问题，但应明确记录后续动作。
- 通过：没有达到报告门槛的发现；同时列出未验证范围和残余风险。
不得因为“代码能运行”就通过，也不得为了显得严格而虚构问题。输出风格参考 examples.md。
来源与许可
本 Skill 基于 Cursor 的 thermo-nuclear-code-quality-review 思路进行中文重构与渐进式拆分，不是逐句翻译。上游与本改编均按 MIT License 发布，版权声明见 LICENSE.txt。