/code-review 技能

它的作用

code-review 审查 HEAD 以及你指定的一个固定点——一次提交、一个分支、一个标签， main, HEAD~5 ——沿两个维度。 标准 问代码是否符合这个仓库的代码写法。 规格说明 问代码是否做了原始 issue 或 spec 要求的。每条轴在各自的 sub-agent 所以双方都看不到对方的推理。

两条轴从不合并、从不重新排序。报告以每条轴最差的 每条轴 并拒绝在它们之间选出唯一赢家，因为一个改动可能通过一条轴而败在另一条：实现错东西却遵守所有约定的代码通过标准轴、败在规格轴；完全按 ticket 做的代码在违反仓库约定时效果相反。混合结论会让通过的轴掩盖失败的轴。

何时使用

输入 /code-review，或当你要求审查分支、PR、进行中的工作或任何「自 X 以来」的东西时，智能体会自动调用它。

你必须提供固定点。如果不提供，技能会要一个而不是猜；然后它在派生任何东西之前检查 ref 能解析、diff 非空，所以打错的分支名会当着你的面失败，而不是在两个子智能体内部。

前置条件

标准轴什么都不需要。它读取仓库文档化的任何内容（CODING_STANDARDS.md, CONTRIBUTING.md等）并在仓库没有任何文档时退回内置基线。

规格轴需要规格说明存在且可找到。它按此顺序查找：

1. 提交消息中的 issue 引用（#123, Closes #45，一个 GitLab !67），通过 docs/agents/issue-tracker.md.
2. 作为参数传入的路径。
3. 一个位于 docs/, specs/，或 .scratch/ 与分支或功能名匹配。
4. 问你。

第 1 步依赖 docs/agents/issue-tracker.md，这 setup-matt-pocock-skills 写入。没有它，只要你给一个路径，那条轴仍然工作。完全没有规格说明时，规格子智能体被跳过，报告说「无规格说明可用」，而不是编造需求。

两条轴

一个不知道你标准的通用审查技能，正是这个设计试图避免的东西——它会把你有意为之的代码当作问题标记出来，却漏掉你的代码库真正依赖的不变量。所以仓库自己的文档就是 第一手资料 在标准轴上，而 仓库总是覆盖.

这个 坏味道基线 是它下面的地基：来自 重构 第 3 章——神秘命名、重复代码、特性依恋、数据泥团、基本类型偏执、重复开关、霰弹式修改、发散式变化、臆测式泛化、消息链、中间人、被拒绝的遗赠。每一条都是带标签的启发式判断（「疑似特性依恋」），绝不是硬性违规，每一条都以 它是什么 → 如何修复，于是每项发现都附带一个动作而非抱怨。你的 linter 已强制的内容在两个维度上都会被跳过。

常见问题

它与 Claude Code 自己的 /code-review。我该怎么办？

这是该技能被报告最多的问题，而且没有修复。Claude Code 自带 /code-review，它做的事不同——它在 diff 里猎杀 bug，而这个技能检查规格符合性与仓库标准。安装这个库意味着其中一个会胜出，胜出者取决于你的安装方式。通过插件市场安装时，一切都会以 mattpocock-skills: 前缀，内置的以非限定名变得难以触达；通过普通技能安装，本地文件胜出，这个技能遮蔽了内置。一个干净的答案是彻底移除 Claude Code 的内置技能：一大块 context 保存，冲突就不再重要。遮蔽本身可以说是 Claude Code 的 运行框架 bug——技能作者应该可以自由命名技能——所以另一个答案是重命名本地副本。编辑 frontmatter 或重命名目录会被 npx skills update；用户报告的可持久解决方案是把技能 fork 成一个新名字，并去掉 code-review 从受管技能集中，记下你 fork 时的提交以便手动重新同步。

它的子智能体不断调用 /code-review 再次派生更多智能体。

已知开放 bug，被多人在多个运行框架中复现。标准轴和规格轴提示词都没有禁止委托，所以子智能体可能重新发现技能并再次扇出——一份报告达到 50 多个智能体。人们在 fork 上应用的修复是在两个子智能体简报末尾各加一行：「不要调用 /code-review 或派生额外智能体——直接执行本次审查。」有人更喜欢在运行框架层面处理，让每个技能都继承这道护栏。两者都还没进入已发布的技能。如果你无人值守地运行它，盯住智能体数量。

我应该在同一个 会话 写代码的那个？

优先用全新的。正如一位读者所说：「相同的上下文审查自己不是审查，是带斜杠命令的确认偏误。」编写会话中的审查智能体持有塑造代码的每一个假设，这恰恰是独立审查者不会有的上下文。这也是为什么人们要求 implement 不带内置审查步骤——它在刚写 diff 的会话内运行审查。调用 /code-review 从干净会话中自己动手，才是诚实的版本。

每个任务之后，还是只在最后统一记录？

两者都有效，而技能不会替你决定。按任务审查让每个 diff 足够小，使规格轴有清晰的规格可对照，这正是 implement 使用。把批处理排到分支末尾，能抓住逐任务扫描各自漏掉的任务间交互。如果不确定，按任务审查，再对照分支点跑一次最终扫描。

我能相信这些发现吗？

不检查不行。子智能体的输出是假设，不是证据——一个团队报告了十几个被散文式审查放行的破坏性变更。技能把两份报告逐字或轻度清理地聚合，而不是对照文件重新验证每条论断，所以一项发现可能引用错误的位置或夸大影响。在行动前阅读每项发现的引用。每条发现都被要求带上引用——一条标准规则、一个坏味道加其块、或一行规格——正是这一点让它至少可被检查。

为什么我每次运行它都发现新问题？

因为修复会产生新的表面，也因为标准轴的判断那一半在两次运行之间并不确定。一位读者直白地描述了循环：「/code-review 和 /improve-code-architecture 每次总能发现新东西。我实现修复、重跑这些技能、一次又一次。」没有收敛保证。把一次通过当作线索清单，对有引用规则支撑的线索采取行动，然后停止——不要循环运行直到它变干净，因为它不会。

它会审查我未提交的工作吗？

不。它对比 <fixed-point>...HEAD，三点式，从合并基点起算，排除暂存区和工作区改动。如果 implement 没有做中间提交，即将提交的工作对审查就是不可见的。先提交，再审查，然后 amend 或添加 fixup。

做到以下就算成功

• 在派发任何子智能体之前，它拒绝在坏的 ref 或空 diff 上开始。
• 报告以两个独立块抵达，位于 ## Standards and ## Spec，而不是合并后的单一清单。
• 每条标准轴发现都点名你仓库某个文件中的一条规则或十二个坏味道之一，并引用对应块；每条规格轴发现都引用规格说明中的一行。
• 收尾摘要给出每条轴最差的一个问题，拒绝选出总冠军。
• 没有规格说明可用时，规格块直说，而不是列出它从代码推断的需求。

在流程中的位置

code-review 是构建链尾部的审查步骤—— grill-with-docs → to-spec → to-tickets → implement → code-review ——并且也能在你指向的任何分支或 PR 上独立运行。

• implement 是最近的邻居：它驱动构建，并在提交前调用这个技能作为自己的收尾审查。
• to-spec and to-tickets 产出规格轴对照检查的文档；模糊的规格说明让那条轴也变得模糊。
• improve-codebase-architecture 是整库范围的对应物——这个技能只看一个 diff。

ask-matt 当你不确定情境需要哪个技能时，跨整套路由。