Local Diff Review（提交前本地评审）

核心原则

1. 审查标准必须与 pr-review 保持一致，不允许自定义弱化标准。
2. 先审查再改代码：默认先输出问题清单，只有用户明确要求才改代码。
3. 结论必须可执行：每个问题都要给出文件路径、行号、风险说明、修复建议。

审查标准来源（必须遵循）

• 代码质量标准：./code-quality-standards.md
• 常见问题清单：./common-issues-checklist.md

说明：本 skill 的“评审准则”以 pr-review 当前版本为准，以上链接即唯一标准来源。

使用场景

• 用户希望“先本地 review，再提 PR”。
• 用户给出“review 我当前改动/本地 diff/暂存区改动/分支差异”。
• 用户希望获得与 PR review 同等级别的风险分级反馈。

信息收集流程

先收集仓库状态：

git status --short
git branch --show-current
git remote -v

再根据用户意图选择 diff 范围（默认优先问清楚范围）：

# 1) 未暂存改动
git diff

# 2) 已暂存改动
git diff --staged

# 3) 工作区全部改动（含暂存+未暂存）
git diff HEAD

# 4) 当前分支相对基线分支（推荐用于“准备提 PR”）
git diff upstream/<base-branch>...HEAD

# 5) 指定提交
git show <commit>

审查步骤

1. 阅读 diff，按文件分组梳理改动目的。
2. 依次执行三维度审查（严格按上面 3 份标准文档）。
3. 标注问题等级：
   • 🔴 严重问题（必须修复）
   • 🟡 建议改进（建议本次修）
   • 🟢 可选优化（可后续处理）
4. 汇总回归风险：i18n、类型安全、边界行为、兼容性、性能影响。
5. 给出审查结论：可合并 / 需修改后再审。

输出格式（建议）

1) 变更概览

• 审查范围（哪一种 diff）
• 涉及文件数、核心模块

2) 问题清单

每个问题都包含：

• 文件路径 + 行号
• 风险等级（🔴/🟡/🟢）
• 问题描述（为什么是问题）
• 修复建议（给出可落地方案）

3) 总体结论

• 是否建议现在提 PR
• 提 PR 前建议补做的最小验证（如 lint / typecheck / 相关测试）

评审时的行为约束

1. 不凭空猜测业务意图；证据不足时明确“需用户确认”。
2. 不把“个人偏好”当成阻塞项。
3. 不为不存在的调用路径添加过度防御性建议。
4. 与用户沟通时优先中文、结论清晰、步骤可执行。

常用触发语句（示例）

• “请按 PR 标准 review 我本地当前改动。”
• “请 review 我的 git diff --staged，只给问题清单。”
• “请按 FastGPT 规范审查我当前分支相对 upstream/v4.14.7-dev 的改动。”