code-review-uncommitted

Code Review Uncommitted Changes

Perform 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 the steps below:

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 containing changed files)
2. Read these specification files and extract key coding specification points
3. Also reference the user's global ~/.claude/CLAUDE.md specifications

Phase 3: Parallel multi-dimensional review

Launch 4 parallel subagents (using the Task tool, with model set to sonnet), each agent independently reviews 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, path alias usage, type definition locations, constant extraction locations, utility function usage preferences, etc.
• Each issue must state which specific specification was violated

Agent 2: Shallow bug scan

• Only focus on the diff itself, do not read additional context
• Only report 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 for misleading comments
• Check for leftover invalid comments 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 the 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

Uniformly score all issues found by the agents (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 possible, but it 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 be verified as a real issue, but it may be a nitpick or rarely triggered in practice. Not very important relative to the entire PR.
75	High confidence: after secondary verification, it is very likely a real issue and will be triggered in practice. The current code handles it poorly, 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 are actually 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 CLAUDE.md/AGENTS.md explicitly requires them
• 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 incremental changes: Only review issues introduced by this change, not existing code
3. Respect context: Understand the intent and background of the change, and avoid criticism out of context
4. Actionability: Each issue should include specific fix suggestions
5. Parallel execution: The 4 review agents must be started in parallel to improve efficiency
6. Use Chinese: All output should use Chinese