code-review

对比 HEAD 与用户提供的固定基准点的 diff，从两个方面进行审查：

• Standards — 代码是否符合此仓库已记录的编码标准？
• Spec — 代码是否忠实实现了来源 issue / spec？

这两个方面会由并行子 Agent分别执行，避免彼此影响上下文，然后由此技能汇总审查结果。

你应该已获得 issue 跟踪器信息——如果缺少 docs/agents/issue-tracker.md，请运行 /setup-leandrocfe-skills。

流程

1. 固定基准点

基准点由用户指定——可以是提交 SHA、分支名、标签、main、HEAD~5 等。如果用户未指定，请询问。

记录一次 diff 命令：git diff <固定基准点>...HEAD（使用 three-dot，以便与 merge-base 进行比较）。同时记录提交列表：git log <固定基准点>..HEAD --oneline。

继续之前，确认该基准点有效（git rev-parse <固定基准点>），且 diff 不为空。无效的 ref 或空 diff 都应在此处导致流程失败，而不是等到两个并行子 Agent 开始执行后才失败。

2. 确定 spec 来源

按以下顺序查找来源 spec：

1. 提交消息中的 issue 引用（#123、Closes #45、GitLab 中的 !67 等）——通过 docs/agents/issue-tracker.md 中的工作流进行查找。
2. 用户作为参数提供的路径。
3. docs/、specs/ 或 .scratch/ 下与分支名或功能名匹配的 spec 文件。
4. 如果未找到任何内容，请询问用户 spec 在哪里。如果用户表示不存在，则跳过 Spec 子 Agent，并报告“没有可用的 spec”。

3. 找出标准来源

仓库中任何说明代码应如何编写的内容，例如 CODING_STANDARDS.md 或 CONTRIBUTING.md。

除了仓库文档中的内容，Standards 维度始终包含以下 smell baseline——一组固定的 Fowler 代码异味（Refactoring，第 3 章），即使仓库没有任何相关文档也适用。它受两条规则约束：

• 仓库标准优先。 仓库中有文档记录的标准始终优先；若该标准认可了 baseline 会标记的做法，则忽略该异味。
• 始终需要判断。 每种异味都是启发式标签（“可能存在 Feature Envy”），而非硬性违规；与这里的任何标准一样，跳过工具已能保证的内容。

每种异味都按 是什么 → 如何修正 描述；请对照 diff 检查：

• Mysterious Name — 函数、变量或类型的名称未能说明其功能或所存内容。→ 重命名；若想不出恰当的名称，说明设计不清晰。
• Duplicated Code — 同一种逻辑结构在本次改动的多个代码块或文件中重复出现。→ 提取共享结构，并在两处调用。
• 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. 并行启动两个子 Agent

Standards 子 Agent 的提示词——包括：

• 完整的 diff 命令和提交列表。
• 第 3 步找到的标准来源文件列表，以及完整粘贴的第 3 步 smell baseline——子 Agent 无法通过其他方式访问该内容。
• 任务说明：“报告——在相关时按文件／代码块说明——(a) diff 中所有违反已记录标准的位置：引用标准（文件 + 规则）；以及 (b) 发现的任何 baseline 异味：注明异味名称并引用代码块。区分硬性违规与判断性意见——违反已记录标准可能属于硬性违规，但 baseline 异味始终属于判断性意见，且仓库中有文档记录的标准优先于 baseline。跳过工具已能保证的内容。少于 400 词。”

Spec 子 Agent 的提示词——包括：

• diff 命令和提交列表。
• spec 的路径或已检索的内容。
• 任务说明：“报告：(a) spec 要求但缺失或仅部分实现的内容；(b) diff 中未要求的行为（范围蔓延）；(c) 看似已实现但实现方式可能有误的要求。每项发现都引用对应的 spec 行。少于 400 词。”

如果 spec 缺失，则跳过 Spec 子 Agent，并在最终报告中注明。

5. 汇总

将两份报告分别放在 ## Standards 和 ## Spec 标题下，完整呈现或稍作整理。不要合并或重新排序发现项——这两个维度是刻意分开的（参见 为什么要分成两个维度）。

最后用一行总结：每个维度的发现项总数，以及_各自维度内_最严重的问题（如有）。不要在两个维度之间选出唯一赢家——这正是分开呈现所要避免的重新排序。

为什么要分成两个维度

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

• 代码遵循所有标准，却实现了错误的内容 → Standards 通过，Spec 未通过。
• 代码完全按照 issue 的要求执行，却违反了项目约定 → Spec 通过，Standards 未通过。

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