/code-review 技能

它的作用

code-review 审查 HEAD and a fixed point you name (a commit, a branch, a tag, main, HEAD~5) along two axes. 标准问代码是否符合这个仓库的代码写法。 规格说明 问代码是否做了原始 issue 或 spec 要求的。每条轴在各自的 sub-agent 所以双方都看不到对方的推理。

The skill never merges or re-ranks the two axes. The report ends with a worst issue 每条轴 and declines to name a single winner across them. A change can pass one axis and fail the other. Code that follows every convention but implements the wrong thing passes Standards and fails Spec. Code that does exactly what the ticket asked but breaks the repo's conventions does the reverse. A blended verdict lets the passing axis hide the failing one.

何时使用

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

你的情境	何时使用
有一个 diff，你想知道它是否构建正确 and 是正确的事	`code-review`
You want bugs hunted in the diff: null paths, races, off-by-one	Claude Code 自带的审查，不是这个（见下面的名称冲突）
什么都没写，你想以测试先行来写	tdd
整个规格说明需要构建，包括审查	implement，它自身会调用该技能
整个代码库都漂移了，不是一个 diff	improve-codebase-architecture
有东西坏了，你不知道为什么	diagnosing-bugs

You must supply the fixed point. If you do not, the skill asks for one rather than guessing. Before it spawns anything, it checks that the ref resolves and that the diff is not empty, so a mistyped branch name fails in front of you instead of inside two sub-agents.

前置条件

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

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

提交消息中的 issue 引用（#123, Closes #45，一个 GitLab !67), fetched through the tracker doc.
作为参数传入的路径。
一个位于 docs/, specs/，或 .scratch/ 与分支或功能名匹配。
问你。

Step 1 depends on the tracker doc, which setup-matt-pocock-skills writes. Without it the axis still works if you hand it a path. With no spec at all, the skill skips the Spec sub-agent and the report says "no spec available" rather than inventing requirements.

两条轴

	标准	规格说明
问题	它构建得对吗？	它是正确的东西吗？
读取	仓库文档化的标准，加上坏味道基线	原始 issue 或规格说明
报告	有据可查的违规（可能很难），以及坏味道（始终是判断题）	需求缺失或不完整、范围蔓延、需求实现错误
每项发现都引用	标准文件和规则，或点名的坏味道加其块	规格说明中的那一行

This design exists to avoid a generic review skill that does not know your standards. Such a skill flags what is deliberate in your codebase and misses the invariants your codebase depends on. So the repo's own documentation is the 第一手资料在标准轴上，而 仓库总是覆盖.

这个 坏味道基线 sits under the repo's standards. It is twelve code smells from chapter 3 of Fowler's 重构: Mysterious Name, Duplicated Code, Feature Envy, Data Clumps, Primitive Obsession, Repeated Switches, Shotgun Surgery, Divergent Change, Speculative Generality, Message Chains, Middle Man, Refused Bequest. Each is a labelled heuristic ("possible Feature Envy"), never a hard violation. Each states what the smell is and how to fix it, so a finding comes with a fix attached rather than only a complaint. Both axes skip anything your linter already enforces.

常见问题

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

这是该技能被报告最多的问题，而且没有修复。Claude Code 自带 /code-review, which does something different: it hunts bugs in the diff, where this one checks spec compliance and repo standards. When you install this library, one of them wins, and which one depends on how you installed:

Plugin marketplace. Every skill gets a mattpocock-skills: prefix, and the built-in becomes hard to reach at the unqualified name.
Plain skills install. The local file wins, and this skill shadows the built-in.

One answer is to remove Claude Code's built-in skills entirely. That saves a lot of context, and the collision stops mattering. The shadowing itself is arguably a Claude Code 运行框架 bug (a skill author should be free to name a skill anything), so the other answer is to rename the local copy. npx skills update undoes an edit to the frontmatter or a renamed directory. The durable workaround users report is to fork the skill to a new name and drop code-review from the managed set. Keep a note of the commit you forked from so you can re-sync by hand.

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

This is a known open bug. Several people have reproduced it, in more than one harness. The Standards and Spec prompts do not forbid delegation, so a sub-agent can find the skill again and fan out again. One report reached more than 50 agents. The fix people have applied on forks is one line appended to both sub-agent briefs: "Do not invoke /code-review or spawn additional agents: perform this review directly." Some prefer to handle it at the harness level so every skill inherits the guard. Neither is in the shipped skill yet. If you run this unattended, watch the agent count.

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

Prefer a fresh one. As one reader put it: "Same context reviewing itself isn't review, it's confirmation bias with a slash command." An agent that reviews in the authoring session has every assumption that shaped the code in its context. An independent reviewer would not have that context. This is also why people ask for implement without its built-in review step, because that step runs the review inside the session that just wrote the diff. The independent version is to invoke /code-review yourself from a clean session.

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

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

我能相信这些发现吗？

Not without checking. Sub-agent output is a hypothesis, not evidence. One team reported a dozen breaking changes that prose-based reviews had missed. The skill combines the two reports as they are, or lightly cleaned. It does not re-verify each claim against the files, so a finding can cite the wrong location or overstate an impact. Read the citation on each finding before you act on it. The skill requires every finding to carry a citation (a standards rule, a smell plus its hunk, or a spec line), and that is what makes the findings checkable.

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

Each fix adds new code to review, and the judgement-call half of the Standards axis gives different results from run to run. One reader described the loop: "/code-review and /improve-code-architecture always find new stuff every time. I implement fixes, rerun these skills, and again and again." There is no convergence guarantee. Treat a pass as a list of leads. Act on the ones with a cited rule behind them, then stop. Do not run it in a loop until it comes back clean, because it never will.

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

不。它对比 <fixed-point>...HEAD. The three-dot form measures from the merge-base and excludes staged and working-tree changes. If implement has not made an interim commit, the review cannot see the work that is about to go into the next commit. Commit first, then review, then amend or add a fixup.

做到以下就算成功

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

在流程中的位置

code-review is the review step near the tail of the build chain: grill-with-docs → to-spec → to-tickets → implement → code-review → retro. It also stands alone on any branch or PR you point it at.

implement is the closest neighbour. It drives the build and calls this skill as its own closing review before committing. implement-spec does the same once, over the whole integration branch.
retro comes after it and tunes it. When a session shows the review missing a class of mistake, retro proposes the check or the CODING_STANDARDS.md rule the Standards axis then reads.
pr writes the pull request body once the reviewed work goes up.
to-spec and to-tickets produce the document the Spec axis checks against, so a vague spec makes that axis vague.
improve-codebase-architecture is the whole-codebase counterpart, because this skill only looks at one diff.

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