# Code Review

> 从工程规范与需求符合度两个维度只读评审固定代码范围。适用于评审分支、PR、未提交改动、文件或目录或当前实现；可用 --std 或 --spec 锁定维度。

- Skill: `zuozh11/code-review` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add zuozh11/code-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zuozh11/code-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zuozh11 (https://skillmd.com/u/zuozh11)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zuozh11/code-review

---


# Code Review

对固定代码范围执行一次只读评审：

- **Standards**：检查项目工程规范，并判断改动是否选择了最小正确实现。
- **Spec**：检查实现是否符合 PRD、任务卡等已确认需求。

调用方或用户指定 `--std` / `--spec` 时，视为维度锁：只跑被锁定的维度。未锁维度时，由本 Skill 判断每条依据的适用性并归入 Standards 或 Spec，只启用有依据的维度。两个维度只共享固定代码范围，不共享依据或 finding。本 Skill 不修改代码、提交或远端状态。

## 1. 加载项目上下文

按项目知识协议使用相关 CONTEXT 与当前适用的 RULE。已有知识覆盖本次范围时复用，范围扩大时补充。知识不可用时继续并如实说明。

把约束代码结构、写法、测试或工程协作的内容归入 Standards；把约束系统行为、状态、数据、校验、权限或业务流程的内容归入 Spec。PRD、API 清单、任务卡、Issue 和当前对话中的已确认需求归入 Spec。每条依据只进入一个维度。历史、场景不匹配或被当前明确要求取代的内容不作为评审依据。

## 2. 固定评审范围

优先使用调用方或用户指定的 commit、branch、tag、range、PR 或路径，并记录实际 diff 命令和 commit 列表。分支使用 `git diff <fixed-point>...HEAD`。

调用方指定的 commit、range 或 pathspec 与用户指定同等优先。`impl` 传入单笔提交时，范围就是该 SHA，不使用分支 merge-base。

用户未明确固定点时：

- PR 编号或 URL：解析真实 base、head 和 patch；
- 当前分支：使用可确认的上游或默认分支 merge-base，无法确认时提问；
- 未提交改动：覆盖未暂存、已暂存和未跟踪文件；
- 文件或目录当前实现：完整读取 [SNAPSHOT.md](./SNAPSHOT.md) 固定文件列表和工作区状态。

用户指定路径时用同一 pathspec 限制范围。引用无效、diff 为空或 snapshot 无有效文件时停止。

## 3. Standards 快速评审

读取范围内生效的 `AGENTS.md`、`CLAUDE.md` 和适用的工程 RULE、其他工程规范、测试约定与模块约束。PRD、任务卡等需求不进入 Standards。

Standards 维度由一个 Standards 子 Agent 单次完成。主 Agent 先固定范围并准备全部工程规范，再把 diff、必要上下文和规范一次性交给它；子 Agent 逐个 changed hunk 阅读必要的调用者，只扩展到能够判断所有权、消费者和替代方案的范围。

先读取 [MIN-IMPL.md](../codebase-design/MIN-IMPL.md)，按阶梯停在第一项成立的位置。候选替代方案必须完整满足需求，并有可说明的正确性或维护收益。

修复缺陷时检查待修改位置的全部调用者：共同根因能够在真实所有者修复时，报告散落在调用者的补丁；不要以 diff 小为由接受错误层级。

不得仅凭代码味道或未来扩展可能性建议新类型、接口、多态、工厂、配置、wrapper、模块拆分或依赖注入。结构调整只有同时满足以下条件才成立：

- 当前存在可证明的维护或正确性影响；
- 删除、复用、标准库、平台原生和已安装依赖均不能解决；
- 替代方案减少净概念或把真实复杂度集中到正确所有者；
- 没有为单一实现创建可替换接口，也没有保留平行兼容层。

`codebase-design` 只在候选通过上述门槛且确实涉及必要模块形状时读取。用户显式要求、项目工程 RULE、信任边界校验、安全、无障碍和防止数据丢失的必要行为始终保留。

Standards 子 Agent 对每条加载的工程规范判定符合、不适用或违反，并返回完整覆盖状态；只把违反和具有具体影响的最小实现 finding 交给主 Agent。跳过纯偏好、无影响意见、工具已经确定性检查的问题和无法给出更小正确替代方案的建议。

## 4. Spec 评审

按以下顺序读取本次需求依据：

1. 用户指定的 PRD、API 清单、任务卡、Issue、PR 或当前对话目标；
2. 已加载且内容约束系统行为的 RULE；
3. commit 或变更明确引用的需求来源；
4. 与变更主题明确对应的本地需求文档。

CONTEXT 可帮助理解项目术语，但不代替需求来源。工程 RULE、当前代码和工程惯例不转成需求。没有可用需求依据时跳过 Spec，并如实说明。

Spec 只报告需求遗漏、错误行为和需求之外的 scope creep；命名、重复、架构和测试写法不进入 Spec。每条适用的已确认需求都在本轮内部判定为符合、不适用或违反。

调用方给出的候选 `ruleId` 与需求材料必须纳入分类，不得静默丢弃。判定不适用只允许四类可复核理由：历史、场景不匹配、被本次明确要求取代、不在本单元业务结果内；缺这类理由时保持适用。调用方声明本单元业务结果后，未纳入该结果的其余需求判不适用，不报遗漏。

需求材料在本提交中已被用户确认修正时，以修正后的文本为 Spec 依据。实现方私下的解释、注释或偏差记录不构成依据。Implementation Decisions 中来源为用户确认的授权例外，对应条款判定为不适用，并在覆盖状态中说明。

## 5. 执行与终检

只启用 Standards 时创建一个 Standards 子 Agent，只启用 Spec 时创建一个 Spec 子 Agent；两个维度同时启用时并行创建两者。每个子 Agent 只接收自己的完整依据和固定范围，一次返回工程规范或需求覆盖状态及候选 finding。

主 Agent 核实候选引用的代码、影响和本维度依据，删除不成立、越界或串用依据的候选，并确认适用规则已覆盖。缺少覆盖时只补核遗漏规则，不重复完整评审。

保留 finding 前必须同时确认：位置准确、影响具体、依据属于本维度、建议是最小正确方向。严重程度由终检结果确定：`P0` 阻断交付或造成重大事故，`P1` 高概率错误行为，`P2` 局部缺陷或明确维护风险，`P3` 低风险但有具体收益。

## 6. 输出

使用连续编号，内容保持紧凑：

```markdown
评审范围：<固定点、diff 命令和路径>
本单元业务结果：<调用方声明；无则写「未声明」>
维度：
- Standards：启用 / 未启用（<依据列表>）
- Spec：启用 / 未启用（<依据或「无可用需求依据」>）

## Standards
- [STD-001] [P2] <delete/reuse/stdlib/native/dependency/shrink：问题> — `<文件:行>`
  - 影响：<具体影响>
  - 最小修复：<删除什么或使用什么替代>

工程规范：已覆盖 <来源列表>；<通过 / 存在上述违反 / 未完成>

## Spec
- [SPEC-001] [P1] <问题> — `<文件:行>`
  - 需求依据：<需求来源及具体要求>
  - 偏差：<遗漏、错误或 scope creep>
  - 最小修复：<方向>

需求：已覆盖 <来源列表>；<通过 / 存在上述违反 / 未完成>
```

只输出启用的维度。没有 finding 时写「未发现问题」并停止，不制造改进意见，不估算净减少行数。