Menu
代码审查（编排型 skill）。按分层规范审查当前改动，输出分级问题清单 + 修复建议。覆盖 Controller/Service/DAO/日志/异常/通用项，红灯必改黄灯建议改。引用 rules/ 下的规范文件作为依据。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
多 Agent 并行编排 skill。一条命令拉起团队做完复杂任务:环境检测→分析蓝图→确认→并行执行→质量验收→交付。编排 Claude Code 原生 Agent 工具,自己不实现业务逻辑。触发:/agent-teams,或 多agent/拉团队/并行/跨项目/分工协作 等关键词。
会话记忆(记忆型 skill)。长对话/超长任务超出上下文时,结构化压缩历史,保留用户纠正与关键决策。触发:对话太长要续接/上下文要清/跨会话记关键。
品牌合规(规范型 skill)。生成或检查 UI/文档是否符合品牌色卡与字体规范。触发:做页面/海报/PPT/组件时检查品牌一致性。含校验器,违规即报。
性能诊断(诊断型 skill·只读)。定位慢 SQL、内存热点、接口耗时,给结论与建议。触发:慢查询/接口卡/内存高/CPU 飙时排查根因。只读不改动系统。
CRUD 代码脚手架（工具型 skill）。读数据库表结构，一键生成分层 CRUD 代码（domain/dto/service/dao/controller）。通用分层范式，DAO 层按你的 ORM 适配。
开发工作流 skill。一条命令从需求到交付：需求探索 → 规范生成 → 计划拆分 → TDD 执行 → 验证 → 归档。编排 OpenSpec 和 Superpowers 两个框架，不重新实现任何逻辑。
| name | code-review |
| description | 代码审查（编排型 skill）。按分层规范审查当前改动，输出分级问题清单 + 修复建议。覆盖 Controller/Service/DAO/日志/异常/通用项，红灯必改黄灯建议改。引用 rules/ 下的规范文件作为依据。 |
| license | MIT |
| metadata | {"author":"Johnson","version":"1.0"} |
对当前改动（git diff）按分层规范做代码审查，输出分级问题清单和修复建议。
这是「编排型 skill」的范例——和工具型（sql-query 连库查数据）不同，编排型 skill 不自己实现功能，而是编排「读 diff → 按规范逐项检查 → 输出结构化报告 → 询问是否修复」这个流程。价值在把团队的审查 checklist 固化成 AI 可执行的步骤，规范依据来自
rules/下的 rule 文件。
git status
git diff # 已暂存 + 未暂存
git diff --cached # 仅已暂存
下方「规范依据」对应
.claude/rules/下的文件。严重程度：🔴 高（必改）/ 🟡 中（建议改）/ 🟢 低（提示）。
| 检查项 | 规范依据 | 严重 |
|---|---|---|
| 返回值是否用统一响应模型包装 | api-response.md | 🔴 |
| 是否只做参数校验 + 调 Service | service-dao.md | 🔴 |
| 是否含业务逻辑 | service-dao.md | 🔴 |
| 是否直接调 DAO | service-dao.md | 🔴 |
| 是否在 Controller 加 @Transactional | service-dao.md | 🔴 |
| 方法是否过长（> 30 行） | — | 🟡 |
| URL / 路由命名是否符合规范 | naming.md | 🟡 |
| 检查项 | 规范依据 | 严重 |
|---|---|---|
| 接口与实现是否分离（接口在 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 | 🟡 |
| 检查项 | 规范依据 | 严重 |
|---|---|---|
是否用 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 未处理 | 🟢 |
## 代码审查报告
### 概览
- 检查文件数：X 个
- 问题总数：Y 个
- 🔴 高危：A
- 🟡 中等：B
- 🟢 建议：C
### 🔴 高危问题（必须修复）
| 文件 | 行号 | 问题描述 | 规范依据 | 修复建议 |
|------|------|----------|----------|----------|
| XxxController.java | 45 | Controller 含业务逻辑 | service-dao.md | 将逻辑移至 Service |
### 🟡 中等问题（建议修复）
| 文件 | 行号 | 问题描述 | 规范依据 | 修复建议 |
|------|------|----------|----------|----------|
| XxxServiceImpl.java | 78 | 日志未用占位符 | logging.md | 改为 log.info("x={}", v) |
### 🟢 改进建议
| 文件 | 建议 |
|------|------|
| XxxDAO.java | 建议补批量查询方法 |
### 通过项
- 响应包装：通过
- 事务使用：通过
- ...
报告输出后询问：
rules/ 具体文件——AI 不是凭感觉挑刺，是按团队成文规范审。相关：
rules/下各分层 rule 文件（api-response / service-dao / batch / naming / git-branch / logging / error-handling）。