名称: 审查描述: 在提交、PR或发布前运行全面的代码审查。使用代码审查代理，进行分层安全、性能和质量检查。参数提示: “[scope] [–baseline <branch>] [–profile <name>] [flags]” 允许的工具: Task, Bash, Read, Glob, Grep, AskUserQuestion

代码审查命令

对指定文件或暂存更改运行全面的代码审查。

指令

预检：研究阶段 + 文件计数（强制）

关键：代码审查代理在分析前运行强制研究阶段（步骤0）：

技术检测 - 代理扫描文件扩展名、导入和包清单
MCP研究 - 代理查询MCP服务器以获取当前最佳实践
构建真实上下文 - 代理在审查代码前构建已验证的上下文

这个研究阶段确保所有发现都根据当前文档验证，而不是过时的训练数据。

在调用代理前，计数文件以确保准确报告并确定审查模式：

# 对于暂存更改
FILE_COUNT=$(git diff --staged --name-only | wc -l)

# 对于PR更改
FILE_COUNT=$(git diff --name-only main...HEAD | wc -l)

# 对于特定路径 - 使用Glob并计数结果

报告这个计数并应用阈值：

1-49个文件：标准单代理审查（除非指定--consensus）
50+个文件：自动启用共识模式（除非指定--no-consensus）
100+个文件：警告用户并建议分成更小的块

使用代码审查代理执行系统的代码质量分析。

代码审查代理提供：

分层渐进披露以优化令牌
安全分析（OWASP前10名，密钥检测）
性能审查（N+1查询，资源泄漏）
代码质量（SOLID、DRY、清洁代码原则）
CLAUDE.md合规性用于Claude Code生态系统文件
严重级别（CRITICAL/MAJOR/MINOR）
MCP验证用于当前最佳实践和版本准确性（perplexity、context7、microsoft-learn）

根据提供的参数调用代理：

$ARGUMENTS

基于参数，确定审查范围：

如果'staged'或无参数：
  - 审查当前暂存文件（git diff --staged）
  - 适用于预提交审查

如果'pr'或'pull-request'：
  - 审查当前PR/分支与主分支的所有更改
  - 适用于PR审查

如果提供特定文件路径：
  - 审查那些特定文件
  - 可以是通配符如"src/**/*.ts"

如果'--parallel'：
  - 并行运行多个代码审查代理（每个文件/模块一个）
  - 适用于大型更改集
  - ⚠️ 注意：限制每次2-3个Opus代理以防止上下文耗尽

如果'--sequential'：
  - 运行单个代码审查代理审查所有文件
  - 适用于较小更改集或文件间上下文重要时

如果'--batched'：
  - 分批运行代理，每批2-3个，批次间等待完成
  - 适用于非常大更改集（50+文件）或多类型审计
  - 防止大型工作负载下的上下文耗尽

如果'--consensus'：
  - 强制多代理共识模式（即使对于小更改集）
  - 启动3个专门代理：代码审查、安全审查、质量审查
  - 基于一致级别整合发现
  - 适用于需要额外验证的关键代码路径

如果'--no-consensus'：
  - 禁用自动共识模式（即使对于50+文件）
  - 强制单个代码审查代理
  - 适用于当您想要更快审查而不是更高准确性时

如果'--show-rules'：
  - 显示活动规则而不运行审查
  - 显示：配置源、技术栈、排除规则、严重性覆盖、自定义检查
  - 适用于在审查前验证配置

如果'--ignore-repo-config'：
  - 跳过.claude/code-review.md和CLAUDE.md配置
  - 仅使用默认规则（第1层通用检查）
  - 适用于比较有/无仓库特定规则

如果'--baseline <branch>'（例如，'--baseline main'，'--baseline develop'）：
  - 对比指定分支的更改以识别新问题与现有问题
  - 运行`git diff <baseline>...HEAD`以获取更改的行范围
  - 标记每个发现为"new"（在此更改集中添加/修改的行）或"pre-existing"
  - 输出将新问题（突出显示）与现有债务（折叠）分开
  - 默认基线：当使用'pr'范围时为'main'，对于'staged'无
  - 对于采用是游戏规则改变者：团队只看到他们引入的问题，而不是继承的债务
  - 质量门（--fail-on-new-critical）仅适用于新问题

