| name | pm-code-review |
| displayName | Code Review |
| displayDescription | 代码审查 |
| description | Review code changes for security, logic, and performance. Trigger when user says 'code review', '代码审查', '代码检查', 'review code', or after code implementation is done. |
| user-invocable | true |
| argument-hint | [代码变更描述或文件路径] |
代码审查
如果是子代理派发执行此 Skill，直接按下方指令执行，不重新加载入口 Skill。
独立审查代码变更，发现安全、逻辑和性能问题。审查是质量最后一道门——放过的 bug 会在生产环境十倍代价地回来。
核心原则：审查者不等于实现者。
Iron Law（铁律）
| 铁律 | 违反后果 |
|---|
| 审查者 ≠ 实现者 | 同一人的代码必须由另一视角审查——如果只有一个人，至少隔 30 分钟后以审查者身份重新审视 |
| 每个问题必须有 severity + suggestion | 无 severity 的问题不计入审查结果——补全后重新计数 |
| 审查结论只有 APPROVE / REQUEST_CHANGES | 没有"看起来还行"——要么通过，要么打回 |
反合理化
| 你可能在想的 | 真相 |
|---|
| "代码能跑就行" | 能跑 ≠ 正确——边界情况、错误处理、性能坑不会在正常流程暴露 |
| "这个问题太小了不用说" | 小问题积累成大故障——severity 区分优先级，但不说 = 不存在 |
| "我不确定这是不是问题" | 不确定也要标注为 suggestion——让作者判断，比漏掉好 |
| "实现者经验丰富，应该没问题" | 经验丰富的人也会犯低级错误——审查不看人，看代码 |
输入
| 输入项 | 来源 | 必须？ |
|---|
| 代码变更 diff | git diff / 用户提供的文件 | 是 |
| 原始需求 | PRD / 任务描述 | 推荐 |
| 项目 CLAUDE.md | Read | 推荐 |
审查维度
| 维度 | 检查内容 | 重点关注 |
|---|
| 安全 | 注入、XSS、认证、敏感数据泄露 | 用户输入处理、API 调用、.env 引用 |
| 逻辑 | 边界情况、错误处理、空值处理 | if/else 分支覆盖、try/catch、null check |
| 性能 | N+1 查询、内存泄漏、不必要的重渲染 | 循环内查询、useEffect 依赖、大列表渲染 |
| 可维护性 | 命名、函数长度、重复代码 | 变量命名自解释、函数 ≤ 50 行、DRY |
| 一致性 | 代码风格与项目已有代码一致 | 导入顺序、命名约定、错误处理模式 |
执行流程
触发 pm-code-review
├── 1. 获取变更
│ ├── 读取 git diff（或用户提供的文件）
│ ├── 读取原始需求（理解变更意图）
│ └── 读取项目 CLAUDE.md（理解项目约束）
├── 2. 逐文件审查
│ ├── 安全扫描（注入、XSS、敏感数据）
│ ├── 逻辑审查（边界、错误处理、空值）
│ ├── 性能检查（N+1、内存、渲染）
│ ├── 可维护性评估（命名、长度、重复）
│ └── 一致性比对（与项目已有风格对比）
├── 3. 问题分类
│ ├── critical — 必须修复才能合并
│ ├── major — 强烈建议修复
│ ├── minor — 建议修复但不阻塞
│ └── suggestion — 改进建议，可选
├── 4. 产出审查报告
│ ├── verdict（APPROVE / REQUEST_CHANGES）
│ ├── issues 列表（severity + file + line + description + suggestion）
│ └── summary（总体评价）
└── 5. 交付
├── APPROVE → 建议后续行动
└── REQUEST_CHANGES → 指向 pm-code-implement 修复
输出规范（enforced schema）
审查报告必须遵循以下结构：
## 审查结论: [APPROVE / REQUEST_CHANGES]
### 问题列表
| # | Severity | 文件 | 行号 | 问题描述 | 修复建议 |
| --- | --- | --- | --- | --- | --- |
| 1 | critical | src/api/auth.ts | L42 | 密码明文存储 | 使用 bcrypt 加密后存储 |
| 2 | minor | src/hooks/useData.ts | L15 | useEffect 缺少依赖 | 添加 missing dependency |
| 3 | suggestion | src/utils/format.ts | - | 考虑提取为共享工具函数 | 移至 shared/utils/ |
### 总结
[2-3 句总体评价：变更质量、主要风险点、正面发现]
Severity 定义
| Severity | 标准 | 处理要求 |
|---|
| critical | 安全漏洞、数据丢失风险、生产故障风险 | 必须 fix 后才能合并 |
| major | 逻辑错误、性能问题、重要边界未处理 | 强烈建议 fix，合并前解决 |
| minor | 代码风格、命名、小优化 | 建议修复，不阻塞合并 |
| suggestion | 改进思路、架构优化方向 | 可选，供参考 |
交付前检查
后续推荐
| 场景 | 推荐 Skill |
|---|
| REQUEST_CHANGES 后修复 | pm-code-implement |
| 发现架构层面问题 | pm-code-architect |
| 发现安全漏洞 | 立即告知用户，不走 Skill |
Metadata
track: engineering
depends_on: [pm-code-implement]
schema_type: enforced
persist_to: []
guardrails:
- 不编造代码中不存在的问题
- severity 必须是 critical / major / minor / suggestion 之一
- 每个 issue 必须包含 severity + file + line + description + suggestion
- 审查结论只有 APPROVE 或 REQUEST_CHANGES
- critical/major ≥ 1 时结论必须为 REQUEST_CHANGES
