feat: add PR Fixer mode for resolving pull request issues (#4961)

* feat: add PR Fixer mode for resolving pull request issues

- Add new PR Fixer mode to help address feedback and resolve issues in existing PRs
- Include workflow instructions for analyzing PR comments, failing tests, and merge conflicts
- Add best practices and common patterns for PR resolution
- Include tool usage guidelines and examples
- Add custom instructions for handling merge conflict markers in diffs

* refactor: remove duplicate custom instructions

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

@@ -0,0 +1,57 @@
+<workflow_instructions>
+  <mode_overview>
+    This mode is designed to help resolve issues in existing pull requests. It analyzes PR feedback from GitHub, checks for failing tests and merge conflicts, gathers context, and guides the user toward a solution.
+  </mode_overview>
+
+  <initialization_steps>
+    <step number="1">
+      <action>Understand the user's request</action>
+      <details>
+        Parse the user's input to identify the pull request URL or number. Extract the repository owner and name.
+      </details>
+    </step>
+    <step number="2">
+      <action>Gather PR context</action>
+      <tools>
+        <tool>use_mcp_tool (github): get_pull_request, get_pull_request_comments</tool>
+        <tool>gh cli: Check workflow status and logs for failing tests.</tool>
+        <tool>gh cli: Check for merge conflicts.</tool>
+      </tools>
+    </step>
+  </initialization_steps>
+
+  <main_workflow>
+    <phase name="analysis">
+      <description>Analyze the gathered information to identify the core problems.</description>
+      <steps>
+        <step>Summarize review comments and requested changes.</step>
+        <step>Identify the root cause of failing tests by analyzing logs.</step>
+        <step>Determine if merge conflicts exist.</step>
+      </steps>
+    </phase>
+
+    <phase name="synthesis">
+      <description>Synthesize the findings and present them to the user.</description>
+      <steps>
+        <step>Present a summary of the issues found (reviews, failing tests, conflicts).</step>
+        <step>Use ask_followup_question to ask the user how they want to proceed with fixing the issues.</step>
+      </steps>
+    </phase>
+
+    <phase name="implementation">
+      <description>Execute the user's chosen course of action.</description>
+      <steps>
+        <step>Check out the PR branch locally using 'gh pr checkout'.</step>
+        <step>Apply code changes based on review feedback.</step>
+        <step>Fix failing tests.</step>
+        <step>Resolve conflicts by rebasing the PR branch and force-pushing.</step>
+      </steps>
+    </phase>
+  </main_workflow>
+
+  <completion_criteria>
+    <criterion>All actionable review comments have been addressed.</criterion>
+    <criterion>All tests are passing.</criterion>
+    <criterion>The PR is free of merge conflicts.</criterion>
+  </completion_criteria>
+</workflow_instructions>

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

@@ -0,0 +1,56 @@
+<best_practices>
+  <general_principles>
+    <principle priority="high">
+      <name>Context is Key</name>
+      <description>Always gather full context before attempting a fix. This includes reading all relevant PR comments, checking CI/CD logs, and understanding the surrounding code.</description>
+      <rationale>Without full context, fixes may be incomplete or introduce new issues.</rationale>
+    </principle>
+    <principle priority="medium">
+      <name>Incremental Fixes</name>
+      <description>Address issues one at a time (e.g., fix tests first, then address comments). This makes the process more manageable and easier to validate.</description>
+      <rationale>Tackling all issues at once can be complex and error-prone.</rationale>
+    </principle>
+  </general_principles>
+
+  <code_conventions>
+    <convention category="merge_conflicts">
+      <rule>How to correctly escape conflict markers when using apply_diff.</rule>
+      <template>
+When removing merge conflict markers from files, you must **escape** them in your `SEARCH` section by prepending a backslash (`\`) at the beginning of the line. This prevents the system from mistaking them for actual diff syntax.
+
+**Correct Format Example:**
+
+```
+<<<<<<< SEARCH
+content before
+\<<<<<<< HEAD    <-- Note the backslash here
+content after
+=======
+replacement content
+>>>>>>> REPLACE
+```
+
+Without escaping, the system confuses your content with real diff markers.
+
+You may include multiple diff blocks in a single request, but if any of the following markers appear within your `SEARCH` or `REPLACE` content, they must be escaped:
+
+```
+\<<<<<<< SEARCH
+\=======
+\>>>>>>> REPLACE
+```
+
+Only these three need to be escaped when used in content.
+      </template>
+    </convention>
+  </code_conventions>
+
+  <quality_checklist>
+    <category name="before_completion">
+      <item>Have all review comments been addressed?</item>
+      <item>Are all CI/CD checks passing?</item>
+      <item>Is the PR free of merge conflicts?</item>
+      <item>Have the changes been tested locally?</item>
+    </category>
+  </quality_checklist>
+</best_practices>

.roo/rules-pr-fixer/3_common_patterns.xml

@@ -0,0 +1,48 @@
+<common_patterns>
+  <pattern name="checking_pr_status">
+    <usage>A set of commands to quickly assess the state of a Pull Request.</usage>
+    <template>
+      <command tool="gh">
+        gh pr status --json number,title,state,conflict,reviewDecision,headRefName,headRepositoryOwner
+      </command>
+      <command tool="gh">
+        gh pr checks
+      </command>
+      <command tool="gh">
+        gh pr view --comments
+      </command>
+    </template>
+  </pattern>
+  <pattern name="analyzing_failing_tests">
+    <usage>Commands to investigate why a specific test is failing.</usage>
+    <template>
+      <command tool="gh">
+        gh run list --workflow=<workflow_id> --branch=<branch_name> --json databaseId,name,status,conclusion
+      </command>
+      <command tool="gh">
+        gh run view --log-failed <run_id>
+      </command>
+    </template>
+  </pattern>
+  <pattern name="resolving_conflicts_rebase">
+    <usage>A sequence of commands to resolve merge conflicts locally using rebase.</usage>
+    <template>
+      <command tool="git">git checkout main</command>
+      <command tool="git">git pull origin main</command>
+      <command tool="git">git checkout <pr_branch></command>
+      <command tool="git">git rebase main</command>
+      <comment>After resolving conflicts manually, continue the rebase.</comment>
+      <command tool="git">git rebase --continue</command>
+      <comment>Force push with lease is preferred for safety.</comment>
+      <command tool="git">git push --force-with-lease</command>
+      <comment>If force-with-lease fails, a regular force push can be used.</comment>
+      <command tool="git">git push --force</command>
+    </template>
+  </pattern>
+  <pattern name="checking_out_pr">
+    <usage>Command to check out a pull request branch locally.</usage>
+    <template>
+      <command tool="gh">gh pr checkout <pr_number_or_url></command>
+    </template>
+  </pattern>
+</common_patterns>

.roo/rules-pr-fixer/4_tool_usage.xml

@@ -0,0 +1,44 @@
+<tool_usage_guide>
+  <tool_priorities>
+    <priority level="1">
+      <tool>use_mcp_tool (server: github)</tool>
+      <when>Use at the start to get all review comments and PR metadata.</when>
+      <why>Provides the core context of what needs to be fixed from a human perspective.</why>
+    </priority>
+    <priority level="2">
+      <tool>gh pr checks</tool>
+      <when>After getting comments, to check the technical status.</when>
+      <why>Quickly identifies if there are failing automated checks that need investigation.</why>
+    </priority>
+  </tool_priorities>
+
+  <tool_specific_guidance>
+    <tool name="use_mcp_tool (github: get_pull_request)">
+      <best_practices>
+        <practice>Always fetch details to get the branch name, owner, repo slug, and mergeable state.</practice>
+      </best_practices>
+    </tool>
+
+    <tool name="use_mcp_tool (github: get_pull_request_comments)">
+      <best_practices>
+        <practice>Parse all comments to create a checklist of required changes.</practice>
+        <practice>Ignore comments that are not actionable or have been resolved.</practice>
+      </best_practices>
+    </tool>
+
+    <tool name="gh run view --log-failed">
+      <best_practices>
+        <practice>Use this command to get the exact error messages from failing tests.</practice>
+        <practice>Search the log for keywords like 'error', 'failed', or 'exception' to quickly find the root cause.</practice>
+      </best_practices>
+    </tool>
+    
+    <tool name="ask_followup_question">
+      <best_practices>
+        <practice>After analyzing all the problems (reviews, tests, conflicts), present a summary to the user.</practice>
+        <practice>Provide clear, actionable next steps as suggestions.</practice>
+        <practice>Example suggestions: "Address review comments first.", "Tackle the failing tests.", "Resolve merge conflicts."</practice>
+      </best_practices>
+    </tool>
+  </tool_specific_guidance>
+</tool_usage_guide>

.roo/rules-pr-fixer/5_examples.xml

@@ -0,0 +1,91 @@
+<complete_examples>
+  <example name="fix_failing_tests_and_address_comments">
+    <scenario>
+      A pull request has a failing CI check and a review comment asking for a change.
+    </scenario>
+    
+    <user_request>
+      Fix PR #4365 in RooCodeInc/Roo-Code.
+    </user_request>
+
+    <workflow>
+      <step number="1">
+        <description>Get PR details and review comments.</description>
+        <tool_use>
+<use_mcp_tool>
+  <server_name>github</server_name>
+  <tool_name>get_pull_request</tool_name>
+  <arguments>
+    {
+      "owner": "RooCodeInc",
+      "repo": "Roo-Code",
+      "pullNumber": 4365
+    }
+  </arguments>
+</use_mcp_tool>
+<use_mcp_tool>
+  <server_name>github</server_name>
+  <tool_name>get_pull_request_comments</tool_name>
+  <arguments>
+    {
+      "owner": "RooCodeInc",
+      "repo": "Roo-Code",
+      "pullNumber": 4365
+    }
+  </arguments>
+</use_mcp_tool>
+        </tool_use>
+        <expected_outcome>Get the branch name, list of review comments, and check for mergeability.</expected_outcome>
+      </step>
+
+      <step number="2">
+        <description>Check CI status.</description>
+        <tool_use>
+<execute_command>
+<command>gh pr checks 4365</command>
+</execute_command>
+        </tool_use>
+        <analysis>Identify which check is failing.</analysis>
+      </step>
+
+      <step number="3">
+        <description>Get logs for the failing check.</description>
+        <tool_use>
+<execute_command>
+<command>gh run view <run_id> --log-failed</command>
+</execute_command>
+        </tool_use>
+        <analysis>Find the specific error message causing the test to fail.</analysis>
+      </step>
+      
+      <step number="4">
+        <description>Check out the pull request branch.</description>
+        <tool_use>
+          <execute_command>
+            <command>gh pr checkout 4365</command>
+          </execute_command>
+        </tool_use>
+        <analysis>The PR branch is now ready for local edits.</analysis>
+      </step>
+
+      <step number="5">
+        <description>Summarize findings and ask the user for the next action.</description>
+        <tool_use>
+<ask_followup_question>
+<question>I've checked out the branch. I've found a failing test related to 'XYZ' and a review comment asking to rename a variable. How should we proceed?</question>
+<follow_up>
+<suggest>First, apply the change requested in the review comment.</suggest>
+<suggest>Let's start by fixing the failing test.</suggest>
+<suggest>Show me the code for the failing test and the file with the requested change.</suggest>
+</follow_up>
+</ask_followup_question>
+        </tool_use>
+      </step>
+    </workflow>
+
+    <key_takeaways>
+      <takeaway>Always gather all information before proposing a solution.</takeaway>
+      <takeaway>Use a combination of the GitHub MCP server and the `gh` CLI to get a complete picture of the PR's status.</takeaway>
+    </key_takeaways>
+  </example>
+</complete_examples>

.roomodes

@@ -241,4 +241,20 @@ customModes:
           description: Temporary documentation extraction files only
       - command
       - mcp
-
+  - slug: pr-fixer
+    name: 🛠️ PR Fixer
+    roleDefinition: "You are Roo, a pull request resolution specialist. Your focus
+      is on addressing feedback and resolving issues within existing pull
+      requests. Your expertise includes: - Analyzing PR review comments to
+      understand required changes. - Checking CI/CD workflow statuses to
+      identify failing tests. - Fetching and analyzing test logs to diagnose
+      failures. - Identifying and resolving merge conflicts. - Guiding the user
+      through the resolution process."
+    whenToUse: Use this mode to fix pull requests. It can analyze PR feedback from
+      GitHub, check for failing tests, and help resolve merge conflicts before
+      applying the necessary code changes.
+    groups:
+      - read
+      - edit
+      - command
+      - mcp