如果'--profile <name>'：
  - 使用预定义检查子集运行聚焦审查
  - 配置文件：
    - security: 仅OWASP、密钥、认证检查（快速安全扫描）
    - quick: 仅样式、明显问题（预提交快速检查）
    - thorough: 所有检查（默认 - 完整审查）
    - performance: N+1、复杂性、内存、并发检查
    - strict: thorough + 模式合规性、模块边界、依赖迁移
  - 适用于聚焦审查或更快的预提交检查
  - 参见SKILL.md配置文件部分以获取层映射

如果'--profile strict'：
  - 运行所有'thorough'检查加上额外严格性：
    - 模式合规性：架构模式、DI模式、命名约定
    - 导入卫生：模块边界违规、桶文件污染
    - 测试相关性：孤立测试检测
    - 依赖安全性：主要版本升级的迁移验证
  - 更高令牌成本（约17,000令牌）但捕获更多微妙问题
  - 适用于关键代码库、库发布或全面审计

如果'--history'：
  - 强制git历史分析，即使对于跳过它的配置文件（例如，quick）
  - 分析：
    - 耦合：通常一起更改的文件
    - 热点：需要额外审查的高变更文件
    - 作者上下文：所有权模式和巴士因子
    - 最近模式：指示脆弱区域的错误修复历史
  - 适用于调查不熟悉的代码区域或深度审查
  - 添加约1,500令牌用于历史上下文分析

如果'--no-history'：
  - 跳过git历史分析，即使对于包含它的配置文件（thorough、strict）
  - 当历史上下文不需要时节省时间
  - 适用于对孤立、充分理解的更改的快速审查
  - 节省约1,500令牌

默认：暂存更改、顺序模式、50+文件自动共识、每个配置文件的历史

仓库配置

审查命令自动从以下加载仓库特定规则：

.claude/code-review.md（主要）- .claude文件夹中的专用配置文件
CLAUDE.md + @imports（后备）- 从现有项目指令中提取规则

配置优先级链：

1. .claude/code-review.md存在吗？
   └── 是：解析配置，应用规则
   └── 否：继续到后备

2. CLAUDE.md存在吗？
   └── 是：读取 + 遵循@imports，提取规则
   └── 否：继续到默认

3. 未找到配置（交互模式）：
   └── AskUserQuestion: "未找到审查配置。使用默认规则审查吗？"
   └── 用户可以确认或提供指导

配置内容：

部分	效果
`## 技术栈`	覆盖自动检测的技术，提高MCP查询准确性
`## 排除规则`	跳过特定规则（例如，非DB项目的`sql-injection`）
`## 严重性覆盖`	更改默认严重性（CRITICAL→MAJOR，MAJOR→MINOR）
`## 自定义检查`	添加项目特定验证（文件模式、内容规则）

参见repo-config.md以获取完整模式文档。

Claude Code组件验证（强制）

关键：当在审查范围中检测到Claude Code文件时，通过审计代理进行专门验证是强制的。这不是可选的 - 如果验证无法运行，审查失败。

Claude Code组件（技能、代理、命令、钩子、内存文件、插件等）需要通过docs-management技能针对官方文档进行验证。代码审查代理仅执行基本语法检查 - 全面验证需要专门的审计代理。

为什么需要审计

代码审查代理：

缺乏Task工具访问（无法生成子代理）
只能执行基本语法验证（YAML/JSON结构）
无法验证frontmatter字段与官方文档
无法验证工具配置、钩子事件或权限模式

审计代理：

委托给开发技能（skill-development等）
开发技能委托给docs-management以获取官方文档
提供100%文档驱动的验证
捕获无效的frontmatter属性、不正确的字段值等

CC检测（步骤0c - 代码审查前）

在调用代码审查代理前，扫描审查范围以查找Claude Code文件：

检测模式：

