Update PR reviewer rules and mode configuration (RooCodeInc#6391)

Author: daniel-lxs

.roo/rules-pr-reviewer/1_workflow.xml

@@ -33,10 +33,11 @@
       Use the GitHub CLI to fetch the PR details:
 
       <execute_command>
-      <command>gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,body,author,state,url,headRefName,baseRefName,mergeable,isDraft,createdAt,updatedAt</command>
+      <command>gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,body,author,state,url,headRefName,baseRefName,headRefOid,mergeable,isDraft,createdAt,updatedAt</command>
       </execute_command>
 
       Parse the JSON output to understand the PR's current state and metadata.
+      IMPORTANT: Save the headRefOid value as it will be needed for submitting the review via the API.
 
       <update_todo_list>
       <todos>
@@ -124,7 +125,7 @@
 
       Also fetch review details:
       <execute_command>
-      <command>gh pr reviews [PR_NUMBER] --repo [owner]/[repo]</command>
+      <command>gh api repos/[owner]/[repo]/pulls/[PR_NUMBER]/reviews</command>
       </execute_command>
 
       Create a mental or written list of:
@@ -372,24 +373,65 @@
   <step number="11">
     <name>Submit Review</name>
     <instructions>
-      Based on user preference, submit the review using GitHub CLI:
+      Based on user preference, submit the review using the GitHub API to support inline comments:
 
-      Note: The GitHub CLI has limited support for creating reviews with inline comments.
-      For comprehensive reviews with line-specific comments, we'll need to:
+      1. Construct the review payload with inline comments. For each comment, you need:
+         - The file path (relative to repository root)
+         - The line number where the comment should appear
+         - The comment body text
+         - The side ("RIGHT" for new code, "LEFT" for old code)
 
-      1. Create individual comments on specific lines (if needed):
+      2. Submit the review using the GitHub API with heredoc syntax:
       <execute_command>
-      <command>gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body "[comment text]"</command>
+      <command>gh api -X POST repos/[owner]/[repo]/pulls/[PR_NUMBER]/reviews --input - <<EOF
+{
+  "commit_id": "[headRefOid from Step 2]",
+  "body": "Thank you for your contribution! I've reviewed the changes and [found issues that need attention / have some suggestions for improvement].",
+  "event": "[COMMENT|REQUEST_CHANGES|APPROVE]",
+  "comments": [
+    {
+      "path": "[file/path/to/code.ts]",
+      "body": "[Your comment text here - use friendly, curious tone]",
+      "line": [line_number],
+      "side": "RIGHT"
+    }
+  ]
+}
+EOF</command>
       </execute_command>
 
-      2. Or create a general review comment summarizing all findings:
+      The review will be created with all inline comments attached to specific lines of code.
+      
+      Note on event types:
+      - "COMMENT": Submit general feedback without approval/rejection
+      - "REQUEST_CHANGES": Request changes be made before merging
+      - "APPROVE": Approve the PR for merging
+      
+      Example for a review requesting changes:
       <execute_command>
-      <command>gh pr review [PR_NUMBER] --repo [owner]/[repo] --comment --body "[review summary with all findings]"</command>
+      <command>gh api -X POST repos/RooCodeInc/Roo-Code/pulls/6378/reviews --input - <<EOF
+{
+  "commit_id": "abc123def4567890...",
+  "body": "Thank you for your contribution! I've reviewed the changes and found that the critical issues from the previous review are still pending. I've left some suggestions inline to help improve the implementation.",
+  "event": "REQUEST_CHANGES",
+  "comments": [
+    {
+      "path": "packages/cloud/src/CloudService.ts",
+      "body": "Missing error handling here...",
+      "line": 19,
+      "side": "RIGHT"
+    },
+    {
+      "path": "packages/cloud/src/CloudService.ts",
+      "body": "Is this intentional? The timeout seems quite high (30s). Could we consider reducing it or making it configurable?",
+      "line": 45,
+      "side": "RIGHT"
+    }
+  ]
+}
+EOF</command>
       </execute_command>
 
-      Note: For line-specific comments, you may need to use the GitHub web interface or API directly,
-      as the gh CLI has limited support for inline review comments.
-      
       <update_todo_list>
       <todos>
       [x] Fetch pull request information

.roo/rules-pr-reviewer/2_best_practices.xml

@@ -1,6 +1,7 @@
 <best_practices>
   - ALWAYS create a todo list at the start to track the review workflow (Step 1)
   - Use GitHub CLI (`gh`) commands instead of MCP tools for all GitHub operations
+  - ALWAYS fetch the PR's headRefOid in Step 2 - this is required for API review submission
   - ALWAYS fetch existing comments and reviews BEFORE reviewing any code (Step 5)
   - Create a list of all existing feedback before starting your review
   - Check out the PR locally using `gh pr checkout` for better context understanding
@@ -27,9 +28,13 @@
   - Present findings in a numbered list format for clarity
   - Group feedback by priority (critical, important, minor)
   - Always preview comments with the user before submitting
+  - Use the GitHub API for submitting reviews to support inline comments
+  - Construct proper JSON payloads with commit_id, body, event, and comments array
+  - Each inline comment needs: path, body, line number, and side (RIGHT for new code)
+  - Choose appropriate review event: COMMENT, REQUEST_CHANGES, or APPROVE
+  - Use heredoc syntax (--input - <<EOF) to pass JSON directly
   - Offer the option to create individual tasks for each suggestion
   - When creating tasks, choose the appropriate mode for each type of work
   - Include specific context and file references in each task
   - Update the todo list after each major step to track progress
-  - Note: GitHub CLI has limited support for inline review comments
 </best_practices>

.roo/rules-pr-reviewer/3_common_mistakes_to_avoid.xml

@@ -1,6 +1,7 @@
 <common_mistakes_to_avoid>
   - Not creating a todo list at the start to track the review workflow
   - Using MCP tools instead of GitHub CLI commands for GitHub operations
+  - Forgetting to fetch headRefOid in Step 2 - this is REQUIRED for API review submission
   - Starting to review code WITHOUT first fetching existing comments and reviews
   - Failing to create a list of existing feedback before reviewing
   - Not systematically checking each existing comment against the current code
@@ -28,6 +29,15 @@
   - Creating tasks without specific context or file references
   - Choosing inappropriate modes when creating tasks for suggestions
   - Not updating the todo list after completing each step
-  - Forgetting that GitHub CLI has limited support for inline review comments
   - Not including --repo flag when using gh commands for non-default repositories
+  - Using wrong commit_id in review payload (must use headRefOid from PR info)
+  - Forgetting to specify "side": "RIGHT" for comments on new code
+  - Using incorrect line numbers that don't match the actual diff
+  - Not escaping special characters in JSON payload properly
+  - Using wrong event type (e.g., REQUEST_CHANGES when only commenting)
+  - Not constructing proper file paths relative to repository root
+  - Submitting empty comments array when inline comments are needed
+  - Forgetting to use <<EOF syntax properly in the command
+  - Not properly escaping special characters in heredoc JSON content
+  - Missing the EOF delimiter at the end of the heredoc
 </common_mistakes_to_avoid>

.roomodes

@@ -205,6 +205,21 @@ customModes:
       - command
       - mcp
     source: project
+  - slug: pr-reviewer
+    name: 🔍 PR Reviewer
+    roleDefinition: |-
+      You are Roo, a pull request reviewer specializing in code quality, structure, and translation consistency. Your expertise includes: - Analyzing pull request diffs and understanding code changes in context - Evaluating code quality, identifying code smells and technical debt - Ensuring structural consistency across the codebase - Verifying proper internationalization (i18n) for UI changes - Providing constructive feedback with a friendly, curious tone - Reviewing test coverage and quality without executing tests - Identifying opportunities for code improvements and refactoring
+      You work primarily with the RooCodeInc/Roo-Code repository, using GitHub MCP tools to fetch and review pull requests. You check out PRs locally for better context understanding and focus on providing actionable, constructive feedback that helps improve code quality.
+    whenToUse: Use this mode to review pull requests on the Roo-Code GitHub repository or any other repository if specified by the user.
+    description: Review PRs for code quality, structure, and i18n compliance.
+    groups:
+      - read
+      - - edit
+        - fileRegex: \.md$
+          description: Markdown files only
+      - mcp
+      - command
+    source: project
   - slug: mode-writer
     name: ✍️ Mode Writer
     roleDefinition: |-
@@ -236,17 +251,3 @@ customModes:
       - command
       - mcp
     source: project
-  - slug: pr-reviewer
-    name: 🔍 PR Reviewer
-    roleDefinition: |-
-      You are Roo, a pull request reviewer specializing in code quality, structure, and translation consistency. Your expertise includes: - Analyzing pull request diffs and understanding code changes in context - Evaluating code quality, identifying code smells and technical debt - Ensuring structural consistency across the codebase - Verifying proper internationalization (i18n) for UI changes - Providing constructive feedback with a friendly, curious tone - Reviewing test coverage and quality without executing tests - Identifying opportunities for code improvements and refactoring
-      You work primarily with the RooCodeInc/Roo-Code repository, using GitHub MCP tools to fetch and review pull requests. You check out PRs locally for better context understanding and focus on providing actionable, constructive feedback that helps improve code quality.
-    whenToUse: Use this mode to review pull requests on the Roo-Code GitHub repository or any other repository if specified by the user.
-    groups:
-      - read
-      - - edit
-        - fileRegex: \.md$
-          description: Markdown files only
-      - mcp
-      - command
-    source: project