| name | code-review |
| description | 代码审查（编排型 skill）。按分层规范审查当前改动，输出分级问题清单 + 修复建议。覆盖 Controller/Service/DAO/日志/异常/通用项，红灯必改黄灯建议改。引用 rules/ 下的规范文件作为依据。 |
| license | MIT |
| metadata | {"author":"Johnson","version":"1.0"} |
代码审查技能（编排型 skill · 按规范审查改动）
对当前改动（git diff）按分层规范做代码审查，输出分级问题清单和修复建议。
这是「编排型 skill」的范例——和工具型（sql-query 连库查数据）不同，编排型 skill 不自己实现功能，而是编排「读 diff → 按规范逐项检查 → 输出结构化报告 → 询问是否修复」这个流程。价值在把团队的审查 checklist 固化成 AI 可执行的步骤，规范依据来自 rules/ 下的 rule 文件。
输入
- 审查范围（可选）：当前文件 / 当前分支所有改动 / 指定文件路径。默认当前改动。
执行步骤
1. 获取改动
git status
git diff
git diff --cached
2. 按分层逐项检查
下方「规范依据」对应 .claude/rules/ 下的文件。严重程度：🔴 高（必改）/ 🟡 中（建议改）/ 🟢 低（提示）。
Controller 层
| 检查项 | 规范依据 | 严重 |
|---|
| 返回值是否用统一响应模型包装 | api-response.md | 🔴 |
| 是否只做参数校验 + 调 Service | service-dao.md | 🔴 |
| 是否含业务逻辑 | service-dao.md | 🔴 |
| 是否直接调 DAO | service-dao.md | 🔴 |
| 是否在 Controller 加 @Transactional | service-dao.md | 🔴 |
| 方法是否过长（> 30 行） | — | 🟡 |
| URL / 路由命名是否符合规范 | naming.md | 🟡 |
Service 层
| 检查项 | 规范依据 | 严重 |
|---|
| 接口与实现是否分离（接口在 API 模块） | naming.md | 🔴 |
| @Transactional 是否 rollbackFor = Exception.class | service-dao.md | 🔴 |
| 事务方法是否为 public、未被同类自调用 | service-dao.md | 🔴 |
| 事务内是否调外部 HTTP / RPC / 发 MQ | service-dao.md | 🔴 |
| Service 实现里是否写 SQL（应归 DAO） | service-dao.md | 🟡 |
DAO 层
| 检查项 | 规范依据 | 严重 |
|---|
是否用 SELECT *（应明确列字段） | service-dao.md | 🔴 |
| 是否循环内执行 SQL（N+1） | batch.md | 🔴 |
| IN 子句是否用命名参数 | batch.md | 🟡 |
| IN 子句是否超 500 未分批 | batch.md | 🟡 |
| 是否含业务逻辑判断（应归 Service） | service-dao.md | 🔴 |
日志
| 检查项 | 规范依据 | 严重 |
|---|
是否用 System.out.println | logging.md | 🔴 |
是否用 e.printStackTrace() | logging.md | 🔴 |
| 是否打印敏感信息（密码 / token / 身份证） | logging.md | 🔴 |
| 是否用字符串拼接而非占位符 | logging.md | 🟡 |
日志前缀是否规范（[ClassName]） | logging.md | 🟢 |
异常处理
| 检查项 | 规范依据 | 严重 |
|---|
| 是否空 catch 块 | error-handling.md | 🔴 |
| catch 后是否只打日志不处理（不返回 / 不重抛） | error-handling.md | 🔴 |
是否直接抛 RuntimeException（应业务异常） | error-handling.md | 🟡 |
| Controller 是否对异常做了合理响应 | api-response.md | 🟡 |
批量操作（改动涉及循环 / 集合时）
| 检查项 | 规范依据 | 严重 |
|---|
| 循环内是否单条查询 / 更新 | batch.md | 🔴 |
| 循环内是否调 Service（应直接 DAO） | batch.md | 🔴 |
| 大批量是否分批（每 500） | batch.md | 🟡 |
通用
| 检查项 | 严重 |
|---|
| 未使用的 import | 🟢 |
| 注释掉的废弃代码 | 🟡 |
| 硬编码 IP / 密码 / 密钥 | 🔴 |
| TODO / FIXME 未处理 | 🟢 |
3. 输出格式
## 代码审查报告
### 概览
- 检查文件数：X 个
- 问题总数：Y 个
- 🔴 高危：A
- 🟡 中等：B
- 🟢 建议：C
### 🔴 高危问题（必须修复）
| 文件 | 行号 | 问题描述 | 规范依据 | 修复建议 |
|------|------|----------|----------|----------|
| XxxController.java | 45 | Controller 含业务逻辑 | service-dao.md | 将逻辑移至 Service |
### 🟡 中等问题（建议修复）
| 文件 | 行号 | 问题描述 | 规范依据 | 修复建议 |
|------|------|----------|----------|----------|
| XxxServiceImpl.java | 78 | 日志未用占位符 | logging.md | 改为 log.info("x={}", v) |
### 🟢 改进建议
| 文件 | 建议 |
|------|------|
| XxxDAO.java | 建议补批量查询方法 |
### 通过项
- 响应包装：通过
- 事务使用：通过
- ...
4. 交互确认
报告输出后询问：
- 是否自动修复可修复的问题？
- 是否查看某个问题的详细说明？
设计要点
- 依据可追溯：每条问题挂「规范依据」，指向
rules/ 具体文件——AI 不是凭感觉挑刺，是按团队成文规范审。
- 分级：红灯必改（架构 / 安全 / 性能），黄灯建议，绿灯提示。避免把所有问题堆成一锅。
- 编排型不自己写规则：检查项的「标准」由 rule 文件定义，skill 只负责「跑流程」。团队加新规范时改 rule，不改 skill。
- 可裁剪：没有对应 rule 文件的项目，删掉对应检查项即可；新增分层（如前端组件）按同表格扩展。
相关：rules/ 下各分层 rule 文件（api-response / service-dao / batch / naming / git-branch / logging / error-handling）。