文件模式	组件类型
`.claude/agents/*/.md`, `agents/*.md`	代理
`.claude/skills/*`, `skills//SKILL.md`	技能
`.claude/hooks/**`, `hooks.json`	钩子
`.claude/skills/**`	技能
`CLAUDE.md`, `.claude/memory/*/.md`	内存
`output-styles/*.md`	输出样式
`.mcp.json`, `mcp.json`	MCP配置
`settings.json`, `.claude/settings.json`, `.claude/settings.local.json`	设置
`plugin.json`, `.claude-plugin/**`	插件
状态行脚本	状态行

工作流：

获取审查范围中的文件列表（暂存、PR或指定路径）
使用Glob匹配检测模式
按组件类型分组检测到的文件
存储列表用于代码审查后的审计调用

CC审计调用（步骤8 - 代码审查后）

如果步骤0c中检测到CC文件，调用专门的审计：

步骤8a：检查插件可用性

尝试生成一个审计代理（例如，claude-ecosystem:skill-auditor）：

如果生成成功：claude-ecosystem插件已安装，继续步骤8b
如果生成失败：审查失败并显示错误消息（见下文）

步骤8b：按优先级分批生成审计

为防止上下文耗尽，分批生成审计，每批2-3个，批次间等待：

优先级	审计	理由
第1轮	`memory-component-auditor`, `skill-auditor`	内存影响所有；技能定义行为
第2轮	`agent-auditor`, `hook-auditor`	代理使用技能；钩子定义运行时行为
第3轮	`mcp-auditor`, `settings-auditor`	运行时配置
第4轮	`plugin-component-auditor`, `output-style-auditor`, `statusline-auditor`	打包和显示

仅生成检测到的组件类型的审计。例如，如果未更改钩子，跳过hook-auditor。

步骤8c：提供审计上下文

对于每个审计，提供：

project_root：仓库根的绝对路径
files：要审计的文件列表（过滤到组件类型）
source：“project"或"plugin:{plugin-name}”

审计写入双重输出：

JSON文件：.claude/temp/audit-{source}-{component-name}.json
Markdown报告：.claude/temp/audit-{source}-{component-name}.md

步骤8d：整合发现

将审计分数映射到审查严重性：

审计分数	审计结果	审查严重性
< 70	失败	CRITICAL
70-84	通过但有警告	MAJOR
85+ 带问题	通过	MINOR

在审查报告中包含审计发现，并注明来源：

### [发现标题]
**文件**: `path/to/file.md:line`
**严重性**: CRITICAL
**类别**: Claude Code合规性
**来源**: claude-ecosystem:skill-auditor

**问题**: YAML frontmatter包含不受支持的字段'color'

**影响**: 无效的frontmatter可能导致技能加载失败或未定义行为

**修复**: 删除'color'字段 - 对于技能，只有'name'、'description'和'allowed-tools'是有效的

插件不可用 - 审查失败

如果检测到CC文件但未安装claude-ecosystem插件：

## 审查失败：需要Claude Code验证

**错误：** 在审查范围中检测到Claude Code生态系统文件，但未安装`claude-ecosystem`插件。CC验证是强制的。

**检测到的文件：**
| 组件类型 | 计数 | 文件 |
| --- | --- | --- |
| [类型] | [计数] | [文件列表] |

**为什么这是必需的：**
Claude Code文件需要针对官方文档进行专门验证。代码审查代理只能执行基本语法检查（YAML/JSON结构），这不足够。审计代理验证：
- YAML frontmatter字段名和值
- 工具配置和限制
- 钩子事件和匹配器模式
- 权限模式和模型选择
- 官方文档合规性

**解决方案：**
安装claude-ecosystem插件：

/plugin install claude-ecosystem@claude-code-plugins

然后重新运行审查：

/code-quality:review [原始参数]

CC验证输出部分

当审查CC文件时，添加到审查报告：

## Claude Code验证摘要

**检测到的CC文件**: [计数]
**调用的审计**: [列表]
**验证状态**: 通过 | 失败

### 按组件的CC发现

#### 技能（[计数]个问题）
| 文件 | 问题 | 严重性 |
| --- | --- | --- |
| [文件] | [问题] | [严重性] |

#### 代理（[计数]个问题）
...

### 审计来源
- skill-auditor: 审计2个文件，1个问题
- agent-auditor: 审计3个文件，0个问题

