一起看看 Cursor 团队内部最常用的 Skills

thermo-nuclear-code-quality-review，一位苛刻的代码质量审计员，它的设计目标是：在 PR 合并之前，识别那些"能跑、但让代码库变得更糟"的改动并拒掉它们。

在这安装 @cursor_ai Team Kit：
https://cursor.com/marketplace/cursor/cursor-team-kit

四条核心审计原则

1. 删除复杂性，而不是搬运复杂性
重构的常见反模式是把一坨复杂逻辑从 A 文件挪到 B 文件，调用栈变深，但总复杂度没降甚至上升。该 skill 要求改动产生净简化，而非位置转移。

2. 阻止超过 1000 行的文件
硬性上限。超过 1k 行的文件几乎必然意味着职责不清、难以测试、难以并行修改。这是一条"宁可错杀"的工程红线。

3. 标记薄包装层和泄漏的逻辑
· Thin wrappers：只是转发参数、没有实质行为的函数/类，徒增间接层。
· Leaked logic：本该封装在某层的业务规则散落到了调用方，破坏边界。

4. 拒绝"能工作但让代码更乱"的 PR
这是最关键的一条立场：功能正确 ≠ 可以合并。维护性是一等公民，与功能性同等重要。

两阶段、父子 Agent 协作的运行机制

阶段 1 — 父 agent 准备上下文（并行）
· 一个 shell 子 agent 执行 git diff <base>...HEAD（默认 base 为 main）
· 一个 explore 子 agent 抓取所有变更文件的完整内容

阶段 2 — 调用审计 agent
父 agent 把上面两份产物组装成带 ### Git / diff output 和 ### Changed file contents 两个标注段落的 prompt，传给 thermo-nuclear-code-quality-review 子 agent 执行审计。
这个设计有几个值得注意的点：
· 审计 agent 本身不做信息收集，输入是结构化的、确定的，避免它在探索阶段被噪声干扰。
· 禁止嵌套子 agent（除非显式要求），强制单次、聚焦的判断。
· 只评判 diff 中看得见的东西，但当改动触及模块边界时要追踪跨文件影响——这避免了"只见树木"的局部审查。

Rubric 的兜底逻辑

Skill 明确写了一个 fallback：如果 cursor-team-kit 插件不在，就退化为一次"严厉的可维护性审计"，目标对齐：
· 大胆简化（ambitious simplification）
· 文件不无故膨胀超过 ~1k 行
· 不容忍随手加 if/else 让分支无序增长
· 显式类型与边界
· 规范的分层（canonical layers）