code-review

代码审查：深度正确性审计

找出真正会导致问题的错误。不要关注风格或代码质量问题，而要关注会在生产环境中造成影响的正确性、可靠性和逻辑错误。

此技能与 code-simplification（代码质量／风格）和 security-audit（漏洞／OWASP）互为补充。前两者分别检查“代码是否整洁？”和“代码是否安全？”，而此技能检查“代码是否真的能正常工作？”

涵盖：TypeScript/JavaScript、Python、Go、Java、Bash/Shell 和 基础设施即代码（Terraform、Ansible、Helm、Kubernetes、Docker/Compose、Proxmox/LXC）。通用模式适用于所有语言；语言特定章节则提供针对性检查。

适用场景

• 审查近期更改中的错误、回归问题、边缘情况或脆弱假设
• 在合并或发布前检查代码是否可靠
• 查找静态工具可能遗漏的逻辑错误
• 进行重点关注正确性、次要关注风格和安全性的审查

三个问题

每个发现都要回答以下一个问题：

1. 会崩溃吗？——空值解引用、未处理的错误、资源耗尽、缺少导入
2. 会做错事吗？——逻辑错误、差一错误、比较错误、遗漏情况
3. 以后会出问题吗？——竞态条件、隐式排序、脆弱假设、API 契约偏移

不适用场景

• 风格、冗长程度或机器生成代码的质量问题——使用 code-simplification
• 可利用的漏洞、身份验证缺陷或密钥扫描——使用 security-audit
• 流水线配置审查、流水线架构、运行器行为、缓存或部署任务错误——使用 ci-cd
• 会话结束时的文档整理或指令文件清理——使用 update-docs

AI 自检

在报告置信度不低于 80% 的发现之前，请确认：

• 阅读完整上下文：阅读整个函数／文件，而不只是标记的代码行；如果错误取决于调用方式，也要查看调用方。孤立来看似乎有问题的模式，在上下文中可能是正确的
• 检查测试：是否有覆盖此情况的测试？测试本身是否正确？
• 检查 git blame：这是新代码还是经过长期验证的代码？仅在限定于差异范围的审查中排除已有问题
• 检查解释性注释：注释说明了意图；请确认实现确实符合该意图
• 引用证据：提供约定审查范围内能证明问题的确切文件、行号和代码。没有引用 = 没有发现
• 对抗性自检：逐条反驳每个发现。如果反驳理由成立，就放弃该发现
• 构造失败案例：每个发现都要描述一个合理的失败输入、竞态、泄漏或回归；对于 P0 级发现，要给出触发错误的具体输入或操作顺序
• 验证 API／标准库相关说法：不要凭记忆断言 API 或标准库的行为。18% 的“高置信度”AI 审查建议在框架行为方面存在事实错误；因此，在将某项问题列为发现之前，应查证函数是否稳定排序、是否返回视图，或是否处理空值
• 检查被标记数值输入的边界值：根据实际输入契约和调用方，追踪零、负数和溢出值；只有确认存在可触发的失败后，才能给出相应置信度
• 应用跨领域的 Agent 卫生规范——参见 references/agent-hygiene.md

---

工作流

步骤 1：确定审查范围

根据上下文确定默认范围：

• 如果是在本次会话中刚写完代码后调用 → 自检（审查刚写的内容）
• 如果有未提交的更改（git diff --name-only）→ 近期更改
• 如果用户指定了文件／目录／提交 → 定向审查
• 如果用户要求审查整个代码库 → 全代码库审查，按“在大型代码库中确定优先级”中的方式安排优先级，并按类别报告
• 否则 → 询问用户

大型差异（> 500 行）： 按文件分块。结合周边上下文审查每个文件，然后进行跨文件检查，查找集成问题（边界间类型不匹配、错误处理不一致、调用链断裂）。大型差异本身也是值得在“观察”中指出的代码异味。

步骤 2：收集项目上下文

