# Review Pr

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

- Skill: `oschina/review-pr` (Agent Skill)
- Install (CLI): `npx skillmds@latest add oschina/review-pr`
- Raw SKILL.md: https://api.skillmd.com/api/skills/oschina/review-pr/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: oschina (https://skillmd.com/u/oschina)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/oschina/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
[Overall assessment — LGTM or key changes needed]
```

If no issues are found, show:

```
## Code Review Preview

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

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:

```
## 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