| name | deep-review |
| description | Multi-agent parallel code review (security + logic + architecture) for local changes or a PR |
| argument-hint | [PR number, PR URL, or empty for local changes] |
Review: 多维度并行代码审查
对代码变更进行全面审查,使用多个 agent 并行覆盖不同审查维度。
确定审查范围
根据 $ARGUMENTS 决定审查目标:
无参数时(本地变更)
按优先级选择审查范围:
- 未提交的变更(staged + unstaged + untracked):
- 运行
git diff HEAD 查看 tracked 文件的变更
- 运行
git ls-files --others --exclude-standard 发现 untracked 新文件,将其完整内容也纳入审查
- 如果有任何变更或新文件,则审查这些内容
- 最近一次 commit:如果没有未提交变更,运行
git diff HEAD~1..HEAD 审查最近一个 commit
边界处理:
- 先运行
git rev-list --count HEAD 2>/dev/null 检查 commit 数量
- 如果命令失败(无 commit),提示用户"仓库尚无 commit,无内容可审查"
- 如果只有 1 个 commit 且无未提交变更,用
git show HEAD 代替 git diff HEAD~1..HEAD
用 git status 确认当前状态,告知用户审查的是哪个范围。
有参数时(审查 PR)
参数可以是:
- PR 编号:
/review 4 → gh pr diff 4,gh pr view 4
- PR URL:
/review https://github.com/org/repo/pull/4 → 提取编号后同上
用 gh pr diff 获取完整 diff,用 gh pr view 了解 PR 意图。
参数校验:如果 $ARGUMENTS 既不是有效的正整数,也无法从 URL 中提取 PR 编号(格式应为 https://github.com/{owner}/{repo}/pull/{number}),则告知用户参数无效并给出正确用法示例:/review 4 或 /review https://github.com/org/repo/pull/4。
多 Agent 并行审查
使用 TeamCreate 创建审查团队,启动 3 个并行 agent,每个专注一个维度。
给每个 agent 的共同上下文:
- CLAUDE.md 的内容(项目架构、模式、技术栈)
- 完整的 diff 内容
- 变更涉及的文件列表
Agent 1: 🔒 安全审查 (security-reviewer)
检查项:
- 命令注入、SQL 注入、XSS 等注入风险
- 密钥/凭据泄露(.env、API key、token 硬编码)
- 不安全的权限配置
- 缺少输入校验(尤其是系统边界:用户输入、外部 API)
- 不安全的依赖使用
Agent 2: 🐛 逻辑与正确性审查 (logic-reviewer)
检查项:
- 逻辑错误、off-by-one、空值/undefined 访问
- 竞态条件、未处理的 Promise rejection
- 错误处理遗漏或不当(catch 吞异常、错误类型丢失)
- 资源泄漏(未关闭连接、未清理事件监听、定时器泄漏)
- 边界条件和异常路径
Agent 3: 🏗️ 架构与质量审查 (architecture-reviewer)
检查项:
- 是否符合 CLAUDE.md 中描述的项目模式(ESM
.js 后缀、单例模式、两阶段消息等)
- TypeScript 类型安全(不安全的
any、错误的泛型、async/await 陷阱)
- 模块边界是否清晰,是否有循环依赖
- 命名一致性、代码组织
- 是否过度工程或缺少必要抽象
每个 Agent 的输出格式
每个 agent 必须对发现的每个问题标注:
- 严重程度:🔴 Critical / 🟡 Warning / 🔵 Info
- 置信度:0-100 分
- 文件和行号:
path/to/file.ts:42
- 问题描述:简洁说明问题
- 建议修复:给出具体的代码修改建议
置信度规则(参考 GitHub Action 标准):
- 90-100:确定的 bug 或安全问题
- 75-89:高度确信,很可能是真实问题
- 50-74:中等置信,值得提及
- 低于 50 的不报告(噪音太大)
误报过滤(以下情况不报告):
- PR/变更之前就存在的问题
- 代码风格偏好或 nitpick
- linter/formatter 会自动处理的问题
- 不言自明的代码缺少注释
- 假设性的未来问题
- 代码"可以更好"但当前实现正确
汇总审查结果
收集所有 agent 的结果后,汇总成一份报告:
## 📋 Code Review 总结
**审查范围**:<描述审查了什么>
**总体评价**:✅ Approved / ⚠️ Issues Found / 🚫 Changes Requested
### 发现问题
#### 🔴 Critical
- [security-reviewer] `path/file.ts:42` — 描述 (置信度: 95)
#### 🟡 Warning
- [logic-reviewer] `path/file.ts:88` — 描述 (置信度: 80)
#### 🔵 Info
- [architecture-reviewer] `path/file.ts:15` — 描述 (置信度: 60)
### 亮点
- <变更中做得好的地方>
### 建议
- <改进建议>
判定标准:
- 有任何 🔴 Critical → 🚫 Changes Requested
- 只有 🟡 Warning → ⚠️ Issues Found
- 只有 🔵 Info 或无问题 → ✅ Approved
注意事项
- 每个 agent 必须 阅读完整源文件,不能只看 diff 片段
- 用
git blame 和 git log 了解变更历史和上下文
- 审查要基于事实,引用具体代码行,不要猜测
- 对每个问题给出可操作的修复建议,不要只说"这不好"