code-review 技能 - 双轴 AI 代码审查

技能概述

code-review 技能针对指定固定点（commit、分支、tag 或 merge-base）以来的全部代码改动，从规范和规格两条轴分别做一次代码评审，两路用并行子智能体独立运行，最后并排汇报结果。

适用场景

1. 分支或 PR 合并前的评审：分支开发完成、准备合入 main 之前，先确认它既守住了本仓库的编码规范，也确实实现了当初要做的功能。
2. 审查尚未提交的工作区改动：手头有一批改动说不清做得对不对，用一个固定点（如 HEAD~5）划出范围，让两路评审各自给出结论。
3. 需求实现符合度核对：当 issue 或规格文档写得比较细，需要逐条核对哪些实现了、哪些只做了一半、哪些夹带了没要求的东西时使用。

核心功能

1. 双轴独立评审：规范轴回答"代码是否符合本仓库文档化的编码标准"，规格轴回答"代码是否忠实实现了原始 issue / 规格"。两条轴刻意不合并、不重新排序，因为一个维度很容易掩盖另一个维度——完全合规但做错事，或者做对了事但违反约定，都是常见情况。
2. 并行子智能体执行：两路评审由并行子智能体分别完成，互不污染上下文，再由主流程汇总。技能会先校验固定点能否解析、diff 是否为空，避免把无效输入带进两个并行子智能体里才报错。
3. 规范来源自动归集：规范轴会搜集仓库中所有描述"代码该怎么写"的文件（如 CODING_STANDARDS.md、CONTRIBUTING.md），并在此基础上附加一套固定的代码坏味道基线（Mysterious Name、Duplicated Code、Feature Envy、Data Clumps、Primitive Obsession、Repeated Switches、Shotgun Surgery、Divergent Change、Speculative Generality、Message Chains、Middle Man、Refused Bequest）。两条规则约束这套基线：仓库已文档化的标准优先，基线可以被它覆盖；每条坏味道都只是"疑似"的判断项，不是硬性违规，工具链已经能管的事情一律跳过。
4. 规格来源溯源：按顺序查找原始规格——提交信息里的 issue 引用（#123、Closes #45、GitLab !67）、用户直接传入的路径、docs/、specs/、.scratch/ 下与分支名匹配的文件；都没有时才会反问用户。

常见问题

code-review 技能和普通的 AI 代码审查有什么不一样？

普通代码审查通常只回答"这段代码写得好不好"。这个技能把问题拆成两问：写得好不好（规范），以及写的是不是该写的东西（规格）。两路各自出报告，不做交叉排名，所以你既能看到"完全合规但做错了事"，也能看到"做对了事但违反了项目约定"。

为什么标准和规格要分成两路，不合并成一份报告？

因为合并会让一个维度掩盖另一个维度。一份合并报告很容易把"需求没实现"这种严重问题，和"命名不够清楚"这种小问题放在同一个列表里比高低，结果两边都失真。分开汇报、各自给出一条"本轴内最严重的问题"，是刻意的设计。

找不到对应的 issue 或规格文档还能用吗？

能，但只跑一半。没有规格来源时，规格轴的子智能体会被跳过，报告里明确写"无可用规格"；规范轴照常运行。另外，如果仓库缺少 docs/agents/issue-tracker.md，技能会提示你先运行 /setup-matt-pocock-skills 来补齐 issue 追踪的读取流程。

这个技能会改动我的代码吗？

不会。它的产物是评审报告，只读取 diff 和仓库文档，不写代码、不提交、不推送。改不改、怎么改由你自己决定。

用之前需要准备什么？

至少需要一个能解析的固定点（commit SHA、分支名、tag、main、HEAD~5 等）。如果没指定，技能会直接问你。技能会自己确认该 ref 能解析、且与 HEAD 的 diff 非空，这两件事不通过就会在启动并行评审之前失败。