关键：上下文耗尽预防

当审查大型更改集或运行多个专门代理（审计代理、代码审查等）时，遵循这些规则以防止上下文耗尽：

文件计数阈值

要审查的文件	推荐模式	共识
1-20个文件	顺序或2-3个并行代理	可选（如果需要使用`--consensus`）
20-50个文件	分批模式（每批2-3个代理）	可选
50-100个文件	顺序模式 + 共识	自动启用
100+个文件	警告用户，建议分成更小的块	如果继续则自动启用

多代理审计（插件审计）

当调用多个专门审计代理（plugin-component-auditor、skill-auditor、agent-auditor、output-style-auditor）时：

永远不要并行启动5+个Opus代理 - 这会耗尽上下文
分批成2-3个代理的组，批次间明确等待
考虑使用Haiku进行更简单的审计以减少令牌开销
如果不确定，使用顺序模式

示例：审计100+个插件文件，跨5个组件类型

第1轮：启动plugin-component-auditor + skill-auditor（并行，2个代理）
         等待完成
第2轮：启动agent-auditor + hook-auditor（并行，2个代理）
         等待完成
第3轮：启动output-style-auditor（顺序，1个代理）
         等待完成
聚合结果并报告

从上下文耗尽恢复

如果遇到"上下文低" + “/compact失败”：

停止启动新代理
记录已完成与待处理的内容
建议用户运行/clear并恢复剩余项目
不要继续重试 - 上下文已耗尽

参见.claude/memory/agent-usage-patterns.md以获取完整分批指导。

示例

审查暂存更改

/code-quality:review
/code-quality:review staged

审查PR更改

/code-quality:review pr

审查特定文件

/code-quality:review src/auth.ts src/config.ts
/code-quality:review "src/**/*.ts"

并行审查（大型更改集）

/code-quality:review --parallel
/code-quality:review pr --parallel

分批审查（非常大更改集）

/code-quality:review --batched
/code-quality:review staged --batched

共识审查（多个审查者）

/code-quality:review --consensus
/code-quality:review pr --consensus

跳过自动共识（大型更改集，单个审查者）

/code-quality:review pr --no-consensus

基线模式（仅显示新问题）

/code-quality:review pr --baseline main
/code-quality:review staged --baseline develop
/code-quality:review --baseline main  # 对比所有文件与主分支

基于配置文件的审查

/code-quality:review --profile security    # 仅安全检查（快速）
/code-quality:review --profile quick       # 预提交快速检查
/code-quality:review --profile performance # 性能聚焦
/code-quality:review pr --profile thorough # 完整审查（默认）
/code-quality:review pr --profile strict   # 全面审计（模式 + 模块 + 依赖检查）

组合标志

/code-quality:review pr --baseline main --profile security  # 仅新安全问题
/code-quality:review staged --profile quick                 # 快速预提交检查
/code-quality:review pr --baseline main --profile strict    # 仅新代码的全面审计

共识模式

当共识模式激活时（50+文件自动启用或通过--consensus），命令并行启动3个专门审查者：

代理	焦点领域
`code-reviewer`	逻辑、设计、可维护性、一般质量
`security-reviewer`	OWASP前10名、密钥、认证、加密、注入
`quality-reviewer`	SOLID、清洁代码、性能、资源泄漏

共识模式中的配置

