Local Diff Review（提交前本地评审） 核心原则 1. 审查标准必须与 保持一致，不允许自定义弱化标准。 2. 先审查再改代码：默认先输出问题清单，只有用户明确要求才改代码。 3. 结论必须可执行：每个问题都要给出文件路径、行号、风险说明、修复建议。 审查标准来源（必须遵循） - 代码质量标准： - 常见问题清单： 说明：本 skill 的“评审准则”以 当前版本为准，以上链接即唯一标准来源。 使用场景 - 用户希望“先本地 review，再提 PR”。 - 用户给出“review 我当前改动/本地 diff/暂存区改动/分支差异”。 - 用户希望获得与 PR review 同等级别的风险分级反馈。 信息收集流程 先收集仓库状态： 再根据用户意图选择 diff 范围（默认优先问清楚范围）： 审查步骤 1. 阅读 diff，按文件分组梳理改动目的。 2. 依次执行三维度审查（严格按上面 3 份标准文档）。 3. 标注问题等级： - 🔴 严重问题（必须修复） - 🟡 建议改进（建议本次修） - 🟢 可选优化（可后续处理） 4. 汇总回归风险：i18n、类型安全、边界行为、兼容性、性能影响。 5. 给出审查结论：可合并 / 需修改后再审。 输出格式（建议） 1) 变更概览 - 审查范围（哪一种 diff） - 涉及文件数、核心模块 2) 问题清单 每个问题都包含：…