审查任何代码之前，先了解项目背景：

1. 阅读项目指令文件（如存在 AGENTS.md 或等效文件）——了解项目惯例、模式和已知陷阱
2. 检查项目使用的语言／框架版本（package.json、pyproject.toml、go.mod 等）
3. 了解架构——单体应用、微服务、命令行工具还是库？
4. 留意自定义错误处理模式、日志惯例或测试要求

这些背景信息有助于避免误报。在 React 应用中不恰当的模式，在 Node 命令行工具中可能完全正确。

步骤 3：优先运行机械检查（若可用且切实可行）

手动审查前，运行标准工具以排除明显问题——但仅在合适时运行：

• TypeScript：tsc --noEmit / eslint（如果没有 tsconfig.json / .eslintrc*，或项目有 500 个以上 TS 文件、运行过慢，则跳过）
• Python：ruff check / mypy（如果没有 pyproject.toml / ruff.toml / mypy.ini，则跳过）
• Shell：shellcheck（运行速度快；如果已安装，始终值得运行）
• Terraform：terraform validate（如果尚未运行 terraform init，则跳过——validate 需要已初始化的提供程序）
• Ansible：ansible-lint（如果没有 .ansible-lint 配置且项目并非主要使用 Ansible，则跳过）

跳过工具的情况：

• 项目中没有该工具的配置文件（没有 tsconfig.json、pyproject.toml 等）
• 审查的是小型差异（< 5 个文件）——为 3 个文件的更改检查整个项目是徒劳的
• 用户只想快速审查，而不是全面审计

工具未安装时（使用 command -v <tool> 检查）：不要默默跳过。告知用户一次缺少哪些工具、对应的软件包名称和安装命令（例如“未安装 shellcheck——可考虑运行 pacman -S shellcheck”），然后继续审查。

Linter 会通过机械检查发现语法、导入和已知反模式。这项技能关注自动化工具无法发现的问题：逻辑错误、边界情况、不正确的假设，以及需要理解意图才能发现的细微 Bug。不要在 Linter 输出上浪费时间和 Token——转而进行实际审查。

步骤 4：从四个重点方面进行审查

从四个角度审查代码。这些并非按顺序进行的检查步骤，而是阅读代码时需要评估的几个维度。顺序体现了优先级：首先理解意图，因为其他一切都依赖于此。

重点 1：理解意图 阅读代码，了解它应该实现什么功能。如果审查的是差异，也要阅读相关上下文。查看提交消息、PR 描述或注释，了解说明的意图。不知道什么才算“正确”，就无法发现错误。

重点 2：追踪逻辑路径 跟进每条代码路径。对于每个分支、循环或条件：

• 正常路径会发生什么？
• 每条错误路径会发生什么？
• 边界情况（空、零、最大值、null、负数）会发生什么？
• 是否处理了所有情况？（switch/match 是否穷尽，if/else 是否完整）

边界值分析值得特别关注。请根据函数契约和实际调用方，追踪 page=1、page=0、page=-1、页面大小为零、最后一页以及算术溢出的情况。如果无效输入可能到达某个会失败或返回错误结果的操作，请报告缺少保护检查的问题。LIMIT 超出剩余 SQL 行数通常是有效的；切片结束位置超出数组范围则可能导致 panic。不要臆测后续会发生除法，也不要假设每个数值边界都是错误。与其他问题一样，采用相同的证据和置信度标准。

重点 3：检查契约与边界 检查组件之间的每个接口：

• 函数签名：调用方传入的类型和形状是否正确？
• API 边界：输入在使用前是否经过验证？
• 状态转换：是否检查了前置条件？
• 错误传播：错误是否包含足够的上下文？
• 资源生命周期：获取和释放操作是否对称？
• 下游影响：审查对导出函数、接口或 API 端点的更改时，使用 grep 查找所有调用方/使用方。更改配置/环境变量时，检查所有引用已更改键的文件。一个文件中的布尔开关可能导致十二个模块中的功能标志逻辑失效。