每个共识代理独立加载仓库配置（来自代码审查技能步骤0b）。所有3个代理读取相同的.claude/code-review.md（或CLAUDE.md后备），并且运行时自动将.claude/rules/*.md内容加载到所有代理上下文中。排除规则、严重性覆盖和自定义检查统一应用。

共识整合

发现基于一致级别整合：

一致	置信度	严重性映射
3个代理同意	高	按标记（CRITICAL/MAJOR/MINOR）
2个代理同意	中	如果标记为CRITICAL则降一级
1个代理标记	低	标记为"需要人工审查" - 可能是误报

共识输出格式

## 共识审查摘要
**审查的文件**: [计数]
**审查模式**: 共识（3个代理）
**发现的问题**: [CRITICAL: X | MAJOR: Y | MINOR: Z | 需要审查: W]

## 高置信度问题（3/3个代理同意）
[详情]

## 中置信度问题（2/3个代理同意）
[详情]

## 低置信度问题（1/3个代理 - 可能是误报）
[详情]

输出格式

代理返回结构化审查报告：

## 技术研究摘要（来自研究阶段）
### 检测到的技术栈
| 类别 | 技术 | 版本 | 来源 |
| --- | --- | --- | --- |
| [类别] | [技术] | [版本] | [检测自] |

### 当前最佳实践（MCP验证）
| 领域 | 当前推荐 | 来源 |
| --- | --- | --- |
| [领域] | [推荐] | [mcp-server] |

## 审查摘要
**审查的文件**: [计数]
**发现的问题**: [CRITICAL: X | MAJOR: Y | MINOR: Z]
**总体评估**: [通过/关注/失败]

## 关键问题
[带文件:行、问题、影响、修复、**验证**: 状态的详情]

## 主要问题
[带验证状态的详情]

## 次要问题
[带验证状态的详情]

## 正面观察
[注意到的好模式]

## MCP验证摘要
**咨询的来源**: [计数]
**验证的发现**: [已验证/总计]
**应用的更正**: [计数]
**检测到的过时模式**: [计数]

### 来源
- [perplexity]: [查询或来源描述]
- [microsoft-learn]: [文档标题和URL（如果可用）]
- [context7]: [库名和版本]

基线模式输出格式

当指定--baseline时，输出将新问题与现有债务分开：

## 审查摘要

**基线**: `main`（比较HEAD与主分支）
**更改的文件**: [计数]

**新问题（此更改集）**: 2个关键，1个主要，3个次要 ← 聚焦此处
**现有问题**: 47（折叠在下）

**总体评估**: [通过/关注/失败]（仅基于新问题）

## 引入的新问题

这些问题在此更改集中引入。在合并前解决。

### 关键（新）

#### [发现标题]
**文件**: `src/api/users.ts:42`（此更改集中添加的行）
**归因**: 新 - 第42行在提交abc123中添加
[... 完整发现详情 ...]

### 主要（新）
[... 发现 ...]

### 次要（新）
[... 发现 ...]

---

<details>
<summary>现有问题（47） - 技术债务（点击展开）</summary>

这些问题在此更改集前已存在。不阻塞，但注意以了解。

### 关键（现有）: 5
[... 折叠的发现 ...]

### 主要（现有）: 20
[... 折叠的发现 ...]

### 次要（现有）: 22
[... 折叠的发现 ...]

</details>

质量门支持（CI/CD集成）

当使用--baseline与质量门时：

--fail-on-new-critical - 如果找到任何新关键问题，退出代码1
--fail-on-new-major - 如果找到任何新主要问题，退出代码1

注意： 质量门仅适用于新问题。现有债务不会使构建失败。

命令设计笔记

此命令委托给代码审查代理，该代理使用code-quality:code-reviewing技能作为其权威来源。该技能提供分层检查列表和仓库特定规则。这种分离保持命令简单，同时利用全面的审查逻辑。

只读设计

代码审查代理以plan模式（只读）运行。它分析代码并报告发现，但不应用修复。这是故意的：

审查和修复是分开的关注点：审查识别问题；修复是独立操作
用户控制：开发者决定应用哪些修复以及如何应用
安全性：审查期间无意外修改

未来：修复模式

如果未来添加--fix标志以自动应用修复：

使用具有编辑能力的单独代理（非plan模式）
默认：将修复保留为未暂存以供用户审查
支持--auto-stage标志以在验证后暂存修复
遵循fix-workflow.md中的模式

未来使用示例：

# 审查并应用修复，保留为未暂存（默认）
/code-quality:review staged --fix

# 审查、应用修复并暂存（用于自动化）
/code-quality:review staged --fix --auto-stage

名称: 审查 描述: 在提交、PR或发布前运行全面的代码审查。使用代码审查代理，进行分层安全、性能和质量检查。 参数提示: “[scope] [–baseline <branch>] [–profile <name>] [flags]” 允许的工具: Task, Bash, Read, Glob, Grep, AskUserQuestion