code-review

---
# yaml-language-server: $schema=../../../schemas/skill-frontmatter.schema.json
name: code-review
description: >-
  六维代码评审：按 correctness / architecture / security / performance / UX / maintainability 逐维检查改动并输出分级 findings。当用户要求 review、审计代码或合并前检查时使用；覆盖评审范围确认、六维判定与 blocker / warning / nit 分级输出。
metadata:
  author: LOUSANPANG
  version: 1.0.0
  kind: native
  provides:
    - code-review
  invocation:
    mode: user
    userInvocable: true
  status: stable
---

# Code Review（六维评审）

## Purpose

对指定改动给出一次独立、可复核的评审：六维逐维结论 + 分级 findings（blocker / warning / nit），
每条 finding 带 `文件:行号` 与理由，blocker 附修复建议。产出**评审报告**，不直接改代码。

六维：correctness / architecture / security / performance /
maintainability 五维，另加 UX 维度。

## When to Use

- 当用户明确要求 review / 审计 / 走查这批改动时（本 skill 为 user 显式调用）
- 当 PR 或合并前需要一次独立检查时
- 当用户要求对大批量生成代码把关时（仍需用户开口，本 skill 不自行触发）

## When NOT to Use

- 普通编码任务中不要自动触发本 skill：只在用户显式要求时运行
- 定位与修复 bug：改用 `debugging-and-error-recovery`
- 验证自己刚完成的改动是否达标：改用 `verification`
- 评审结论要固化为长期约束：写进 `rules/`，不停留在报告里

## Inputs

- 评审范围（PR diff、commit 区间或文件列表）：缺失时用 `git diff <base>...HEAD` 并向用户确认 base
- 项目约定（CLAUDE.md、CONTRIBUTING、DESIGN.md）：缺失时按通用工程约定评审，并在报告头注明「项目约定缺失」
- 运行环境（能否执行测试 / 构建）：缺失时以静态阅读为主，并在报告声明未运行检查

## Workflow

### 1. Inspect

- `git diff <base>...HEAD --stat` + `git status`：确定改动文件、规模与是否含生成物
- 读 CLAUDE.md / DESIGN.md 拿到项目自己的约定，评审时以其为准
- 按模块读改动上下文：被改符号的调用方与被调用方，不只看 diff 行

### 2. Plan

- 固定六维检查顺序：correctness → architecture → security → performance → UX → maintainability
- 决定评审深度（全量 / 抽样）与抽样规则，写入报告头

### 3. Implement

- 逐维过 diff：correctness 看边界与错误路径；architecture 看分层与职责；
  security 看注入、越权、密钥泄露与依赖漏洞；performance 看热路径与多余请求；
  UX 看交互状态与可访问性；maintainability 看命名、重复与可测性
- 每条 finding 记录：`文件:行号`、所属维度、级别、理由；blocker 另附修复建议
- 级别判定：blocker = 错误行为 / 数据损坏 / 安全漏洞；warning = 明确缺陷但不阻塞合并；nit = 风格与可读性
- UI 改动补 UX 维的实际证据（截图或浏览器检查），不以想象代替运行

### 4. Verify

- 逐条复核 blocker：能给出触发路径或反例才保留，否则降级 warning
- 确认每条 finding 都有 `文件:行号` 与可判定理由，六维各留一条结论（含「无问题」）
- 跑一次受影响路径的 `typecheck → lint → test`，避免评出早已红着的基线

## Rules

- 每条 finding 必须带 `文件:行号` 与可判定理由，禁止只写「建议优化」
- blocker 必须给出具体修复建议（改法或代码方向），给不出就降级 warning
- 禁止在本 skill 内直接修改代码：评审与实现分离，修复由后续任务执行
- 与项目约定冲突时以项目约定为准，并注明所依据的约定文件
- security 维发现的问题级别不得低于 warning

## Common Failure Modes

| 症状 | 纠正 |
| --- | --- |
| 只看 diff 行，漏了调用方受到的影响 | 读被改符号的引用处后再下结论 |
| 所有意见都标 blocker，报告无法执行 | 按 blocker 判定标准重新分级 |
| 报告缺可复核证据 | 补 `文件:行号` 引用与检查阶梯输出 |
| 用个人风格偏好刷屏 nit | nit 收敛为一段，不与缺陷混排 |

## Common Rationalizations

| Agent says | Correct response |
| --- | --- |
| "改动不大，扫一眼就行" | 六维逐维过一遍，逐条给 `文件:行号` |
| "这是生成代码，不用认真审" | 生成的代码按同一套 blocker 判定标准审 |
| "问题明显，不写行号也知道在哪" | 每条 finding 必须给 `文件:行号` |
| "风格不合我口味也算问题" | 归入 nit，不得阻塞合并 |

## Verification

- `git diff <base>...HEAD --stat` → 报告覆盖全部改动文件，或写明抽样范围
- 六维各留一条结论 → 无遗漏维度
- 逐条核对 blocker → 每条都有修复建议
- 受影响路径的 `typecheck → lint → test` → 附输出关键行

## Exit Criteria

- [ ] 六维逐维过完，各留一条结论
- [ ] findings 按 blocker / warning / nit 分级，每条带 `文件:行号`
- [ ] blocker 全部附修复建议
- [ ] 报告头写明评审范围、深度与是否运行了检查