重点 4：遵循约定 检查是否符合项目特定的正确性规则，而非代码风格（那属于代码简化），重点关注影响代码能否正常工作的规则：

• 项目指令文件中关于错误处理、事务、API 模式的规则
• 与周边代码的错误处理和状态管理是否一致
• 影响正确性的框架惯用模式（不只是风格）
• 关键路径是否需要测试覆盖

步骤 5：为每项发现评分

使用 0–100 的置信度评分来评估每个潜在问题：

分数	含义	操作
0	误报。经不起仔细推敲。	丢弃
25	可能是真的，也可能是有意为之或取决于上下文。	丢弃
50	证据不一；尚未确认存在问题。	丢弃
75	极有可能是真的，但仍有重要假设未确认。	边界情况
80+	有具体证据和上下文支持；严重程度另行评估。	报告
100	确凿无疑。代码肯定有问题，证据毫无歧义。	报告

只报告评分 >= 80 的发现。 重质不重量。报告 3 个真实 Bug，胜过报告 20 个不确定问题。

自查模式例外： 审查你在本次会话中刚编写的代码时，将阈值降至 >= 70%。现在修复成本几乎为零，而且可以跳过 git blame 步骤（所有代码都是新写的）。重点检查逻辑路径和契约——新写的代码最容易在这些方面出错。

发现数量上限： 如果可报告的发现超过 8–10 个，就说明有问题——代码可能糟糕到无可救药（请在摘要中说明），或者你的阈值太低。务必严格筛选。冗长的审查报告往往会被忽略。

对于每项重要的代码更改，请问：最可能出现的三种故障模式是什么？ 这个问题能发现逐行审查容易漏掉的架构级 Bug，尤其是 AI 生成的代码：单独看每一行都没问题，但整体设计却存在缺口。

评分前，请先执行上方的 AI 自查清单。如果你无法引用证据或构造出会导致故障的输入，就应针对该发现返回步骤 4，或降低评分，而不是报告它。

步骤 6：报告

按严重程度归类呈现发现，并提供具体修复建议。请参阅下方的输出格式。

---

通用模式（所有语言）

阅读 references/universal-patterns.md，了解完整的跨语言 Bug 目录。

完成审查前，请务必检查以下十类问题：

• 逻辑错误
• 空值或缺失值隐患
• 错误处理缺口
• 竞态条件和共享状态问题
• 资源泄漏和生命周期不匹配
• 边界或边缘情况导致的问题
• API 和数据契约不匹配
• 实际性能陷阱
• 影响正确性的约定违规
• 虽然通过但未能证明行为正确的测试

标准很简单：如果某个问题可能导致返回错误结果、在现实路径上崩溃，或随时间悄然恶化，就应纳入审查。

---

大型代码库中的优先级排序

审查包含 100+ 个文件的完整代码库时，你不可能逐一阅读所有内容。请按以下优先级处理：

1. 近期更改的文件（git log --since='2 weeks ago' --name-only）——新代码更容易有 Bug
2. 关键路径——身份验证、支付、数据修改、API 处理程序、中间件
3. 入口点——主文件、路由定义、CLI 命令、事件处理程序
4. 没有测试的文件——git ls-files '*.ts' | while read f; do test -f "${f%.ts}.test.ts" || echo "$f"; done
5. 复杂文件——长函数、高圈复杂度、分支众多
6. 共享实用工具——此处的 Bug 会影响整个代码库

跳过：供应商代码、生成文件、测试夹具/快照、文档、静态资源。

对于针对性审查（差异/特定文件），先检查发生更改的公共接口、共享实用工具、迁移，以及并发边界；然后阅读被更改文件的完整内容，以及它们的直接调用方和被调用方。上下文很重要——单独看似乎没问题的函数，可能会被错误调用。请使用测试和静态分析验证怀疑的问题，而不是按顺序通读整个代码库。

