sc-code-review

代码审查技能

使用 PAL MCP 多模型共识进行全面的代码审查。审查近期提交、已暂存的更改或分支比较，重点关注安全性、质量、性能和架构。

快速入门

# Review last 5 commits (default)
/sc:code-review

# Review staged changes
/sc:code-review --staged

# Compare feature branch against main
/sc:code-review --branch main

# Security-focused review
/sc:code-review commits=3 --focus security

# Post review as PR comment
/sc:code-review --branch main --post-pr

理念：尽早提问，经常提问

此技能会在每个决策点灵活使用 AskUserQuestion。 代码审查具有主观性——关注重点取决于具体情境，而对审查者优先事项的假设往往是错误的。提问的成本很低；审查范围错误或遗漏用户关心内容的代价却很高。

交互式检查点：

• 审查前——确认审查范围以及用户关心的内容
• 差异较大时——让用户选择优先关注的内容
• 分类存在歧义时——询问严重程度级别
• 模型意见不一时——让用户裁定问题严重程度
• 发现问题后——询问下一步操作（修复、重新审查、发布到 PR）
• 存在权衡时——明确列出选项，而不是默默替用户做决定
• 对于严重/高优先级问题——定稿前向用户确认严重程度

用户应该感觉自己在主导审查，而不是收到一份一键生成、无需参与的报告。

行为流程

1. 解析 - 从参数中提取审查模式、关注领域和提交范围
2. 验证 - 检查 Git 状态、分支是否存在以及已暂存的更改
3. 确认范围 - 与用户交互并确认审查范围
4. 发现 - 通过 mcp__pal__listmodels 列出可用模型
5. 收集 - 收集 Git 差异、已更改文件和提交历史
6. 分类 - 将已更改文件映射到审查关注领域
7. 处理大型差异 - 交互式选择大型更改的分块策略
8. 审查 - 通过多模型评估运行 PAL MCP 共识
9. 解决分歧 - 由用户裁定模型间的分歧
10. 验证发现 - 由用户确认严重/高优先级问题
11. 格式化 - 以 GitHub PR 评论样式呈现发现
12. 后续跟进 - 询问用户下一步操作（修复、深入分析、发布到 PR）
13. 发布 - 可选择通过 gh CLI 发布到 PR

标志

标志	类型	默认值	说明
commits	int	5	要审查的近期提交数量
--staged	bool	false	仅审查已暂存的更改
--branch	string	-	将当前分支与目标分支进行比较
--focus	string	full	关注领域：security、performance、quality、architecture、full
--post-pr	bool	false	将审查结果作为 PR 评论发布
--models	int	2	用于达成共识的模型数量（2-5）

审查模式

各模式互斥：

模式	触发条件	Git 命令
提交	默认或 commits=N	git diff -U10 HEAD~N..HEAD
已暂存	--staged	git diff -U10 --cached
分支	--branch <target>	git diff -U10 origin/<target>...HEAD

阶段 1：验证 Git 状态

# Verify git repository
git rev-parse --is-inside-work-tree

# Get current branch
git branch --show-current

特定模式的验证：

• 提交：检查 git rev-list --count HEAD >= N
• 已暂存：检查 git diff --cached --name-only 是否非空
• 分支：检查 git rev-parse --verify "origin/$TARGET" 是否存在

阶段 1b：确认审查范围

收集 Git 上下文后，向用户展示摘要，并让用户确认或调整：

AskUserQuestion:
  question: "Here's what I'll be reviewing. Does this scope look right?"
  header: "Scope"
  multiSelect: false
  options:
    - label: "Looks good — proceed"
      description: "<N files changed, +X/-Y lines, commits/staged/branch summary>"
    - label: "Too much — narrow scope"
      description: "I only want to review a subset of these changes"
    - label: "Too little — expand scope"
      description: "Include more commits or compare against a different branch"
    - label: "Different focus"
      description: "I want to focus on a specific area (security, performance, etc.)"

如果选择“太多了——缩小范围”：询问要重点关注哪些文件或目录：

AskUserQuestion:
  question: "Which areas should I focus the review on?"
  header: "Focus"
  multiSelect: true
  options:
    - label: "Backend (app/)"
      description: "<N files, +X/-Y lines in app/>"
    - label: "Frontend (frontend/)"
      description: "<N files, +X/-Y lines in frontend/>"
    - label: "Tests"
      description: "<N files, +X/-Y lines in tests/>"
    - label: "Config/Infra"
      description: "<N files in Docker, CI, config>"

如果选择“太少了——扩大范围”：询问如何扩大范围（增加提交、改用其他分支）。

如果选择“更换关注领域”：询问要使用哪个审查关注领域，并覆盖 --focus 标志。

阶段 2：发现模型

调用 mcp__pal__listmodels 获取可用模型。按分数从高到低选择前 N 个模型，并优先选择不同提供商的模型，以提高多样性。

选择标准：

1. 按分数降序排序
2. 尽可能选择不同提供商的模型
3. 有效达成共识至少需要 2 个模型

第 3 阶段：收集 Git 上下文

根据所选审查模式收集：

