code-review-uncommitted

Code Review Uncommitted Changes

Conduct a systematic multi-dimensional code review of uncommitted code changes in git (unstaged + staged + untracked).

Trigger Conditions

When the user:

• Requests a review of uncommitted code
• Requests a review of the current changes / current diff
• Uses /code-review-uncommitted

Review Process

Strictly follow these steps:

Phase 1: Collect change content

1. Run git diff to get unstaged changes
2. Run git diff --cached to get staged changes
3. Run git status --short to get all file statuses (including untracked files)
4. Read the contents of all untracked new files

Phase 2: Collect project specifications

1. Search the project for all CLAUDE.md and AGENTS.md files (root directory + directories of changed files)
2. Read these specification files and extract coding specification key points
3. Also refer to the specifications in the user's global ~/.claude/CLAUDE.md specifications in

Phase 3: Parallel multi-dimensional review

Launch 4 parallel subagents (using the Task tool, with model set to sonnet); each agent reviews independently and returns a list of issues:

Agent 1: Project specification compliance review

• Check whether the changes comply with the coding specifications in CLAUDE.md / AGENTS.md
• Focus on: naming conventions, file organization, use of path aliases, location of type definitions, location of constant extraction, preferences for utility function usage, etc.
• Each issue must state which specific specification was violated

Agent 2: Shallow Bug scan

• Focus only on the diff itself; do not read additional context
• Report only obvious major Bugs; ignore minor issues and nitpicks
• Ignore possible false positives
• Focus on: logic errors, null pointers, missing dependency arrays, type mismatches, resource leaks, etc.

Agent 3: Code comment compliance check

• Check whether the code comments in the changes are consistent with the actual code behavior
• Check whether there are misleading comments
• Check whether invalid leftover comments remain after code deletion

Agent 4: Component encapsulation and architecture design review

• Check whether the component design pattern is reasonable
• Check whether state management is appropriate
• Check whether type design is reasonable
• Check whether the level of abstraction is appropriate
• Why the current design is not good, and a better design approach

Phase 4: Confidence scoring and filtering

Score all issues found by all agents uniformly (0-100), with the following scoring criteria:

Score	Meaning
0	Completely uncertain, a false positive that cannot withstand scrutiny, or an existing historical issue
25	Somewhat likely, but could also be a false positive. If it is a style issue, it is not explicitly mentioned in CLAUDE.md/AGENTS.md
50	Medium confidence, can verify it is a real issue, but it may be a nitpick or rarely triggered in practice. Relatively unimportant compared to the entire PR
75	High confidence, after secondary verification, it is very likely a real issue and will be triggered in practice. The existing code's handling is not good enough, or it is an issue explicitly mentioned in CLAUDE.md/AGENTS.md
100	Completely certain, after secondary verification, confirmed to be a real issue and will be triggered frequently, with evidence directly supporting it

Filtering rule: only keep issues scoring 80 and above.

The following situations should be judged as false positives (low score):

• Existing historical issues (not introduced by this change)
• Situations that look like bugs but actually are not
• Pedantic nitpicks that a senior engineer would not point out
• Issues that linters / type checkers / compilers can catch (such as missing imports, type errors, formatting issues)
• General code quality issues (such as lack of test coverage, general security issues), unless explicitly required by CLAUDE.md/AGENTS.md
• Issues explicitly ignored in the code via lint ignore comments
• Feature changes that may be intentional
• Real issues on lines the user did not modify
• Over-engineered suggestions (such as extracting a hook for a simple page, creating an abstraction for a one-off operation)

Phase 5: Output results

Display the scoring process in table form, then output the details of issues that pass the threshold:

## 评分过滤

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

## Code Review 结果

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

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

Important principles

1. Better to omit than to overreport: prefer missing reports over false positives, and only report high-confidence real issues
2. Focus on the increment: only review issues introduced by this change, do not review existing code
3. Respect the context: understand the intent and background of the change, and avoid criticism detached from context
4. Actionability: each issue should come with specific fix suggestions
5. Parallel execution: the 4 review agents must be launched in parallel to improve efficiency
6. Use Chinese: all output should use Chinese