---

语言：TypeScript / JavaScript

完整的 TS/JS Bug 模式目录请参阅 references/typescript.md。重点包括：

• Promise 陷阱：缺少 await、未处理的拒绝、Promise.all 部分失败、async void
• 类型收窄漏洞：类型断言（as）绕过运行时检查、判别联合类型未穷尽检查
• 闭包陷阱：循环／副作用中的闭包过期、异步回调捕获可变变量
• React 特有问题：缺少依赖数组、渲染期间更新状态、副作用中的内存泄漏
• Node 特有问题：未处理的流错误、EventEmitter 缺少 error 事件处理程序

语言：Python

完整的 Python Bug 模式目录请参阅 references/python.md。重点包括：

• 可变默认参数：def foo(items=[])——该列表会在多次调用之间共享
• 异常处理：裸 except: 会捕获 KeyboardInterrupt/SystemExit，异常链会丢失上下文
• 迭代器耗尽：生成器被重复消费且不会发出提示，map()／filter() 返回迭代器而非列表
• 导入副作用：循环导入、导入时运行的模块级代码
• 异步陷阱：混用同步与异步代码、阻塞事件循环、缺少 await
• Dataclass/pydantic Bug：可变默认字段未使用 default_factory、验证器副作用、model_validate() 会强制转换不可信输入
• 属性拼写错误：在普通类中，self.nmae = name 会悄悄创建新属性——请使用 __slots__ 或 @dataclass(slots=True)

语言：Bash / Shell

完整的 Shell Bug 模式目录请参阅 references/shell.md。重点包括：

• 单词拆分：未加引号的变量会因空格而拆分，在意外位置发生 glob 展开
• 退出码掩盖：管道会隐藏失败（cmd1 | cmd2 只检查 cmd2），$(...) 的错误会被 local／export 声明掩盖
• 信号处理：缺少用于清理的 trap、后台进程未清理
• 可移植性：#!/bin/sh 脚本中使用 bash 专属语法、GNU 与 BSD 工具差异

语言：Java

完整的 Java Bug 模式目录请参阅 references/java.md。重点包括：

• Quarkus：CDI 作用域线程安全（@ApplicationScoped + 可变状态）、响应式管道中 @RequestScoped 丢失、Uni／Multi 从未订阅、原生镜像反射、开发服务配置漂移（在生产环境使用 drop-and-create）
• Spring Boot：@Transactional 代理陷阱（自调用、非公开方法、final 方法、受检异常）、SecurityFilterChain 顺序、WebFlux 阻塞调用、Reactor 上下文／MDC 丢失
• Java 常见问题：对可空值使用 Optional.of()、重复使用流、延迟求值逃逸出 try-catch、ConcurrentHashMap 的检查后执行竞态、equals/hashCode 契约、lambda 中受检异常被吞掉
• 现代 Java 17+：虚拟线程因 synchronized 而固定、Loom 中 ThreadLocal 导致内存激增、密封类 IncompatibleClassChangeError、StructuredTaskScope 泄漏
• AI 生成的 Java 代码：框架混淆（在 CDI 中使用 @Autowired）、泛型过度复杂、并发问题意识不足（发生率高出 2 倍）、安全捷径（发生率高出 1.5～2 倍）

语言：基础设施即代码

阅读 references/iac.md，了解完整的 IaC Bug 模式目录。重点包括：

