review-pr

Original：🇺🇸 English

Translated

Use this skill when the user asks to review a PR, do a code review, check a pull request, "review this PR", "review-pr", or "look at this pull request". Requires Gitee MCP Server to be configured.

2installs

Sourceoschina/gitee-agent-skills

Added on2026-03-10

NPX Install

npx skill4agent add oschina/gitee-agent-skills review-pr

SKILL.md Content

View Translation Comparison →

Note: If you have
mcporter
installed locally, you should use
mcporter
to invoke the MCP tool instead of directly calling the MCP tool. The
mcporter
CLI provides a more convenient interface and better error handling.

Review PR via Gitee MCP

Perform a thorough code review on a Pull Request in a Gitee repository.

Prerequisites

Gitee MCP Server configured (tools:

get_pull_detail

,

get_diff_files

,

list_pull_comments

,

comment_pull

)

User must provide: repository owner, repository name, PR number (or say "review the latest PR")
Optional: If the current directory is the local clone of the PR's repository, you can leverage local git commands and file access to get more context.

Steps

Step 1: Fetch PR Details

Use

get_pull_detail

to retrieve PR information, checking:

Whether the title and description clearly explain the purpose of the changes
Whether the source and target branches are correct
PR state (if already closed/merged, stop the review)
Whether it is a Draft — if so, notify the user

Step 2: Fetch Diff Files

Use

get_diff_files

to get the list of changed files, analyzing:

Number and scope of changed files
Whether any sensitive files are involved (config files, secrets, permission-related code)

For each core changed file, use

get_file_content

to read its content for context.

If running in the local repository directory, leverage local git commands and file access to gain additional context for the review (e.g., viewing related commits, related files, file history).

Step 3: Check Existing Comments

Use

list_pull_comments

to retrieve existing comments and avoid raising issues that have already been discussed.

Step 4: Code Review

Review the code across these dimensions:

Correctness

Is the logic correct? Are edge cases handled?
Are there obvious bugs or null pointer risks?
Is error handling adequate?

Security

Are there SQL injection, XSS, command injection, or other security risks?
Is sensitive information hardcoded?
Are permission checks in place?

Maintainability

Are names clear and semantic?
Does each function/method have a single responsibility?
Are complex logic blocks documented with comments?

Performance

Are there unnecessary nested loops or N+1 queries?
Are large file operations mindful of memory usage?

Consistency

Does the code follow the existing project style?
Is it consistent with related modules?

Step 5: Classify Issues

Classify findings by severity:

🔴 Blocker: Affects correctness or has a security risk — must be fixed
🟡 Suggestion: Code quality issue — recommended but not mandatory
🟢 Optional: Nice-to-have improvement

Step 6: Post Review Comment

Use

comment_pull

to post the review to the PR. Use this format:

## Code Review

**Summary**: [One sentence describing the purpose of the PR and overall quality assessment]

### 🔴 Blockers
1. **[filename:line]** [Issue description]
   - Problem: [Specific explanation]
   - Suggestion: [How to fix it]

### 🟡 Suggestions
1. **[filename]** [Issue description]
   - Suggestion: [Direction for improvement]

### 🟢 Optional
1. [Improvement suggestion]

### Conclusion
[Overall assessment — LGTM or key changes needed]

🤖 Generated by AI + Gitee MCP

If no issues are found, comment:

## Code Review

LGTM! No significant issues found. Code quality looks good.

🤖 Generated by AI + Gitee MCP

Notes

Focus only on new/modified code in the PR, not pre-existing code
Avoid nitpicking — do not raise issues that a linter would automatically catch
Comments should be specific and actionable — provide suggestions, not just observations
For uncertain issues, say "recommend verifying" rather than asserting it is definitely a bug