review-pr

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_comments (resource_type: pull), create_comment (resource_type: 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_comments (resource_type: pull) 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: Present Review to User

STOP — Do not post yet!

Present the review content to the user for confirmation. Use this format:

## Code Review Preview

**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

If no issues are found, show:

Then ask the user: "请确认以上评审内容是否有问题。确认无误后，我将提交到 PR。"

Step 7: Post Review Comment (After User Confirmation)

Once the user confirms the review content is correct, use create_comment (resource_type: pull) to post the review to the PR. Use this format:

If no issues are found, comment:

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