• Terraform：资源依赖关系错误或缺失、create_before_destroy 生命周期问题、手动更改导致状态漂移、数据源竞争条件
• Ansible：未通知处理程序、变量优先级带来的意外、when 条件中使用未定义变量、幂等性违规
• Helm：模板渲染错误只有在部署时才会显现、值类型不匹配、缺少必需值
• Kubernetes：存活探针错误地终止健康 Pod、资源限制导致 OOMKill、缺少用于高可用的 PDB
• ArgoCD：生产环境启用自动同步和 prune、同步波次顺序、健康检查配置错误、应用集群的集群目标选择
• Docker：ENTRYPOINT 使用 shell 形式而非 exec 形式、多阶段构建时从错误阶段执行 COPY、ARG 在多个 FROM 之间的作用域、缺少 .dockerignore
• Compose：depends_on 未搭配 condition: service_healthy（启动顺序竞争条件）、restart: always 未搭配健康检查（无限崩溃循环）、仍保留 version 字段（自 Compose v2 起已弃用）
• Proxmox/LXC：API 令牌权限范围过宽、LXC 使用 nesting=1 却未启用 keyctl=1（导致 Docker 无法在其中运行）、Terraform telmate/proxmox provider 未锁定版本（可能发生破坏性变更）、Proxmox 与来宾系统的 cloud-init 网络配置不匹配、本可使用链接克隆却使用了 full_clone

CI/CD 流水线

仅涉及流水线的发现应归类到 ci-cd。本参考资料用于追踪应用更改跨越交付边界的过程，并非第二次流水线审计。

阅读 references/cicd-pipelines.md，了解完整的 CI/CD Bug 模式目录。重点包括：

• GitLab CI/CD：混用 rules: 与 only:/except:（会被静默拒绝）、无条件的末尾规则创建不需要的任务、缺少 workflow:rules 导致流水线重复、在 rules: 中使用 dotenv 变量（此时变量尚不存在）、受保护变量在非受保护分支上静默为空
• GitHub Actions：通过 ${{ }} 将用户控制的输入注入表达式、GITHUB_TOKEN 权限范围过宽、可复用工作流的输入类型不匹配、并发组 Bug 取消了错误的运行
• Forgejo Actions：与 GitHub Actions 的兼容性差异（功能缺失、运行器行为不同、密钥处理方式不同）
• ArgoCD 高级模式：ApplicationSet 生成器冲突、多源 Application 的陷阱、基于注解的同步选项悄然改变行为、渐进式交付的回滚顺序
• Terraform 高级模式：状态锁定竞争条件、工作区隔离失败、provider 别名混淆、moved 块破坏计划、import 块的限制

AI 时代模式

使用本参考资料查找具体的行为缺陷。命名、风格和抽象偏好属于 code-simplification；漏洞发现属于 security-audit。模式匹配和历史统计数据只是调查线索，不能作为审查代码的证据。

阅读 references/ai-age-patterns.md，了解完整的 AI 时代 Bug 模式目录。重点包括：

• AI 生成代码的异味：虚构的 API/依赖（样本中占 1/5）、过时训练数据带来的弃用模式、过度防御式错误处理、不必要的抽象、不安全的默认设置
• Agentic AI 模式：提示词注入（OWASP LLM 2025 排名第 1）、未对 LLM API 调用进行速率限制、上下文窗口溢出、流式处理边缘情况、工具/函数调用验证缺口
• LLM SDK Bug：提供商 SDK 中流式处理与工具调用的交互、适用时保留推理块、结构化输出陷阱、缺少令牌限制或默认值
• MCP 漏洞：命令注入（43% 的服务）、工具投毒（5% 的开源服务）、路径遍历、SSRF、跨租户数据泄露

数据库

阅读 references/databases.md，了解完整的数据库 bug 模式目录。重点包括：

• 通用 SQL：事务误用（部分写入、未回滚）、NULL 处理（NOT IN 中含 NULL 时返回 0 行）、迁移 bug（在已有表上添加不带 DEFAULT 的 NOT NULL 列）
• PostgreSQL：混淆 timestamp 和 timestamptz、连接池耗尽、jsonb 运算符混用（-> 和 ->>）、事务空闲阻塞 autovacuum
• MongoDB：将普通替换文档传给 updateOne/updateMany（更新文档无效）、字段名称拼写错误导致静默匹配不到内容、写关注 w:0 导致数据丢失、无模式设计造成类型不一致
• MySQL/MariaDB：非严格模式下静默截断数据、utf8 并非真正的 UTF-8（应使用 utf8mb4）、GROUP BY 返回任意值
• MSSQL：@@IDENTITY 和 SCOPE_IDENTITY() 的区别、VARCHAR 无法存储 Unicode（应使用 NVARCHAR）、TOP 未搭配 ORDER BY
• ORM 陷阱：N+1 查询、实体缓存过期、枚举按序号存储（重新排序会破坏数据）、在生产环境中自动执行 DDL

