code-review

代码审查技能

你正在对一个差异进行全面的代码审查。你的任务是分析变更代码中的安全漏洞、反模式和质量问题。

输入模型

此技能需要在调用前将差异放入上下文中。调用方负责生成差异。

调用示例：

• 用户粘贴 PR 差异，然后运行 /code-review
• Agent 运行 git diff HEAD~1，然后调用此技能
• CI 工具提供差异内容以供审查

如果上下文中没有差异，请要求用户提供差异，或提出代为生成（例如，git diff、git diff main..HEAD）。

---

领域检测

根据差异中的目录路径，自动检测要应用的检查清单：

目录	领域	检查清单
designer/	前端	读取 frontend.md
server/	后端	读取 backend.md
rag/	后端	读取 backend.md
runtimes/universal/	后端	读取 backend.md
cli/	CLI/Go	仅通用检查
config/	配置	仅通用检查

如果差异涉及多个领域，请加载所有相关检查清单。

---

审查流程

步骤 1：解析差异

从差异中提取：

• 变更文件列表
• 变更行（新增和修改）
• 根据文件路径检测到的领域

步骤 2：初始化审查文档

使用临时文件模式创建审查文档：

SANITIZED_PATH=$(echo "$PWD" | tr '/' '-')
REPORT_DIR="/tmp/claude/${SANITIZED_PATH}/reviews"
mkdir -p "$REPORT_DIR"
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
FILEPATH="${REPORT_DIR}/code-review-${TIMESTAMP}.md"

使用以下架构初始化：

# Code Review Report

**Date**: {current date}
**Reviewer**: Code Review Agent
**Source**: {e.g., "PR diff", "unstaged changes", "main..HEAD"}
**Files Changed**: {count}
**Domains Detected**: {list}
**Status**: In Progress

## Summary

| Category | Items Checked | Passed | Failed | Findings |
|----------|---------------|--------|--------|----------|
| Security | 0 | 0 | 0 | 0 |
| Code Quality | 0 | 0 | 0 | 0 |
| LLM Code Smells | 0 | 0 | 0 | 0 |
| Impact Analysis | 0 | 0 | 0 | 0 |
| Simplification | 0 | 0 | 0 | 0 |
{domain-specific categories added based on detected domains}

## Detailed Findings

{findings added here as review progresses}

步骤 3：审查变更代码

针对每一项检查清单：

1. 仅针对差异行提供反馈——只标记变更代码中的问题
2. 结合文件上下文——读取完整文件内容，了解周边代码
3. 应用相关检查——使用适用于相应领域的检查项
4. 记录发现——记录变更代码中发现的每项违规

核心原则：审查对象是差异。文件的其余部分仅提供上下文，以确保审查准确。

步骤 4：影响分析

检查差异是否可能影响代码库的其他部分：

• 变更的导出项/接口——搜索其他位置的用法，检查是否可能造成问题
• 修改的 API 签名——检查是否需要更新调用方
• 变更的共享工具——查找可能受影响的使用方
• 配置/架构变更——查找依赖旧结构的代码

将任何未考虑到的影响作为发现项报告，并根据风险确定严重程度。

步骤 5：记录每项发现

对于发现的每个问题，添加一条记录：

### [{CATEGORY}] {Item Name}

**Status**: FAIL
**Severity**: Critical | High | Medium | Low
**Scope**: Changed code | Impact analysis

#### Violation

- **File**: `path/to/file.ext`
- **Line(s)**: 42-48 (from diff)
- **Code**:

// 来自差异的问题代码片段

