code-review

代码审查

概述

依据原始计划、编码标准和已学习的项目模式进行全面代码审查。此技能会调度专门的代码审查 Agent 进行全面分析，确保每项更改在合并到主分支前都有依据、符合计划且遵循约定。

开始时宣布：“我将使用代码审查技能来审查实现。”

---

阶段 1：收集上下文

**目标：**确定更改内容、计划要求以及适用的约定。

操作

1. 获取要审查的更改：

git diff HEAD~N..HEAD          # or specific commit range
git log --oneline HEAD~N..HEAD # what was done

2. 定位计划文档：

ls docs/plans/*.md | tail -1

3. 从 memory/learned-patterns.md 加载项目约定

4. 确定：

   • 哪些文件发生了更改
   • 计划／规范要求了什么
   • 适用哪些约定

停止 — 在进入阶段 2 前，请勿继续：

• 已确定所有更改的文件
• 已加载计划或规范要求
• 已从记忆中加载相关约定
• 能够说明原本要构建什么

---

阶段 2：调度代码审查员

**目标：**向 code-reviewer Agent 发送结构化审查请求。

审查提示词模板

Review the following changes against:
1. Plan: [plan document or requirements]
2. Conventions: [learned patterns from memory]
3. Standards: [CLAUDE.md rules]

Changes:
[git diff output or file list]

Check for:
- Plan alignment (did we build what was specified?)
- Code quality (DRY, YAGNI, naming, structure)
- Error handling (edge cases, failure modes)
- Security (injection, XSS, auth issues)
- Test coverage (are changes tested?)
- Performance (obvious bottlenecks)
- Documentation (are public APIs documented?)

停止 — 在进入阶段 3 前，请勿继续：

• 已发送审查请求
• 审查 Agent 已返回审查结果

---

阶段 3：分类并解决问题

**目标：**对审查结果进行分类，并修复所有严重问题。

问题分类表

类别	定义	所需操作
严重	Bug、安全问题、数据丢失风险、违反计划	合并前必须修复
重要	代码质量问题、缺少测试、违反约定	合并前应修复
建议	风格、命名、小幅改进	有则更好，时间允许时修复

修复循环

针对严重和重要问题：

1. 修复问题
2. 运行测试以验证修复
3. 针对具体修复重新调度代码审查 Agent
4. 重复以上步骤，直至不再有严重问题

停止 — 在进入阶段 4 前，请勿继续：

• 所有严重问题均已解决
• 所有重要问题均已解决，或已明确说明延期理由
• 所有修复完成后，测试套件通过

---

阶段 4：整合自我学习

**目标：**保存审查过程中发现的模式，供后续会话使用。

操作

1. 如果发现了新模式，更新 memory/learned-patterns.md
2. 如果发现常见错误，将其记录下来以供日后参考
3. 如果计划需要调整，更新 memory/decisions-log.md

---

审查输出格式

## Code Review Summary

**Scope:** [files/components reviewed]
**Plan alignment:** [aligned / minor deviations / major deviations]

### Critical Issues (N)
1. **[Issue title]** — `file:line`
   Problem: [description]
   Fix: [specific recommendation]

### Important Issues (N)
1. **[Issue title]** — `file:line`
   Problem: [description]
   Fix: [specific recommendation]

### Suggestions (N)
1. **[Suggestion]** — `file:line`

### What Was Done Well
- [Positive observations]

---

决策表：审查深度

更改类型	审查深度	审查者
新功能（>100 行）	全面审查：计划符合度 + 质量 + 安全性 + 测试	code-reviewer Agent
Bug 修复（<50 行）	聚焦审查：回归测试 + 根本原因 + 修复正确性	code-reviewer Agent
重构（行为不变）	行为保持：所有测试通过 + 无回归问题	code-reviewer Agent
配置／基础设施更改	安全性 + 正确性：未暴露机密，语法有效	code-reviewer Agent
仅文档更改	准确性 + 完整性：与当前代码行为一致	行内审查

---

反模式 / 常见错误

反模式	错误原因	正确做法
跳过“小修复”的审查	小改动也可能导致生产环境故障	审查所有内容
不看计划就进行审查	没有需求就无法验证正确性	始终先加载计划
修复问题后不重新运行测试	修复可能引入新错误	每次修复后运行完整测试套件
给出笼统反馈（“看起来不错”）	不具备可操作性，也会漏掉真正的问题	指出具体代码行并给出修复建议
只审查自己的代码	作者容易对缺陷视而不见	始终派遣 code-reviewer Agent
将严重问题留待以后处理	严重问题会演变成生产事故	合并前必须修复，不得例外

---

自我开脱——有以下想法时立即停止

借口	事实
“只是修个拼写错误”	拼写修复可能破坏 API。请审查。
“我对这段代码很有信心”	信心不等于正确。请审查。
“测试通过了”	测试可能漏掉错误。请审查。
“只是样式／格式调整”	样式更改可能引入错误。请审查。
“没人会注意到”	错误往往就是在这种情况下被带入发布版本。请审查。
“我稍后再审查”	稍后永远不会到来。现在就审查。
“截止时间很紧”	发布错误造成的代价高于审查。请审查。

---

子 Agent 派遣机会

任务模式	派遣给	时机
审查多个相互独立的文件／模块	使用 Agent 工具并设置 subagent_type="Explore"	当审查范围涉及多个无关模块时
专注安全的审查	使用 Agent 工具调用 security-review 技能	当更改涉及身份验证、输入处理或外部 API 时
评估性能影响	使用 Agent 工具调用 performance-optimization 技能	当更改影响热点路径或数据密集型操作时

派遣时遵循 dispatching-parallel-agents 技能协议。

---

集成点

技能	关系
planning	审查会根据已批准的计划检查实现
test-driven-development	审查会验证测试覆盖率和 TDD 合规性
verification-before-completion	审查是验证的前提
self-learning	审查发现会反馈到已学习的模式中
acceptance-testing	审查会检查是否为所有标准编写了验收测试
systematic-debugging	如果审查发现错误，请切换到调试技能
security-review	审查期间发现安全问题时，应进行更深入的安全分析

---

铁律

┌─────────────────────────────────────────────────────────────────┐
│  HARD-GATE: NO MERGE WITHOUT REVIEW                            │
│                                                                 │
│  Every change gets reviewed. No exceptions for "small fixes"   │
│  or "obvious changes." If you are about to merge without       │
│  review, STOP immediately.                                     │
└─────────────────────────────────────────────────────────────────┘

---

技能类型

RIGID — 必须执行四阶段流程。每项更改都必须由 code-reviewer Agent 审查。未经审查不得合并。不得例外。