philip-cao-9527/code-note-helper/code-reviewer

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、用户指定文件或目录。
• 审查目标：发布前风险、行为回归、接口契约、文档一致性、安全隐私、测试缺口等。

1. 读取目标项目 AGENTS.md、README、测试说明和与审查范围相关的规则。
2. 读取 references/review-template.md，按项目类型和审查范围裁剪。
3. 输出一个完整、连续、可复制的 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。