Agent skill
super-review
Use when user requests code review with multiple perspectives, wants parallel review from different models, or uses trigger words: super-review, 超级审查, 并行审查, 全面 review
Install this agent skill to your Project
npx add-skill https://github.com/majiayu000/claude-skill-registry/tree/main/skills/development/super-review-zuozuo-super-review
SKILL.md
Super Review
使用 Claude Code 原生 subagent 并发能力进行多模型并行审查。
核心能力
- 并发启动多个 reviewer(Claude Code opus/sonnet/haiku、Codex、Gemini CLI)
- 智能选择 prompt 模板
- 结果去重、分级、汇总
- 只关注 P0/P1 问题
执行流程
1. 确定审查内容
优先级:
- 用户明确指定(文件/目录/commit/commit 范围)
- 智能推断:
- 检查 staged changes:
git diff --cached --name-only - 检查最近 commit:
git log -1 --format=%H - 如都无,询问用户
- 检查 staged changes:
推断逻辑:
# 检查 staged changes
staged=$(git diff --cached --name-only)
if [ -n "$staged" ]; then
echo "发现 staged changes,建议审查这些变更"
fi
# 检查最近 commit
last_commit=$(git log -1 --format=%H 2>/dev/null)
if [ -n "$last_commit" ]; then
echo "发现最近 commit: $last_commit"
fi
推断后必须向用户确认:
- "检测到有 staged changes,是否审查这些变更?"
- "检测到最近的 commit [hash],是否审查该 commit?"
2. 收集背景信息
从以下来源提取业务背景:
- 用户在 prompt 中的描述
- commit messages(如审查 commit)
- PR 描述(如有)
- 相关文档(CLAUDE.md、README.md、docs/ 目录)
整理为结构化背景:
- purpose:这次修改要实现什么目标
- scope:修改范围概述
- requirements:具体需求或约束
- related_docs:相关文档路径列表
获取 commit message 示例:
# 单个 commit
git log -1 --format=%B <commit-id>
# 多个 commit
git log --format="- %s" HEAD~3..HEAD
注意:背景信息是业务层面的(做什么、为什么),不是技术层面的(用什么语言、框架),技术信息 reviewer 自己从代码中获取。
2.5 检查固定文档路径
固定路径规范(项目纪律):
| 文档类型 | 固定路径 | 说明 |
|---|---|---|
| UI 设计规范 | docs/design/ui-spec.md |
前端 UI 一致性审查的参照 |
| 设计文档 | docs/design/ |
架构设计、技术设计 |
| 开发计划 | docs/plans/ |
开发计划、实现方案 |
检查步骤:
- 检查变更是否涉及前端文件(.tsx, .jsx, .vue, .css, .scss 等)
- 如果涉及前端,检查
docs/design/ui-spec.md是否存在 - 检查
docs/design/和docs/plans/目录是否存在设计文档 - 如果必要文档缺失,向用户确认是否继续
用户确认场景:
┌────────────────────────────────────────┐
│ ⚠️ 文档路径检查 │
├────────────────────────────────────────┤
│ 发现前端文件变更,但缺少 UI 规范: │
│ - docs/design/ui-spec.md (不存在) │
│ │
│ 将跳过 UI 一致性审查阶段。继续? │
├────────────────────────────────────────┤
│ [继续] [取消] │
└────────────────────────────────────────┘
2.6 确定审查范围
范围来源优先级:
| 优先级 | 来源 | 场景 |
|---|---|---|
| 1 | 外部注入 (--context) |
Workflow 调用 |
| 2 | 自主推断 | 用户手动调用 |
自主推断信息来源:
| 优先级 | 来源 | 提取的信息 |
|---|---|---|
| 1 | Commit message / PR description | 本次变更的目标 |
| 2 | docs/plans/ 开发计划文档 |
当前阶段、任务范围 |
| 3 | docs/design/ 设计文档 (PRD/架构) |
参照物,用于一致性审查 |
| 4 | 代码变更涉及的目录结构 | 推断影响的模块 |
推断步骤:
-
从 commit message 提取目标:
bashgit log -1 --format=%B HEAD -
查找相关计划文档:
bash# 查找最近修改的计划文档 ls -t docs/plans/*.md 2>/dev/null | head -3 -
查找相关设计文档:
bash# 根据变更文件路径推断相关设计文档 # 例如:src/auth/ 变更 → 查找 docs/design/auth*.md -
分析变更涉及的目录:
bashgit diff --name-only HEAD~1..HEAD | xargs dirname | sort -u
审查范围结构:
review_scope:
objective: "本次变更的目标"
includes:
- "包含的功能点1"
- "包含的功能点2"
excludes:
- "明确不在范围内的内容"
reference_docs:
- "docs/design/xxx.md"
- "docs/plans/xxx.md"
2.7 确认审查范围
执行模式:
| 调用方式 | 行为 |
|---|---|
super-review HEAD |
推断范围 → 展示确认 → 执行 |
super-review HEAD --skip-confirm |
推断范围 → 直接执行 |
super-review HEAD --context:{...} |
使用注入范围 → 直接执行 |
默认模式(需确认):
推断完成后,向用户展示范围摘要并等待确认:
┌────────────────────────────────────────┐
│ 📋 审查范围 │
├────────────────────────────────────────┤
│ 目标: {{scope.objective}} │
│ 参照: {{scope.reference_docs}} │
│ 不含: {{scope.excludes}} │
├────────────────────────────────────────┤
│ [确认执行] [修正范围] [取消] │
└────────────────────────────────────────┘
跳过确认的场景:
- 用户明确指定
--skip-confirm - 通过
--context注入完整范围 - 在 Workflow 中被调用(检测到上下文)
注入范围格式示例:
super-review HEAD --context:'{"objective":"实现登录API","includes":["登录端点","JWT验证"],"excludes":["密码找回"],"reference_docs":["docs/design/auth.md"]}'
3. 读取配置
从 .reviews/config.yaml 读取配置。如不存在,使用默认配置。
配置文件格式:
output_dir: .reviews
default_timeout: 300
reviewers:
# Claude 系列:通过 Task tool 启动,无需 command 配置
claude-opus:
enabled: true
timeout: 300
claude-sonnet:
enabled: true
timeout: 300
claude-haiku:
enabled: true
timeout: 300
# 外部 CLI:通过 Bash tool 调用,需要 command 配置
codex:
enabled: true
timeout: 300
# command 可选,有默认值
gemini:
enabled: true
timeout: 300
# command 可选,有默认值
# 外部 CLI(ccs + claude -p):通过上下文切换使用其他 LLM
gemini-cc:
enabled: true
timeout: 300
# command: "$(ccs gemini) && claude -p --dangerously-skip-permissions '{{prompt}}'"
glm-cc:
enabled: true
timeout: 300
# command: "$(ccs glm) && claude -p --dangerously-skip-permissions '{{prompt}}'"
prompts:
my-custom:
path: .reviews/prompts/my-custom.md
默认配置(当 config.yaml 不存在时):
| Reviewer | 默认启用 | 超时 | 启动方式 |
|---|---|---|---|
| claude-opus | ✅ | 300s | Task tool (subagent) |
| claude-sonnet | ✅ | 300s | Task tool (subagent) |
| claude-haiku | ✅ | 300s | Task tool (subagent) |
| codex | ✅ | 300s | Bash tool (CLI) |
| gemini | ✅ | 300s | Bash tool (CLI) |
| gemini-cc | ✅ | 300s | Bash tool (ccs gemini + claude -p) |
| glm-cc | ✅ | 300s | Bash tool (ccs glm + claude -p) |
注意:Claude 系列使用 Claude Code 原生 subagent,不需要 CLI 命令配置。
3.5 前置检查 - CLI 工具可用性
在启动 reviewer 前,检查外部 CLI 工具是否存在。
注意:Claude 系列(opus/sonnet/haiku)使用 Task tool 启动,无需检查 CLI。
检查方法(仅外部 CLI):
# 检查 codex CLI
which codex >/dev/null 2>&1 && echo "codex: OK" || echo "codex: NOT FOUND"
# 检查 gemini CLI
which gemini >/dev/null 2>&1 && echo "gemini: OK" || echo "gemini: NOT FOUND"
# 检查 ccs (context switch) 命令
which ccs >/dev/null 2>&1 && echo "ccs: OK" || echo "ccs: NOT FOUND"
# 检查 claude CLI
which claude >/dev/null 2>&1 && echo "claude: OK" || echo "claude: NOT FOUND"
处理逻辑:
| Reviewer 类型 | 检查方式 | 不可用时处理 |
|---|---|---|
| Claude 系列 | 无需检查(始终可用) | - |
| codex | which codex |
跳过,标记 skipped (CLI not found) |
| gemini | which gemini |
跳过,标记 skipped (CLI not found) |
| gemini-cc | which ccs && which claude |
跳过,标记 skipped (CLI not found) |
| glm-cc | which ccs && which claude |
跳过,标记 skipped (CLI not found) |
- enabled: false → 跳过该 reviewer
- 至少需要一个可用的 reviewer,否则报错退出(Claude 系列始终可用,所以这种情况不会发生)
4. 选择 Prompt 模板
V2 变更:使用统一审查模板
不再根据内容类型选择不同模板,统一使用 unified-review.md。
模板位置: ~/.claude/skills/super-review/prompts/unified-review.md
模板特点:
- 三阶段审查:一致性审查 → UI 一致性审查 → 探索性审查
- 三评分:compliance_score + ui_compliance_score + quality_score
- 自适应:reviewer 根据内容类型自行判断适用的审查维度
旧模板保留: prompts/ 目录下的其他模板暂时保留,用于特定类型审查。
模板选择逻辑:
| 审查内容类型 | 模板 |
|---|---|
| 代码/Commit | unified-review.md(三阶段审查) |
| PRD 文档 | prd.md |
| 教程文档 | beginner-tutorial.md 或 expert-tutorial-review.md |
| UI 设计稿(独立审查) | ui-compliance.md |
5. 创建结果目录
目录命名格式:
.reviews/<content_name>_<YYYYMMDD_HHMMSS>/
命名规则:
- 文件:使用文件名(去除路径和扩展名)
- 目录:使用目录名
- commit:使用 commit message 前 20 字符(中文友好)
- 多文件/多 commit:使用 "multi" 或主题词
示例:
.reviews/login_20251228_143052/
.reviews/src_auth_20251228_150000/
.reviews/fix_用户登录_20251228_160000/
创建目录:
review_dir=".reviews/${content_name}_$(date +%Y%m%d_%H%M%S)"
mkdir -p "$review_dir"
6. 并发启动 Reviewers
⚠️ 关键理解:两类 Reviewer 使用不同的启动方式
| Reviewer 类型 | 启动方式 | 工具 | 说明 |
|---|---|---|---|
| Claude 系列 (opus/sonnet/haiku) | Task tool | Claude Code 原生 subagent | 高效,无需 CLI |
| 外部 CLI (codex/gemini) | Bash tool | 调用外部 CLI 命令 | 必须用 Bash |
强制要求:所有 reviewer 必须在单个消息中并行启动!
这意味着你需要在一个响应中同时发起:
- 多个 Task tool 调用(用于 Claude 系列)
- 多个 Bash tool 调用(用于 codex/gemini)
6.1 Claude 系列 Reviewer(Task tool)
对于 claude-opus、claude-sonnet、claude-haiku,使用 Task tool 启动 subagent:
Task tool 参数:
subagent_type: "general-purpose"
model: "opus" # 或 "sonnet" / "haiku"
prompt: |
你是一个代码审查专家,请对以下内容进行审查。
## 审查目标
类型:{{review_target.type}}
目标:{{review_target.value}}
## 审查范围
目标:{{review_scope.objective}}
包含:{{review_scope.includes}}
不含:{{review_scope.excludes}}
## 项目文档路径(固定规范)
- UI 设计规范: docs/design/ui-spec.md
- 设计文档目录: docs/design/
- 开发计划目录: docs/plans/
## 审查流程
### Phase 1: 一致性审查
参照 docs/design/ 或 docs/plans/ 中的设计文档:
1. 读取相关设计文档,提取设计要点清单
2. 逐项核对实现情况(✅已实现 / ❌未实现 / ⏭️跳过 / ⚠️有偏差)
3. 输出 compliance_score (0-10) 及理由
如果没有相关设计文档,跳过此阶段,compliance_score 为 N/A。
### Phase 2: UI 一致性审查
如果变更涉及前端文件(.tsx, .jsx, .vue, .css, .scss 等),执行此阶段:
1. 读取 docs/design/ui-spec.md
2. 严格核对前端代码是否符合 UI 设计规范
3. 输出 ui_compliance_score (0-10) 及理由
如果无前端文件变更或 ui-spec.md 不存在,跳过此阶段。
### Phase 3: 探索性审查
在审查范围内自由发现问题:
- **必查**:正确性、安全性
- **可选**:性能、可维护性、边界情况
输出 quality_score (0-10) 及理由。
## 输出要求
1. 按 P0/P1/P2 分级列出问题
2. 给出三个评分
3. 将完整结果写入:{{output_file}}
Subagent 执行步骤:
- 根据 review_target 获取内容(git show / 读取文件)
- 自主研究项目结构、理解代码上下文
- 检查固定文档路径下的设计文档和 UI 规范
- 执行三阶段审查
- 将结果写入 output_file
- 返回执行状态
6.2 外部 CLI Reviewer(Bash tool)
对于 codex、gemini 等外部工具,使用 Bash tool 调用 CLI:
Codex CLI 调用:
# 先准备 diff 内容
git diff HEAD~2..HEAD > /tmp/diff_content.txt
# 调用 codex(后台运行,避免阻塞)
codex --quiet "Review the following code changes. List issues by P0/P1/P2 priority. Give a quality_score (0-10).
$(cat /tmp/diff_content.txt)" > .reviews/xxx/review_codex.md 2>&1
Gemini CLI 调用:
# 调用 gemini
gemini "你是代码审查专家。请审查以下代码变更,按 P0/P1/P2 分级列出问题,给出 quality_score (0-10)。
变更内容:
$(git diff HEAD~2..HEAD)" > .reviews/xxx/review_gemini.md 2>&1
Gemini-CC CLI 调用(ccs gemini + claude -p):
# 使用 ccs 切换到 gemini 上下文,然后通过 claude -p 执行审查
# ccs gemini 会设置 ANTHROPIC_API_KEY 等环境变量指向 gemini 兼容的 API
$(ccs gemini) && claude -p \
--dangerously-skip-permissions \
"你是代码审查专家。请审查以下代码变更,按 P0/P1/P2 分级列出问题,给出 quality_score (0-10)。
变更内容:
$(git diff HEAD~2..HEAD)" > .reviews/xxx/review_gemini-cc.md 2>&1
GLM-CC CLI 调用(ccs glm + claude -p):
# 使用 ccs 切换到 glm 上下文,然后通过 claude -p 执行审查
# ccs glm 会设置 ANTHROPIC_API_KEY 等环境变量指向 glm 兼容的 API
$(ccs glm) && claude -p \
--dangerously-skip-permissions \
"你是代码审查专家。请审查以下代码变更,按 P0/P1/P2 分级列出问题,给出 quality_score (0-10)。
变更内容:
$(git diff HEAD~2..HEAD)" > .reviews/xxx/review_glm-cc.md 2>&1
CLI 调用注意事项:
- 使用
> file 2>&1捕获所有输出 - 对于长时间运行的命令,考虑使用
timeout包裹 - 检查 exit code 判断是否成功
6.3 并行启动示例(完整)
你必须在单个消息中同时发起所有调用:
# 在同一个响应中,同时发起以下调用:
## Task tool 调用 1: Claude Opus
subagent_type: "general-purpose"
model: "opus"
prompt: [审查 prompt,输出到 review_claude-opus.md]
## Task tool 调用 2: Claude Sonnet
subagent_type: "general-purpose"
model: "sonnet"
prompt: [审查 prompt,输出到 review_claude-sonnet.md]
## Task tool 调用 3: Claude Haiku
subagent_type: "general-purpose"
model: "haiku"
prompt: [审查 prompt,输出到 review_claude-haiku.md]
## Bash tool 调用 1: Codex
command: codex --quiet "[prompt]" > .reviews/xxx/review_codex.md 2>&1
## Bash tool 调用 2: Gemini
command: gemini "[prompt]" > .reviews/xxx/review_gemini.md 2>&1
## Bash tool 调用 3: Gemini-CC
command: $(ccs gemini) && claude -p --dangerously-skip-permissions "[prompt]" > .reviews/xxx/review_gemini-cc.md 2>&1
## Bash tool 调用 4: GLM-CC
command: $(ccs glm) && claude -p --dangerously-skip-permissions "[prompt]" > .reviews/xxx/review_glm-cc.md 2>&1
错误示范(不要这样做):
❌ 先启动 Claude opus,等待完成
❌ 再启动 Claude sonnet,等待完成
❌ 最后启动 codex 和 gemini
正确示范:
✅ 在单个消息中同时发起 7 个 tool 调用(3 个 Task + 4 个 Bash)
✅ 所有 reviewer 并行执行
✅ 等待所有完成后汇总
6.4 跳过不可用的 Reviewer
根据 3.5 节的 CLI 检查结果,跳过不可用的 reviewer:
# 伪代码
available_reviewers = []
if claude_available:
available_reviewers.extend(['claude-opus', 'claude-sonnet', 'claude-haiku'])
if codex_available:
available_reviewers.append('codex')
if gemini_available:
available_reviewers.append('gemini')
# 只启动可用的 reviewer
for reviewer in available_reviewers:
launch_reviewer(reviewer)
在最终输出中标记跳过原因:
| codex | ⏭️ skipped | - | CLI not found |
7. 汇总结果
等待所有 subagent 完成后,读取所有 review_*.md 文件进行汇总。
汇总步骤:
- 读取结果:读取
.reviews/<dir>/review_*.md所有文件 - 提取评分:
- 从每个结果中提取
compliance_score及理由 - 从每个结果中提取
ui_compliance_score及理由 - 从每个结果中提取
quality_score及理由
- 从每个结果中提取
- 去重:识别多个 reviewer 提出的相同/相似问题,合并为一条
- 分级:按 P0/P1/P2 分类所有问题
- 过滤:只保留 P0 和 P1 问题
- 评分:对每个 reviewer 的审查质量打
reviewer_score
评分汇总格式:
| Reviewer | Compliance | UI Compliance | Quality | Reviewer Score |
|----------|------------|---------------|---------|----------------|
| opus | 8/10 | 7/10 | 7/10 | 8.5/10 |
| sonnet | 9/10 | 8/10 | 6/10 | 7.0/10 |
| codex | N/A | N/A | 5/10 | 6.5/10 |
| gemini | 7/10 | N/A | 8/10 | 6.0/10 |
**平均分**
- compliance_score: 8.0/10 (3/4 reviewers)
- ui_compliance_score: 7.5/10 (2/4 reviewers)
- quality_score: 6.5/10 (4/4 reviewers)
reviewer_score 评分标准:
| 分数 | 标准 |
|---|---|
| 9-10 | 分析极其深入,问题发现全面,建议具体可执行 |
| 7-8 | 分析到位,问题识别准确,建议有价值 |
| 5-6 | 基本完成审查,但深度或建议质量一般 |
| 3-4 | 审查不够深入或遗漏重要问题 |
| 1-2 | 未能完成有效审查或输出异常 |
| 0 | 超时或执行失败 |
生成文件:
summary.md:汇总报告,包含评分总览和 P0/P1 问题列表meta.json:元数据,包含所有评分和统计信息
8. 写入 meta.json
meta.json 完整结构:
{
"id": "login_20251228_143052",
"timestamp": "2025-12-28T14:30:52+08:00",
"review_target": {
"type": "commits",
"value": "HEAD~3..HEAD"
},
"review_scope": {
"objective": "实现用户登录 API",
"includes": ["登录 API 端点", "JWT 验证中间件"],
"excludes": ["密码找回", "邮箱验证"],
"reference_docs": ["docs/design/auth-design.md"]
},
"fixed_paths": {
"ui_spec": "docs/design/ui-spec.md",
"design_dir": "docs/design/",
"plans_dir": "docs/plans/"
},
"execution_mode": "confirm",
"reviewers": {
"claude-opus": {
"status": "success",
"duration_seconds": 45.2,
"compliance_score": 8.0,
"compliance_score_reason": "设计要点 8/10 已实现",
"ui_compliance_score": 7.0,
"ui_compliance_score_reason": "色彩系统正确,间距有 2 处违规",
"quality_score": 7.5,
"quality_score_reason": "代码结构清晰,但缺少错误处理",
"reviewer_score": 8.5,
"reviewer_score_reason": "分析全面,建议具体可执行"
},
"gemini": {
"status": "success",
"duration_seconds": 38.1,
"compliance_score": null,
"compliance_score_reason": "跳过一致性审查(未找到参照文档)",
"ui_compliance_score": null,
"ui_compliance_score_reason": "跳过 UI 审查(无前端变更)",
"quality_score": 8.0,
"quality_score_reason": "整体质量良好",
"reviewer_score": 6.5,
"reviewer_score_reason": "发现问题较少"
}
},
"summary": {
"total_reviewers": 4,
"success_count": 4,
"failed_count": 0,
"timeout_count": 0,
"skipped_count": 0,
"avg_compliance_score": 8.0,
"avg_ui_compliance_score": 7.5,
"avg_quality_score": 7.0,
"p0_issues": 1,
"p1_issues": 3
}
}
字段说明:
| 字段 | 说明 |
|---|---|
review_scope |
新增,记录推断/注入的审查范围 |
fixed_paths |
新增,记录固定文档路径 |
execution_mode |
新增,记录执行模式 (confirm/skip-confirm/context-injected) |
compliance_score |
新增,一致性评分 (可为 null) |
ui_compliance_score |
新增,UI 一致性评分 (可为 null) |
quality_score |
替换原 content_score |
status 取值:
success:审查成功完成failed:执行出错timeout:超时未完成skipped:CLI 工具不存在或 reviewer 被禁用
9. 输出结果
审查完成后,向用户展示:
执行状态汇总:
## 审查完成
| Reviewer | 状态 | 耗时 | Compliance | UI Compliance | Quality |
|----------|------|------|------------|---------------|---------|
| claude-opus | ✅ success | 45.2s | 8/10 | 7/10 | 7.5/10 |
| claude-sonnet | ✅ success | 32.1s | 9/10 | 8/10 | 6/10 |
| codex | ⏭️ skipped | - | - | - | - |
| gemini | ✅ success | 38.1s | N/A | N/A | 8/10 |
**平均分**
- compliance_score: 8.5/10 (2/3 reviewers)
- ui_compliance_score: 7.5/10 (2/3 reviewers)
- quality_score: 7.2/10 (3/3 reviewers)
注:codex 跳过原因:CLI not found
P0/P1 问题汇总:
## P0 致命问题(共 1 个)
1. **SQL 注入风险** [claude-opus, claude-sonnet]
- 位置:`src/auth/login.py:45`
- 影响:攻击者可执行任意 SQL
- 建议:使用参数化查询
## P1 严重问题(共 3 个)
1. **缺少输入验证** [claude-opus, gemini]
...
结果目录:
结果已保存到:.reviews/login_20251228_143052/
使用示例
示例 1:审查指定文件
用户:super-review src/auth/login.py
执行:
- 确定审查内容:
src/auth/login.py - 收集背景:从用户 prompt 和项目文档提取
- 选择模板:backend-code.md(.py 文件)
- 启动 reviewers 并汇总
示例 2:审查最近 commit
用户:超级审查最近三个 commit
执行:
- 确定审查内容:
HEAD~3..HEAD - 收集背景:从 commit messages 提取
- 选择模板:根据涉及文件类型选择
- 启动 reviewers 并汇总
示例 3:智能推断
用户:并行审查(无指定内容)
执行:
- 检测 staged changes → 询问确认
- 如无 staged,检测最近 commit → 询问确认
- 用户确认后继续流程
Didn't find tool you were looking for?