- **Issue**: {explanation of what's wrong}
- **Recommendation**: {how to fix it}

步骤 6：完成报告

完成所有检查后：

1. 更新汇总表，填写最终数量
2. 添加执行摘要：
   • 发现的问题总数
   • 需要立即处理的严重问题
   • 影响分析结果
   • 建议的修复优先顺序
3. 将状态更新为“Complete”
4. 告知用户报告位置

---

通用审查类别

这些检查适用于所有变更代码，不受领域限制。

---

类别：安全基础

硬编码密钥

检查差异中的：

• 变更代码中的 API 密钥、密码、机密信息
• 模式：api_key、apiKey、password、secret、token、credential 搭配字面值

通过标准：差异中没有硬编码密钥（应使用环境变量） 严重程度：严重

---

Eval 和动态代码执行

检查差异中的：

• JavaScript/TypeScript：eval(、new Function(、setTimeout("、setInterval("
• Python：eval(、exec(、compile(

通过标准：变更行中没有动态代码执行 严重程度：严重

---

命令注入

检查差异中的：

• Python：subprocess 搭配 shell=True、os.system(
• Go：exec.Command( 搭配未经清理的输入

通过标准：Shell 命令中没有未经验证的用户输入 严重程度：严重

---

类别：代码质量

Console/打印语句

检查差异中的：

• JavaScript/TypeScript：console.log、console.debug、console.info
• Python：print( 语句

通过标准：生产代码改动中没有调试语句 严重程度：低

---

TODO/FIXME 注释

检查差异中的：

• TODO:、FIXME:、HACK:、XXX: 注释

通过标准：新增 TODO 应在问题跟踪中记录 严重程度：低

---

空的 Catch/Except 代码块

检查差异中的：

• JavaScript/TypeScript：catch { } 或 catch(e) { }
• Python：except: pass 或空的 except 代码块

通过标准：所有错误处理程序都记录错误或重新抛出错误 严重程度：高

---

类别：LLM 代码异味

占位实现

检查差异中的：

• TODO、PLACEHOLDER、IMPLEMENT、NotImplemented
• 仅执行 return None、return []、return {} 的函数

通过标准：生产代码中没有占位实现 严重程度：高

---

过于通用的抽象

检查差异中的：

• 新增名称类似 GenericHandler、BaseManager、AbstractFactory 的类/函数
• 缺乏明确复用理由的抽象

通过标准：抽象有实际复用需求作为依据 严重程度：低

---

类别：影响分析

破坏性变更

检查差异是否修改了：

• 导出的函数/类——搜索其他位置的导入
• API 端点——搜索调用方
• 共享类型/接口——搜索使用位置
• 配置架构——搜索使用方

通过标准：已识别并考虑所有受影响的代码 严重程度：高（如果发现未考虑的影响）

---

类别：简化

重复逻辑

检查差异中的：

• 重复的代码模式（不只是语法相似）
• 只有细微差异的复制粘贴代码
• 相似的验证、转换或格式化逻辑

通过标准：修改后的代码中没有明显重复 严重程度：中 建议：将共享逻辑提取到可复用函数中

---

不必要的复杂性

检查差异中的：

• 深度嵌套的条件语句（超过 3 层）
• 执行多个无关操作的函数
• 过于复杂的控制流

通过标准：代码结构合理扁平且职责明确 严重程度：中 建议：使用提前返回，并提取辅助函数

---

冗长模式

检查差异中的：

• 该语言中有更简单替代方案的模式
• 多余的 null 检查或类型断言
• 不必要的中间变量

通过标准：代码采用符合惯用法的模式 严重程度：低 建议：使用语言内置功能简化代码

---

特定领域的审查项

根据检测到的领域，阅读并应用相应的检查清单：

• 检测到前端（designer/）：阅读 frontend.md，并将其中的检查项应用于修改后的代码
• 检测到后端（server/、rag/、runtimes/）：阅读 backend.md，并将其中的检查项应用于修改后的代码

---

最终摘要模板

## Executive Summary

**Review completed**: {timestamp}
**Total findings**: {count}

### Critical Issues (Must Fix)
1. {issue 1}
2. {issue 2}

### Impact Analysis Results
- {summary of any breaking changes or unaccounted impacts}

### High Priority (Should Fix)
1. {issue 1}
2. {issue 2}

### Recommendations
{Overall recommendations based on the changes reviewed}

---

给 Agent 的说明

1. 限定差异范围：仅指出修改行中的问题。不要审查未修改的代码。

2. 结合上下文：阅读完整文件以理解修改内容，但反馈仅针对差异。

3. 检查影响：如果修改涉及导出项、API 或共享代码，请搜索受影响的使用方。

4. 具体说明：每项发现都应包含文件路径、行号（以差异中的行号为准）和代码片段。

5. 确定优先级：立即指出关键安全问题。

6. 提供解决方案：每项发现都应包含修复建议。

7. 增量更新：每完成一个类别，就更新审查文档，不要等到最后。