Code Review

---
name: code-review
description: Review changed code for high-confidence bugs, behavior regressions, project-rule violations, and meaningful side effects. Use when the user asks to review, audit, re-check, or inspect code changes, and before committing substantial or high-risk changes when an additional correctness pass is warranted. Focus on changed code and avoid low-value nitpicks.
---

# 代码审查

审查目标是发现真正会影响结果的问题，不是重新设计代码，也不是输出一份通用 Clean Code 建议清单。

## 审查范围

默认从当前 `git diff` 和本次会话实际修改范围开始；用户指定文件、提交或模块时按用户范围审查。

先读取适用于目标文件的 `AGENTS.md`、正式 PRD / 规范和必要的项目上下文。涉及同类实现是否一致时，按 `.agents/skills/code-consistency/SKILL.md` 比较当前项目先例。

不要把本次改动之外的历史问题混入结果。发现无关旧问题可以忽略；只有它被本次改动直接放大或触发时才报告。

## 重点检查

### 1. 业务与逻辑正确性

- 条件、分支、循环、停止条件、状态更新是否与需求一致。
- 是否漏处理本次需求明确覆盖的场景。
- 是否改变原有业务口径、执行顺序、返回值或副作用。
- 边界值、空结果、重复数据等是否会在当前真实业务中产生错误结果。

### 2. 项目规则与实现一致性

- 是否违反当前项目 `AGENTS.md`、PRD 或用户已确认规则。
- 同类问题已有成熟实现时，是否无理由改用了另一套 API、控制流、异常或日志方式。
- 是否为一个小改动引入无必要的新抽象、封装层或长期状态。

### 3. xbot / 外部能力

- 不根据通用 Python、Selenium、Playwright 经验猜 xbot API。
- 当前项目已有相同用法时以项目成熟实现为先；现有用法存在疑问、冲突或本次新增 / 改变 API 时，再按项目 `AGENTS.md` 路由到知识库事实页核验。
- 检查 XPath、字段、请求响应结构、页面状态或 Profile 等是否被本次改动错误假设。

### 4. 异常与失败语义

- 是否吞掉异常后继续把业务当作成功。
- fallback、默认值或空值是否把技术失败伪装成正常业务数据。
- 是否错误扩大 `try/except` 范围，吃掉不应捕获的失败。
- 补充业务上下文时是否仍保留原始异常链。
- 收尾、重试和日志是否会覆盖真正的主异常或误报最终结果。

### 5. 实际副作用

- 是否重复提交、重复点击、重复写回、重复通知或漏执行必要动作。
- 是否因执行顺序变化导致页面、文件、数据库或外部状态与原行为不同。
- 是否修改了用户没有要求变化的接口、配置、持久化格式或长期业务规则。

## 过滤低价值问题

不要报告：

- 纯个人审美、可改可不改的写法。
- “另一种实现也不错”但当前代码没有问题的建议。
- 仅为了 DRY、SOLID、函数更短、抽象更多而提出的重构。
- 格式化、拼写或普通 lint 能直接处理且不影响当前任务的问题。
- 与本次改动无关的既有问题。
- 缺乏实际证据、只是理论上可能发生的低概率问题。

对每个候选问题先判断置信度。只有确定度高、影响明确的问题才输出；可以沿用 0-100 的判断方式，默认只报告 `>= 80` 的问题。

## 输出要求

每个问题至少说明：

- 严重程度与置信度。
- 文件和具体位置。
- 为什么这是实际问题，而不是偏好差异。
- 会造成什么业务或运行影响。
- 最小修复方向。

优先按 `P0 / P1 / P2` 或“严重 / 重要”排序。没有高置信问题时，直接说明未发现需要修改的问题，不为了让 Review 看起来有产出而硬找问题。

代码审查默认只给结论和修复建议；只有用户明确要求修复，或当前任务本身包含“审查并修复”时，才继续修改代码。