nangongwentian-fe/code-review-uncommitted

Code Review Uncommitted Changes

对 git 中未提交的代码变更（unstaged + staged + untracked）进行系统化的多维度 code review。

触发条件

当用户：

• 要求 review 未提交的代码
• 要求 review 当前的改动 / 当前的 diff
• 使用 /code-review-uncommitted

Review 流程

严格按照以下步骤执行：

第一阶段：收集变更内容

1. 运行 git diff 获取未暂存的变更
2. 运行 git diff --cached 获取已暂存的变更
3. 运行 git status --short 获取所有文件状态（包括未跟踪文件）
4. 读取所有未跟踪的新文件内容

第二阶段：收集项目规范

1. 搜索项目中所有 CLAUDE.md 和 AGENTS.md 文件（根目录 + 变更文件所在目录）
2. 读取这些规范文件，提取编码规范要点
3. 同时参考用户全局的 ~/.claude/CLAUDE.md 中的规范

第三阶段：并行多维度审查

启动 4 个并行的 subagent（使用 Task 工具，model 选择 sonnet），每个 agent 独立审查并返回问题列表：

Agent 1：项目规范合规性审查

• 检查变更是否符合 CLAUDE.md / AGENTS.md 中的编码规范
• 重点关注：命名约定、文件组织、路径别名使用、类型定义位置、常量提取位置、工具函数使用偏好等
• 每个问题需说明违反了哪条具体规范

Agent 2：浅层 Bug 扫描

• 只关注 diff 本身，不读取额外上下文
• 只报告明显的大 Bug，忽略小问题和 nitpick
• 忽略可能的误报
• 重点关注：逻辑错误、空指针、依赖数组缺失、类型不匹配、资源泄漏等

Agent 3：代码注释合规性检查

• 检查变更中的代码注释是否与实际代码行为一致
• 检查是否有误导性的注释
• 检查删除代码后是否有遗留的无效注释

Agent 4：组件封装与架构设计审查

• 检查组件设计模式是否合理
• 检查状态管理是否恰当
• 检查类型设计是否合理
• 检查抽象层次是否恰当
• 为什么当前设计不好，以及更好的设计方案

第四阶段：置信度评分与过滤

对所有 agent 发现的问题进行统一评分（0-100），评分标准：

| 分数 | 含义 | |------|------| | 0 | 完全不确定，经不起推敲的误报，或是已有的历史问题 | | 25 | 有一定可能，但也可能是误报。如果是风格问题，CLAUDE.md/AGENTS.md 中没有明确提及 | | 50 | 中等确信，能验证是真实问题，但可能是 nitpick 或实际很少触发。相对于整个 PR 不太重要 | | 75 | 高度确信，经过二次验证，很可能是真实问题且会在实际中触发。现有代码的处理方式不够好，或者是 CLAUDE.md/AGENTS.md 中明确提到的问题 | | 100 | 完全确定，经过二次验证，确认是真实问题且会频繁触发，证据直接支持 |

过滤规则：只保留 80 分及以上的问题。

以下情况应判定为误报（低分）：

• 已有的历史问题（不是本次变更引入的）
• 看起来像 bug 但实际不是的情况
• 资深工程师不会指出的 pedantic nitpick
• linter / 类型检查器 / 编译器能捕获的问题（如缺少导入、类型错误、格式问题）
• 通用的代码质量问题（如缺少测试覆盖、通用安全问题），除非 CLAUDE.md/AGENTS.md 明确要求
• 代码中通过 lint ignore 注释明确忽略的问题
• 可能是有意为之的功能变更
• 用户未修改的行上的真实问题
• 过度设计的建议（如为简单页面抽取 hook、为一次性操作创建抽象）

第五阶段：输出结果

以表格形式展示评分过程，然后输出通过阈值的问题详情：

## 评分过滤

| 问题 | 来源 | 评分 | 理由 |
|------|------|------|------|
| 问题描述 | 哪个 Agent | 分数 | 评分理由 |

## Code Review 结果

通过阈值的问题：
1. **问题标题**
   - 文件位置（带行号链接）
   - 问题描述
   - 违反的规范（如适用）
   - 修复建议

其他观察（未达到报告阈值，仅供参考）：
- 接近阈值（75分）的问题简要列出

重要原则

1. 宁缺毋滥：宁可漏报也不要误报，只报告高置信度的真实问题
2. 关注增量：只审查本次变更引入的问题，不审查已有代码
3. 尊重上下文：理解变更的意图和背景，避免脱离上下文的批评
4. 可操作性：每个问题都应附带具体的修复建议
5. 并行执行：4 个审查 agent 必须并行启动以提高效率
6. 使用中文：所有输出使用中文