name: code-review description: 当代码已编写，需要在提交前验证时使用，或当用户请求代码审查或安全检查时。 context: fork agent: code-reviewer

代码审查

概述

审查代码的安全性、正确性和质量。在隔离的代码审查上下文中运行，预加载标准。

开始时宣布: “我正在使用代码审查技能来验证 [文件/功能]。”

过程

步骤1：预加载上下文（主代理）

在调用审查之前加载标准：

读取: .opencode/context/core/standards/code-quality.md
读取: .opencode/context/core/standards/security-patterns.md

步骤2：调用审查

/code-review 路径/到/文件.ts
/code-review src/auth/*.ts
/code-review $(git diff --name-only HEAD~1)

步骤3：分析报告

代码审查器返回结构化的发现：

## 代码审查：认证服务

### 🔴 严重（必须修复）
1. **SQL注入风险** — src/db/query.ts:42
   - 问题：使用未参数化的查询处理用户输入
   - 风险：数据库受损
   - 修复：
     ```diff
     - db.query(`SELECT * FROM users WHERE id = ${userId}`)
     + db.query('SELECT * FROM users WHERE id = ?', [userId])
     ```

### 🟠 高（正确性）
2. **缺少错误处理** — src/auth/service.ts:28
   - 问题：异步函数没有try/catch块
   - 风险：未处理的promise拒绝
   - 修复：包装在try/catch中，并添加适当的日志记录

### 🟡 中（风格）
3. **命名约定** — src/auth/middleware.ts:15
   - 问题：使用snake_case而非camelCase
   - 修复：重命名verify_token → verifyToken

### 总结
总问题数：3（1严重，1高，1中）
建议：请求更改

步骤4：采取行动

如果存在严重或高问题：

停止——不要提交
使用建议的差异修复问题
重新运行 /code-review 以验证
只有在干净时才继续

如果只有中或低问题：

评估是现在修复还是稍后修复
应用质量改进
可以安全提交

如果无问题：

自信地提交
记录积极模式

审查检查

🔴 严重（安全）：

SQL注入、XSS、命令注入
硬编码凭据或密钥
路径遍历、认证绕过

🟠 高（正确性）：

缺少错误处理
类型不匹配
null/undefined间隙
逻辑错误、竞争条件

🟡 中（可维护性）：

命名违规
代码重复
组织不良

🟢 低（建议）：

性能优化
文档改进

错误处理

审查失败：

确保上下文文件已预加载

发现过多：

首先修复严重问题，然后重新审查

发现不清晰：

在报告中请求澄清

红旗警示

如果您想到以下任何一点，请停止并重新阅读此技能：

“代码看起来没问题，审查是多余的”
“我写的，我知道它是正确的”
“我们很赶，可以稍后审查”
“只是个小改动，没有安全风险”

常见合理化

借口	现实
“我刚写的，所以我知道它是正确的”	作者是最差的审查者。新的视角能捕捉到熟悉度掩盖的问题。
“只是个小改动”	安全漏洞几乎总是在小的、“明显”的改动中。
“我们可以在合并后审查”	合并后审查在线上找到错误。合并前审查能免费找到它们。
“没有用户输入，所以没有注入风险”	当需求改变时，内部数据变成用户输入。现在就审查。

记住

在调用审查之前预加载标准
严重和高问题阻止提交
使用代码差异应用建议的修复
修复阻止问题后重新审查
审查不修改代码——只建议更改
审查不运行测试——使用测试生成来做那部分

代码审查Skill code-review