code-review

对 HEAD 与用户提供的固定点之间的 diff 进行双轴审查：

• Standards：代码是否符合本仓库已记录的编码标准？
• Spec：代码是否忠实实现了源 Issue 或规格说明？

两个轴向会并行运行子 Agent，以避免相互污染上下文，随后本技能汇总它们的发现。

Issue 跟踪器应已提供给你。若未提供，请告知用户运行 /setup-matt-pocock-skills。

流程

1. 锁定固定点

用户提供的任何内容都作为固定点（提交 SHA、分支名、标签、main、HEAD~5 等）。若用户未指定，请询问。

只需获取一次 diff 命令：git diff <fixed-point>...HEAD（使用三点语法，比较基准为 merge-base）。同时记录提交列表：git log <fixed-point>..HEAD --oneline。

继续之前，确认固定点可以解析（git rev-parse <fixed-point>），且 diff 非空。错误的引用或空 diff 应在此处失败，而不是在两个并行子 Agent 内部才暴露。

2. 确定规格来源

按以下顺序查找源规格：

1. 提交信息中的 Issue 引用（#123、Closes #45、GitLab !67 等），并通过跟踪器文档中的工作流获取。
2. 用户作为参数传入的路径。
3. docs/、specs/ 或 .scratch/ 下与分支名或功能匹配的规格文件。
4. 若仍未找到，请询问用户规格位于何处。若用户表示没有规格，Spec 子 Agent 将跳过，并报告"no spec available"。

3. 确定标准来源

在代码仓库中搜索所有说明代码应如何编写的文件。如果存在 CODING_STANDARDS.md 或 CONTRIBUTING.md，必须将其列入清单。

除了代码仓库文档中提到的内容，标准维度始终包含以下异味基线：一组固定的 Fowler 代码异味（Refactoring，第 3 章），即使代码仓库没有文档也适用。遵循以下两条规则：

• 代码仓库标准优先。 文档中说明的代码仓库标准始终优先；如果它认可了基线会标记的做法，则抑制该异味。
• 始终是判断，而非定论。 每种异味都是带标签的启发式判断（“可能存在特性依恋”），绝不是硬性违规。与此处的任何标准一样，跳过工具已强制执行的内容。

每种异味都按“是什么”→“如何修复”的顺序说明；请对照差异进行检查：

• 命名不明：函数、变量或类型的名称没有说明它的作用或所保存的内容。→ 重命名；如果想不出恰当的名称，说明设计不清晰。
• 重复代码：同一种逻辑结构出现在此次更改的多个代码块或文件中。→ 提取共用结构，并让两处都调用它。
• 特性依恋：某个方法访问其他对象的数据多于访问自身数据。→ 将该方法移到它所依恋的数据所在对象中。
• 数据泥团：同一组少数几个字段或参数总是结伴出现（这类数据需要有自己的类型）。→ 将它们封装为一个类型，并传递该类型。
• 基本类型偏执：用基本类型或字符串表示本应拥有独立类型的领域概念。→ 为该概念定义一个简单类型。
• 重复的条件分支：此次更改中，针对同一类型的 switch/if 级联在多处重复出现。→ 用多态替代，或让两处共用同一个映射。
• 霰弹式修改：一项逻辑更改迫使你在差异中的许多文件里分散修改。→ 将相关内容集中到一个模块中。
• 发散式修改：一个文件或模块因多个互不相关的原因而被修改。→ 拆分模块，使每个模块只因一个原因而修改。
• 推测性通用化：添加了规范并未要求的抽象、参数或钩子。→ 删除它；内联回去，直到出现真实需求。
• 消息链：调用方不该依赖的冗长 a.b().c().d() 导航。→ 在第一个对象上添加一个方法，将这段调用隐藏起来。
• 中间人：某个类或函数大多只负责将调用转发出去。→ 删除它，直接调用真正的目标。
• 被拒绝的遗赠：某个子类或实现类忽略或覆盖了继承内容中的大部分。→ 移除继承，改用组合。

4. 并行启动两个子 Agent

同时在前台发起两个子 Agent 调用，并汇总它们返回的报告。

标准子 Agent 提示词应包含：

• 完整的 diff 命令和提交列表。
• 第 3 步中找到的标准来源文件列表，以及第 3 步中完整粘贴的气味基线（子 Agent 无法通过其他方式访问它）。
• 以下简述：“按文件/代码块报告：(a) diff 中所有违反已记录标准的位置：引用标准（文件 + 规则）；(b) 你发现的任何基线气味：为其命名并引用相关代码块。区分硬性违规和主观判断：违反已记录标准的情况可能是硬性违规，但基线气味始终属于主观判断，且已记录的仓库标准优先于基线。跳过工具强制执行的内容。为每项发现注明文件和行号；只有在你会因此阻止合并时，才将其标记为阻塞；对于阻塞项，说明如何证明其失败。不要调用 /code-review 或启动更多 Agent：直接进行审查。少于 400 个词。”
• 不要提供其他内容。不要传入用户请求、规范或你对改动的个人笔记：此子 Agent 只根据标准评审 diff。

规范子 Agent 提示词应包含：

• diff 命令和提交列表。
• 规范的路径或获取到的规范内容。
• 以下简述：“报告：(a) 规范要求但缺失或仅部分实现的内容；(b) diff 中未被要求的行为（范围蔓延）；(c) 看似已实现、但实现可能有误的要求。每项发现都引用规范中的对应行，并注明 diff 中的文件和行号；只有在你会因此阻止合并时，才将其标记为阻塞；对于阻塞项，说明如何证明其失败。不要调用 /code-review 或启动更多 Agent：直接进行审查。少于 400 个词。”

如果缺少规范，则跳过规范子 Agent，并在最终报告中注明。

5. 汇总

呈报之前，核实每项阻塞发现的证据：打开引用的文件和行号，确认内容确实支持该发现。保留属实的发现；无法确认的则标记为未确认，并说明你检查的位置。子 Agent 的报告只是主张，不是证据。

将两份报告分别放在 ## Standards 和 ## Spec 标题下，原样呈现或稍作整理；每个维度内将阻塞项放在前面。不要合并或重新排序发现，因为这两个维度刻意保持独立（参见 为何要分成两个维度）。

最后用一行总结：每个维度的发现总数，以及各维度中最严重的问题（如果有）。不要在两个维度之间选出单一胜者：这会违背分开评估的初衷。

为何要分成两个维度

改动可能通过一个维度，却未通过另一个：

• 代码遵循了所有标准，但实现了错误的内容 → 标准通过，规范未通过。
• 代码准确实现了问题要求，却违反了项目惯例 → 规范通过，标准未通过。

分别报告可避免一个维度掩盖另一个维度。