| name | code-review-uncommitted |
| description | 对 git 中未提交的代码变更进行多维度 code review，包括项目规范合规性、Bug 扫描、代码注释合规性、组件封装/架构设计合理性审查，并通过置信度评分过滤误报。当用户要求 review 未提交的代码、review 当前改动、或使用 /code-review-uncommitted 时触发。 |
Code Review Uncommitted Changes
对 git 中未提交的代码变更（unstaged + staged + untracked）进行系统化的多维度 code review。
触发条件
当用户：
- 要求 review 未提交的代码
- 要求 review 当前的改动 / 当前的 diff
- 使用
/code-review-uncommitted
Review 流程
严格按照以下步骤执行：
第一阶段：收集变更内容
- 运行
git diff 获取未暂存的变更
- 运行
git diff --cached 获取已暂存的变更
- 运行
git status --short 获取所有文件状态（包括未跟踪文件）
- 读取所有未跟踪的新文件内容
第二阶段：收集项目规范
- 搜索项目中所有
CLAUDE.md 和 AGENTS.md 文件（根目录 + 变更文件所在目录）
- 读取这些规范文件，提取编码规范要点
- 同时参考用户全局的
~/.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分）的问题简要列出
重要原则
- 宁缺毋滥：宁可漏报也不要误报，只报告高置信度的真实问题
- 关注增量：只审查本次变更引入的问题，不审查已有代码
- 尊重上下文：理解变更的意图和背景，避免脱离上下文的批评
- 可操作性：每个问题都应附带具体的修复建议
- 并行执行：4 个审查 agent 必须并行启动以提高效率
- 使用中文：所有输出使用中文
