Review Pr

---

name: review-pr description: 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. version: 1.0.0 requires: mcp-servers: - gitee

---

> 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

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.

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