---
name: code-reviewer
description: 生成面向 code review 任务的中文 prompt。用于审查代码、文档、配置、PR diff、指定 commit 或发布前风险；默认只生成审查任务 prompt，不直接 review，也不直接修改代码。
---

# code-reviewer

## 技能定位

生成 code review prompt。这个 skill 不直接审查当前代码，也不默认修复问题；它的产物是一份可复制给 Codex/Agent 执行的审查 prompt。

如果用户明确要求“直接 review 当前改动”，可以改用普通审查流程而不是本 skill。若用户要求“审查并修复”，最终 prompt 中也要先要求 findings first，再由用户或任务边界决定是否进入修复。

## Skill 交叉引用规则

如果生成的 code review prompt 需要指向其他 skill，必须使用 `$skill-name` 形式引用，例如 `$project-prompt-creator` 或 `$plan-mode-planner`。不要只写反引号包裹的 skill 名称，也不要把 skill 名称写成普通说明。

## 使用流程

1. 确认用户要的是生成 code review prompt，不是直接审查或直接改代码。
2. 明确审查范围：
   - 当前分支 diff、指定 commit、PR diff、用户指定文件或目录。
   - 审查目标：发布前风险、行为回归、接口契约、文档一致性、安全隐私、测试缺口等。
3. 读取目标项目 `AGENTS.md`、README、测试说明和与审查范围相关的规则。
4. 读取 `references/review-template.md`，按项目类型和审查范围裁剪。
5. 输出一个完整、连续、可复制的 code review prompt。

## 审查重点生成规则

生成 code review prompt 时，不要提供一份固定风险清单让执行者照单审查。固定清单会把审查范围锁死，容易漏掉当前项目真正重要的风险。

最终 prompt 必须要求执行者先建立本轮“项目化风险地图”，再从风险地图生成审查重点。风险地图至少回答：

- 本次改动可能改变了哪些对用户、调用方、维护者或发布流程的承诺。
- 哪些项目不变量、数据状态、交互边界、运行假设或文档承诺可能被破坏。
- 哪些失败模式最难被发现、最难恢复，或者影响面最大。
- 哪些证据足以证明本轮改动没有破坏关键路径。
- 哪些风险来自 `{{项目类型}}`、`{{审查范围}}`、`{{高风险领域}}`、`{{发布审核约束}}`、`{{用户可见文案要求}}` 或用户明确边界。

可以给执行者提供“风险维度示例”，但必须明确它们只是启发，不是完整清单，也不能限制审查范围。生成最终 review prompt 时，应把不适用的示例删除，并要求执行者根据真实仓库补充项目专属风险。

## 输出要求

- 最终 prompt 必须要求审查输出 findings first。
- 默认 code review 只输出审查报告和建议，不直接修改代码。
- 每条 finding 必须包含：严重级别、可跳转 Markdown 相对路径位置、证据、影响、可能的解决方案、验证建议；带行号时统一使用 `[文件名](相对路径#L行号)`，不要把 `:行号` 写进链接目标。
- 每个定位到的问题都要给出可能的解决方案，不能只写“建议修复”。解决方案要说明可行方向、涉及文件、预期影响和需要补充的验证；如果存在多种方案，可以给 1 到 3 个方向，但不要在证据不足时强行拍板。
- 生成的 code review prompt 必须要求审查报告保存为单独 Markdown 文档。用户指定路径时使用用户路径；未指定路径时，要求执行者先根据项目习惯选择合理的 `{{报告目录}}`，例如项目已有 `docs/`、`reports/` 或类似目录，并在执行前说明路径。报告文件名应体现任务主题和日期，但不能写死当前仓库命名。
- 审查报告至少包含：问题清单、严重程度、可跳转 Markdown 相对路径位置、证据摘要、影响说明、可能的解决方案、建议验证方式、是否阻塞合并 / 发布 / 交付、未覆盖风险或测试缺口；文件链接能定位到行号时必须使用 `#L{行号}` 锚点。
- 问题按严重程度排序。
- 如果没有发现问题，也要生成报告，明确说明未发现阻塞项、已检查范围、剩余风险和测试缺口。
- 不要把 review prompt 写成实现 prompt；除非用户明确要求修复，否则只要求审查报告和建议。

## 输出包裹规则

- 最终 code review prompt 必须整体放入一个 Markdown 文本块。
- 如果 prompt 内部包含三反引号，外层使用四反引号或更长围栏。
- 输出代码块前最多写一句中文引导；输出代码块后不要追加额外正文。

## 自检

输出前逐条检查：

1. 是否明确本 skill 生成的是 review prompt，不是直接 review。
2. 是否写清审查目标、范围、对比基准和不直接修改代码边界。
3. 是否把审查重点按项目类型和风险域模板化。
4. 是否要求 findings first、严重程度排序和证据链接。
5. 是否包含没有发现问题时的输出规则和测试缺口说明。
6. 如果 prompt 中交叉引用其他 skill，是否统一使用 `$skill-name` 形式。
7. 是否没有把旧项目的权限、发布、版本或测试约束硬写进通用 prompt。