code-review

对比 HEAD 与用户指定固定点之间的差异，进行双轴审查：

• 规范：代码是否符合此代码库中记录的编码规范？
• 规格：代码是否忠实实现了起始问题／规格？

这两个维度由并行子 Agent分别审查，避免彼此的上下文受到干扰，然后由此技能汇总审查结果。

问题跟踪器应该已提供给你。如果缺少 docs/agents/issue-tracker.md，请告知用户运行 /setup-matt-pocock-skills。

流程

1. 确定固定点

用户指定的内容就是固定点（提交 SHA、分支名称、标签、main、HEAD~5 等）。如果用户没有指定，请向其询问。

记录一次差异命令：git diff <fixed-point>...HEAD（使用三个点，因此比较基于合并基点）。同时记录提交列表：git log <fixed-point>..HEAD --oneline。

继续之前，确认固定点可解析（git rev-parse <fixed-point>），且差异非空。无效引用或空差异应在此处报错，而不是在两个并行子 Agent 中报错。

2. 确定规格来源

按以下顺序查找起始规格：

1. 提交消息中的问题引用（#123、Closes #45、GitLab !67 等），通过 docs/agents/issue-tracker.md 中的工作流获取。
2. 用户作为参数传入的路径。
3. 在 docs/、specs/ 或 .scratch/ 下查找与分支名称或功能匹配的规格文件。
4. 如果没有找到，请询问用户规格的位置。如果用户表示没有规格，则 规格 子 Agent 将跳过审查并报告“无可用规格”。

3. 确定标准来源

仓库中记录代码编写规范的任何内容，例如 CODING_STANDARDS.md 或 CONTRIBUTING.md。

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

• 以仓库规范为准。 已记录的仓库规范始终优先；如果规范认可了基线会标记的做法，则忽略该代码异味。
• 始终需要判断。 每种代码异味都是带标签的启发式提示（“可能存在 Feature Envy”），绝非硬性违规。与此处的任何标准一样，跳过工具已强制执行的规则。

每种代码异味都说明了是什么 → 如何修复；请对照差异进行判断：

• 神秘命名（Mysterious Name）：函数、变量或类型的名称未能揭示其功能或所持数据。→ 重命名；如果找不到恰当的名称，说明设计含糊不清。
• 重复代码（Duplicated Code）：变更中的多个代码块或文件出现相同的逻辑结构。→ 提取共用结构，并在两处调用。
• Feature Envy：某个方法访问其他对象的数据，比访问自身数据还多。→ 将该方法移至它所觊觎的数据所属对象中。
• 数据泥团（Data Clumps）：同一组字段或参数总是一起传递（仿佛在等待被创建为一个类型）。→ 将它们封装为一个类型，并传递该类型。
• 基本类型偏执（Primitive Obsession）：用基本类型或字符串表示本应拥有专属类型的领域概念。→ 为该概念创建一个专属的小型类型。
• 重复的条件分支（Repeated Switches）：变更中反复出现针对同一类型的相同 switch/if 级联。→ 改用多态，或创建一个供两处共用的映射。
• 霰弹式修改（Shotgun Surgery）：一处逻辑变更导致差异中多个文件散落着修改。→ 将相关变更集中到同一个模块。
• 发散式变化（Divergent Change）：一个文件或模块因多个互不相关的原因而被修改。→ 拆分模块，使每个模块只因一个原因而变更。
• 过度泛化（Speculative Generality）：添加了规范未要求的抽象、参数或钩子。→ 删除；内联回去，直到出现真实需求。
• 消息链（Message Chains）：调用方不应依赖的冗长 a.b().c().d() 导航链。→ 在第一个对象上添加一个方法，封装整个调用链。
• 中间人（Middle Man）：一个类或函数基本只负责向下转发调用。→ 删除它，直接调用实际目标。
• 被拒绝的遗产（Refused Bequest）：子类或实现类忽略或重写继承的大部分内容。→ 放弃继承，改用组合。

4. 并行启动两个子 Agent

标准子 Agent 的提示词应包含：

• 完整的差异命令和提交列表。
• 第 3 步中找到的标准来源文件列表，以及第 3 步中的代码异味基线（完整粘贴；子 Agent 无法通过其他方式访问该内容）。
• 简要说明：“按文件／代码块（如相关）报告：(a) 差异中每处违反已记录规范的位置，并引用规范（文件 + 规则）；(b) 发现的任何基线代码异味：指出名称并引用代码块。区分硬性违规与判断性提示：违反已记录规范可能是硬性违规，但基线代码异味始终需要判断，且已记录的仓库规范优先于基线。跳过工具已强制执行的内容。少于 400 词。”

规范子 Agent 的提示词应包含：

• 差异命令和提交列表。
• 规范的路径或已获取的内容。
• 简要说明：“报告：(a) 规范要求但缺失或仅部分实现的内容；(b) 差异中未被要求的行为（范围蔓延）；(c) 看似已实现但实现方式可能有误的要求。每项发现都引用规范中的原文。少于 400 词。”

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

5. 汇总

在 ## Standards 和 ## Spec 标题下分别呈现两份报告，可原样保留或稍作整理。不要合并或重新排序发现的问题，因为这两个维度是刻意分开的（参见 为什么使用两个维度）。

以一行摘要结束：每个维度的发现总数，以及各维度内部最严重的问题（如有）。不要跨维度选出唯一的"最优先"问题，这种重新排序正是分开两个维度要防止的。

为什么使用两个维度

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

• 完全遵循所有规范，但实现了错误的功能 → Standards 通过，Spec 失败。
• 完全按 issue 要求实现功能，但破坏了项目约定 → Spec 通过，Standards 失败。

分开报告可以防止一个维度掩盖另一个维度。