| name | code-review-skills |
| description | 当在本仓库中审查功能改动、缺陷修复、Pull Request 或 git diff,且需要按业务功能实现、代码质量、架构合理性和项目 rules 四个部分输出固定中文审查结果时使用。 |
代码审查技能
概述
这个 skill 是当前仓库的项目级 code review 入口。它不把所有规则都塞进 SKILL.md,而是按“入口、规则、模板”拆分,方便单独维护和复用。
文件职责
SKILL.md
只负责触发条件、使用顺序、文件路由。
references/review-dimensions.md
定义四个审查部分的边界与去重规则。
references/review-checklist.md
提供实际执行时的检查动作。
references/review-inputs.md
定义 review 输入归一化方式,包括 code plan、需求文本、Flash 地址。
references/review-findings-schema.md
定义结构化审查结果字段,供 markdown 和 HTML 复用。
references/review-score-rules.md
定义统一评分机制和结论口径。
references/code-quality-rules.md
提供“代码质量”部分的规则正文。
references/project-rules-index.md
提供项目 rules 的查找入口。
scripts/review-scope.mjs
生成默认 review 范围,基线固定为 origin/master。
scripts/render-review-report.mjs
把结构化 findings JSON 渲染成根目录 HTML 审查报告。
scripts/review-ignore.json
维护不参与 review 的文件与目录。
templates/output-template.md
提供 markdown 输出模板和结构化 findings 约束。
templates/findings-example.json
提供结构化 findings 的示例,降低首次组织 JSON 时的漂移。
templates/reviewer-prompt-addendum.md
只负责把这些文件挂接到标准 reviewer 骨架。
使用时机
- 用户要求审查当前仓库中的分支、PR、提交区间或代码 diff
- 用户希望使用项目定制规则,而不是泛化的 code review
- 用户希望按固定的四段式模版输出 findings,便于团队沟通
- 改动涉及权限、路由、请求封装、环境配置、MBF 生成文件等高风险区域
不要把这个 skill 用在只输出 JSON 的 pre-commit AI review hook 场景。那类场景继续使用 .cursor/skills/code-quality-review。
必要输入
- 审查范围:PR、分支、提交区间,或明确给出的文件列表
- 预期行为:需求说明、工单、实施计划、Flash 地址,或改动摘要
- 证据来源:
git diff、变更文件,以及已有的测试结果或手工验证记录
如果没有提供明确的审查范围,默认审查“当前分支相对 origin/master 的全部 commit 内容”。优先运行 node .cursor/skills/code-review-skills/scripts/review-scope.mjs 生成审查范围,不要手工拼接 diff。
使用顺序
1. 先归一化输入来源
先读 references/review-inputs.md,把用户给出的需求上下文统一成可引用的 review 输入。
- 如果输入是 code plan,提炼目标范围、模块拆分、验收点
- 如果输入是纯需求文本,提炼业务流程、边界条件、关键约束
- 如果输入是 Flash 地址,先调用
mcp-flash 的 get_story_task_description
- 将整理结果归一为统一上下文,再和 diff 做一致性比对,不要直接跳过需求侧信息
2. 再读审查维度
读 references/review-dimensions.md,明确这次 review 分成哪四个部分,以及每个部分的边界。
3. 再读执行清单
读 references/review-checklist.md,按清单组织审查顺序和证据要求。
4. 先确定 review 范围
- 如果用户明确给了
base/head 或文件列表,按用户指定范围审查
- 否则运行
node .cursor/skills/code-review-skills/scripts/review-scope.mjs
- ignore 规则以
.cursor/skills/code-review-skills/scripts/review-ignore.json 为准
5. 按需加载规则正文
6. 先产出结构化 findings,再生成双份报告
结构化产出要求
- markdown 负责终端可读性,HTML 负责结构化归档和分享
- HTML 和 markdown 必须来自同一份 findings 数据,不允许两份内容各写一套
- 每条 finding 至少包含:维度、严重程度、是否必须修复、文件路径、行号、问题描述、风险、证据
- 如果引用了规则或需求,优先给出具体规则文件或需求来源字段
- 如果没有发现问题,也要生成“无审查发现”的 markdown 和 HTML 报告
核心原则
- 优先报告明确缺陷、功能回归、校验缺失、验证缺失,不要把重点放在样式评论上
- 不要因为看到了历史遗留代码就直接报问题,除非这次改动依赖了它,或把它变得更糟
- 不要把生成产物当成唯一真相,要核对对应的源文件或配置是否也一起更新了
- 所有判断都优先引用需求、实施计划、rules 原文或模板文件,不重复改写这些内容
- Flash 地址只是需求入口,不是结论依据;仍然要回到实际 story 详情、任务描述和 diff 证据