code-review

name	code-review
description	沿两个轴线审查自某个固定点（commit、分支、tag 或合并基准）以来的变更 — 标准（代码是否遵循此仓库已记录的编码规范？）和规范（代码是否匹配原始 issue/PRD 要求的内容？）。以并行子 agent 运行两项审查，并将结果并排呈现。当用户想要审查分支、PR、进行中的变更，或要求"从 X 开始审查"时使用。

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

• 标准 — 代码是否符合此仓库已记录的编码规范？
• 规范 — 代码是否忠实地实现了原始 issue / PRD / 规范？

两个轴以并行子 agent 方式运行，以免互相污染上下文，然后本技能汇总它们的发现。

应该已经向你提供了问题追踪器 — 如果 docs/agents/issue-tracker.md 缺失，请运行 /setup-matt-pocock-skills。

流程

1. 确定固定点

用户所说的任何固定点 — 一个 commit SHA、分支名、tag、main、HEAD~5 等。如果用户未指定，请询问。

一次性捕获 diff 命令：git diff <固定点>...HEAD（三个点，以便与合并基准比较）。同时通过 git log <固定点>..HEAD --oneline 记录 commit 列表。

继续之前，确认固定点可解析（git rev-parse <固定点>）且 diff 非空。无效引用或空 diff 应在此处失败 — 而非在两个并行子 agent 内部。

2. 识别规范来源

按以下顺序查找原始规范：

1. commit 消息中的 issue 引用（#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 代码异味（《重构》第 3 章），即使仓库没有任何记录也适用。两条规则约束它：

• 仓库优先。 已记录的仓库标准始终优先；当它认可基线可能标记的内容时，抑制该异味。
• 始终是判断。 每个异味是一个带标签的启发式（"可能的 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

发送一条消息，包含两个 Agent 工具调用。两者均使用 general-purpose 子 agent。

标准子 agent 提示词 — 包含：

• 完整的 diff 命令和 commit 列表。
• 在第 3 步中找到的标准来源文件列表，加上第 3 步中的异味基线全文粘贴 — 子 agent 没有其他途径获取它。
• 任务简述："报告 — 在相关时按文件/代码块 — (a) diff 违反已记录标准的每个地方：引用标准（文件 + 规则）；以及 (b) 你发现的任何基线异味：命名并引用代码块。区分硬性违规和判断性调用 — 已记录标准的违规可以是硬性的，但基线异味始终是判断性调用，且已记录的仓库标准覆盖基线。跳过工具链已强制执行的内容。400 词以内。"

规范子 agent 提示词 — 包含：

• diff 命令和 commit 列表。
• 规范的路径或已获取的内容。
• 任务简述："报告：(a) 规范要求但缺失或不完整的需求；(b) diff 中存在但未被要求的、超出范围的行为；(c) 看起来已实现但实现方式错误的需求。每个发现引用规范原文。400 词以内。"

如果规范缺失，跳过规范子 agent 并在最终报告中注明。

5. 汇总

在 ## 标准 和 ## 规范 标题下呈现两份报告，原文或略微整理。不要合并或重新排名发现 — 两个轴故意分离（见_为什么是两个轴_）。

以一行摘要结束：每个轴的发现总数，以及每个轴内_最严重的问题_（如有）。不要在轴之间选一个"赢家" — 那正是分离设计要防止的重新排名。

为什么是两个轴

一个变更可能通过一个轴而未通过另一个：

• 代码遵循所有标准但实现了错误的东西 → 标准通过，规范未通过。
• 代码完全按 issue 要求做了，但违反了项目的约定 → 规范通过，标准未通过。

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