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 章）。即使仓库没有任何相关记录，这些坏味道也适用。该基线受两条规则约束：

• 仓库规范优先。 仓库中已记录的标准始终优先。如果仓库明确认可某种做法，而基线会标记该做法，则抑制该坏味道。
• 始终属于判断性意见。 每个坏味道都是带标签的启发式判断（例如“可能存在 Feature Envy”），而不是硬性违规。与本文件中的其他标准一样，凡工具已强制执行的内容一律跳过。

每个坏味道按是什么 → 如何修复的格式描述；将其与 diff 对照：

• Mysterious Name（神秘命名）：函数、变量或类型的名称无法体现其作用或所持有的内容。→ 重命名；如果想不出恰当的名称，说明设计本身不清晰。
• Duplicated Code（重复代码）：同一逻辑结构出现在变更中的多个代码块或文件里。→ 提取共享结构，并从两处调用它。
• Feature Envy（特性依恋）：某个方法访问其他对象的数据多于访问自身的数据。→ 将该方法移动到它所依恋的数据所在的类上。
• Data Clumps（数据泥团）：同样的几个字段或参数总是成组出现（说明应该有一个类型来承载它们）。→ 将它们封装为一个类型，改为传递该类型。
• Primitive Obsession（基本类型偏执）：用基本类型或字符串代替本应拥有独立类型的领域概念。→ 为该概念定义一个小型专用类型。
• Repeated Switches（重复的 Switch）：同一类型上的同一个 switch/if 级联在变更中多次出现。→ 用多态替换，或使用一个两处共享的映射表。
• Shotgun Surgery（霰弹式修改）：一项逻辑变更需要在 diff 中的多个文件里零散地修改。→ 将一起变化的内容集中到同一个模块中。
• Divergent Change（发散式变化）：一个文件或模块因多个互不相关的原因而被修改。→ 拆分，使每个模块只因一个原因而变化。
• Speculative Generality（过度设计）：为规格中并不存在的需求而添加的抽象、参数或钩子。→ 删除；内联回去，直到出现真实需求。
• Message Chains（消息链）：调用方不应依赖的冗长 a.b().c().d() 导航。→ 将这段访问路径隐藏在第一个对象的一个方法之后。
• Middle Man（中间人）：某个类或函数大部分时间只是转发调用。→ 删除它，让调用方直接调用真正的目标。
• Refused Bequest（拒绝继承）：子类或实现者忽略或覆盖了其继承的大部分内容。→ 去掉继承，改用组合。

4. 并行启动两个子 Agent

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

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

• 完整的 diff 命令和提交列表。
• 第 3 步中找到的标准来源文件列表，外加第 3 步中的坏味道基线（完整粘贴）（子 Agent 无法访问其他途径获取该基线）。
• 任务说明：“按文件或代码块（如相关）报告：(a) diff 违反已记录标准的每一处：引用该标准（文件 + 规则）；(b) 你发现的任何基线坏味道：说明其名称并引用对应代码块。区分硬性违规与判断性意见：违反已记录的仓库标准可以判定为硬性违规，但基线坏味道始终是判断性意见，且仓库已记录的标准优先于基线。跳过工具已强制执行的内容。不超过 400 字。”

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

• diff 命令和提交列表。
• 规格说明的路径或抓取到的内容。
• 任务说明：“报告：(a) 规格要求但缺失或仅部分实现的需求；(b) diff 中出现的、规格未要求的行为（范围蔓延）；(c) 看似已实现但实现可能有误的需求。为每项发现引用对应的规格原文。不超过 400 字。”

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

5. 汇总

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

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

为什么使用两个维度

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

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

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