| 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 名称写成普通说明。
使用流程
- 确认用户要的是生成 code review prompt，不是直接审查或直接改代码。
- 明确审查范围：
- 当前分支 diff、指定 commit、PR diff、用户指定文件或目录。
- 审查目标：发布前风险、行为回归、接口契约、文档一致性、安全隐私、测试缺口等。
- 读取目标项目
AGENTS.md、README、测试说明和与审查范围相关的规则。
- 读取
references/review-template.md，按项目类型和审查范围裁剪。
- 输出一个完整、连续、可复制的 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 内部包含三反引号，外层使用四反引号或更长围栏。
- 输出代码块前最多写一句中文引导；输出代码块后不要追加额外正文。
自检
输出前逐条检查：
- 是否明确本 skill 生成的是 review prompt，不是直接 review。
- 是否写清审查目标、范围、对比基准和不直接修改代码边界。
- 是否把审查重点按项目类型和风险域模板化。
- 是否要求 findings first、严重程度排序和证据链接。
- 是否包含没有发现问题时的输出规则和测试缺口说明。
- 如果 prompt 中交叉引用其他 skill，是否统一使用
$skill-name 形式。
- 是否没有把旧项目的权限、发布、版本或测试约束硬写进通用 prompt。