语言：Go

阅读 references/go.md，了解完整的 Go bug 模式目录。重点包括：

• Goroutine 泄漏：goroutine 阻塞在没有接收方的通道上、缺少 context/done 信号、未使用 WaitGroup
• Nil 接口陷阱：接口中存放着一个类型化的 nil 指针时，该接口并非 nil——以 (*MyError)(nil) 形式返回的 error 无法通过 nil 检查
• Defer 顺序：按 LIFO 顺序执行、闭包按引用捕获变量、在循环中使用 defer 导致文件描述符耗尽
• 通道死锁：同一 goroutine 中对无缓冲通道发送和接收、重复关闭导致 panic、循环中的计时器分配和版本相关的保留行为
• 错误包装：fmt.Errorf 中 %s 和 %w 的区别、使用 == 而非 errors.Is() 比较哨兵错误、自定义错误缺少 Unwrap()
• Context 泄漏：使用 context.WithCancel/WithTimeout 后未执行 defer cancel()、忽略请求级 context
• 数据竞争：并发写入 map（会触发致命 panic）、共享切片追加、未同步的读-改-写操作、CI 中缺少 -race
• 循环变量捕获：Go 1.22 之前的闭包捕获 bug。先检查 go.mod：go 1.22 或更高版本使用每次迭代各自的变量（安全）；低于 1.22 时，所有 goroutine/闭包共享同一个循环变量（经典捕获 bug）。此检查受版本限制——标记问题前先读取 go.mod。如果没有 go.mod，应将版本条件注明为尚未确认的检查；不要将依赖版本的 bug 报告为已确认问题。

其他语言

对于 Rust 和其他没有专用参考文件的语言：仅应用通用模式（第 1-10 节）。在报告中注明，语言专属检查仅限于通用模式。

---

不要标记的问题

• 风格／质量问题——这是 code-simplification 的工作。
• 安全漏洞——这是 security-audit 的工作。
• 已有的 Bug——审查差异时，未被当前更改触及的代码行中的问题。
• Linter／编译器可以发现的问题——缺少导入、类型错误、格式问题。工具链会处理这些问题。
• 有意为之的权衡——解释“我们因为 Y 而执行 X”的代码注释表明这是有意为之；但如果能证明该做法未达到预期，仍应标记。
• 仅用于测试的代码——测试夹具／辅助函数中较宽松的错误处理通常没有问题。
• 边界处的防御性代码——对外部数据进行输入验证是正确做法，不是 Bug。
• 已知的框架特性——看起来不正确但符合框架惯用模式的写法。
• 带问题引用的 TODO——// TODO(#1234) 表明相关问题已被注意到，并非疏忽。
• 生成／供应商代码——锁定文件、编译输出、自动生成的类型、供应商依赖、ORM 迁移。
• 之前已审查的代码——如果在同一会话中多次调用，请关注上次审查后的更改。
• 重写请求——除非当前结构妨碍正确性或可维护性，否则不要要求重写。
• 普遍缺少测试——只有当某个特定行为或风险需要覆盖时，才指出缺少测试。

---

严重性分类

每条报告的问题（置信度 >= 80）都使用统一的严重性级别：

