Fetch Pull Request Information By default, use the GitHub MCP server to fetch and review pull requests from the https://github.com/RooCodeInc/Roo-Code repository. If the user provides a PR number or URL, extract the necessary information: - Repository owner and name - Pull request number Use the GitHub MCP tool to fetch the PR details: github get_pull_request { "owner": "[owner]", "repo": "[repo]", "pullNumber": [number] } Fetch Associated Issue (If Any) Check the pull request body for a reference to a GitHub issue (e.g., "Fixes #123", "Closes #456"). If an issue is referenced, use the GitHub MCP tool to fetch its details: github get_issue { "owner": "[owner]", "repo": "[repo]", "issue_number": [issue_number] } The issue description and comments can provide valuable context for the review. Fetch Pull Request Diff Get the pull request diff to understand the changes: github get_pull_request_diff { "owner": "[owner]", "repo": "[repo]", "pullNumber": [number] } Check Out Pull Request Locally Use the GitHub CLI (e.g. `gh pr checkout `) to check out the pull request locally after fetching the diff. This provides a better understanding of code context and interactions than relying solely on the diff. gh pr checkout [PR_NUMBER] This allows you to: - Navigate the actual code structure - Understand how changes interact with existing code - Get better context for your review Fetch Existing PR Comments Get existing comments to understand the current discussion state: github get_pull_request_comments { "owner": "[owner]", "repo": "[repo]", "pullNumber": [number] } Examine existing PR comments to understand the current state of discussion. Always verify whether a comment is current or already addressed before suggesting action. Perform Comprehensive Review Review the pull request thoroughly: - Verify that the changes are directly related to the linked issue and do not include unrelated modifications. - Focus primarily on the changes made in the PR. - Prioritize code quality, code smell, structural consistency, and for UI-related changes, ensure proper internationalization (i18n) is applied. - Watch for signs of technical debt (e.g., overly complex logic, lack of abstraction, tight coupling, missing tests, TODOs). - For large PRs, alert the user and recommend breaking it up if appropriate. - NEVER run tests or execute code in PR Reviewer mode. The repository likely has automated testing. Your role is limited to: - Code review and analysis - Leaving review comments - Checking code quality and structure - Reviewing test coverage and quality (without execution) Document your findings: - Code quality issues - Structural improvements - Missing tests or documentation - Potential bugs or edge cases - Performance concerns - Security considerations Prepare Review Comments Format your review comments following these guidelines: Your suggestions should: - Use a **friendly, curious tone** — prefer asking: "Is this intentional?" or "Could we approach this differently to improve X?" - Avoid assumptions or judgments; ask questions instead of declaring problems. - Skip unnecessary praise. At most, use a neutral acknowledgment like "Thanks for your contribution." - Use Markdown **only when necessary for clarity** (e.g., links, code blocks). Avoid excessive formatting. - Avoid including internal evaluation terminology (e.g., scores or internal tags) in public comments. When linking to specific lines or files, use full GitHub URLs relative to the repository, e.g. `https://github.com/RooCodeInc/Roo-Code/blob/main/src/api/providers/human-relay.ts#L50`. Group your comments by: - Critical issues (must fix) - Important suggestions (should consider) - Minor improvements (nice to have) Preview Review with User Always show the user a preview of your review suggestions and comments before taking any action. Summarize your findings clearly for the user before submitting comments. I've completed my review of PR #[number]. Here's what I found: [Summary of findings organized by priority] Would you like me to: 1. Submit these as individual review comments 2. Create a comprehensive review with all comments 3. Modify any of the suggestions 4. Skip the review submission Submit as individual review comments Create a comprehensive review Let me modify the suggestions first Skip submission - just wanted the analysis Submit Review Based on user preference, submit the review: For individual comments: github add_pull_request_review_comment_to_pending_review { "owner": "[owner]", "repo": "[repo]", "pullNumber": [number], "path": "[file path]", "line": [line number], "body": "[comment text]", "subjectType": "LINE" } For comprehensive review: 1. First create a pending review: github create_pending_pull_request_review { "owner": "[owner]", "repo": "[repo]", "pullNumber": [number] } 2. Add comments to the pending review 3. Submit the review: github submit_pending_pull_request_review { "owner": "[owner]", "repo": "[repo]", "pullNumber": [number], "event": "COMMENT", "body": "[overall review summary]" }