local-diff-review

Local Diff Review (pre-commit local review)

Core Principles

1. Review standards must be consistent with pr-review and must not be customized to weaken the standards.
2. Review before changing code: by default, output the issue list first; only change code when the user explicitly requests it.
3. Conclusions must be actionable: every issue must include the file path, line number, risk description, and fix suggestion.

Review standard sources (must be followed)

• Code quality standards:./code-quality-standards.md
• Common issues checklist:./common-issues-checklist.md

Note: The "review criteria" of this skill are based on the current version of pr-review ; the above links are the sole source of standards.

Use Cases

• The user wants to "review locally first, then submit a PR".
• The user says "review my current changes/local diff/staged changes/branch differences".
• The user wants risk-graded feedback at the same level as PR review.

Information Collection Process

First collect repository status:

git status --short
git branch --show-current
git remote -v

Then choose the diff scope based on user intent (by default, first clarify the scope):

# 1) 未暂存改动
git diff

# 2) 已暂存改动
git diff --staged

# 3) 工作区全部改动（含暂存+未暂存）
git diff HEAD

# 4) 当前分支相对基线分支（推荐用于“准备提 PR”）
git diff upstream/<base-branch>...HEAD

# 5) 指定提交
git show <commit>

Review Steps

1. Read the diff and organize the purpose of changes grouped by file.
2. Perform the three-dimensional review in sequence (strictly according to the 3 standard documents above).
3. Label issue severity:
   • 🔴 Critical issue (must fix)
   • 🟡 Suggested improvement (recommend fixing this time)
   • 🟢 Optional optimization (can be handled later)
4. Summarize regression risks: i18n, type safety, boundary behavior, compatibility, performance impact.
5. Provide the review conclusion: mergeable / needs revision before re-review.

Output Format (suggested)

1) Change Overview

• Review scope (which kind of diff)
• Number of files involved, core modules

2) Issue List

Every issue includes:

• File path + line number
• Risk level (🔴/🟡/🟢)
• Issue description (why it is an issue)
• Fix suggestion (provide an actionable solution)

3) Overall Conclusion

• Whether it is recommended to submit the PR now
• Minimum verification recommended before submitting the PR (such as lint / typecheck / relevant tests)

Behavioral Constraints During Review

1. Do not guess business intent out of thin air; when evidence is insufficient, clearly state "requires user confirmation".
2. Do not treat "personal preference" as a blocking item.
3. Do not add overly defensive suggestions for non-existent call paths.
4. When communicating with the user, prioritize Chinese, with clear conclusions and actionable steps.

Common Trigger Phrases (examples)

• "Please review my current local changes according to PR standards."
• "Please review my git diff --staged, and only provide the issue list."
• "Please review the changes of my current branch relative to upstream/v4.14.7-dev according to FastGPT conventions."