用途
code-review 是一个代码审查技能，用于对 HEAD 与用户提供的固定点之间的差异（diff）进行双轴审查。固定点可以是提交 SHA、分支名、标签、main、HEAD~5 等。如果用户未指定固定点，技能会要求用户提供。
主要能力
审查沿两个轴进行：
- Standards：代码是否符合本仓库文档化的编码规范。
- Spec：代码是否忠实实现了原始 issue / 规格。
两个轴作为并行子代理运行，因此不会污染彼此的上下文，随后技能汇总它们的发现。
使用方式
1. 固定比较点
用户所说的固定点即为比较点。捕获一次 diff 命令：git diff <fixed-point>...HEAD（三点，因此比较基于 merge-base）。同时通过 git log <fixed-point>..HEAD --oneline 记录提交列表。在继续之前，确认固定点可解析（git rev-parse <fixed-point>）且 diff 非空。错误的引用或空 diff 应在此处失败，而不是在两个并行子代理内部失败。
2. 识别规格来源
按以下顺序查找原始规格：
- 提交消息中的 issue 引用（#123、Closes #45、GitLab !67 等）——通过 docs/agents/issue-tracker.md 中的工作流获取。
- 用户作为参数传入的路径。
- docs/、specs/ 或 .scratch/ 下与分支名或功能匹配的规格文件。
如果找不到任何内容，询问用户规格在哪里。如果用户说没有规格，Spec 子代理将跳过并报告“no spec available”。
3. 识别规范来源
仓库中任何记录代码应如何编写的内容，例如 CODING_STANDARDS.md 或 CONTRIBUTING.md。
除仓库文档化的内容外，Standards 轴始终携带以下坏味道基线——一组固定的 Fowler 代码坏味道（《重构》第 3 章），即使仓库没有记录任何内容也适用。两条规则约束它：
- 仓库优先。文档化的仓库标准始终胜出；当仓库标准认可基线会标记的内容时，抑制该坏味道。
- 始终是判断性判断。每个坏味道都是带标签的启发式（“possible Feature Envy”），绝不是硬性违规——并且，与此处任何标准一样，跳过工具已强制执行的任何内容。
每个坏味道的读法是“它是什么 → 如何修复”；将其与 diff 匹配：
- Mysterious Name——函数、变量或类型的名称没有揭示其作用或持有内容。→ 重命名；如果没有诚实的名字，说明设计模糊。
- Duplicated Code——相同的逻辑形态在变更中的多个 hunk 或文件中出现。→ 提取共享形态，从两处调用。
- Feature Envy——方法访问另一个对象的数据多于自身数据。→ 将方法移到它所羡慕的数据上。
- Data Clumps——相同的几个字段或参数总是结伴出现（一个想要诞生的类型）。→ 将它们捆绑为一个类型，传递该类型。
- Primitive Obsession——用原始类型或字符串代表值得拥有自己类型的领域概念。→ 给该概念自己的小类型。
- Repeated Switches——对同一类型的相同 switch/if 级联在变更中反复出现。→ 用多态替换，或两处共享一个映射。
- Shotgun Surgery——一个逻辑变更迫使在 diff 中许多文件里分散编辑。→ 将一起变化的内容聚集到一个模块中。
- Divergent Change——一个文件或模块因多个不相关原因被编辑。→ 拆分，使每个模块因一个原因变化。
- Speculative Generality——为规格没有的需求添加的抽象、参数或钩子。→ 删除它；内联回去，直到出现真实需求。
- Message Chains——调用者不应依赖的长 a.b().c().d() 导航。→ 将遍历隐藏在第一个对象的一个方法后面。
- Middle Man——主要只是向下委托的类或函数。→ 删掉它，直接调用真实目标。
- Refused Bequest——子类或实现者忽略或覆盖了它继承的大部分内容。→ 放弃继承，使用组合。
4. 并行启动两个子代理
Standards 子代理提示词包含：完整的 diff 命令和提交列表；第 3 步中找到的规范来源文件列表，加上第 3 步的坏味道基线全文粘贴——子代理没有其他途径访问它。简报：“Report — per file/hunk where relevant — (a) every place the diff violates a documented standard: cite the standard (file + the rule); and (b) any baseline smell you spot: name it and quote the hunk. Distinguish hard violations from judgement calls — documented-standard breaches can be hard, but baseline smells are always judgement calls, and a documented repo standard overrides the baseline. Skip anything tooling enforces. Under 400 words.”
Spec 子代理提示词包含：diff 命令和提交列表；规格的路径或获取的内容。简报：“Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. Under 400 words.”
如果规格缺失，跳过 Spec 子代理并在最终报告中注明。
5. 汇总
在 ## Standards 和 ## Spec 标题下呈现两份报告，逐字或轻度清理。不要合并或重新排序发现——两个轴是刻意分开的（见“为什么是两个轴”）。以一行摘要结束：每个轴的发现总数，以及每个轴内最严重的问题（如果有）。不要跨轴挑选单一赢家——那正是分离所要防止的重新排序。
适用场景
- 需要同时检查代码规范符合度与规格实现忠实度的代码审查。
- 希望将规范审查与规格审查分开、避免一个轴掩盖另一个轴的场景。
- 仓库有文档化编码规范或 issue 跟踪器的工作流。
限制
- 需要用户提供固定点；未提供时会询问。
- 需要 issue 跟踪器文档 docs/agents/issue-tracker.md；缺失时可运行 /setup-utarn-skills。
- 如果找不到规格，Spec 子代理会跳过并报告“no spec available”。
- 坏味道基线始终是判断性判断，不是硬性违规；仓库文档化标准优先于基线。
- 跳过工具已强制执行的任何内容。
- 两个子代理的简报均要求 400 词以内。
为什么是两个轴
一个变更可以通过一个轴而失败于另一个轴：
- 遵循每条标准但实现了错误内容的代码 → Standards 通过，Spec 失败。
- 完全按 issue 要求做但破坏项目约定的代码 → Spec 通过，Standards 失败。
分别报告它们可以防止一个轴掩盖另一个轴。