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