数据	用途
git diff -U10 ...	包含扩展上下文的完整差异
git diff --stat ...	更改统计信息
git log --oneline ...	提交摘要
更改的文件列表	文件分类

第 4 阶段：对更改的文件进行分类

模式	类别	审查重点
*.py、*.ts、*.go、*.rs	源代码	安全性、SOLID、性能
tests/**、*_test.*	测试代码	覆盖率、边缘情况、断言
*.yml、*.yaml、*.toml	配置	安全性、正确性
*requirements*、*package*	依赖项	漏洞、版本
Dockerfile*、docker-compose*	基础设施	安全性、最佳实践
*.md、*.rst	文档	准确性、完整性

跳过二进制文件（注明这些文件，但不纳入差异审查）。

第 5 阶段：处理大型差异

如果差异超过约 1000 行，询问用户希望如何处理：

AskUserQuestion:
  question: "The diff is large (~<N> lines across <M> files). How should I handle it?"
  header: "Large diff"
  multiSelect: false
  options:
    - label: "Review in chunks by category (Recommended)"
      description: "Group files by type (backend, frontend, tests, config) and review each separately"
    - label: "Focus on highest-risk files only"
      description: "Skip low-risk changes (docs, tests, config) and focus on production code"
    - label: "Review everything in one pass"
      description: "Send the full diff to models — may lose detail on individual files"
    - label: "Let me pick specific files"
      description: "I'll tell you exactly which files to review"

如果选择“让我挑选特定文件”：

• 列出所有更改的文件及其统计信息
• 询问用户选择要审查的文件
• 相应地缩小差异范围

如果选择“按类别分块审查”：

1. 按类别对文件分组（源代码、测试、配置、文档）
2. 使用 PAL 共识分别审查每组
3. 将发现汇总为一份报告
4. 对重叠问题去重

如果选择“只关注风险最高的文件”：

• 排除文档、配置和测试文件
• 仅针对生产源代码进行共识审查

第 6 阶段：运行 PAL MCP 共识

使用已发现的模型调用 mcp__pal__consensus。

共识工作流：

• step 1：你基于差异进行初步分析
• step 2+：每个模型依次给出发现
• total_steps = 模型数量 + 1

按关注领域划分的审查清单：

关注领域	检查项
security	密钥、注入、身份验证、输入验证、依赖项
performance	N+1 查询、复杂度、缓存、内存泄漏
quality	SOLID、命名、错误处理、类型、死代码
architecture	模式、耦合、关注点分离、可测试性
full	以上全部（默认）

备用方案：如果共识失败，则使用 mcp__pal__codereview 进行单模型审查。

第 6a 阶段：说明模型之间的分歧

如果模型对某个问题的严重程度或是否存在有分歧，不要自行解决分歧。请说明每项重要分歧：

AskUserQuestion:
  question: "Models disagreed on <specific issue>. How should this be classified?"
  header: "Severity"
  multiSelect: false
  options:
    - label: "<Model A's severity> (e.g., Critical)"
      description: "<Model A> flagged this as <severity> because: <reasoning>"
    - label: "<Model B's severity> (e.g., Low)"
      description: "<Model B> considers this <severity> because: <reasoning>"
    - label: "Dismiss this finding"
      description: "This isn't actually an issue — it's intentional or acceptable"

对每项重要分歧重复此操作（每次 AskUserQuestion 调用最多 4 项）。如果细微差异不会改变严重程度级别，则跳过。

第 6b 阶段：验证严重/高危发现

如果有任何发现被归类为严重或高危，请先提交给用户确认，再纳入最终报告。这些严重程度级别的误报会损害信任：

AskUserQuestion:
  question: "I found <N> critical/high issues. Do these look like real problems, or should I reclassify any?"
  header: "Validate"
  multiSelect: true
  options:
    - label: "<Issue 1 summary>"
      description: "[FILE:LINE] — <brief description>. Classified as <severity>"
    - label: "<Issue 2 summary>"
      description: "[FILE:LINE] — <brief description>. Classified as <severity>"
    - label: "<Issue 3 summary>"
      description: "[FILE:LINE] — <brief description>. Classified as <severity>"
    - label: "All look correct"
      description: "Keep all critical/high classifications as-is"

解释：

• 选中的项目确认是真实问题——保留当前严重程度
• 未选中的严重/高危项目应降级为中等，并附上说明
• 如果选择“全部看起来正确”，则保持所有项目不变

如果没有严重或高危发现，则跳过此问题。

使用 mcp__pal__challenge 进行验证：

• 对每项严重/高危发现，运行 mcp__pal__challenge 验证其严重程度
• 同时呈现原始发现和挑战结果
• 由用户最终决定严重程度

挑战提示词示例：

"The code review identified this as a Critical security issue: <issue description>.
Challenge this finding: Is it actually critical? Could it be a false positive?
What's the real-world exploitability? What's the actual severity?"

这会增加一层对抗性验证，以防止误报。

第 7 阶段：格式化输出

## Code Review: Multi-Model Consensus

**Review Mode**: [Commits (last N) | Staged Changes | Branch vs TARGET]
**Files Reviewed**: N files
**Lines Changed**: +X / -Y

---

### Executive Summary
[2-3 sentence overview]

---

### Critical Issues
> Must be addressed before merge

- [ ] **[FILE:LINE]** - [Issue description]
  - **Category**: Security/Performance/Bug Risk
  - **Severity**: Critical
  - **Recommendation**: [Specific fix]

### High Priority
> Should be addressed

- [ ] **[FILE:LINE]** - [Issue description]
  - **Category**: [Category]
  - **Recommendation**: [Specific fix]

### Medium Priority
> Recommended improvements

- [ ] **[FILE:LINE]** - [Issue description]
  - **Recommendation**: [Suggestion]

### Low Priority / Suggestions
> Nice to have

- [ ] [Suggestion]

---

### Positive Observations
- [Good pattern observed]

---

### Review Summary

| Category | Rating | Notes |
|----------|--------|-------|
| Security | X/5 | [Brief note] |
| Code Quality | X/5 | [Brief note] |
| Performance | X/5 | [Brief note] |
| Architecture | X/5 | [Brief note] |
| Test Coverage | X/5 | [Brief note] |

**Overall Assessment**: [APPROVE / REQUEST CHANGES / NEEDS DISCUSSION]

---

### Model Consensus

| Model | Key Findings |
|-------|--------------|
| [Model 1] | [Summary] |
| [Model 2] | [Summary] |

**Agreement Areas**: [Where models agreed]
**Divergent Views**: [Where models differed]

第 8 阶段：评审后续跟进

展示评审结果后，始终询问用户接下来想做什么：

AskUserQuestion:
  question: "Review complete (<overall assessment>). What would you like to do next?"
  header: "Next"
  multiSelect: false
  options:
    - label: "Auto-fix issues"
      description: "Attempt to fix all critical and high issues automatically"
    - label: "Review a specific file in detail"
      description: "Deep-dive into one file that needs closer inspection"
    - label: "Post to PR"
      description: "Post this review as a comment on the current PR"
    - label: "Re-review with different models"
      description: "Run the review again with different model consensus"
    - label: "Done"
      description: "Review is complete — no further action needed"

如果选择“自动修复问题”：询问要修复哪些严重级别的问题：

AskUserQuestion:
  question: "Which issues should I attempt to fix?"
  header: "Fix scope"
  multiSelect: true
  options:
    - label: "Critical issues (<N>)"
      description: "Must-fix items that block merge"
    - label: "High priority (<N>)"
      description: "Should-fix items"
    - label: "Medium priority (<N>)"
      description: "Recommended improvements"
    - label: "All issues"
      description: "Fix everything that can be automated"

然后使用 Edit 尝试修复并报告结果。每次修复后，询问用户是想继续还是查看更改。

如果选择“详细评审特定文件”：

• 询问要从已更改文件列表中选择哪个文件
• 仅针对该文件的差异，使用最大上下文（-U20）重新运行共识评审
• 仅展示该文件的详细发现

如果选择“使用不同模型重新评审”：

• 再次运行 mcp__pal__listmodels
• 让用户选择其他模型
• 使用新的模型组合重新运行完整评审

第 9 阶段：发布到 PR（可选）

如果设置了 --post-pr 标志且处于 PR 上下文中：

PR_NUMBER=$(gh pr view --json number -q .number 2>/dev/null)
gh pr comment $PR_NUMBER --body "<review output>"

MCP 集成

PAL MCP（主要）

工具	何时使用	用途
mcp__pal__listmodels	始终	发现可用模型
mcp__pal__consensus	默认	多模型代码评审共识
mcp__pal__codereview	回退方案	单模型代码评审
mcp__pal__challenge	关键发现	验证关键问题的严重程度

Rube MCP（可选）

工具	何时使用	用途
mcp__rube__RUBE_SEARCH_TOOLS	--notify	查找通知工具
mcp__rube__RUBE_MULTI_EXECUTE_TOOL	--notify	将评审结果发送到 Slack/Jira

错误处理

场景	操作
不是 git 仓库	退出并报错
范围内没有提交	将 N 调整为可用的提交数
没有暂存的更改	报错并提示使用 git add
未找到分支	报错并列出可用分支
PAL MCP 不可用	回退到 mcp__pal__codereview
没有可用模型	报错 — PAL MCP 未配置

工具协同

• Bash - Git 操作、发布 PR
• Read - 检查源文件以获取上下文
• Grep - 在已更改文件中搜索模式
• Edit - 根据发现自动修复问题
• Glob - 为大型差异查找文件
• PAL MCP - 多模型共识评审
• Rube MCP - 外部通知
• AskUserQuestion - 交互式决策节点

备注

• 扩展差异上下文（-U10）可帮助模型更好地理解代码
• 会注明二进制文件，但不将其纳入差异评审
• 根据 CLAUDE.md，对 Python 文件额外评审 SOLID 原则
• 评审深度会随差异大小调整（较大的差异会分块处理）
• 交互式验证可避免关键发现中的误报
• 评审流程由用户引导——这是协作过程，而非自动化流程