Integrate subtask timeout feature

.github/pull_request_template.md

@@ -30,37 +30,15 @@ Detail the steps to test your changes. This helps reviewers verify your work.
 - Include relevant testing environment details if applicable.
 -->
 
-### Type of Change
-
-<!-- Mark all applicable boxes with an 'x'. -->
-
-- [ ] 🐛 **Bug Fix**: Non-breaking change that fixes an issue.
-- [ ] ✨ **New Feature**: Non-breaking change that adds functionality.
-- [ ] 💥 **Breaking Change**: Fix or feature that would cause existing functionality to not work as expected.
-- [ ] ♻️ **Refactor**: Code change that neither fixes a bug nor adds a feature.
-- [ ] 💅 **Style**: Changes that do not affect the meaning of the code (white-space, formatting, etc.).
-- [ ] 📚 **Documentation**: Updates to documentation files.
-- [ ] ⚙️ **Build/CI**: Changes to the build process or CI configuration.
-- [ ] 🧹 **Chore**: Other changes that don't modify `src` or test files.
-
 ### Pre-Submission Checklist
 
 <!-- Go through this checklist before marking your PR as ready for review. -->
 
 - [ ] **Issue Linked**: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
 - [ ] **Scope**: My changes are focused on the linked issue (one major feature/fix per PR).
 - [ ] **Self-Review**: I have performed a thorough self-review of my code.
-- [ ] **Code Quality**:
-    - [ ] My code adheres to the project's style guidelines.
-    - [ ] There are no new linting errors or warnings (`npm run lint`).
-    - [ ] All debug code (e.g., `console.log`) has been removed.
-- [ ] **Testing**:
-    - [ ] New and/or updated tests have been added to cover my changes.
-    - [ ] All tests pass locally (`npm test`).
-    - [ ] The application builds successfully with my changes.
-- [ ] **Branch Hygiene**: My branch is up-to-date (rebased) with the `main` branch.
+- [ ] **Testing**: New and/or updated tests have been added to cover my changes (if applicable).
 - [ ] **Documentation Impact**: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
-- [ ] **Changeset**: A changeset has been created using `npm run changeset` if this PR includes user-facing changes or dependency updates.
 - [ ] **Contribution Guidelines**: I have read and agree to the [Contributor Guidelines](/CONTRIBUTING.md).
 
 ### Screenshots / Videos

.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

@@ -25,6 +25,8 @@ customModes:
         - fileRegex: (\.roomodes$|\.roo/.*\.xml$|\.yaml$)
           description: Mode configuration files and XML instructions
       - command
+      - mcp
+    source: project
   - slug: test
     name: 🧪 Test
     roleDefinition: >-
@@ -241,4 +243,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