review

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

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

两个审查轴作为并行子 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/ 下与分支名或功能匹配的 PRD／规格文件。
4. 如果未找到，请询问用户规格位于何处。如果用户表示不存在规格，规格子 Agent 将跳过并报告“没有可用规格”。

3. 确定标准来源

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

除了仓库记录的内容之外，标准维度始终还包含下述坏味道基线——一组固定的 Fowler 代码坏味道（Refactoring 第 3 章），即使仓库没有任何记录也会适用。它受两条规则约束：

• 仓库规则优先。 成文的仓库标准始终优先；如果标准认可了基线本会标记的内容，则不报告该坏味道。
• 始终需要判断。 每种坏味道都是带标签的启发式判断（“可能存在依恋情结”），绝非硬性违规——而且，与这里的任何标准一样，跳过工具已经强制执行的内容。

每种坏味道均按它是什么 → 如何修复的格式描述；将其与差异进行比对：

• 神秘命名——函数、变量或类型的名称无法揭示其功能或所持内容。→ 重命名；如果仍想不出一个恰当的名称，说明设计本身并不清晰。
• 重复代码——相同的逻辑结构出现在本次变更的多个差异区块或文件中。→ 提取共享结构，并在两处调用它。
• 依恋情结——方法访问另一个对象的数据多于访问自身的数据。→ 将该方法移到它所依恋的数据所属对象上。
• 数据泥团——几个相同的字段或参数总是一起传递（一个亟需诞生的类型）。→ 将它们封装为一个类型，并传入该类型。
• 基本类型偏执——用基本类型或字符串代替一个理应有独立类型的领域概念。→ 为该概念创建一个小型专用类型。
• 重复条件分支——针对同一类型的相同 switch/if 级联判断在本次变更中反复出现。→ 改用多态，或者让两处共享同一张映射表。
• 霰弹式修改——一项逻辑变更迫使人们跨变更中的许多文件进行零散编辑。→ 将共同变化的内容集中到一个模块中。
• 发散式变化——一个文件或模块因多个不相关的原因而被修改。→ 进行拆分，使每个模块只因一个原因而变化。
• 夸夸其谈的通用性——为规格中不存在的需求添加抽象、参数或钩子。→ 删除它；在实际需求出现前，将相关内容内联回去。
• 消息链——调用方不应依赖的长 a.b().c().d() 导航链。→ 用第一个对象上的一个方法隐藏这段遍历。
• 中间人——主要只负责继续委托的类或函数。→ 删掉它，直接调用真正的目标。
• 被拒绝的遗赠——忽略或重写其继承的大部分内容的子类或实现者。→ 放弃继承，改用组合。

4. 并行启动两个子 Agent

在一条消息中发送两次 Agent 工具调用。对两者都使用 general-purpose 子 Agent。

标准子 Agent 提示词——包括：

• 完整的差异命令和提交列表。
• 步骤 3 中找到的标准来源文件列表，以及步骤 3 中的坏味道基线，并将其完整粘贴进去——子 Agent 无法通过其他方式访问它。
• 简述：“报告——按相关文件／差异区块列出——(a) 差异中每一处违反成文标准的位置：引用标准（文件 + 规则）；以及 (b) 发现的任何基线坏味道：指出其名称并引用差异区块。区分硬性违规与判断项——成文标准违规可以是硬性问题，但基线坏味道始终是判断项，且成文的仓库标准优先于基线。跳过工具已强制执行的所有内容。少于 400 字。”

规格子 Agent 提示词——包括：

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

如果缺少规格说明，则跳过规格子 Agent，并在最终报告中注明这一点。

5. 汇总

在 ## Standards 和 ## Spec 标题下原样或略作整理呈现这两份报告。不要合并或重新排序发现项——这两个维度是刻意分开的（见_为何采用两个维度_）。

最后以一行摘要结束：每个维度的发现项总数，以及_每个维度内_最严重的问题（如有）。不要跨维度选出一个“最严重项”——分维度正是为了防止这种重新排序。

为何采用两个维度

一项变更可能通过一个维度，却在另一个维度失败：

• 遵循所有标准但实现了错误内容的代码 → 标准通过，规格失败。
• 完全按照问题要求执行，却违反项目约定的代码 → 规格通过，标准失败。

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