用途
这是一个代码审查技能（Code Review Skill），用于审查由 Claude Code 或人类编写的代码，支持多种语言。当被要求审查、审计、批评或分析代码质量时使用。审查范围覆盖代码的正确性、安全性、性能、测试、文档和架构。
主要能力与审查内容
审查按以下六大类别产出发现，且每个发现都带有严重度评级：
- 正确性：逻辑错误与缺陷、未处理的边界情况、差一错误、空值/未定义处理、类型不匹配、竞态条件。
- 安全：注入漏洞（SQL、命令、XSS）、认证/授权缺陷、代码中的密钥、不安全的反序列化、路径遍历、依赖漏洞。
- 性能：算法复杂度问题、不必要的内存分配、N+1 查询、缺失的缓存机会、阻塞操作、内存泄漏。
- 测试：缺失的测试覆盖、未测试的边界情况、脆弱的测试、缺失的集成测试、不充分的 mock。
- 文档：缺失的函数/类文档字符串、过时注释、不清晰的变量名、缺失的 README 更新、未文档化的公开 API。
- 架构：紧耦合、上帝对象/上帝函数、循环依赖、分层违规、缺失的抽象、关注点分离不佳。
确定审查范围时会识别：单文件、目录、Diff/PR（聚焦改动行及上下文）或整个代码库（从入口点开始、沿依赖追踪）。
审查深度可自动选择或接受用户覆盖：
- Quick（快速）：适用于小改动、琐碎文件、时间紧迫场景，仅关注关键问题。
- Standard（标准）：适用于大多数审查、单文件、典型 PR，覆盖所有类别、均衡审查。
- Deep（深度）：适用于预生产、安全敏感、复杂系统，穷尽式且以安全为重点。
语言检测后会加载相应参考文件：R、Python、JavaScript、SQL、C++、Rust、Go、Ansible、Kubernetes/Kustomize、Dockerfile、Docker Compose、Bash。
使用方式
工作流程如下：
- 在任何代码改动之前，强制使用 context7 查询当前文档。在建议修复或改进之前、审查库/框架用法时、在编写代码示例或片段之前、不确定 API 行为或最佳实践时，都应使用 context7。使用方式为：先执行
context7 resolve <library-name>解析库，再执行context7 get-library-docs --library <library> --topic <topic>获取文档。示例：
context7 resolve react
context7 get-library-docs --library react --topic "useEffect dependencies"
- 确定审查范围。
- 选择审查深度。
- 检测语言并加载参考文件。
- 使用 context7 查询文档：审查任何库/框架用法时、建议代码改动或修复前、检查 API 使用是否正确、验证废弃模式、确认特定版本的最佳实践、在审查反馈中编写代码示例时，始终查询 context7。流程为：识别被审查代码中的库/框架，对每个库使用
context7 resolve <library>，再用context7 get-library-docs验证 API 用法和模式，之后才进行审查发现。示例查询包括 react 的 hooks、tensorflow 的 layers、R tidyverse 模式、kubernetes 清单校验、express 的 Node.js API 模式。 - 使用子代理并行审查：语言子代理（每种检测到的语言一个，审查惯用法、模式及语言特定问题，输出结构化发现）、安全子代理（分析注入、认证问题、密钥暴露、不安全操作、依赖风险，输出带严重度和修复建议的安全发现）、架构子代理（审查整体结构与设计，关注耦合、内聚、关注点分离、设计模式、可测试性，输出架构发现与建议）。
输出
该技能产出两类输出：
输出一：Claude Code 动作格式。产出的结构化发现可供 Claude Code 直接处理，按文件分组、按严重度排序（Critical 优先），每条包含：文件路径、行号与标题、严重度、类别、问题描述、当前代码、建议修复、理由。
输出二：REVIEW.md 人类摘要。写入项目根目录的 REVIEW.md，内容包括：审查范围、深度、日期；总体概述；按严重度列出的发现（Critical、Major、Minor、Nitpicks，各含数量与带文件:行号的单行摘要）；类别分布表（正确性、安全、性能、测试、文档、架构各分级的数量）；优先排序的建议；以及正面观察（做得好的地方，以提供平衡反馈）。
严重度分级
每条发现按以下级别标注：
- Critical（关键）：安全漏洞、数据丢失风险、生产环境崩溃；必须在合并前修复。
- Major（主要）：重大缺陷、性能问题、可维护性阻碍；应在合并前修复。
- Minor（次要）：代码异味、风格问题、轻微低效；方便时修复。
- Nitpick（吹毛求疵）：偏好、非常轻微的风格、可选改进；可考虑修复。
迭代
生成输出后：使用 context7 在实施前验证修复方法；若用户确认，则应用对 Critical 和 Major 问题的修复；重新审查改动后的代码以验证修复未引入新问题；更新 REVIEW.md 中的解决状态。提醒：在建议或实施任何代码改动之前，使用 context7 查询正确的 API 用法。