---
name: code-review
version: "1.0.0"
category: quality
description: "当用户请求代码审查、评估代码问题、检查Pull Request或需要实现质量反馈时使用。不要用于安全专项审计（用 security-check）或代码重构规划（用 code-quality）。Use when user requests code review, asks about code problems, evaluates pull requests, or wants feedback on implementation quality. Do NOT use for security-specific audits (use security-check) or refactoring plans (use code-quality)."
triggers:
  zh: ["code review", "review", "代码审查", "code smell", "代码坏味道"]
  en: ["code review", "review", "code smell", "bad code", "code quality"]
license: MIT
compatibility: Node.js >= 18, Java 11+
metadata: 
  author: "sunhongda@example.com"
  created: "2026-06-16"
  updated: "2026-06-16"
  status: "stable"
---

# 代码审查 / Code Review

## Changelog / 版本履历
| 日期 | 版本 | 变更摘要 |
|------|------|---------|
| 2026-06-16 | 1.0.0 | 规范化调整 |

***
## Core Concept / 核心概念

### 🇨🇳
一句话说清：输入什么 → 做什么 → 输出什么。明确 **不做什么**。

**输入**: 代码文件或diff内容 | **输出**: 按🔴严重、🟡警告、🔵建议三级分类的结构化报告 | **不负责**: 安全专项审计和重构规划

### 🇺🇸
One line: Input → Process → Output. Explicitly state what is **NOT done**.

**Input**: code files/diff → **Process**: scan 4 dimensions (logic, performance, security, code standards) → **Output**: categorized report 🔴🟡🔵 | **NOT responsible for**: security-specific audits and refactoring plans

***
## Position / 定位

```
quality router → code-review → developer
    (代码质量域)        (开发者)
```

***
## Description / 描述
系统代码审查技能，按严重程度分类检查代码中的逻辑漏洞、性能问题、安全风险和代码坏味道，并提供具体的修复建议和代码示例。适用于全面的代码质量评估和改进指导。

## Triggers / 触发词
- English: 'code review', 'review', 'code smell', 'bad code', 'code quality'
- 中文: 'code review', 'review', '代码审查', 'code smell', '代码坏味道'

## Capabilities / 能力
- **逻辑漏洞检测** - 识别空指针、边界条件、死代码、竞态条件等问题
- **性能问题分析** - 发现N+1查询、不必要循环、大对象创建等性能瓶颈
- **安全风险扫描** - 检测SQL注入、XSS、敏感信息泄露等安全漏洞
- **代码规范检查** - 验证命名、注释、异常处理、事务边界等编码规范
- **严重程度分类** - 按🔴严重、🟡警告、🔵建议三级分类输出问题

## Dependencies / 依赖
- None

## Usage / 使用方式

### Invocation / 调用方式
通过quality域路由器自动调用，或通过expert入口直接调用

### Parameters / 参数
| 参数 | 类型 | 必填 | 说明 |
|------|------|------|------|
| files | array | ✅ | 要审查的文件路径列表 |
| diff | string | ❌ | Git diff内容（可选） |

### Example / 示例
```
/code-review src/main/java/com/example/service/UserService.java
```

## Output Format / 输出格式
结构化的Markdown格式报告，按严重程度分类：
```
🔴 严重 (需立即修复):
  - [文件:行号] 问题描述 → 修复建议

🟡 警告 (建议修复):
  - [文件:行号] 问题描述 → 修复建议

🔵 建议 (可选优化):
  - [文件:行号] 问题描述 → 修复建议
```

## Workflow / 工作流程
1. **输入处理** - 读取指定文件或diff内容
2. **全面扫描** - 逐文件分析逻辑、性能、安全、规范四个维度
3. **问题分类** - 按严重程度对发现的问题进行分类
4. **生成报告** - 输出结构化报告，每个问题附带修复建议和代码示例

***
## Iron Law / 核心铁律

### 🇨🇳
1. **铁律1**: 每个问题必须有明确的文件路径和行号位置。违规示例：❌ "代码中有性能问题"。合规示例：✅ "[UserService.java:45] 循环内重复查询数据库 → 将查询移到循环外"。
2. **铁律2**: 每个问题必须提供具体的修复建议。违规示例：❌ "这个函数太长了"。合规示例：✅ "[UserService.java:120] 函数超过100行 → 拆分为validateUser()、createUser()、sendNotification()三个函数"。
3. **铁律3**: 任何跳过的文件都必须记录原因，且严重程度分类必须保持一致。违规示例：❌ 跳过大型文件不审查。合规示例：✅ "跳过node_modules/目录（第三方依赖）"。

### 🇺🇸
1. **Law 1**: Every issue MUST have file+line location. Violation: ❌ "There's a performance issue". Compliance: ✅ "[UserService.java:45] Database query inside loop → Move query outside loop".
2. **Law 2**: Every issue MUST have fix suggestion. Violation: ❌ "This function is too long". Compliance: ✅ "[UserService.java:120] Function exceeds 100 lines → Split into validateUser(), createUser(), sendNotification()".
3. **Law 3**: Never skip files without documenting why, and severity classification MUST be consistent. Violation: ❌ Skipping large files without review. Compliance: ✅ "Skipping node_modules/ directory (third-party dependencies)".

***
## Rationalization Table / 合理化防御表

| # | Trap / 陷阱 | Question / 请问自己 | Action / 应该怎么做 |
|---|-------------|------------------|------------------|
| 1 | "this file is too large to review properly" | 大文件是否真的无法审查？ | review it in sections |
| 2 | "I'll skip the obvious parts" | 明显的部分是否真的没有问题？ | obvious parts often hide bugs |
| 3 | "this is just a style issue, skip the severity" | 风格问题是否影响代码质量？ | everything must be classified |

***
## Red Flags / 三层防御

### Layer 1: Input / 输入
- **INPUT-01**: no files specified → 🔴 CRITICAL → request specific files to review
- **INPUT-02**: binary file detected → 🔴 CRITICAL → skip binary files and document reason

### Layer 2: Execution / 执行
- **EXEC-01**: review taking too long → 🟡 WARN → suggest splitting large reviews into smaller chunks

### Layer 3: Output / 输出
- **OUTPUT-01**: report has issues without locations → 🔴 CRITICAL → ensure all issues have file+line references
- **OUTPUT-02**: severity not assigned → 🔴 CRITICAL → classify all issues as 🔴严重/🟡警告/🔵建议

**级别标识**: 🔴 CRITICAL → 中断 | 🟡 WARN → 继续+标记 | 🔵 INFO → 记录

***
## Auto-Review / 自检清单
| # | 检查项 |
|---|--------|
| 1 | 所有发现的问题都有明确的文件位置和行号 |
| 2 | 每个问题都提供了具体的修复建议 |
| 3 | 问题按严重程度正确分类（🔴严重/🟡警告/🔵建议） |
| 4 | 输出格式符合标准结构化要求 |
| 5 | 不包含敏感信息或项目特定细节 |
| 6 | 报告内容清晰易懂，便于开发者理解和修复 |