القائمة
按照团队 Code Review 规范审查代码变更（本地 git diff 或 GitHub PR）。当用户要求 review 代码、审查 PR、或检查代码质量时触发。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | code-review |
| description | 按照团队 Code Review 规范审查代码变更（本地 git diff 或 GitHub PR）。当用户要求 review 代码、审查 PR、或检查代码质量时触发。 |
依据团队约定，对本地代码变更或远程 GitHub PR 进行结构化审查。
远程 PR：
ghCLI 仅作为本地兜底手段，远程场景优先走 MCP。
本地变更：
git diff
git diff --staged
git diff <base-branch>...HEAD
大规模变更（> 500 行）：先用 git diff --stat 输出文件级概览，按模块分批审查，防止一次性处理遗漏细节。
在深入审查前，先建立对本次变更的全局认知：
如果 PR 描述缺失或含糊，在输出中标注「PR 描述信息不足，以下基于 diff 推断」
在架构判断之前，先厘清本次变更对已有系统的影响：
无影响则注明「无」，有影响则逐条列出受影响的范围和风险点。
从宏观视角审视整体设计：
架构层面存在问题时应优先指出——结构不对，逐行纠错没有意义。
按文件逐一检查，对照 RULES.md 中的规则分类进行判断。
审查优先级（风险优先，风格靠后）：
每条反馈附带严重等级标签：
| 标签 | 含义 | 是否阻断合并 |
|---|---|---|
[Required] | 必须修改 | 是 |
[Optional] | 建议改进 | 否（作者应说明是否采纳） |
[Question] | 需要作者澄清 | 澄清后可能升级为 Required |
[FYI] | 信息同步 | 否 |
每条反馈遵循 三段式：问题 → 原因 → 建议方案。
输出结构：
# 审查结果
## 变更摘要
**目标：** <本次变更要解决的问题或需求>
**核心改动：** <一句话概括>
**动机：** <为什么改>
**波及面：** <涉及的功能区域>
## 影响点评估
<对已有功能的影响范围及风险点，无影响注明「无」>
## 架构评估
<整体设计是否合理，如有问题在此列出>
## 逐文件反馈
### <文件名>
#### [Required] <简短标题>
**定位：** [`<文件路径>:<起始行>-<结束行>`](<文件路径>)
<问题代码片段（使用 CODE REFERENCES 格式引用源码）>
**问题：** <哪里有问题>
**原因：** <为什么有问题>
**建议：** <如何修复（如有修复代码，用 markdown 代码块展示）>
## Next Steps
共发现 X 个问题（Required: _、Optional: _、Question: _、FYI: _）。
**如何处理？**
1. **全部修复** — 自动修复所有问题
2. **仅修复 Required** — 只处理阻断项
3. **指定修复** — 告诉我要修复哪些
4. **仅审查** — 不需要修改，审查结束
用户选择修复方案后，Agent 按照反馈逐条实施代码修改：
无问题时：不能只说"没问题"，必须说明检查了哪些方面、未覆盖的范围、以及残留风险或建议的后续验证。
定位要求：
[Required] / [Optional] / [Question] 反馈必须给出 定位 字段[src/xx/file.tsx:10-24](src/xx/file.tsx)（可点击跳转）代码展示要求：
以下类型的问题始终标记为 [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>
.cursor/rules/（根据你的项目自行维护）