• P0——必须修复：在正常使用中会导致崩溃、数据损坏或结果错误。包括常见路径上的空值解引用、数据丢失、影响正确性的竞态条件、会掩盖故障的错误传播问题，以及通过逻辑错误绕过身份验证等与安全相关的逻辑错误。
• P1——应该修复：在特定的现实条件下会导致问题，或随着时间推移降低可靠性。包括边缘情况崩溃、资源泄漏、最终会触发的性能陷阱、对外部操作缺少错误处理，以及会在此代码库中导致 Bug 的惯例违规。
• P2——建议修复：优先级较低的正确性风险、针对已确认 Bug 缺少专项回归测试，或存在合理未来故障模式的可维护性问题。
• P3——待办事项：确实存在但不紧急的后续工作，不应阻碍已审查的更改。
• info——仅供参考：已核实的观察结果，无需立即采取行动。

经验法则：如果问题严重到要在凌晨 2 点叫醒别人，那就是 P0。如果可以等到下一个迭代，就是 P1。如果适合列入待办事项，但仍存在合理的故障模式，就是 P2／P3。

---

输出格式

使用 references/report-format.md 中的报告模板：一个模板用于按严重性分组的问题，并提供修复前后对比；另一个模板用于无问题的审查，但仍列出已检查的内容以及运行或缺失的 linter。编写最终报告前，请先阅读该文件。

---

参考文件

• references/universal-patterns.md——跨语言 Bug 模式和故障模式
• references/typescript.md——TypeScript 和 JavaScript Bug 模式
• references/python.md——Python Bug 模式
• references/shell.md——Shell Bug 模式
• references/java.md——Java Bug 模式
• references/go.md——Go Bug 模式
• references/iac.md——基础设施即代码 Bug 模式
• references/cicd-pipelines.md——CI/CD 流水线 Bug 模式
• references/ai-age-patterns.md——AI 时代的正确性模式和由幻觉驱动的 Bug
• references/databases.md——应用层数据库 Bug 模式
• references/report-format.md——问题报告和无问题审查的报告模板（在第 6 步阅读）

---

输出约定

完整约定见 references/output-contract.md。

• 技能名称： CODE-REVIEW
• 交付物类别： audits
• 模式： 始终启用。每次调用都遵循 references/output-contract.md 中的报告篇幅和证据规则。
• 交付物路径： docs/local/audits/code-review/<YYYY-MM-DD>-<slug>.md
• 严重性级别： P0 | P1 | P2 | P3 | info（见统一约定）。

相关技能

• code-simplification — 负责处理风格、质量和机器生成代码模式。如果发现的问题是“难看但正确”，则转交给 code-simplification。如果会导致行为错误，则保留在此处。
• security-audit — 负责检测漏洞（注入、绕过身份验证、凭据泄露）。Code-review 捕获逻辑错误；security-audit 捕获可被利用的漏洞。
• repo-audit — 并行协调 code-review、code-simplification、security-audit 和 update-docs。Code-review 是四项检查之一。
• databases — 此技能中的 references/databases.md 涵盖应用层数据库错误模式。databases 技能涵盖引擎配置和运维。
• git — 用于创建 PR/MR 和执行 git 操作。Code-review 评估 PR 中的代码；git 负责创建和管理 PR/MR。

---

规则

• 标记问题前先阅读。 切勿标记尚未在完整上下文中阅读的代码（参见 AI Self-Check）。
• 是错误还是风格问题？ 如果不确定某项发现是错误还是风格问题，请问自己：“这会导致行为错误吗？”如果不会，就跳过；风格问题和漏洞按“不要标记的内容”中的说明转交处理。
• 每个错误报告一项发现，而不是每次出现都报告。 如果同一种模式出现在 5 个文件中，报告一次并列出受影响的位置。不要凑数。
• 给出修复方案。 每项发现都必须包含具体的代码修复方案，而不只是描述问题。如果无法给出修复方案，说明该发现不够具体。
• 不要重复报告已被驳回的发现。 如果用户在本次会话中确认或驳回了某项发现，后续调用时不要再次报告。你已经提醒过一次了。