name	code-review
description	按照团队 Code Review 规范审查代码变更（本地 git diff 或 GitHub PR）。当用户要求 review 代码、审查 PR、或检查代码质量时触发。

Code Review

依据团队约定，对本地代码变更或远程 GitHub PR 进行结构化审查。

约束

所有审查反馈仅在本地输出，不推送到 GitHub。
审查必须严格按照工作流顺序执行，不得跳过任何环节。

审查工作流

Step 1：获取变更内容

远程 PR：

读取 GitHub MCP 工具的 schema
通过 GitHub MCP 拉取 PR 元信息、变更文件列表及文件级 diff
按文件维度聚合后，进入后续审查环节

gh CLI 仅作为本地兜底手段，远程场景优先走 MCP。

本地变更：

git diff
git diff --staged
git diff <base-branch>...HEAD

大规模变更（> 500 行）：先用 git diff --stat 输出文件级概览，按模块分批审查，防止一次性处理遗漏细节。

Step 2：变更摘要

在深入审查前，先建立对本次变更的全局认知：

目标：从 PR 标题、描述、关联 Issue/Ticket、commit message 中提炼业务意图
核心改动：一句话概括做了什么，再按模块分组罗列关键变更
动机：为什么做这个改动（修缺陷、重构、新功能、性能调优），PR 描述有说明则直接引用
波及面：预判可能受影响的功能区域，为后续逐文件审查建立上下文

如果 PR 描述缺失或含糊，在输出中标注「PR 描述信息不足，以下基于 diff 推断」

Step 3：影响点评估

在架构判断之前，先厘清本次变更对已有系统的影响：

是否修改了公共组件、共享状态、API 签名等具有传播性的代码？
影响了哪些下游模块或页面？
是否存在潜在的回归风险？

无影响则注明「无」，有影响则逐条列出受影响的范围和风险点。

Step 4：架构评估

从宏观视角审视整体设计：

耦合度与可扩展性是否经过考量？
是否存在不必要的抽象层或冗余设计？
代码是否放在了合理的模块/目录下？
新增的公共 API 或组件是否确实有必要？
是否引入了循环依赖或层级倒置？

架构层面存在问题时应优先指出——结构不对，逐行纠错没有意义。

Step 5：逐文件审查

按文件逐一检查，对照 RULES.md 中的规则分类进行判断。

审查优先级（风险优先，风格靠后）：

正确性 — 行为错误、状态异常、数据闪烁
安全与权限 — 越权访问、数据泄露
可维护性 — 重复逻辑、魔法值、职责混乱
一致性 — 是否遵循项目既有约定
体验细节 — 加载态、交互动效、响应式适配

Step 6：格式化输出

每条反馈附带严重等级标签：

标签	含义	是否阻断合并
`[Required]`	必须修改	是
`[Optional]`	建议改进	否（作者应说明是否采纳）
`[Question]`	需要作者澄清	澄清后可能升级为 Required
`[FYI]`	信息同步	否

每条反馈遵循 三段式：问题 → 原因 → 建议方案。

输出结构：

# 审查结果

## 变更摘要

**目标：** <本次变更要解决的问题或需求>
**核心改动：** <一句话概括>
**动机：** <为什么改>
**波及面：** <涉及的功能区域>

## 影响点评估

<对已有功能的影响范围及风险点，无影响注明「无」>

## 架构评估

<整体设计是否合理，如有问题在此列出>

## 逐文件反馈

### <文件名>

#### [Required] <简短标题>
**定位：** [`<文件路径>:<起始行>-<结束行>`](<文件路径>)

<问题代码片段（使用 CODE REFERENCES 格式引用源码）>

**问题：** <哪里有问题>
**原因：** <为什么有问题>
**建议：** <如何修复（如有修复代码，用 markdown 代码块展示）>

## Next Steps

共发现 X 个问题（Required: _、Optional: _、Question: _、FYI: _）。

**如何处理？**

1. **全部修复** — 自动修复所有问题
2. **仅修复 Required** — 只处理阻断项
3. **指定修复** — 告诉我要修复哪些
4. **仅审查** — 不需要修改，审查结束

Step 7：自动修复

用户选择修复方案后，Agent 按照反馈逐条实施代码修改：

按文件顺序依次修改，每处改动对应一条反馈
修改完成后重新运行 lint 和类型检查，确保不引入新问题
最终输出修改清单，列出每条反馈的处理结果

输出规范

无问题时：不能只说"没问题"，必须说明检查了哪些方面、未覆盖的范围、以及残留风险或建议的后续验证。

定位要求：

每条 [Required] / [Optional] / [Question] 反馈必须给出 定位 字段
格式：[src/xx/file.tsx:10-24](src/xx/file.tsx)（可点击跳转）
多处问题拆成多条反馈，各自标注定位，避免一条反馈覆盖多个不连续区域

代码展示要求：

每条反馈必须附带问题代码片段，使用 CODE REFERENCES 格式引用源码
修复建议的代码使用标准 markdown 代码块展示（带语言标签）
不允许只描述问题而不展示代码

Blocking 清单

以下类型的问题始终标记为 [Required]，不可降级：

用户可感知的行为错误
权限或安全漏洞
违反已确定的技术约束
可预见的回归风险
绕过静态检查的注释

作者自查清单

权限控制与角色匹配
无硬编码魔法值
复用了已有公共能力
关键交互已验证多端表现
公共资源变更已补充测试

辅助脚本

fetch-pr-comments.mjs — 从 GitHub 拉取历史 PR Review 评论，写入 review-log.md。用于积累团队审查知识库，不参与审查流程本身。

GITHUB_TOKEN=<token> node .cursor/skills/code-review/scripts/fetch-pr-comments.mjs --owner <org> --repo <repo>

参考

审查规则分类：RULES.md
项目约定：.cursor/rules/（根据你的项目自行维护）

name	code-review
description	按照团队 Code Review 规范审查代码变更（本地 git diff 或 GitHub PR）。当用户要求 review 代码、审查 PR、或检查代码质量时触发。