Remove roocode.com web app (#12375)

* Remove contributor and community references

* shutdown notice

* Allow empty web app test suite

.changeset/changelog-config.js

@@ -1,9 +1,9 @@
 const getReleaseLine = async (changeset) => {
-	const [firstLine] = changeset.summary
+	const lines = changeset.summary
 		.split("\n")
 		.map((l) => l.trim())
 		.filter(Boolean)
-	return `- ${firstLine}`
+	return lines.map((line) => (line.startsWith("- ") ? line : `- ${line}`)).join("\n")
 }
 
 const getDependencyReleaseLine = async () => {

.changeset/config.json

@@ -7,5 +7,5 @@
 	"access": "restricted",
 	"baseBranch": "main",
 	"updateInternalDependencies": "patch",
-	"ignore": []
+	"ignore": ["@roo-code/cli"]
 }

.changeset/v3.54.0.md

@@ -0,0 +1,15 @@
+---
+"roo-cline": minor
+---
+
+- Remove: Roo Code Cloud and eval infrastructure from the extension, CLI, workflows, and package surfaces so the release is focused on the standalone extension (PR #12328 by @mrubens)
+- Remove: All telemetry collection and analytics plumbing across the extension, website, shared types, provider flows, and related tests (PR #12324 by @mrubens)
+- Remove: MDM and organization membership enforcement, including host wiring, webview state, user-facing messages, and locale strings (PR #12323 by @mrubens)
+- Remove: The MCP marketplace, marketplace services, webview marketplace UI, package contributions, and related localized copy (PR #12326 by @mrubens)
+- Update: Extension-facing support, diagnostics, and announcement content for the final Roo Code release, including GitHub help paths and links to Roomote, ZooCode, and Cline (PR #12341 by @brunobergher)
+- Add: A cleaned docs app with GitHub Pages deployment support (PR #12344 by @brunobergher)
+- Fix: Configure the docs GitHub Pages base URL so deployed assets and canonical paths load correctly under the repository Pages path (PR #12370 by @mrubens)
+- Update: Point docs links in the root README, localized READMEs, and web app copy to the current GitHub Pages docs URL (PR #12371 by @mrubens)
+- Remove: Stale `roocode.github.io` docs references, including the old CNAME and outdated docs README and robots.txt URLs (PR #12372 by @mrubens)
+- Update: The website to focus almost entirely on the Roo Code extension and remove cloud, team, enterprise, provider, pricing, Slack, and Linear product pages (PR #12180 by @brunobergher)
+- Remove: Contributor, community, social channel, and tutorial references from README files, docs, website copy, issue templates, and workflows (PR #12347 by @brunobergher)

.dockerignore

@@ -76,15 +76,18 @@ src/node_modules
 !pnpm-workspace.yaml
 !scripts/bootstrap.mjs
 !apps/web-evals/
+!apps/cli/
 !src/
 !webview-ui/
 !packages/evals/.docker/entrypoints/runner.sh
 !packages/build/
-!packages/cloud/
 !packages/config-eslint/
 !packages/config-typescript/
+!packages/core/
 !packages/evals/
 !packages/ipc/
 !packages/telemetry/
 !packages/types/
+!packages/vscode-shim/
+!packages/cloud/
 !locales/

.env.sample

@@ -3,3 +3,4 @@ POSTHOG_API_KEY=key-goes-here
 # Roo Code Cloud / Local Development
 CLERK_BASE_URL=https://epic-chamois-85.clerk.accounts.dev
 ROO_CODE_API_URL=http://localhost:3000
+ROO_CODE_PROVIDER_URL=http://localhost:8080/proxy/v1

.gitattributes

@@ -4,3 +4,22 @@ src/assets/docs/demo.gif filter=lfs diff=lfs merge=lfs -text
 
 # Test snapshot files - mark as linguist-generated to exclude from GitHub language statistics
 *.snap linguist-generated=true
+
+# Non-English translation files - mark as linguist-generated to exclude from GitHub language statistics
+# Package NLS files - mark non-English ones as generated
+src/package.nls.*.json linguist-generated=true
+# Exclude the base English file from being marked as generated
+src/package.nls.json linguist-generated=false
+
+# Root locales directory (contains only non-English translations)
+locales/** linguist-generated=true
+
+# Mark all locale directories as generated first
+src/i18n/locales/** linguist-generated=true
+webview-ui/src/i18n/locales/** linguist-generated=true
+
+# Then explicitly mark English directories as NOT generated (override the above)
+src/i18n/locales/en/** linguist-generated=false
+webview-ui/src/i18n/locales/en/** linguist-generated=false
+
+# This approach uses gitattributes' last-match-wins rule to exclude English while including all other locales

.github/CODEOWNERS

@@ -1,2 +1,2 @@
 # These owners will be the default owners for everything in the repo
-* @mrubens @cte @jr
+* @mrubens @cte @jr @hannesrudolph @daniel-lxs

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -1,12 +1,66 @@
 name: Bug Report
-description: Clearly report a bug with detailed repro steps
+description: Report a broken behavior in plain language with a minimal reproduction
 labels: ["bug"]
+title: "[BUG] "
 body:
   - type: markdown
     attributes:
       value: |
-        **Thanks for your report!** Please check existing issues first:  
-        👉 https://github.com/RooCodeInc/Roo-Code/issues
+        Thank you for your report! Please search existing issues first:
+        https://github.com/RooCodeInc/Roo-Code/issues
+
+  - type: textarea
+    id: problem
+    attributes:
+      label: Problem (one or two sentences)
+      description: Describe what went wrong in plain language.
+      placeholder: 'Example: "Expected the task to start, but nothing happened and no message appeared."'
+    validations:
+      required: true
+
+  - type: textarea
+    id: context
+    attributes:
+      label: Context (who is affected and when)
+      description: Who sees this and in what situation? Keep it non-technical.
+      placeholder: 'Example: "Happens to new users when starting a run from the New Run page with dark theme enabled."'
+    validations:
+      required: true
+
+  - type: textarea
+    id: steps
+    attributes:
+      label: Reproduction steps
+      description: Provide clear, numbered steps so we can reproduce.
+      placeholder: |
+        1) Environment/setup (OS, extension version, relevant settings)
+        2) Exact actions (clicks, inputs, commands)
+        3) What you observed after each step
+    validations:
+      required: true
+
+  - type: input
+    id: expected
+    attributes:
+      label: Expected result
+      placeholder: e.g., "The task starts and shows progress."
+    validations:
+      required: true
+
+  - type: input
+    id: actual
+    attributes:
+      label: Actual result
+      placeholder: e.g., "The button appears disabled and no progress is shown."
+    validations:
+      required: true
+
+  - type: textarea
+    id: variations
+    attributes:
+      label: Variations tried (optional)
+      description: Different browsers, devices, providers, or settings you tried.
+      placeholder: e.g., "Tried Chrome/Firefox, disabling dark theme, switching providers."
 
   - type: input
     id: version
@@ -19,17 +73,17 @@ body:
   - type: dropdown
     id: provider
     attributes:
-      label: API Provider
+      label: API Provider (optional)
       options:
         - Anthropic
-        - AWS Bedrock
+        - Amazon Bedrock
         - Chutes AI
         - DeepSeek
-        - Glama
+        - Featherless AI
+        - Fireworks AI
         - Google Gemini
         - Google Vertex AI
         - Groq
-        - Human Relay Provider
         - LiteLLM
         - LM Studio
         - Mistral AI
@@ -38,61 +92,28 @@ body:
         - OpenAI Compatible
         - OpenRouter
         - Requesty
+        - SambaNova
         - Unbound
         - VS Code Language Model API
         - xAI (Grok)
         - Not Applicable / Other
-    validations:
-      required: true
 
   - type: input
     id: model
     attributes:
-      label: Model Used
+      label: Model Used (optional)
       description: Exact model name (e.g., Claude 3.7 Sonnet). Use N/A if irrelevant.
-    validations:
-      required: true
 
   - type: textarea
     id: roo-code-tasks
     attributes:
-      label: Roo Code Task Links (Optional)
-      description: |
-        If you have any publicly shared task links that demonstrate the issue, please paste them here.
-        This helps maintainers understand the context.
-        Example: https://app.roocode.com/share/task-id
+      label: Roo Code Task Links (optional)
+      description: If you have any publicly shared Roo Code task links that demonstrate the issue, paste them here.
       placeholder: Paste your Roo Code share links here, one per line
 
-  - type: textarea
-    id: steps
-    attributes:
-      label: 🔁 Steps to Reproduce
-      description: |
-        Help us see what you saw. Give clear, numbered steps:
-
-        1. Setup (OS, extension version, settings)
-        2. Exact actions (clicks, input, files, commands)
-        3. What happened after each step
-
-        Think like you're writing a recipe. Without this, we can't reproduce the issue.
-    validations:
-      required: true
-
-  - type: textarea
-    id: what-happened
-    attributes:
-      label: 💥 Outcome Summary
-      description: |
-        Recap what went wrong in one or two lines.
-
-        Example: "Expected code to run, but got an empty response and no error."
-      placeholder: Expected ___, but got ___.
-    validations:
-      required: true
-
   - type: textarea
     id: logs
     attributes:
-      label: 📄 Relevant Logs or Errors (Optional)
-      description: Paste API logs, terminal output, or errors here. Use triple backticks (```) for code formatting.
+      label: Relevant logs or errors (optional)
+      description: Paste relevant output or errors. Use triple backticks (```) for formatting.
       render: shell

.github/ISSUE_TEMPLATE/config.yml

@@ -1,8 +1,5 @@
 blank_issues_enabled: false
 contact_links:
-    - name: Feature Request
-      url: https://github.com/RooCodeInc/Roo-Code/discussions/categories/feature-requests
-      about: Share and vote on feature requests for Roo Code
     - name: Leave a Review
       url: https://marketplace.visualstudio.com/items?itemName=RooVeterinaryInc.roo-cline&ssr=false#review-details
       about: Enjoying Roo Code? Leave a review here!

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -1,71 +1,47 @@
-name: Detailed Feature Proposal
-description: Report a specific problem that needs solving in Roo Code
-labels: ["proposal", "enhancement"]
+name: Enhancement Request
+description: Propose an improvement in plain language focused on user benefit
+labels: ["enhancement"]
+title: "[ENHANCEMENT] "
 body:
   - type: markdown
     attributes:
       value: |
-        **Thank you for submitting a feature request for Roo Code!**
-        
-        This template helps you describe problems that need solving. Focus on the problem - the Roo team will work to design solutions unless you want to contribute the implementation yourself.
-        
-        **Quality over speed:** We prefer detailed, clear problem descriptions over quick ones. Vague requests often get closed or require multiple rounds of clarification, which wastes everyone's time.
-        
-        **Before submitting:**
-        - Search existing [Issues](https://github.com/RooCodeInc/Roo-Code/issues) and [Discussions](https://github.com/RooCodeInc/Roo-Code/discussions) to avoid duplicates
-        - For general ideas, use [GitHub Discussions](https://github.com/RooCodeInc/Roo-Code/discussions/categories/feature-requests) instead of this template.
-
-  - type: markdown
-    attributes:
-      value: |
-        ## ❌ Common mistakes that lead to request rejection:
-        - **Vague problem descriptions:** "UI is bad" -> Should be: "Submit button is invisible on dark theme"
-        - **Missing user impact:** "This would be cool" -> Should explain who benefits and how
-        - **No specific context:** Describe exactly when and how the problem occurs
-
+        Thank you for helping improve Roo Code!
+        Please focus on the problem and the desired behavior in plain language.
 
   - type: textarea
-    id: problem-description
+    id: problem
     attributes:
-      label: What specific problem does this solve?
-      description: |
-        **Be concrete and detailed.** Explain the problem from a user's perspective.
-        
-        ✅ **Good examples (specific, clear impact):**
-        - "When running large tasks, users wait 5+ minutes because tasks execute sequentially instead of in parallel, blocking productivity"
-        - "AI can only read one file per request, forcing users to make multiple requests for multi-file projects, increasing wait time from 30s to 5+ minutes"
-        - "Dark theme users can't see the submit button because it uses white text on light grey background"
-        
-        ❌ **Poor examples (vague, unclear impact):**
-        - "The UI looks weird" -> What specifically looks weird? On which screen? What's the impact?
-        - "System prompt is not good" -> What's wrong with it? What behaviour does it cause? What should it do instead?
-        - "Performance could be better" -> Where? How slow is it currently? What's the user impact?
-        
-        **Your problem description should answer:**
-        - Who is affected? (all users, specific user types, etc.)
-        - When does this happen? (specific scenarios/steps)
-        - What's the current behaviour vs expected behaviour?
-        - What's the impact? (time wasted, errors caused, etc.)
-      placeholder: Be specific about the problem, who it affects, and the impact. Avoid generic statements like "it's slow" or "it's confusing."
+      label: Problem (one or two sentences)
+      description: What problem are users facing?
+      placeholder: e.g., "Users often click Copy Run by mistake and duplicate runs unintentionally."
     validations:
       required: true
 
+  - type: textarea
+    id: context
+    attributes:
+      label: Context (who is affected and when)
+      description: Who encounters this and in what situation?
+      placeholder: e.g., "Happens when browsing the Runs list; most visible for new users."
+    validations:
+      required: true
 
   - type: textarea
-    id: additional-context
+    id: desired
     attributes:
-      label: Additional context (optional)
-      description: Mockups, screenshots, links, user quotes, or other relevant information that supports your proposal.
+      label: Desired behavior (conceptual, not technical)
+      description: Describe what should happen in simple terms.
+      placeholder: e.g., "Ask for confirmation before copying a run."
+    validations:
+      required: true
 
   - type: textarea
-    id: roo-code-tasks
+    id: constraints
     attributes:
-      label: Roo Code Task Links (Optional)
-      description: |
-        If you used Roo Code to explore this feature request or develop solutions, share the public task links here.
-        This helps maintainers understand the context and any exploration you've done.
-        Example: https://app.roocode.com/share/task-id
-      placeholder: Paste your Roo Code share links here, one per line
+      label: Constraints / preferences (optional)
+      description: Any considerations like performance, accessibility, or UX expectations.
+      placeholder: e.g., "Keep it quick and unobtrusive; keyboard accessible."
 
   - type: checkboxes
     id: checklist
@@ -74,128 +50,42 @@ body:
       options:
         - label: I've searched existing Issues and Discussions for duplicates
           required: true
-        - label: This describes a specific problem with clear impact and context
+        - label: This describes a specific problem with clear context and impact
           required: true
 
+  - type: textarea
+    id: roo-code-tasks
+    attributes:
+      label: Roo Code Task Links (optional)
+      description: If you explored this with Roo Code, share public task links for context.
+      placeholder: Paste your Roo Code share links here, one per line
+
   - type: markdown
     attributes:
       value: |
         ---
-        
-        ## 🛠️ **Optional: Contributing & Technical Analysis**
-        
-        **🎯 Just reporting a problem?** You can click "Submit new issue" right now! The sections below are only needed if you want to contribute a solution via pull request.
-        
-        **⚠️ Only continue if you want to:**
-        - Propose a specific solution design
-        - Implement the feature yourself via pull request
-        - Provide technical analysis to help with implementation
-        
-        **For contributors who continue:**
-        - A maintainer (especially @hannesrudolph) will review this proposal. **Do not start implementation until approved and assigned.** We're a small team with limited resources, so every code addition needs careful consideration. We're always happy to receive clear, actionable proposals though!
-        - Join [Discord](https://discord.gg/roocode) and DM **Hannes Rudolph** (`hrudolph`) for guidance on implementation
-        - Check our [Roadmap](https://github.com/orgs/RooCodeInc/projects/1/views/1?query=sort%3Aupdated-desc+is%3Aopen&filterQuery=is%3Aissue%2Copen%2Cclosed+label%3A%22feature+request%22+status%3A%22Issue+%5BUnassigned%5D%22%2C%22Issue+%5BIn+Progress%5D%22) to see open feature requests ready to be implemented or currently being worked on
-
-  - type: checkboxes
-    id: willingness-to-contribute
-    attributes:
-      label: Interested in implementing this?
-      description: |
-        **Important:** If you check "Yes" below, the technical sections become REQUIRED.
-        We need detailed technical analysis from contributors to ensure quality implementation.
-      options:
-        - label: Yes, I'd like to help implement this feature
-          required: false
-
-  - type: checkboxes
-    id: implementation-approval
-    attributes:
-      label: Implementation requirements
-      options:
-        - label: I understand this needs approval before implementation begins
-          required: false
-
-  - type: textarea
-    id: proposed-solution
-    attributes:
-      label: How should this be solved? (REQUIRED if contributing, optional otherwise)
-      description: |
-        **If you want to implement this feature, this section is REQUIRED.**
-        
-        **Describe your solution in detail.** Explain not just what to build, but how it should work.
-        
-        ✅ **Good examples:**
-        - "Add parallel task execution: Allow up to 3 tasks to run simultaneously with a queue system for additional tasks. Show progress for each active task in the UI."
-        - "Enable multi-file AI processing: Modify the request handler to accept multiple files in a single request and process them together, reducing round trips."
-        - "Fix button contrast: Change submit button to use primary colour on dark theme (white text on blue background) instead of current grey."
-        
-        ❌ **Poor examples:**
-        - "Make it faster" -> How? What specific changes?
-        - "Improve the UI" -> Which part? What specific improvements?
-        - "Fix the prompt" -> What should the new prompt do differently?
-        
-        **Your solution should explain:**
-        - What exactly will change?
-        - How will users interact with it?
-        - What will the new behaviour look like?
-      placeholder: Describe the specific changes and how they will work. Include user interaction details if relevant.
+        Optional: You can stop here if you're just proposing the improvement.
 
   - type: textarea
     id: acceptance-criteria
     attributes:
-      label: How will we know it works? (Acceptance Criteria - REQUIRED if contributing, optional otherwise)
-      description: |
-        **If you want to implement this feature, this section is REQUIRED.**
-        
-        **This is crucial - don't skip it.** Define what "working" looks like with specific, testable criteria.
-        
-        **Format suggestion:**
-        ```
-        Given [context/situation]
+      label: Acceptance criteria (optional)
+      description: Define what “working” looks like with specific, testable outcomes.
+      placeholder: |
+        Given [context]
         When [user action]
         Then [expected result]
         And [additional expectations]
         But [what should NOT happen]
-        ```
-        
-        **Example:**
-        ```
-        Given I have 5 large tasks to run
-        When I start all of them
-        Then they execute in parallel (max 3 at once, can be configured)
-        And I see progress for each active task
-        And queued tasks show "waiting" status
-        But the UI doesn't freeze or become unresponsive
-        ```
-      placeholder: |
-        Define specific, testable criteria. What should users be able to do? What should happen? What should NOT happen?
-        Use the Given/When/Then format above or your own clear structure.
 
   - type: textarea
-    id: technical-considerations
+    id: proposed-solution
     attributes:
-      label: Technical considerations (REQUIRED if contributing, optional otherwise)
-      description: |
-        **If you want to implement this feature, this section is REQUIRED.**
-        
-        Share technical insights that could help planning:
-        - Implementation approach or architecture changes
-        - Performance implications
-        - Compatibility concerns
-        - Systems that might be affected
-        - Potential blockers you can foresee
-      placeholder: e.g., "Will need to refactor task manager", "Could impact memory usage on large files", "Requires a large portion of code to be rewritten"
+      label: Proposed approach (optional)
+      description: If you have an idea, describe it briefly in plain language.
 
   - type: textarea
-    id: trade-offs-and-risks
+    id: risks
     attributes:
-      label: Trade-offs and risks (REQUIRED if contributing, optional otherwise)
-      description: |
-        **If you want to implement this feature, this section is REQUIRED.**
-        
-        What could go wrong or what alternatives did you consider?
-        - Alternative approaches and why you chose this one
-        - Potential negative impacts (performance, UX, etc.)
-        - Breaking changes or migration concerns
-        - Edge cases that need careful handling
-      placeholder: 'e.g., "Alternative: use library X but it is 500KB larger", "Risk: might slow older devices", "Breaking: changes API response format"'
+      label: Trade-offs / risks (optional)
+      description: Potential downsides or alternatives considered.

.github/pull_request_template.md

@@ -1,75 +0,0 @@
-<!--
-Thank you for contributing to Roo Code!
-
-Before submitting your PR, please ensure:
-- It's linked to an approved GitHub Issue.
-- You've reviewed our [Contributing Guidelines](../CONTRIBUTING.md).
--->
-
-### Related GitHub Issue
-
-<!-- Every PR MUST be linked to an approved issue. -->
-
-Closes: # <!-- Replace with the issue number, e.g., Closes: #123 -->
-
-### Roo Code Task Context (Optional)
-
-<!--
-If you used Roo Code to help create this PR, you can share public task links here.
-This helps reviewers understand your development process and provides additional context.
-Example: https://app.roocode.com/share/task-id
--->
-
-### Description
-
-<!--
-Briefly summarize the changes in this PR and how they address the linked issue.
-The issue should cover the "what" and "why"; this section should focus on:
-- The "how": key implementation details, design choices, or trade-offs made.
-- Anything specific reviewers should pay attention to in this PR.
--->
-
-### Test Procedure
-
-<!--
-Detail the steps to test your changes. This helps reviewers verify your work.
-- How did you test this specific implementation? (e.g., unit tests, manual testing steps)
-- How can reviewers reproduce your tests or verify the fix/feature?
-- Include relevant testing environment details if applicable.
--->
-
-### 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.
-- [ ] **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).
-- [ ] **Contribution Guidelines**: I have read and agree to the [Contributor Guidelines](/CONTRIBUTING.md).
-
-### Screenshots / Videos
-
-<!--
-For UI changes, please provide before-and-after screenshots or a short video of the *actual results*.
-This greatly helps in understanding the visual impact of your changes.
--->
-
-### Documentation Updates
-
-<!--
-Does this PR necessitate updates to user-facing documentation?
-- [ ] No documentation updates are required.
-- [ ] Yes, documentation updates are required. (Please describe what needs to be updated or link to a PR in the docs repository).
--->
-
-### Additional Notes
-
-<!-- Add any other context, questions, or information for reviewers here. -->
-
-### Get in Touch
-
-<!--
-Please provide your Discord username for reviewers or maintainers to reach you if they have questions about your PR
--->

.github/workflows/changeset-release.yml

@@ -31,8 +31,6 @@ jobs:
           ref: ${{ env.GIT_REF }}
       - name: Setup Node.js and pnpm
         uses: ./.github/actions/setup-node-pnpm
-        with:
-          skip-checkout: 'true'
 
       # Check if there are any new changesets to process
       - name: Check for changesets

.github/workflows/cli-release.yml

@@ -0,0 +1,394 @@
+name: CLI Release
+
+on:
+  workflow_dispatch:
+    inputs:
+      version:
+        description: 'Version to release (e.g., 0.1.0). Leave empty to use package.json version.'
+        required: false
+        type: string
+      dry_run:
+        description: 'Dry run (build and test but do not create release).'
+        required: false
+        type: boolean
+        default: false
+
+jobs:
+  # Build CLI for each platform.
+  build:
+    strategy:
+      fail-fast: false
+      matrix:
+        include:
+          - os: macos-latest
+            platform: darwin-arm64
+            runs-on: macos-latest
+          - os: ubuntu-latest
+            platform: linux-x64
+            runs-on: ubuntu-latest
+          - os: ubuntu-24.04-arm
+            platform: linux-arm64
+            runs-on: ubuntu-24.04-arm
+
+    runs-on: ${{ matrix.runs-on }}
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - name: Setup Node.js and pnpm
+        uses: ./.github/actions/setup-node-pnpm
+
+      - name: Get version
+        id: version
+        run: |
+          if [ -n "${{ inputs.version }}" ]; then
+            VERSION="${{ inputs.version }}"
+          else
+            VERSION=$(node -p "require('./apps/cli/package.json').version")
+          fi
+          echo "version=$VERSION" >> $GITHUB_OUTPUT
+          echo "tag=cli-v$VERSION" >> $GITHUB_OUTPUT
+          echo "Using version: $VERSION"
+
+      - name: Build extension bundle
+        run: pnpm bundle
+
+      - name: Build CLI
+        run: pnpm --filter @roo-code/cli build
+
+      - name: Create release tarball
+        id: tarball
+        env:
+          VERSION: ${{ steps.version.outputs.version }}
+          PLATFORM: ${{ matrix.platform }}
+        run: |
+          RELEASE_DIR="roo-cli-${PLATFORM}"
+          TARBALL="roo-cli-${PLATFORM}.tar.gz"
+
+          # Clean up any previous build.
+          rm -rf "$RELEASE_DIR"
+          rm -f "$TARBALL"
+
+          # Create directory structure.
+          mkdir -p "$RELEASE_DIR/bin"
+          mkdir -p "$RELEASE_DIR/lib"
+          mkdir -p "$RELEASE_DIR/extension"
+
+          # Copy CLI dist files.
+          echo "Copying CLI files..."
+          cp -r apps/cli/dist/* "$RELEASE_DIR/lib/"
+
+          # Create package.json for npm install.
+          echo "Creating package.json..."
+          node -e "
+            const pkg = require('./apps/cli/package.json');
+            const newPkg = {
+              name: '@roo-code/cli',
+              version: '$VERSION',
+              type: 'module',
+              dependencies: {
+                '@inkjs/ui': pkg.dependencies['@inkjs/ui'],
+                '@trpc/client': pkg.dependencies['@trpc/client'],
+                'commander': pkg.dependencies.commander,
+                'fuzzysort': pkg.dependencies.fuzzysort,
+                'ink': pkg.dependencies.ink,
+                'p-wait-for': pkg.dependencies['p-wait-for'],
+                'react': pkg.dependencies.react,
+                'superjson': pkg.dependencies.superjson,
+                'zustand': pkg.dependencies.zustand
+              }
+            };
+            console.log(JSON.stringify(newPkg, null, 2));
+          " > "$RELEASE_DIR/package.json"
+
+          # Copy extension bundle.
+          echo "Copying extension bundle..."
+          cp -r src/dist/* "$RELEASE_DIR/extension/"
+
+          # Add package.json to extension directory for CommonJS.
+          echo '{"type": "commonjs"}' > "$RELEASE_DIR/extension/package.json"
+
+          # Find and copy ripgrep binary.
+          echo "Looking for ripgrep binary..."
+          RIPGREP_PATH=$(find node_modules -path "*/@vscode/ripgrep/bin/rg" -type f 2>/dev/null | head -1)
+          if [ -n "$RIPGREP_PATH" ] && [ -f "$RIPGREP_PATH" ]; then
+            echo "Found ripgrep at: $RIPGREP_PATH"
+            mkdir -p "$RELEASE_DIR/node_modules/@vscode/ripgrep/bin"
+            cp "$RIPGREP_PATH" "$RELEASE_DIR/node_modules/@vscode/ripgrep/bin/"
+            chmod +x "$RELEASE_DIR/node_modules/@vscode/ripgrep/bin/rg"
+            mkdir -p "$RELEASE_DIR/bin"
+            cp "$RIPGREP_PATH" "$RELEASE_DIR/bin/"
+            chmod +x "$RELEASE_DIR/bin/rg"
+          else
+            echo "Warning: ripgrep binary not found"
+          fi
+
+          # Create the wrapper script
+          echo "Creating wrapper script..."
+          printf '%s\n' '#!/usr/bin/env node' \
+            '' \
+            "import { fileURLToPath } from 'url';" \
+            "import { dirname, join } from 'path';" \
+            '' \
+            'const __filename = fileURLToPath(import.meta.url);' \
+            'const __dirname = dirname(__filename);' \
+            '' \
+            '// Set environment variables for the CLI' \
+            "process.env.ROO_CLI_ROOT = join(__dirname, '..');" \
+            "process.env.ROO_EXTENSION_PATH = join(__dirname, '..', 'extension');" \
+            "process.env.ROO_RIPGREP_PATH = join(__dirname, 'rg');" \
+            '' \
+            '// Import and run the actual CLI' \
+            "await import(join(__dirname, '..', 'lib', 'index.js'));" \
+            > "$RELEASE_DIR/bin/roo"
+
+          chmod +x "$RELEASE_DIR/bin/roo"
+
+          # Create empty .env file.
+          touch "$RELEASE_DIR/.env"
+
+          # Create tarball.
+          echo "Creating tarball..."
+          tar -czvf "$TARBALL" "$RELEASE_DIR"
+
+          # Clean up release directory.
+          rm -rf "$RELEASE_DIR"
+
+          # Create checksum.
+          if command -v sha256sum &> /dev/null; then
+            sha256sum "$TARBALL" > "${TARBALL}.sha256"
+          elif command -v shasum &> /dev/null; then
+            shasum -a 256 "$TARBALL" > "${TARBALL}.sha256"
+          fi
+
+          echo "tarball=$TARBALL" >> $GITHUB_OUTPUT
+          echo "Created: $TARBALL"
+          ls -la "$TARBALL"
+
+      - name: Verify tarball
+        env:
+          PLATFORM: ${{ matrix.platform }}
+        run: |
+          TARBALL="roo-cli-${PLATFORM}.tar.gz"
+
+          # Create temp directory for verification.
+          VERIFY_DIR=$(mktemp -d)
+
+          # Extract and verify structure.
+          tar -xzf "$TARBALL" -C "$VERIFY_DIR"
+
+          echo "Verifying tarball contents..."
+          ls -la "$VERIFY_DIR/roo-cli-${PLATFORM}/"
+
+          # Check required files exist.
+          test -f "$VERIFY_DIR/roo-cli-${PLATFORM}/bin/roo" || { echo "Missing bin/roo"; exit 1; }
+          test -f "$VERIFY_DIR/roo-cli-${PLATFORM}/lib/index.js" || { echo "Missing lib/index.js"; exit 1; }
+          test -f "$VERIFY_DIR/roo-cli-${PLATFORM}/package.json" || { echo "Missing package.json"; exit 1; }
+          test -d "$VERIFY_DIR/roo-cli-${PLATFORM}/extension" || { echo "Missing extension directory"; exit 1; }
+
+          echo "Tarball verification passed!"
+
+          # Cleanup.
+          rm -rf "$VERIFY_DIR"
+
+      - name: Upload artifact
+        uses: actions/upload-artifact@v4
+        with:
+          name: cli-${{ matrix.platform }}
+          path: |
+            roo-cli-${{ matrix.platform }}.tar.gz
+            roo-cli-${{ matrix.platform }}.tar.gz.sha256
+          retention-days: 7
+
+  # Create GitHub release with all platform artifacts.
+  release:
+    needs: build
+    runs-on: ubuntu-latest
+    if: ${{ !inputs.dry_run }}
+    permissions:
+      contents: write
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+
+      - name: Get version
+        id: version
+        run: |
+          if [ -n "${{ inputs.version }}" ]; then
+            VERSION="${{ inputs.version }}"
+          else
+            VERSION=$(node -p "require('./apps/cli/package.json').version")
+          fi
+          echo "version=$VERSION" >> $GITHUB_OUTPUT
+          echo "tag=cli-v$VERSION" >> $GITHUB_OUTPUT
+
+      - name: Download all artifacts
+        uses: actions/download-artifact@v4
+        with:
+          path: artifacts
+
+      - name: Prepare release files
+        run: |
+          mkdir -p release
+          find artifacts -name "*.tar.gz" -exec cp {} release/ \;
+          find artifacts -name "*.sha256" -exec cp {} release/ \;
+          ls -la release/
+
+      - name: Extract changelog
+        id: changelog
+        env:
+          VERSION: ${{ steps.version.outputs.version }}
+        run: |
+          CHANGELOG_FILE="apps/cli/CHANGELOG.md"
+
+          if [ -f "$CHANGELOG_FILE" ]; then
+            # Extract content between version headers.
+            CONTENT=$(awk -v version="$VERSION" '
+              BEGIN { found = 0; content = ""; target = "[" version "]" }
+              /^## \[/ {
+                if (found) { exit }
+                if (index($0, target) > 0) { found = 1; next }
+              }
+              found { content = content $0 "\n" }
+              END { print content }
+            ' "$CHANGELOG_FILE")
+
+            if [ -n "$CONTENT" ]; then
+              echo "Found changelog content"
+              echo "content<<EOF" >> $GITHUB_OUTPUT
+              echo "$CONTENT" >> $GITHUB_OUTPUT
+              echo "EOF" >> $GITHUB_OUTPUT
+            else
+              echo "No changelog content found for version $VERSION"
+              echo "content=" >> $GITHUB_OUTPUT
+            fi
+          else
+            echo "No changelog file found"
+            echo "content=" >> $GITHUB_OUTPUT
+          fi
+
+      - name: Generate checksums summary
+        id: checksums
+        run: |
+          echo "checksums<<EOF" >> $GITHUB_OUTPUT
+          cat release/*.sha256 >> $GITHUB_OUTPUT
+          echo "EOF" >> $GITHUB_OUTPUT
+
+      - name: Check for existing release
+        id: check_release
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          TAG: ${{ steps.version.outputs.tag }}
+        run: |
+          if gh release view "$TAG" &> /dev/null; then
+            echo "exists=true" >> $GITHUB_OUTPUT
+          else
+            echo "exists=false" >> $GITHUB_OUTPUT
+          fi
+
+      - name: Delete existing release
+        if: steps.check_release.outputs.exists == 'true'
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          TAG: ${{ steps.version.outputs.tag }}
+        run: |
+          echo "Deleting existing release $TAG..."
+          gh release delete "$TAG" --yes || true
+          git push origin ":refs/tags/$TAG" || true
+
+      - name: Create GitHub Release
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          VERSION: ${{ steps.version.outputs.version }}
+          TAG: ${{ steps.version.outputs.tag }}
+          CHANGELOG_CONTENT: ${{ steps.changelog.outputs.content }}
+          CHECKSUMS: ${{ steps.checksums.outputs.checksums }}
+        run: |
+          NOTES_FILE=$(mktemp)
+
+          if [ -n "$CHANGELOG_CONTENT" ]; then
+            echo "## What's New" >> "$NOTES_FILE"
+            echo "" >> "$NOTES_FILE"
+            echo "$CHANGELOG_CONTENT" >> "$NOTES_FILE"
+            echo "" >> "$NOTES_FILE"
+          fi
+
+          echo "## Installation" >> "$NOTES_FILE"
+          echo "" >> "$NOTES_FILE"
+          echo '```bash' >> "$NOTES_FILE"
+          echo "curl -fsSL https://raw.githubusercontent.com/RooCodeInc/Roo-Code/main/apps/cli/install.sh | sh" >> "$NOTES_FILE"
+          echo '```' >> "$NOTES_FILE"
+          echo "" >> "$NOTES_FILE"
+          echo "Or install a specific version:" >> "$NOTES_FILE"
+          echo '```bash' >> "$NOTES_FILE"
+          echo "ROO_VERSION=$VERSION curl -fsSL https://raw.githubusercontent.com/RooCodeInc/Roo-Code/main/apps/cli/install.sh | sh" >> "$NOTES_FILE"
+          echo '```' >> "$NOTES_FILE"
+          echo "" >> "$NOTES_FILE"
+          echo "## Requirements" >> "$NOTES_FILE"
+          echo "" >> "$NOTES_FILE"
+          echo "- Node.js 20 or higher" >> "$NOTES_FILE"
+          echo "- macOS Apple Silicon (M1/M2/M3/M4), Linux x64, or Linux ARM64" >> "$NOTES_FILE"
+          echo "" >> "$NOTES_FILE"
+          echo "## Usage" >> "$NOTES_FILE"
+          echo "" >> "$NOTES_FILE"
+          echo '```bash' >> "$NOTES_FILE"
+          echo "# Run a task" >> "$NOTES_FILE"
+          echo 'roo "What is this project?"' >> "$NOTES_FILE"
+          echo "" >> "$NOTES_FILE"
+          echo "# See all options" >> "$NOTES_FILE"
+          echo "roo --help" >> "$NOTES_FILE"
+          echo '```' >> "$NOTES_FILE"
+          echo "" >> "$NOTES_FILE"
+          echo "## Platform Support" >> "$NOTES_FILE"
+          echo "" >> "$NOTES_FILE"
+          echo "This release includes binaries for:" >> "$NOTES_FILE"
+          echo '- `roo-cli-darwin-arm64.tar.gz` - macOS Apple Silicon (M1/M2/M3)' >> "$NOTES_FILE"
+          echo '- `roo-cli-linux-x64.tar.gz` - Linux x64' >> "$NOTES_FILE"
+          echo '- `roo-cli-linux-arm64.tar.gz` - Linux ARM64' >> "$NOTES_FILE"
+          echo "" >> "$NOTES_FILE"
+          echo "## Checksums" >> "$NOTES_FILE"
+          echo "" >> "$NOTES_FILE"
+          echo '```' >> "$NOTES_FILE"
+          echo "$CHECKSUMS" >> "$NOTES_FILE"
+          echo '```' >> "$NOTES_FILE"
+
+          gh release create "$TAG" \
+            --title "Roo Code CLI v$VERSION" \
+            --notes-file "$NOTES_FILE" \
+            --prerelease \
+            release/*
+
+          rm -f "$NOTES_FILE"
+          echo "Release created: https://github.com/${{ github.repository }}/releases/tag/$TAG"
+
+  # Summary job for dry runs
+  summary:
+    needs: build
+    runs-on: ubuntu-latest
+    if: ${{ inputs.dry_run }}
+
+    steps:
+      - name: Download all artifacts
+        uses: actions/download-artifact@v4
+        with:
+          path: artifacts
+
+      - name: Show build summary
+        run: |
+          echo "## Dry Run Complete" >> $GITHUB_STEP_SUMMARY
+          echo "" >> $GITHUB_STEP_SUMMARY
+          echo "The following artifacts were built:" >> $GITHUB_STEP_SUMMARY
+          echo "" >> $GITHUB_STEP_SUMMARY
+          find artifacts -name "*.tar.gz" | while read f; do
+            SIZE=$(ls -lh "$f" | awk '{print $5}')
+            echo "- $(basename $f) ($SIZE)" >> $GITHUB_STEP_SUMMARY
+          done
+          echo "" >> $GITHUB_STEP_SUMMARY
+          echo "### Checksums" >> $GITHUB_STEP_SUMMARY
+          echo "\`\`\`" >> $GITHUB_STEP_SUMMARY
+          cat artifacts/*/*.sha256 >> $GITHUB_STEP_SUMMARY
+          echo "\`\`\`" >> $GITHUB_STEP_SUMMARY

.github/workflows/code-qa.yml

@@ -58,50 +58,3 @@ jobs:
               uses: ./.github/actions/setup-node-pnpm
             - name: Run unit tests
               run: pnpm test
-
-    check-openrouter-api-key:
-        runs-on: ubuntu-latest
-        outputs:
-            exists: ${{ steps.openrouter-api-key-check.outputs.defined }}
-        steps:
-            - name: Check if OpenRouter API key exists
-              id: openrouter-api-key-check
-              shell: bash
-              run: |
-                  if [ "${{ secrets.OPENROUTER_API_KEY }}" != '' ]; then
-                    echo "defined=true" >> $GITHUB_OUTPUT;
-                  else
-                    echo "defined=false" >> $GITHUB_OUTPUT;
-                  fi
-
-    integration-test:
-        runs-on: ubuntu-latest
-        needs: [check-openrouter-api-key]
-        if: needs.check-openrouter-api-key.outputs.exists == 'true'
-        steps:
-            - name: Checkout code
-              uses: actions/checkout@v4
-            - name: Setup Node.js and pnpm
-              uses: ./.github/actions/setup-node-pnpm
-            - name: Create .env.local file
-              working-directory: apps/vscode-e2e
-              run: echo "OPENROUTER_API_KEY=${{ secrets.OPENROUTER_API_KEY }}" > .env.local
-            - name: Run integration tests
-              working-directory: apps/vscode-e2e
-              run: xvfb-run -a pnpm test:ci
-
-    notify-slack-on-failure:
-        runs-on: ubuntu-latest
-        needs: [check-translations, knip, compile, unit-test, integration-test]
-        if: ${{ always() && github.event_name == 'push' && github.ref == 'refs/heads/main' && contains(needs.*.result, 'failure') }}
-        steps:
-            - name: Checkout code
-              uses: actions/checkout@v4
-
-            - name: Send Slack notification on failure
-              uses: ./.github/actions/slack-notify
-              with:
-                  webhook-url: ${{ secrets.SLACK_WEBHOOK_URL }}
-                  channel: "#ci"
-                  workflow-name: "Code QA"
-                  failed-jobs: ${{ toJSON(needs) }}

.github/workflows/discord-pr-notify.yml

@@ -1,26 +0,0 @@
-name: Discord PR Notifier
-
-on:
-  workflow_dispatch:
-  pull_request_target:
-    types: [opened]
-
-jobs:
-  notify:
-    runs-on: ubuntu-latest
-    if: github.head_ref != 'changeset-release/main'
-    steps:
-      - name: Send Discord Notification
-        run: |
-          PAYLOAD=$(jq -n \
-            --arg title "${{ github.event.pull_request.title }}" \
-            --arg url "${{ github.event.pull_request.html_url }}" \
-            --arg author "${{ github.event.pull_request.user.login }}" \
-            '{
-              content: ("🚀 **New PR:** " + $title + "\n🔗 <" + $url + ">\n👤 **Author:** " + $author),
-              thread_name: ($title + " by " + $author)
-            }')
-
-          curl -X POST "${{ secrets.DISCORD_WEBHOOK }}" \
-          -H "Content-Type: application/json" \
-          -d "$PAYLOAD"

.github/workflows/docs-pages.yml

@@ -0,0 +1,55 @@
+name: Deploy docs to GitHub Pages
+
+on:
+    push:
+        branches:
+            - main
+        paths:
+            - "apps/docs/**"
+            - ".github/workflows/docs-pages.yml"
+            - ".github/actions/setup-node-pnpm/**"
+            - "package.json"
+            - "pnpm-lock.yaml"
+            - "pnpm-workspace.yaml"
+    workflow_dispatch:
+
+concurrency:
+    group: docs-pages
+    cancel-in-progress: true
+
+permissions:
+    contents: read
+    pages: write
+    id-token: write
+
+jobs:
+    build:
+        runs-on: ubuntu-latest
+        steps:
+            - name: Checkout code
+              uses: actions/checkout@v4
+            - name: Setup Node.js and pnpm
+              uses: ./.github/actions/setup-node-pnpm
+              with:
+                  install-args: "--frozen-lockfile"
+            - name: Run type check
+              run: pnpm --filter @roo-code/docs check-types
+            - name: Run lint
+              run: pnpm --filter @roo-code/docs lint
+            - name: Build docs
+              run: pnpm --filter @roo-code/docs build
+            - name: Upload Pages artifact
+              uses: actions/upload-pages-artifact@v3
+              with:
+                  path: apps/docs/build
+
+    deploy:
+        runs-on: ubuntu-latest
+        needs: build
+        environment:
+            name: github-pages
+            url: ${{ steps.deployment.outputs.page_url }}
+        steps:
+            - name: Deploy to GitHub Pages
+              id: deployment
+              uses: actions/deploy-pages@v4

.github/workflows/evals.yml

@@ -1,74 +0,0 @@
-name: Evals
-
-on:
-    pull_request:
-        types: [labeled]
-    workflow_dispatch:
-
-env:
-    DOCKER_BUILDKIT: 1
-    COMPOSE_DOCKER_CLI_BUILD: 1
-
-jobs:
-    evals:
-        # Run if triggered manually or if PR has 'evals' label.
-        if: github.event_name == 'workflow_dispatch' || contains(github.event.label.name, 'evals')
-        runs-on: blacksmith-16vcpu-ubuntu-2404
-        timeout-minutes: 45
-
-        defaults:
-            run:
-                working-directory: packages/evals
-
-        steps:
-            - name: Checkout repository
-              uses: actions/checkout@v4
-
-            - name: Set up Docker Buildx
-              uses: docker/setup-buildx-action@v3
-
-            - name: Create environment
-              run: |
-                  cat > .env.local << EOF
-                  OPENROUTER_API_KEY=${{ secrets.OPENROUTER_API_KEY || 'test-key-for-build' }}
-                  EOF
-
-                  cat > .env.development << EOF
-                  NODE_ENV=development
-                  DATABASE_URL=postgresql://postgres:password@db:5432/evals_development
-                  REDIS_URL=redis://redis:6379
-                  HOST_EXECUTION_METHOD=docker
-                  EOF
-
-            - name: Build image
-              uses: docker/build-push-action@v6
-              with:
-                  context: .
-                  file: packages/evals/Dockerfile.runner
-                  tags: evals-runner:latest
-                  cache-from: type=gha
-                  cache-to: type=gha,mode=max
-                  push: false
-                  load: true
-
-            - name: Tag image
-              run: docker tag evals-runner:latest evals-runner
-
-            - name: Start containers
-              run: |
-                  docker compose up -d db redis
-                  timeout 60 bash -c 'until docker compose exec -T db pg_isready -U postgres; do sleep 2; done'
-                  timeout 60 bash -c 'until docker compose exec -T redis redis-cli ping | grep -q PONG; do sleep 2; done'
-                  docker compose run --rm runner sh -c 'nc -z db 5432 && echo "✓ Runner -> Database connection successful"'
-                  docker compose run --rm runner sh -c 'nc -z redis 6379 && echo "✓ Runner -> Redis connection successful"'
-                  docker compose run --rm runner docker ps
-
-            - name: Run database migrations
-              run: docker compose run --rm runner pnpm --filter @roo-code/evals db:migrate
-
-            - name: Run evals
-              run: docker compose run --rm runner pnpm --filter @roo-code/evals cli --ci
-
-            - name: Cleanup
-              if: always()
-              run: docker compose down -v --remove-orphans

.github/workflows/marketplace-publish.yml

@@ -25,8 +25,6 @@ jobs:
           ref: ${{ env.GIT_REF }}
       - name: Setup Node.js and pnpm
         uses: ./.github/actions/setup-node-pnpm
-        with:
-          skip-checkout: 'true'
       - name: Configure Git
         run: |
           git config user.name "github-actions[bot]"

.github/workflows/nightly-publish.yml

@@ -1,10 +1,7 @@
 name: Nightly Publish
 
 on:
-  workflow_run:
-    workflows: ["Code QA Roo Code"]
-    types:
-      - completed
+  push:
     branches: [main]
   workflow_dispatch: # Allows manual triggering.
 
@@ -23,7 +20,6 @@ jobs:
       - name: Setup Node.js and pnpm
         uses: ./.github/actions/setup-node-pnpm
         with:
-          skip-checkout: 'true'
           install-args: '--frozen-lockfile'
       - name: Forge numeric Nightly version
         id: version

.github/workflows/update-contributors.yml

@@ -1,46 +0,0 @@
-name: Update Contributors
-
-on:
-  push:
-    branches:
-      - main
-  workflow_dispatch:
-
-jobs:
-  update-contributors:
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write  # Needed for pushing changes.
-      pull-requests: write  # Needed for creating PRs.
-    steps:
-      - name: Checkout code
-        uses: actions/checkout@v4
-      - name: Setup Node.js and pnpm
-        uses: ./.github/actions/setup-node-pnpm
-      - name: Disable Husky
-        run: |
-          echo "HUSKY=0" >> $GITHUB_ENV
-          git config --global core.hooksPath /dev/null
-      - name: Update contributors and format
-        run: |
-          pnpm update-contributors
-          npx prettier --write README.md
-          if git diff --quiet; then echo "changes=false" >> $GITHUB_OUTPUT; else echo "changes=true" >> $GITHUB_OUTPUT; fi
-        id: check-changes
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-      - name: Create Pull Request
-        if: steps.check-changes.outputs.changes == 'true'
-        uses: peter-evans/create-pull-request@v7
-        with:
-          token: ${{ secrets.GITHUB_TOKEN }}
-          commit-message: "docs: update contributors list [skip ci]"
-          committer: "github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>"
-          branch: update-contributors
-          delete-branch: true
-          title: "Update contributors list"
-          body: |
-            Automated update of contributors list and related files
-
-            This PR was created automatically by a GitHub Action workflow and includes all changed files.
-          base: main

.github/workflows/website-deploy.yml

@@ -1,46 +0,0 @@
-name: Deploy roocode.com
-
-on:
-    push:
-        branches:
-            - main
-        paths:
-            - 'apps/web-roo-code/**'
-    workflow_dispatch:
-
-env:
-    VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
-    VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
-
-jobs:
-    check-secrets:
-        runs-on: ubuntu-latest
-        outputs:
-            has-vercel-token: ${{ steps.check.outputs.has-vercel-token }}
-        steps:
-            - name: Check if VERCEL_TOKEN exists
-              id: check
-              run: |
-                if [ -n "${{ secrets.VERCEL_TOKEN }}" ]; then
-                  echo "has-vercel-token=true" >> $GITHUB_OUTPUT
-                else
-                  echo "has-vercel-token=false" >> $GITHUB_OUTPUT
-                fi
-
-    deploy:
-        runs-on: ubuntu-latest
-        needs: check-secrets
-        if: ${{ needs.check-secrets.outputs.has-vercel-token == 'true' }}
-        steps:
-            - name: Checkout code
-              uses: actions/checkout@v4
-            - name: Setup Node.js and pnpm
-              uses: ./.github/actions/setup-node-pnpm
-            - name: Install Vercel CLI
-              run: npm install --global vercel@canary
-            - name: Pull Vercel Environment Information
-              run: npx vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}
-            - name: Build Project Artifacts
-              run: npx vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
-            - name: Deploy Project Artifacts to Vercel
-              run: npx vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}

.github/workflows/website-preview.yml

@@ -1,84 +0,0 @@
-name: Preview roocode.com
-
-on:
-    push:
-        branches-ignore:
-            - main
-        paths:
-            - "apps/web-roo-code/**"
-    pull_request:
-        paths:
-            - "apps/web-roo-code/**"
-    workflow_dispatch:
-
-env:
-    VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
-    VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
-
-jobs:
-    check-secrets:
-        runs-on: ubuntu-latest
-        outputs:
-            has-vercel-token: ${{ steps.check.outputs.has-vercel-token }}
-        steps:
-            - name: Check if VERCEL_TOKEN exists
-              id: check
-              run: |
-                  if [ -n "${{ secrets.VERCEL_TOKEN }}" ]; then
-                    echo "has-vercel-token=true" >> $GITHUB_OUTPUT
-                  else
-                    echo "has-vercel-token=false" >> $GITHUB_OUTPUT
-                  fi
-
-    preview:
-        runs-on: ubuntu-latest
-        needs: check-secrets
-        if: ${{ needs.check-secrets.outputs.has-vercel-token == 'true' }}
-        steps:
-            - name: Checkout code
-              uses: actions/checkout@v4
-            - name: Setup Node.js and pnpm
-              uses: ./.github/actions/setup-node-pnpm
-            - name: Install Vercel CLI
-              run: npm install --global vercel@canary
-            - name: Pull Vercel Environment Information
-              run: npx vercel pull --yes --environment=preview --token=${{ secrets.VERCEL_TOKEN }}
-            - name: Build Project Artifacts
-              run: npx vercel build --token=${{ secrets.VERCEL_TOKEN }}
-            - name: Deploy Project Artifacts to Vercel
-              id: deploy
-              run: |
-                  DEPLOYMENT_URL=$(npx vercel deploy --prebuilt --token=${{ secrets.VERCEL_TOKEN }})
-                  echo "deployment_url=$DEPLOYMENT_URL" >> $GITHUB_OUTPUT
-                  echo "Preview deployed to: $DEPLOYMENT_URL"
-
-            - name: Comment PR with preview link
-              if: github.event_name == 'pull_request'
-              uses: actions/github-script@v7
-              with:
-                  script: |
-                      const deploymentUrl = '${{ steps.deploy.outputs.deployment_url }}';
-                      const commentIdentifier = '<!-- roo-preview-comment -->';
-
-                      const { data: comments } = await github.rest.issues.listComments({
-                        owner: context.repo.owner,
-                        repo: context.repo.repo,
-                        issue_number: context.issue.number,
-                      });
-
-                      const existingComment = comments.find(comment =>
-                        comment.body.includes(commentIdentifier)
-                      );
-
-                      if (existingComment) {
-                        return;
-                      }
-
-                      const comment = commentIdentifier + '\n🚀 **Preview deployed!**\n\nYour changes have been deployed to Vercel:\n\n**Preview URL:** ' + deploymentUrl + '\n\nThis preview will be updated automatically when you push new commits to this PR.';
-
-                      await github.rest.issues.createComment({
-                        owner: context.repo.owner,
-                        repo: context.repo.repo,
-                        issue_number: context.issue.number,
-                        body: comment
-                      });

.gitignore

@@ -3,6 +3,7 @@ dist
 out
 out-*
 node_modules
+package-lock.json
 coverage/
 mock/
 
@@ -17,6 +18,7 @@ bin/
 
 # Local prompts and rules
 /local-prompts
+AGENTS.local.md
 
 # Test environment
 .test_env
@@ -45,3 +47,11 @@ logs
 .qodo/
 .vercel
 .roo/mcp.json
+
+# Qdrant
+qdrant_storage/
+
+# Architect plans
+plans/
+
+roo-cli-*.tar.gz*

.husky/pre-push

@@ -18,6 +18,19 @@ fi
 
 $pnpm_cmd run check-types
 
+# Use dotenvx to securely load .env.local and run commands that depend on it
+if [ -f ".env.local" ]; then
+  # Check if RUN_TESTS_ON_PUSH is set to true and run tests with dotenvx
+  if npx dotenvx get RUN_TESTS_ON_PUSH -f .env.local 2>/dev/null | grep -q "^true$"; then
+    npx dotenvx run -f .env.local -- $pnpm_cmd run test
+  fi
+else
+  # Fallback: run tests if RUN_TESTS_ON_PUSH is set in regular environment
+  if [ "$RUN_TESTS_ON_PUSH" = "true" ]; then
+    $pnpm_cmd run test
+  fi
+fi
+
 # Check for new changesets.
 NEW_CHANGESETS=$(find .changeset -name "*.md" ! -name "README.md" | wc -l | tr -d ' ')
 echo "Changeset files: $NEW_CHANGESETS"

.roo/commands/cli-release.md

@@ -0,0 +1,86 @@
+---
+description: "Prepare a new release of the Roo Code CLI"
+argument-hint: "[version-description]"
+mode: code
+---
+
+1. Identify changes since the last CLI release:
+
+    - Get the last CLI release tag: `gh release list --limit 10 | grep "cli-v"`
+    - View changes since last release: `git log cli-v<last-version>..HEAD -- apps/cli --oneline`
+    - Or for uncommitted changes: `git diff --stat -- apps/cli`
+
+2. Review and summarize the changes to determine an appropriate changelog entry. Group changes by type:
+
+    - **Added**: New features
+    - **Changed**: Changes to existing functionality
+    - **Fixed**: Bug fixes
+    - **Removed**: Removed features
+    - **Tests**: New or updated tests
+
+3. Bump the version in `apps/cli/package.json`:
+
+    - Increment the patch version (e.g., 0.0.43 → 0.0.44) for bug fixes and minor changes
+    - Increment the minor version (e.g., 0.0.43 → 0.1.0) for new features
+    - Increment the major version (e.g., 0.0.43 → 1.0.0) for breaking changes
+
+4. Update `apps/cli/CHANGELOG.md` with a new entry:
+
+    - Add a new section at the top (below the header) following this format:
+
+    ```markdown
+    ## [X.Y.Z] - YYYY-MM-DD
+
+    ### Added
+
+    - Description of new features
+
+    ### Changed
+
+    - Description of changes
+
+    ### Fixed
+
+    - Description of bug fixes
+    ```
+
+    - Use the current date in YYYY-MM-DD format
+    - Include links to relevant source files where helpful
+    - Describe changes from the user's perspective
+
+5. Create a release branch and commit the changes:
+
+    ```bash
+    # Ensure you're on main and up to date
+    git checkout main
+    git pull origin main
+
+    # Create a new branch for the release
+    git checkout -b cli-release-v<version>
+
+    # Commit the version bump and changelog update
+    git add apps/cli/package.json apps/cli/CHANGELOG.md
+    git commit -m "chore(cli): prepare release v<version>"
+
+    # Push the branch to origin
+    git push -u origin cli-release-v<version>
+    ```
+
+6. Create a pull request for the release:
+
+    ```bash
+    gh pr create --title "chore(cli): prepare release v<version>" \
+        --body "## CLI Release v<version>
+
+    This PR prepares the CLI release v<version>.
+
+    ### Changes
+    - Version bump in package.json
+    - Changelog update
+
+    ### Checklist
+    - [ ] Version number is correct
+    - [ ] Changelog entry is complete and accurate
+    - [ ] All CI checks pass" \
+        --base main
+    ```

.roo/commands/commit.md

@@ -0,0 +1,80 @@
+---
+description: "Commit and push changes with a descriptive message"
+argument-hint: "[optional-context]"
+mode: code
+---
+
+1. Analyze the current changes to understand what needs to be committed:
+
+    ```bash
+    # Check for staged and unstaged changes
+    git status --short
+
+    # View the diff of all changes (staged and unstaged)
+    git diff HEAD
+    ```
+
+2. Based on the diff output, formulate a commit message following conventional commit format:
+
+    - **feat**: New feature or functionality
+    - **fix**: Bug fix
+    - **refactor**: Code restructuring without behavior change
+    - **docs**: Documentation changes
+    - **test**: Adding or updating tests
+    - **chore**: Maintenance tasks, dependencies, configs
+    - **style**: Formatting, whitespace, no logic changes
+
+    Format: `type(scope): brief description`
+
+    Examples:
+
+    - `feat(api): add user authentication endpoint`
+    - `fix(ui): resolve button alignment on mobile`
+    - `refactor(core): simplify error handling logic`
+    - `docs(readme): update installation instructions`
+
+3. Stage all unstaged changes:
+
+    ```bash
+    git add -A
+    ```
+
+4. Commit with the generated message:
+
+    ```bash
+    git commit -m "type(scope): brief description"
+    ```
+
+    **If pre-commit hooks fail:**
+
+    - Review the error output (linter errors, type checking errors, etc.)
+    - Fix the identified issues in the affected files
+    - Re-stage the fixes: `git add -A`
+    - Retry the commit: `git commit -m "type(scope): brief description"`
+
+5. Push to the remote repository:
+
+    ```bash
+    git push
+    ```
+
+    **If pre-push hooks fail:**
+
+    - Review the error output (test failures, linter errors, etc.)
+    - Fix the identified issues in the affected files
+    - Stage and commit the fixes using steps 3-4
+    - Retry the push: `git push`
+
+**Tips for good commit messages:**
+
+- Keep the first line under 72 characters
+- Use imperative mood ("add", "fix", "update", not "added", "fixes", "updated")
+- Be specific but concise
+- If multiple unrelated changes exist, consider splitting into separate commits
+
+**Common hook failures and fixes:**
+
+- **Linter errors**: Run the project's linter (e.g., `npm run lint` or `pnpm lint`) to see all issues, then fix them
+- **Type checking errors**: Run type checker (e.g., `npx tsc --noEmit`) to identify type issues
+- **Test failures**: Run tests (e.g., `npm test` or `pnpm test`) to identify failing tests and fix them
+- **Format issues**: Run formatter (e.g., `npm run format` or `pnpm format`) to auto-fix formatting

.roo/commands/release.md

@@ -0,0 +1,45 @@
+---
+description: "Create a new release of the Roo Code extension"
+argument-hint: patch | minor | major
+mode: code
+---
+
+1. Identify the SHA corresponding to the most recent release using GitHub CLI: `gh release view --json tagName,targetCommitish,publishedAt`
+2. Analyze changes since the last release using: `gh pr list --state merged --base main --json number,title,author,url,mergedAt,closingIssuesReferences --limit 1000 -q '[.[] | select(.mergedAt > "TIMESTAMP") | {number, title, author: .author.login, url, mergedAt, issues: .closingIssuesReferences}] | sort_by(.number)'`
+3. For each PR with linked issues, fetch the issue details to get the issue reporter: `gh issue view ISSUE_NUMBER --json number,author -q '{number, reporter: .author.login}'`
+4. Summarize the changes. If the user did not specify, ask them whether this should be a major, minor, or patch release.
+5. Create a changeset in .changeset/v[version].md instead of directly modifying package.json. The format is:
+
+```
+---
+"roo-cline": patch|minor|major
+---
+[list of changes]
+```
+
+- Always include contributor attribution and the PR number: use "(PR #<prNumber> by @username)".
+- For PRs that close issues, include both the issue number and the PR number and authors: "- Fix: Description (#123 by @reporter, PR #456 by @contributor)"
+- For PRs without linked issues, include the PR number and author: "- Add support for feature (PR #456 by @contributor)"
+- Provide brief descriptions of each item to explain the change
+- Order the list from most important to least important
+- Example formats:
+    - With issue: "- Fix: Resolve memory leak in extension (#456 by @issueReporter, PR #789 by @prAuthor)"
+    - Without issue: "- Add support for Gemini 2.5 Pro caching (PR #789 by @contributor)"
+- CRITICAL: Include EVERY SINGLE PR in the changeset - don't assume you know which ones are important. Count the total PRs to verify completeness and cross-reference the list to ensure nothing is missed.
+
+6. If the generate_image tool is available, create a release image at `releases/[version]-release.png`
+    - The image should feature a realistic-looking kangaroo doing something human-like that relates to the main highlight of the release
+    - Pass `releases/template.png` as the reference image for aspect ratio and kangaroo style
+    - Add the generated image to .changeset/v[version].md before the list of changes with format: `![X.Y.Z Release - Description](/releases/X.Y.Z-release.png)`
+7. If a major or minor release:
+    - Ask the user what the three most important areas to highlight are in the release
+    - Update the English version relevant announcement files and documentation (webview-ui/src/components/chat/Announcement.tsx, README.md, and the `latestAnnouncementId` in src/core/webview/ClineProvider.ts)
+    - Ask the user to confirm that the English version looks good to them before proceeding
+    - Use the new_task tool to create a subtask in `translate` mode with detailed instructions of which content needs to be translated into all supported languages (The READMEs as well as the translation strings)
+8. Create a new branch for the release preparation: `git checkout -b release/v[version]`
+9. Commit and push the changeset file and any documentation updates to the repository: `git add . && git commit -m "chore: add changeset for v[version]" && git push origin release/v[version]`
+10. Create a pull request for the release: `gh pr create --title "Release v[version]" --body "Release preparation for v[version]. This PR includes the changeset and any necessary documentation updates." --base main --head release/v[version]`
+11. The GitHub Actions workflow will automatically:
+    - Create a version bump PR when changesets are merged to main
+    - Update the CHANGELOG.md with proper formatting
+    - Publish the release when the version bump PR is merged

.roo/commands/roo-resolve-conflicts.md

@@ -0,0 +1,72 @@
+---
+description: "Resolve merge conflicts intelligently using git history analysis"
+argument-hint: "#PR-number"
+mode: merge-resolver
+---
+
+Resolve merge conflicts for a specific pull request by analyzing git history, commit messages, and code changes to make intelligent resolution decisions.
+
+## Quick Start
+
+1. **Provide a PR number** (e.g., `#123` or just `123`)
+
+2. The workflow will automatically:
+   - Fetch PR information (title, description, branches)
+   - Checkout the PR branch
+   - Rebase onto the target branch to reveal conflicts
+   - Analyze and resolve conflicts using git history
+
+## Workflow Steps
+
+### 1. Initialize PR Resolution
+
+```bash
+# Fetch PR info
+gh pr view [PR_NUMBER] --json title,body,headRefName,baseRefName
+
+# Checkout and rebase
+gh pr checkout [PR_NUMBER] --force
+git fetch origin main
+GIT_EDITOR=true git rebase origin/main
+```
+
+### 2. Identify Conflicts
+
+```bash
+git status --porcelain | grep "^UU"
+```
+
+### 3. Analyze Each Conflict
+
+For each conflicted file:
+- Read the conflict markers
+- Run `git blame` on conflicting sections
+- Fetch commit messages for context
+- Determine the intent behind each change
+
+### 4. Apply Resolution Strategy
+
+Based on the analysis:
+- **Bugfixes** generally take precedence over features
+- **Recent changes** are often more relevant (unless older is a security fix)
+- **Combine** non-conflicting changes when possible
+- **Preserve** test updates alongside code changes
+
+### 5. Complete Resolution
+
+```bash
+git add [resolved-files]
+GIT_EDITOR=true git rebase --continue
+```
+
+## Key Guidelines
+
+- Always escape conflict markers with `\` when using `apply_diff`
+- Document resolution decisions in the summary
+- Verify no syntax errors after resolution
+- Preserve valuable changes from both sides when possible
+
+## Examples
+
+- `/roo-resolve-conflicts #123` - Resolve conflicts for PR #123
+- `/roo-resolve-conflicts 456` - Resolve conflicts for PR #456

.roo/commands/roo-translate.md

@@ -0,0 +1,50 @@
+---
+description: "Translate and localize strings in the Roo Code extension"
+argument-hint: "[language-code or 'all'] [string-key or file-path]"
+mode: translate
+---
+
+Perform translation and localization tasks for the Roo Code extension. This command activates the translation workflow with comprehensive i18n guidelines.
+
+## Quick Start
+
+1. **Identify the translation scope:**
+   - If a specific language code is provided (e.g., `de`, `zh-CN`), focus on that language
+   - If `all` is specified, translate to all supported languages
+   - If a string key is provided, locate and translate that specific string
+   - If a file path is provided, work with that translation file
+
+2. **Supported languages:** ca, de, en, es, fr, hi, id, it, ja, ko, nl, pl, pt-BR, ru, tr, vi, zh-CN, zh-TW
+
+3. **Translation locations:**
+   - Core Extension: `src/i18n/locales/`
+   - WebView UI: `webview-ui/src/i18n/locales/`
+
+## Workflow
+
+1. If adding new strings:
+   - Add the English string first
+   - Ask for confirmation before translating to other languages
+   - Use `apply_diff` for efficient file updates
+
+2. If updating existing strings:
+   - Identify all affected language files
+   - Update English first, then propagate changes
+
+3. Validate your changes:
+   ```bash
+   node scripts/find-missing-translations.js
+   ```
+
+## Key Guidelines
+
+- Use informal speech (e.g., "du" not "Sie" in German)
+- Keep technical terms like "token", "Prompt" in English
+- Preserve all `{{variable}}` placeholders exactly
+- Use `apply_diff` instead of `write_to_file` for existing files
+
+## Examples
+
+- `/roo-translate de` - Focus on German translations
+- `/roo-translate all welcome.title` - Translate a specific key to all languages
+- `/roo-translate zh-CN src/i18n/locales/zh-CN/core.json` - Work on specific file

.roo/guidance/roo-translator.md

@@ -0,0 +1,15 @@
+# Roo Code Translation Guidance
+
+This file contains brand voice, tone, and word choice guidelines for Roo Code translations.
+
+## Brand Voice
+
+<!-- Add brand voice guidelines here -->
+
+## Tone
+
+<!-- Add tone guidelines here -->
+
+## Word Choice
+
+<!-- Add word choice preferences here -->

.roo/roomotes.yml

@@ -0,0 +1,6 @@
+version: "1.0"
+
+commands:
+    - name: Install dependencies
+      run: pnpm install
+      timeout: 60

.roo/rules-debug/cli.md

@@ -0,0 +1,67 @@
+# CLI Debugging with File-Based Logging
+
+When debugging the CLI, `console.log` will break the TUI (Terminal User Interface). Use file-based logging to capture debug output without interfering with the application's display.
+
+## File-Based Logging Strategy
+
+1. **Write logs to a temporary file instead of console**:
+
+    - Create a log file at a known location, e.g., `/tmp/roo-cli-debug.log`
+    - Use `fs.appendFileSync()` to write timestamped log entries
+    - Example logging utility:
+
+        ```typescript
+        import fs from "fs"
+        const DEBUG_LOG = "/tmp/roo-cli-debug.log"
+
+        function debugLog(message: string, data?: unknown) {
+        	const timestamp = new Date().toISOString()
+        	const entry = data
+        		? `[${timestamp}] ${message}: ${JSON.stringify(data, null, 2)}\n`
+        		: `[${timestamp}] ${message}\n`
+        	fs.appendFileSync(DEBUG_LOG, entry)
+        }
+        ```
+
+2. **Clear the log file before each debugging session**:
+    - Run `echo "" > /tmp/roo-cli-debug.log` or use `fs.writeFileSync(DEBUG_LOG, "")` at app startup during debugging
+
+## Iterative Debugging Workflow
+
+Follow this feedback loop to systematically narrow down issues:
+
+1. **Add targeted logging** at suspected problem areas based on your hypotheses
+2. **Instruct the user** to reproduce the issue using the CLI normally
+3. **Read the log file** after the user completes testing:
+    - Run `cat /tmp/roo-cli-debug.log` to retrieve the captured output
+4. **Analyze the log output** to gather clues about:
+    - Execution flow and timing
+    - Variable values at key points
+    - Which code paths were taken
+    - Error conditions or unexpected states
+5. **Refine your logging** based on findings—add more detail where needed, remove noise
+6. **Ask the user to test again** with updated logging
+7. **Repeat** until the root cause is identified
+
+## Best Practices
+
+- Log entry/exit points of functions under investigation
+- Include relevant variable values and state information
+- Use descriptive prefixes to categorize logs: `[STATE]`, `[EVENT]`, `[ERROR]`, `[FLOW]`
+- Log both the "happy path" and error handling branches
+- When dealing with async operations, log before and after `await` statements
+- For user interactions, log the received input and the resulting action
+
+## Example Debug Session
+
+```typescript
+// Add logging to investigate a picker selection issue
+debugLog("[FLOW] PickerSelect onSelect called", { selectedIndex, item })
+debugLog("[STATE] Current selection state", { currentValue, isOpen })
+
+// After async operation
+const result = await fetchOptions()
+debugLog("[FLOW] fetchOptions completed", { resultCount: result.length })
+```
+
+Then ask: "Please reproduce the issue by [specific steps]. When you're done, let me know and I'll analyze the debug logs."

.roo/rules-docs-extractor/1_extraction_workflow.xml

@@ -1,236 +1,113 @@
 <extraction_workflow>
-  <mode_overview>
-    The Docs Extractor mode analyzes features to generate documentation.
-    It extracts technical details, business logic, and user workflows
-    for different audiences.
-  </mode_overview>
+  <overview>
+    Extract raw facts from a codebase about a feature or aspect.
+    Output is structured data for documentation teams to use.
+    Do NOT write documentation. Do NOT format prose. Do NOT make structure decisions.
+  </overview>
 
-  <initialization_phase>
+  <process>
     <step number="1">
-      <title>Parse Request</title>
+      <title>Identify Target</title>
       <actions>
-        <action>Identify the feature or component in the user's request.</action>
-        <action>Determine if the request is for a review or to generate new documentation.</action>
-        <action>Default to user-friendly docs unless technical output is requested.</action>
-        <action>Note any specific areas to emphasize.</action>
+        <action>Parse the user's request to identify the feature/aspect</action>
+        <action>Clarify scope if ambiguous (ask one question max)</action>
       </actions>
-      <note>The initial request determines the workflow path (review vs. generation).</note>
     </step>
 
     <step number="2">
-      <title>Discover Feature</title>
+      <title>Discover Code</title>
       <actions>
-        <action>Find related code with semantic search.</action>
-        <action>Identify entry points and components.</action>
-        <action>Map the high-level architecture.</action>
-      </actions>
-      <tool_use><![CDATA[
-<codebase_search>
-<query>[feature name] implementation main entry point</query>
-</codebase_search>
-      ]]></tool_use>
-    </step>
-  </initialization_phase>
-
-  <analysis_phases>
-    <phase name="code_analysis">
-      <title>Code Analysis</title>
-      <steps>
-        <step>
-          <action>Analyze code structure</action>
-          <details>
-            - Identify classes, functions, modules
-            - Extract method signatures, parameters
-            - Document return types, data structures
-            - Map inheritance and composition
-          </details>
-        </step>
-        <step>
-          <action>Extract APIs</action>
-          <details>
-            - REST endpoints
-            - GraphQL schemas
-            - WebSocket events
-            - RPC interfaces
-          </details>
-        </step>
-        <step>
-          <action>Document configuration</action>
-          <details>
-            - Environment variables
-            - Config files and schemas
-            - Feature flags
-            - Runtime parameters
-          </details>
-        </step>
-      </steps>
-    </phase>
-
-    <phase name="business_logic_analysis">
-      <title>Business Logic Extraction</title>
-      <steps>
-        <step>
-          <action>Map workflows</action>
-          <details>
-            - User journey
-            - Decision points and branching
-            - State transitions
-            - Roles and permissions
-          </details>
-        </step>
-        <step>
-          <action>Document business rules</action>
-          <details>
-            - Validation logic
-            - Formulas and algorithms
-            - Business process implementations
-            - Compliance requirements
-          </details>
-        </step>
-        <step>
-          <action>Identify use cases</action>
-          <details>
-            - Primary use cases
-            - Edge cases
-            - Error scenarios
-            - Performance factors
-          </details>
-        </step>
-      </steps>
-    </phase>
-
-    <phase name="integration_analysis">
-      <title>Dependency Analysis</title>
-      <steps>
-        <step>
-          <action>Map dependencies</action>
-          <details>
-            - Third-party libraries
-            - External services and APIs
-            - Database connections
-            - Message queues
-          </details>
-        </step>
-        <step>
-          <action>Document integration points</action>
-          <details>
-            - Incoming webhooks
-            - Outgoing API calls
-            - Event publishers/subscribers
-            - Shared data stores
-          </details>
-        </step>
-        <step>
-          <action>Analyze data flow</action>
-          <details>
-            - Data sources and formats
-            - Data transformations
-            - Output formats and destinations
-            - Data retention policies
-          </details>
-        </step>
-      </steps>
-    </phase>
-
-    <phase name="quality_analysis">
-      <title>Test Analysis</title>
-      <steps>
-        <step>
-          <action>Assess test coverage</action>
-          <details>
-            - Unit test coverage
-            - Integration test scenarios
-            - End-to-end test flows
-            - Performance test results
-          </details>
-        </step>
-        <step>
-          <action>Document error handling</action>
-          <details>
-            - Error types and codes
-            - Exception handling
-            - Fallback mechanisms
-            - Recovery procedures
-          </details>
-        </step>
-        <step>
-          <action>Identify quality metrics</action>
-          <details>
-            - Code complexity
-            - Performance benchmarks
-            - Security vulnerabilities
-            - Maintainability scores
-          </details>
-        </step>
-      </steps>
-    </phase>
-
-    <phase name="security_analysis">
-      <title>Security Analysis</title>
-      <steps>
-        <step>
-          <action>Document security</action>
-          <details>
-            - Auth mechanisms
-            - Access control
-            - Data encryption
-            - Security policies
-          </details>
-        </step>
-        <step>
-          <action>Identify vulnerabilities</action>
-          <details>
-            - Known security issues
-            - Attack vectors
-            - Mitigation
-            - Best practices
-          </details>
-        </step>
-        <step>
-          <action>Check compliance</action>
-          <details>
-            - Regulatory compliance (GDPR, etc.)
-            - Industry standards
-            - Audit trail requirements
-            - Data privacy
-          </details>
-        </step>
-      </steps>
-    </phase>
-  </analysis_phases>
-
-  <documentation_generation>
-    <note>Workflow branches here: review existing docs or generate new docs.</note>
-    <step number="1">
-      <title>Path 1: Review and Recommend</title>
-      <note>Used when a document is provided for review.</note>
-      <actions>
-        <action>Compare provided docs against codebase analysis.</action>
-        <action>Identify inaccuracies, omissions, and areas for improvement.</action>
-        <action>Categorize issues by severity (Critical, Major, Minor).</action>
-        <action>Formulate a structured recommendation in chat.</action>
-        <action>Do not write files.</action>
-        <action>Final output is only the recommendation.</action>
+        <action>Use codebase_search to find relevant files</action>
+        <action>Identify entry points, components, and related code</action>
+        <action>Map the boundaries of the feature</action>
       </actions>
     </step>
-    <step number="2">
-      <title>Path 2: Generate Documentation</title>
-      <note>Used when new documentation is requested.</note>
+
+    <step number="3">
+      <title>Extract Facts</title>
       <actions>
-        <action>Select a template from `2_documentation_patterns.xml`.</action>
-        <action>Structure the document with clear sections and examples.</action>
-        <action>Create `DOCS-TEMP-[feature].md` with generated content.</action>
-        <action>Apply tone and examples from `7_user_friendly_examples.xml`.</action>
+        <action>Read code and extract facts into categories (see fact_categories)</action>
+        <action>Record file paths as sources for each fact</action>
+        <action>Do NOT interpret, summarize, or explain - just extract</action>
       </actions>
     </step>
-  </documentation_generation>
 
-  <completion_criteria>
-    <criterion>Code paths analyzed</criterion>
-    <criterion>Business logic documented</criterion>
-    <criterion>Integration points mapped</criterion>
-    <criterion>Security addressed</criterion>
-    <criterion>Audience needs met</criterion>
-    <criterion>Metadata and links are complete</criterion>
-  </completion_criteria>
+    <step number="4">
+      <title>Output Structured Data</title>
+      <actions>
+        <action>Write extraction to .roo/extraction/EXTRACT-[feature].yaml</action>
+        <action>Use the output schema (see output_format.xml)</action>
+      </actions>
+    </step>
+  </process>
+
+  <fact_categories>
+    <category name="identity">
+      <extracts>
+        <extract>Feature name as it appears in code</extract>
+        <extract>File paths where feature is implemented</extract>
+        <extract>Entry points (commands, UI elements, API endpoints)</extract>
+      </extracts>
+    </category>
+
+    <category name="behavior">
+      <extracts>
+        <extract>What the feature does (from code logic)</extract>
+        <extract>Inputs it accepts</extract>
+        <extract>Outputs it produces</extract>
+        <extract>Side effects (files created, state changed, etc.)</extract>
+      </extracts>
+    </category>
+
+    <category name="configuration">
+      <extracts>
+        <extract>Settings/options that affect behavior</extract>
+        <extract>Default values</extract>
+        <extract>Valid ranges or allowed values</extract>
+        <extract>Where configured (settings file, env var, UI)</extract>
+      </extracts>
+    </category>
+
+    <category name="constraints">
+      <extracts>
+        <extract>Prerequisites and dependencies</extract>
+        <extract>Limitations (what it cannot do)</extract>
+        <extract>Permissions required</extract>
+        <extract>Compatibility requirements</extract>
+      </extracts>
+    </category>
+
+    <category name="errors">
+      <extracts>
+        <extract>Error conditions in code</extract>
+        <extract>Error messages (exact text)</extract>
+        <extract>Recovery paths in code</extract>
+      </extracts>
+    </category>
+
+    <category name="ui">
+      <extracts>
+        <extract>UI components involved</extract>
+        <extract>User-visible labels and text</extract>
+        <extract>Interaction patterns</extract>
+      </extracts>
+    </category>
+
+    <category name="integration">
+      <extracts>
+        <extract>Other features this interacts with</extract>
+        <extract>External APIs or services called</extract>
+        <extract>Events emitted or consumed</extract>
+      </extracts>
+    </category>
+  </fact_categories>
+
+  <rules>
+    <rule>Extract facts, not opinions</rule>
+    <rule>Include source file paths for every fact</rule>
+    <rule>Use code identifiers and exact strings from source</rule>
+    <rule>Do NOT paraphrase - quote when possible</rule>
+    <rule>Do NOT decide what's important - extract everything relevant</rule>
+    <rule>Do NOT format for end users - output is for docs team</rule>
+  </rules>
 </extraction_workflow>

.roo/rules-docs-extractor/2_documentation_patterns.xml

@@ -1,387 +0,0 @@
-<documentation_patterns>
-  <overview>
-    Standard templates for structuring extracted documentation.
-  </overview>
-
-  <output_structure>
-    <user_focused_template><![CDATA[
-# [Feature Name]
-
-[Description of what the feature does and why a user should care.]
-
-### Key Features
-- [Benefit-oriented feature 1]
-- [Benefit-oriented feature 2]
-- [Benefit-oriented feature 3]
-
----
-
-## Use Case
-
-**Before**: [Description of the old way]
-- [Pain point 1]
-- [Pain point 2]
-
-**With this feature]**: [Description of the new experience.]
-
-## How it Works
-
-[Simple explanation of the feature's operation.]
-
-[Suggest visual representations where helpful.]
-
----
-
-## Configuration
-
-[Explanation of relevant settings.]
-
-1. **[Setting Name]**:
-   - **Setting**: `[technical_name]`
-   - **Description**: [What this does.]
-   - **Default**: [Default value and its meaning.]
-
-2. **[Setting Name]**:
-   - **Setting**: `[technical_name]`
-   - **Description**: [What this does.]
-   - **Default**: [Default value and its meaning.]
-
----
-
-## FAQ
-
-**"[User question]"**
-- [Answer.]
-- [Optional tip.]
-
-**"[User question]"**
-- [Answer.]
-- [Optional tip.]
-
-    ]]></user_focused_template>
-
-    <comprehensive_template><![CDATA[
-# [Feature Name] Technical Documentation
-
-## Table of Contents
-1. Overview
-2. Quick Start
-3. Architecture
-4. API Reference
-5. Configuration
-6. User Guide
-7. Developer Guide
-8. Administrator Guide
-9. Security
-10. Performance
-11. Troubleshooting
-12. FAQ
-13. Changelog
-14. References
-
-[This template remains available for generating detailed technical documentation.]
-    ]]></comprehensive_template>
-  </output_structure>
-
-  <documentation_patterns>
-    <before_after>
-      <template><![CDATA[
-**Before**: Multiple, sequential file read requests:
-- "Read `src/app.js`?" → Approve
-- "Read `src/utils.js`?" → Approve
-- "Read `src/config.json`?" → Approve
-
-**Now**: One request to read all related files.
-      ]]></template>
-    </before_after>
-
-    <visual_separator>
-      <format>---</format>
-      <purpose>Separate sections.</purpose>
-    </visual_separator>
-
-    <faq>
-      <template><![CDATA[
-## FAQ
-
-**"Why disable this?"**
-- Your AI model handles single files better.
-- You need more control over file access.
-- You are working with very large files.
-
-**"What if some files are blocked?"**
-- Roo reads approved files and works with what it has.
-- `.rooignore` files are excluded automatically.
-- Individual files can still be denied in the batch dialog.
-      ]]></template>
-    </faq>
-
-    <examples>
-      <guideline>Show tool output or UI elements.</guideline>
-      <guideline>Use actual file paths and setting names.</guideline>
-      <guideline>Include common errors and solutions.</guideline>
-    </examples>
-
-    <troubleshooting>
-      <template><![CDATA[
-## Troubleshooting
-
-**"Too many files requested"**
-- Lower the concurrent file limit in settings.
-- Deny individual files in the batch dialog.
-
-**"Feature isn't working"**
-- Ensure "Enable concurrent file reads" is on in settings.
-- Verify the file limit is set correctly (default: 100).
-- Some AI models may not support this feature.
-      ]]></template>
-    </troubleshooting>
-
-    <help>
-      <template><![CDATA[
-## Help
-
-- See the [FAQ](#faq) for common issues.
-- Report problems on [GitHub Issues](https://github.com/RooCodeInc/Roo-Code/issues).
-- Include reproduction steps and error messages.
-      ]]></template>
-    </help>
-  </documentation_patterns>
-
-  <audience_sections>
-    <audience type="end_user">
-      <focus>
-        <area>Tutorials</area>
-        <area>Use cases</area>
-        <area>Troubleshooting</area>
-        <area>Benefits</area>
-      </focus>
-      <style>
-        <guideline>Simple language</guideline>
-        <guideline>Visual aids</guideline>
-        <guideline>Focus on outcomes</guideline>
-        <guideline>Clear action steps</guideline>
-      </style>
-    </audience>
-
-    <audience type="developer">
-      <focus>
-        <area>Code examples</area>
-        <area>API specs</area>
-        <area>Integration patterns</area>
-        <area>Performance</area>
-      </focus>
-      <style>
-        <guideline>Precise terminology</guideline>
-        <guideline>Code samples</guideline>
-        <guideline>Document edge cases</guideline>
-        <guideline>Debugging guidance</guideline>
-      </style>
-    </audience>
-
-    <audience type="administrator">
-      <focus>
-        <area>Deployment</area>
-        <area>Monitoring</area>
-        <area>Security hardening</area>
-        <area>Backup and recovery</area>
-      </focus>
-      <style>
-        <guideline>Operational focus</guideline>
-        <guideline>CLI examples</guideline>
-        <guideline>Automation opportunities</guideline>
-        <guideline>Security and compliance</guideline>
-      </style>
-    </audience>
-
-    <audience type="stakeholder">
-      <focus>
-        <area>Business value</area>
-        <area>Capabilities and limits</area>
-        <area>Competitive advantages</area>
-        <area>Risk assessment</area>
-      </focus>
-      <style>
-        <guideline>Business language</guideline>
-        <guideline>Metrics and KPIs</guideline>
-        <guideline>Strategic benefits</guideline>
-        <guideline>Executive summaries</guideline>
-      </style>
-    </audience>
-  </audience_sections>
-
-  <metadata_patterns>
-    <version_info>
-      <template><![CDATA[
-### Version Compatibility
-| Component | Min | Recommended | Max | Notes |
-|-----------|-----|-------------|-----|-------|
-| [Component] | [version] | [version] | [version] | [notes] |
-      ]]></template>
-    </version_info>
-
-    <deprecation_notice>
-      <template><![CDATA[
-> ⚠️ **Deprecated**
->
-> Deprecated since: [vX.Y.Z] on [date]
-> Removal target: [vA.B.C]
-> Migration: See [migration guide](#migration).
-> Replacement: [new feature/method].
-      ]]></template>
-    </deprecation_notice>
-
-    <security_warning>
-      <template><![CDATA[
-> 🔒 **Security Warning**
->
-> [Description of concern]
-> - **Risk**: [High/Medium/Low]
-> - **Affected**: [versions]
-> - **Mitigation**: [steps]
-> - **References**: [links]
-      ]]></template>
-    </security_warning>
-
-    <performance_note>
-      <template><![CDATA[
-> ⚡ **Performance Note**
->
-> [Description of performance consideration]
-> - **Impact**: [metrics]
-> - **Optimization**: [approach]
-> - **Trade-offs**: [considerations]
-      ]]></template>
-    </performance_note>
-  </metadata_patterns>
-
-  <code_documentation_patterns>
-    <api_endpoint>
-      <template><![CDATA[
-### `[METHOD] /api/[path]`
-
-**Description**: [What this endpoint does]
-
-**Authentication**: [Required/Optional] - [Type]
-
-**Parameters**:
-| Name | Type | Required | Description | Example |
-|------|------|----------|-------------|---------|
-| [param] | [type] | [Yes/No] | [description] | [example] |
-
-**Request Body**:
-```json
-{
-  "field": "value"
-}
-```
-
-**Response**:
-- **Success (200)**:
-  ```json
-  {
-    "status": "success",
-    "data": {}
-  }
-  ```
-- **Error (4xx/5xx)**:
-  ```json
-  {
-    "error": "error_code",
-    "message": "Human readable message"
-  }
-  ```
-
-**Example**:
-```bash
-curl -X [METHOD] https://api.example.com/[path] \
-  -H "Authorization: Bearer [token]" \
-  -H "Content-Type: application/json" \
-  -d '{"field": "value"}'
-```
-      ]]></template>
-    </api_endpoint>
-
-    <function_documentation>
-      <template><![CDATA[
-### `functionName(parameters)`
-
-**Purpose**: [What this function does]
-
-**Parameters**:
-- `param1` (Type): [Description]
-- `param2` (Type, optional): [Description] - Default: [value]
-
-**Returns**: `Type` - [Description of return value]
-
-**Throws**:
-- `ErrorType`: [When this error occurs]
-
-**Example**:
-```typescript
-const result = functionName(value1, value2);
-// Expected output: [description]
-```
-
-**Notes**:
-- [Important consideration 1]
-- [Important consideration 2]
-      ]]></template>
-    </function_documentation>
-
-    <configuration_option>
-      <template><![CDATA[
-### `CONFIG_NAME`
-
-**Type**: `string | number | boolean`
-
-**Default**: `default_value`
-
-**Environment Variable**: `APP_CONFIG_NAME`
-
-**Description**: [What this configuration controls]
-
-**Valid Values**:
-- `value1`: [Description]
-- `value2`: [Description]
-
-**Example**:
-```yaml
-config:
-  name: value
-```
-
-**Impact**: [What changes when this is modified]
-      ]]></template>
-    </configuration_option>
-  </code_documentation_patterns>
-
-  <cross_reference_patterns>
-    <internal_link>
-      <format>[Link Text](#section-anchor)</format>
-      <example>[See Configuration Guide](#configuration)</example>
-    </internal_link>
-
-    <external_link>
-      <format>[Link Text](https://external.url)</format>
-      <example>[Official Documentation](https://docs.example.com)</example>
-    </external_link>
-
-    <related_feature>
-      <template><![CDATA[
-> 📌 **Related Features**
-> - [Feature A](../feature-a/README.md): [How it relates]
-> - [Feature B](../feature-b/README.md): [How it relates]
-      ]]></template>
-    </related_feature>
-
-    <see_also>
-      <template><![CDATA[
-> 👉 **See Also**
-> - [Related Topic 1](#anchor1)
-> - [Related Topic 2](#anchor2)
-> - [External Resource](https://example.com)
-      ]]></template>
-    </see_also>
-  </cross_reference_patterns>
-</documentation_patterns>

.roo/rules-docs-extractor/2_verification_workflow.xml

@@ -0,0 +1,85 @@
+<verification_workflow>
+  <overview>
+    Compare provided documentation against actual codebase implementation.
+    Output is a structured diff of claims vs reality.
+    Do NOT rewrite the docs. Do NOT suggest wording. Just report discrepancies.
+  </overview>
+
+  <process>
+    <step number="1">
+      <title>Receive Documentation</title>
+      <actions>
+        <action>User provides documentation to verify (text, file, or URL)</action>
+        <action>Identify the feature/aspect being documented</action>
+      </actions>
+    </step>
+
+    <step number="2">
+      <title>Extract Claims</title>
+      <actions>
+        <action>Parse the documentation into discrete claims</action>
+        <action>Tag each claim with a category (behavior, config, constraint, etc.)</action>
+        <action>Record the exact quote from the documentation</action>
+      </actions>
+    </step>
+
+    <step number="3">
+      <title>Verify Against Code</title>
+      <actions>
+        <action>For each claim, find the relevant code</action>
+        <action>Compare claim to actual implementation</action>
+        <action>Record: ACCURATE, INACCURATE, OUTDATED, MISSING_CONTEXT, or UNVERIFIABLE</action>
+        <action>For inaccuracies, record what the code actually does</action>
+      </actions>
+    </step>
+
+    <step number="4">
+      <title>Output Verification Report</title>
+      <actions>
+        <action>Write verification to .roo/extraction/VERIFY-[feature].yaml</action>
+        <action>Use the output schema (see output_format.xml)</action>
+      </actions>
+    </step>
+  </process>
+
+  <verification_statuses>
+    <status name="ACCURATE">
+      <meaning>Claim matches implementation</meaning>
+    </status>
+    <status name="INACCURATE">
+      <meaning>Claim contradicts implementation</meaning>
+      <requires>What the code actually does</requires>
+    </status>
+    <status name="OUTDATED">
+      <meaning>Claim was once true but code has changed</meaning>
+      <requires>Current behavior</requires>
+    </status>
+    <status name="MISSING_CONTEXT">
+      <meaning>Claim is true but omits important information</meaning>
+      <requires>The missing context</requires>
+    </status>
+    <status name="UNVERIFIABLE">
+      <meaning>Cannot find code to verify this claim</meaning>
+      <requires>Search paths attempted</requires>
+    </status>
+  </verification_statuses>
+
+  <claim_categories>
+    <category>behavior</category>
+    <category>configuration</category>
+    <category>constraint</category>
+    <category>error_handling</category>
+    <category>ui</category>
+    <category>integration</category>
+    <category>prerequisite</category>
+  </claim_categories>
+
+  <rules>
+    <rule>Verify facts, not writing quality</rule>
+    <rule>Report what code does, not what docs should say</rule>
+    <rule>Include source file paths as evidence</rule>
+    <rule>Do NOT suggest documentation rewrites</rule>
+    <rule>Do NOT evaluate if docs are "good" - only if they're accurate</rule>
+    <rule>Quote exact code when showing discrepancies</rule>
+  </rules>
+</verification_workflow>

.roo/rules-docs-extractor/3_analysis_techniques.xml

@@ -1,352 +0,0 @@
-<analysis_techniques>
-  <overview>
-    Techniques for analyzing code to extract documentation.
-  </overview>
-
-  <code_analysis_techniques>
-    <technique name="entry_point_analysis">
-      <description>
-        Analyze entry points to understand feature flow.
-      </description>
-      <steps>
-        <step>Find main functions, controllers, or route handlers.</step>
-        <step>Trace execution flow.</step>
-        <step>Map decision branches.</step>
-        <step>Document input validation.</step>
-      </steps>
-      <tools><![CDATA[
-<!-- Find entry points -->
-<codebase_search>
-<query>main function app.listen server.start router controller handler</query>
-</codebase_search>
-
-<!-- Analyze specific entry point -->
-<read_file>
-<path>src/controllers/feature.controller.ts</path>
-</read_file>
-
-<!-- Find all routes -->
-<search_files>
-<path>src</path>
-<regex>(app\.(get|post|put|delete)|@(Get|Post|Put|Delete)|router\.(get|post|put|delete))</regex>
-</search_files>
-      ]]></tools>
-    </technique>
-
-    <technique name="api_extraction">
-      <description>
-        Extract API specifications from code.
-      </description>
-      <patterns>
-        <pattern type="rest">
-          <search_regex><![CDATA[
-(app|router)\.(get|post|put|patch|delete)\s*\(\s*['"`]([^'"`]+)['"`]
-          ]]></search_regex>
-          <extraction>
-            - HTTP method
-            - Route path
-            - Path/query parameters
-            - Request/response schemas
-            - Status codes
-          </extraction>
-        </pattern>
-        <pattern type="graphql">
-          <search_regex><![CDATA[
-type\s+(Query|Mutation|Subscription)\s*{[^}]+}|@(Query|Mutation|Resolver)
-          ]]></search_regex>
-          <extraction>
-            - Schema and input types
-            - Resolvers
-            - Return types
-            - Field arguments
-          </extraction>
-        </pattern>
-      </patterns>
-    </technique>
-
-    <technique name="dependency_mapping">
-      <description>
-        Map dependencies and integration points.
-      </description>
-      <analysis_points>
-        <point>Import/require statements</point>
-        <point>package.json dependencies</point>
-        <point>External API calls</point>
-        <point>DB connections</point>
-        <point>Message queue integrations</point>
-        <point>Filesystem operations</point>
-      </analysis_points>
-      <tools><![CDATA[
-<!-- Find all imports -->
-<search_files>
-<path>src</path>
-<regex>^import\s+.*from\s+['"]([^'"]+)['"]|require\s*\(\s*['"]([^'"]+)['"]\s*\)</regex>
-</search_files>
-
-<!-- Analyze package dependencies -->
-<read_file>
-<path>package.json</path>
-</read_file>
-
-<!-- Find external API calls -->
-<search_files>
-<path>src</path>
-<regex>(fetch|axios|http\.request|request\(|\.get\(|\.post\()</regex>
-</search_files>
-      ]]></tools>
-    </technique>
-
-    <technique name="data_model_extraction">
-      <description>
-        Extract data models, schemas, and type definitions.
-      </description>
-      <sources>
-        <source type="typescript">
-          <patterns>
-            - interfaces, types, classes, enums
-          </patterns>
-        </source>
-        <source type="database">
-          <patterns>
-            - Schema definitions, migration files, ORM models
-          </patterns>
-        </source>
-        <source type="validation">
-          <patterns>
-            - JSON Schema, Joi/Yup/Zod schemas, validation decorators
-          </patterns>
-        </source>
-      </sources>
-      <extraction_example><![CDATA[
-<!-- Find TypeScript interfaces -->
-<search_files>
-<path>src</path>
-<regex>^export\s+(interface|type|class|enum)\s+(\w+)</regex>
-</search_files>
-
-<!-- Find database models -->
-<search_files>
-<path>src/models</path>
-<regex>@(Entity|Table|Model)|class\s+\w+\s+extends\s+(Model|BaseEntity)</regex>
-</search_files>
-      ]]></extraction_example>
-    </technique>
-
-    <technique name="business_logic_extraction">
-      <description>
-        Identify and document business rules.
-      </description>
-      <indicators>
-        <indicator>Complex conditionals</indicator>
-        <indicator>Calculation functions</indicator>
-        <indicator>Validation rules</indicator>
-        <indicator>State machines</indicator>
-        <indicator>Domain-specific constants and algorithms</indicator>
-      </indicators>
-      <documentation_focus>
-        <focus>Why logic exists (business need)</focus>
-        <focus>When logic applies (conditions)</focus>
-        <focus>What logic does (transformation)</focus>
-        <focus>Edge cases</focus>
-        <focus>Impact of changes</focus>
-      </documentation_focus>
-    </technique>
-
-    <technique name="error_handling_analysis">
-      <description>
-        Document error handling and recovery.
-      </description>
-      <analysis_areas>
-        <area>try/catch blocks, error boundaries</area>
-        <area>Custom error classes</area>
-        <area>Error codes and messages</area>
-        <area>Logging, fallbacks, retries, circuit breakers</area>
-      </analysis_areas>
-      <search_patterns><![CDATA[
-<!-- Find error handling -->
-<search_files>
-<path>src</path>
-<regex>try\s*{|catch\s*\(|throw\s+new|class\s+\w*Error\s+extends</regex>
-</search_files>
-
-<!-- Find error constants -->
-<search_files>
-<path>src</path>
-<regex>ERROR_|_ERROR|ErrorCode|errorCode</regex>
-</search_files>
-      ]]></search_patterns>
-    </technique>
-
-    <technique name="security_analysis">
-      <description>
-        Identify security measures and vulnerabilities.
-      </description>
-      <security_checks>
-        <check category="authentication">
-          <patterns>
-            - JWT, sessions, OAuth, API keys
-          </patterns>
-        </check>
-        <check category="authorization">
-          <patterns>
-            - RBAC, permission checks, ownership validation
-          </patterns>
-        </check>
-        <check category="data_protection">
-          <patterns>
-            - Encryption, hashing, sensitive data handling
-          </patterns>
-        </check>
-        <check category="input_validation">
-          <patterns>
-            - Sanitization, SQLi/XSS/CSRF prevention
-          </parents>
-        </check>
-      </security_checks>
-    </technique>
-
-    <technique name="performance_analysis">
-      <description>
-        Identify performance factors and optimization opportunities.
-      </description>
-      <analysis_points>
-        <point>DB query patterns (N+1)</point>
-        <point>Caching strategies</point>
-        <point>Async usage</point>
-        <point>Batch processing</point>
-        <point>Resource pooling</point>
-        <point>Memory management</point>
-        <point>Algorithm complexity</point>
-      </analysis_points>
-      <metrics_to_document>
-        <metric>Time/space complexity</metric>
-        <metric>DB query counts</metric>
-        <metric>API response times</metric>
-        <metric>Memory usage</metric>
-        <metric>Concurrency handling</metric>
-      </metrics_to_document>
-    </technique>
-
-    <technique name="test_coverage_analysis">
-      <description>
-        Analyze test coverage.
-      </description>
-      <test_types>
-        <type name="unit">
-          <location>__tests__, *.test.ts, *.spec.ts</location>
-          <analysis>Function coverage</analysis>
-        </type>
-        <type name="integration">
-          <location>integration/, e2e/</location>
-          <analysis>Workflow coverage</analysis>
-        </type>
-        <type name="api">
-          <location>api-tests/, *.api.test.ts</location>
-          <analysis>Endpoint coverage</analysis>
-        </type>
-      </test_types>
-      <coverage_analysis><![CDATA[
-<!-- Find test files -->
-<search_files>
-<path>src</path>
-<regex>\.(test|spec)\.(ts|js|tsx|jsx)$</regex>
-<file_pattern>*.test.ts</file_pattern>
-</search_files>
-
-<!-- Analyze test descriptions -->
-<search_files>
-<path>src</path>
-<regex>(describe|it|test)\s*\(\s*['"`]([^'"`]+)['"`]</regex>
-</search_files>
-      ]]></coverage_analysis>
-    </technique>
-
-    <technique name="configuration_extraction">
-      <description>
-        Extract configuration options and their impacts.
-      </description>
-      <configuration_sources>
-        <source>.env files, config files, CLI args, feature flags</source>
-      </configuration_sources>
-      <documentation_requirements>
-        <requirement>Default values</requirement>
-        <requirement>Valid values</requirement>
-        <requirement>Behavior impact</requirement>
-        <requirement>Config dependencies</requirement>
-        <requirement>Security implications</requirement>
-      </documentation_requirements>
-    </technique>
-  </code_analysis_techniques>
-
-  <workflow_analysis>
-    <technique name="user_journey_mapping">
-      <description>
-        Map user workflows through the feature.
-      </description>
-      <steps>
-        <step>Identify entry points (UI, API, CLI).</step>
-        <step>Trace user actions.</step>
-        <step>Document decision points.</step>
-        <step>Map data transformations.</step>
-        <step>Identify outcomes.</step>
-      </steps>
-      <deliverables>
-        <deliverable>Flow diagrams, procedures, decision trees, state diagrams.</deliverable>
-      </deliverables>
-    </technique>
-
-    <technique name="integration_flow_analysis">
-      <description>
-        Document integration with other systems.
-      </description>
-      <integration_types>
-        <type>Sync API calls, async messaging, events, batch processing, streaming.</type>
-      </integration_types>
-      <documentation_focus>
-        <focus>Protocols, auth, error handling, data transforms, SLAs.</focus>
-      </documentation_focus>
-    </technique>
-  </workflow_analysis>
-
-  <metadata_extraction>
-    <technique name="version_compatibility">
-      <sources>
-        <source>package.json, READMEs, migration guides, breaking changes docs.</source>
-      </sources>
-      <extraction_pattern><![CDATA[
-<!-- Find version requirements -->
-<search_files>
-<path>.</path>
-<regex>"engines":|"peerDependencies":|requires?\s+\w+\s+version|compatible\s+with</regex>
-</search_files>
-      ]]></extraction_pattern>
-    </technique>
-
-    <technique name="deprecation_tracking">
-      <indicators>
-        <indicator>@deprecated, TODO comments, legacy code markers.</indicator>
-      </indicators>
-      <documentation_requirements>
-        <requirement>Deprecation date, removal timeline, migration path, alternatives.</requirement>
-      </documentation_requirements>
-    </technique>
-  </metadata_extraction>
-
-  <quality_indicators>
-    <indicator name="documentation_completeness">
-      <checks>
-        <check>Public APIs documented.</check>
-        <check>Examples for complex features.</check>
-        <check>Error scenarios covered.</check>
-        <check>Config options explained.</check>
-        <check>Security addressed.</check>
-      </checks>
-    </indicator>
-
-    <indicator name="code_quality_metrics">
-      <metrics>
-        <metric>Cyclomatic complexity, code duplication, test coverage, doc coverage, tech debt.</metric>
-      </metrics>
-    </indicator>
-  </quality_indicators>
-</analysis_techniques>

.roo/rules-docs-extractor/3_output_format.xml

@@ -0,0 +1,133 @@
+<output_format>
+  <overview>
+    Structured data output formats for extraction and verification.
+    All output is YAML. No prose. No markdown formatting.
+    This data feeds into documentation-writer mode.
+  </overview>
+
+  <extraction_schema>
+    <description>Schema for EXTRACT-[feature].yaml files</description>
+    <template>
+feature:
+  name: [feature name from code]
+  slug: [lowercase-hyphenated identifier]
+  extracted_at: [ISO timestamp]
+  source_files:
+    - [list of primary files]
+
+identity:
+  entry_points:
+    - type: [command|ui|api|event]
+      name: [identifier]
+      location: [file:line]
+  components:
+    - name: [component name]
+      file: [path]
+      purpose: [one line from code comments or inferred]
+
+behavior:
+  primary_action: [what it does - from code]
+  inputs:
+    - name: [input name]
+      type: [data type]
+      required: [true|false]
+      source: [file:line]
+  outputs:
+    - name: [output name]
+      type: [data type]
+      source: [file:line]
+  side_effects:
+    - description: [what changes]
+      source: [file:line]
+
+configuration:
+  - name: [setting name]
+    key: [config key path]
+    type: [data type]
+    default: [default value]
+    valid_values: [list or range]
+    effect: [what it changes]
+    source: [file:line]
+
+constraints:
+  prerequisites:
+    - description: [requirement]
+      source: [file:line]
+  limitations:
+    - description: [what cannot be done]
+      source: [file:line]
+  permissions:
+    - description: [permission needed]
+      source: [file:line]
+
+errors:
+  - condition: [when this error occurs]
+    message: "[exact error message text]"
+    code: [error code if any]
+    source: [file:line]
+
+ui:
+  components:
+    - name: [component name]
+      type: [button|panel|input|etc]
+      label: "[visible text]"
+      source: [file:line]
+  interactions:
+    - trigger: [user action]
+      result: [what happens]
+      source: [file:line]
+
+integration:
+  internal:
+    - feature: [other feature name]
+      relationship: [how they interact]
+      source: [file:line]
+  external:
+    - service: [external service]
+      api: [endpoint or method]
+      source: [file:line]
+    </template>
+  </extraction_schema>
+
+  <verification_schema>
+    <description>Schema for VERIFY-[feature].yaml files</description>
+    <template>
+verification:
+  feature: [feature name]
+  doc_source: [where the docs came from]
+  verified_at: [ISO timestamp]
+  summary:
+    total_claims: [count]
+    accurate: [count]
+    inaccurate: [count]
+    outdated: [count]
+    missing_context: [count]
+    unverifiable: [count]
+
+claims:
+  - id: [claim-1]
+    quote: "[exact text from documentation]"
+    category: [behavior|configuration|constraint|error_handling|ui|integration|prerequisite]
+    status: [ACCURATE|INACCURATE|OUTDATED|MISSING_CONTEXT|UNVERIFIABLE]
+    evidence:
+      code_file: [file:line]
+      actual_behavior: [what code does - only if status is not ACCURATE]
+      code_quote: "[relevant code snippet]"
+    </template>
+  </verification_schema>
+
+  <output_rules>
+    <rule>Use YAML, not JSON or markdown</rule>
+    <rule>Include source file:line for every fact</rule>
+    <rule>Quote exact strings from code using double quotes</rule>
+    <rule>Use null for unknown/missing values, not empty strings</rule>
+    <rule>Keep descriptions factual and brief - one line max</rule>
+    <rule>Do NOT add commentary, suggestions, or explanations</rule>
+  </output_rules>
+
+  <file_naming>
+    <extraction>EXTRACT-[feature-slug].yaml</extraction>
+    <verification>VERIFY-[feature-slug].yaml</verification>
+    <location>.roo/extraction/</location>
+  </file_naming>
+</output_format>

.roo/rules-docs-extractor/4_tool_usage_guide.xml

@@ -1,380 +0,0 @@
-<tool_usage_guide>
-  <overview>
-    Guidance on using tools for documentation extraction.
-  </overview>
-
-  <tool_sequence>
-    <priority level="1">
-      <tool>codebase_search</tool>
-      <purpose>Initial code discovery.</purpose>
-      <usage_patterns>
-        <pattern>
-          <scenario>Find feature entry points</scenario>
-          <example><![CDATA[
-<codebase_search>
-<query>authentication login user session JWT token</query>
-</codebase_search>
-          ]]></example>
-        </pattern>
-        <pattern>
-          <scenario>Find business logic</scenario>
-          <example><![CDATA[
-<codebase_search>
-<query>calculate pricing discount tax invoice billing</query>
-</codebase_search>
-          ]]></example>
-        </pattern>
-        <pattern>
-          <scenario>Find configuration</scenario>
-          <example><![CDATA[
-<codebase_search>
-<query>config settings environment variables .env process.env</query>
-</codebase_search>
-          ]]></example>
-        </pattern>
-      </usage_patterns>
-    </priority>
-
-    <priority level="2">
-      <tool>list_code_definition_names</tool>
-      <purpose>Understand code structure.</purpose>
-      <best_practices>
-        <practice>Use on core feature directories.</practice>
-        <practice>Analyze implementation and test directories.</practice>
-        <practice>Look for naming patterns.</practice>
-      </best_practices>
-      <example><![CDATA[
-<list_code_definition_names>
-<path>src/features/authentication</path>
-</list_code_definition_names>
-      ]]></example>
-    </priority>
-
-    <priority level="3">
-      <tool>read_file</tool>
-      <purpose>Analyze specific implementations.</purpose>
-      <strategy>
-        <step>Read main feature files.</step>
-        <step>Follow imports to find dependencies.</step>
-        <step>Read test files for expected behavior.</step>
-        <step>Examine config and type definition files.</step>
-      </strategy>
-      <batch_reading><![CDATA[
-<read_file>
-<args>
-  <file>
-    <path>src/controllers/auth.controller.ts</path>
-  </file>
-  <file>
-    <path>src/services/auth.service.ts</path>
-  </file>
-  <file>
-    <path>src/models/user.model.ts</path>
-  </file>
-  <file>
-    <path>src/types/auth.types.ts</path>
-  </file>
-  <file>
-    <path>src/__tests__/auth.test.ts</path>
-  </file>
-</args>
-</read_file>
-      ]]></batch_reading>
-    </priority>
-
-    <priority level="4">
-      <tool>search_files</tool>
-      <purpose>Find specific patterns.</purpose>
-      <use_cases>
-        <use_case>
-          <description>Find API endpoints</description>
-          <example><![CDATA[
-<search_files>
-<path>src</path>
-<regex>@(Get|Post|Put|Delete|Patch)\(['"]([^'"]+)['"]|router\.(get|post|put|delete|patch)\(['"]([^'"]+)['"]</regex>
-</search_files>
-          ]]></example>
-        </use_case>
-        <use_case>
-          <description>Find error handling</description>
-          <example><![CDATA[
-<search_files>
-<path>src</path>
-<regex>throw new \w+Error|catch \(|\.catch\(|try \{</regex>
-</search_files>
-          ]]></example>
-        </use_case>
-        <use_case>
-          <description>Find config usage</description>
-          <example><![CDATA[
-<search_files>
-<path>src</path>
-<regex>process\.env\.\w+|config\.get\(['"]([^'"]+)['"]|getConfig\(\)</regex>
-</search_files>
-          ]]></example>
-        </use_case>
-      </use_cases>
-    </priority>
-  </tool_sequence>
-
-  <documentation_generation_tools>
-    <tool name="write_to_file">
-      <purpose>Create documentation file for new docs.</purpose>
-      <note>Not used for reviews. Feedback for reviews is provided in chat.</note>
-      <file_naming>DOCS-TEMP-[feature-name].md</file_naming>
-      <best_practices>
-        <practice>Use descriptive feature name in filename.</practice>
-        <practice>Include table of contents.</practice>
-        <practice>Use consistent Markdown formatting.</practice>
-        <practice>Include syntax-highlighted code examples.</practice>
-      </best_practices>
-      <example><![CDATA[
-<write_to_file>
-<path>DOCS-TEMP-authentication-system.md</path>
-<content>
-# Authentication System Documentation
-
-## Table of Contents
-1. [Overview](#overview)
-2. [Architecture](#architecture)
-...
-
-## Overview
-The authentication system provides secure user authentication using JWT tokens...
-</content>
-<line_count>...</line_count>
-</write_to_file>
-      ]]></example>
-    </tool>
-    
-    <tool name="ask_followup_question">
-      <purpose>Clarify ambiguous requirements.</purpose>
-      <when_to_use>
-        <scenario>Multiple features have similar names.</scenario>
-        <scenario>Documentation depth is unclear.</scenario>
-        <scenario>Audience priorities are undefined.</scenario>
-      </when_to_use>
-      <examples>
-        <example><![CDATA[
-<ask_followup_question>
-<question>Which authentication aspects should be the focus?</question>
-<follow_up>
-<suggest>The complete flow (JWT, sessions, OAuth).</suggest>
-<suggest>Only JWT implementation and validation.</suggest>
-<suggest>Only OAuth2 integration.</suggest>
-<suggest>Password reset and recovery workflows.</suggest>
-</follow_up>
-</ask_followup_question>
-        ]]></example>
-        <example><![CDATA[
-<ask_followup_question>
-<question>What level of technical detail is needed?</question>
-<follow_up>
-<suggest>High-level overview for all audiences.</suggest>
-<suggest>Detailed developer implementation.</suggest>
-<suggest>API reference with code examples.</suggest>
-<suggest>Full coverage for all audiences.</suggest>
-</follow_up>
-</ask_followup_question>
-        ]]></example>
-      </examples>
-    </tool>
-  </documentation_generation_tools>
-
-  <analysis_strategies>
-    <strategy name="file_discovery">
-      <description>
-        Find all files related to a feature.
-      </description>
-      <steps>
-        <step>
-          <action>Start with semantic search.</action>
-          <tool_use><![CDATA[
-<codebase_search>
-<query>feature implementation main logic</query>
-</codebase_search>
-          ]]></tool_use>
-        </step>
-        <step>
-          <action>List directory structure.</action>
-          <tool_use><![CDATA[
-<list_files>
-<path>src/features</path>
-<recursive>true</recursive>
-</list_files>
-          ]]></tool_use>
-        </step>
-        <step>
-          <action>Find related tests.</action>
-          <tool_use><![CDATA[
-<search_files>
-<path>src</path>
-<regex>describe\(['"].*Feature.*['"]|test\(['"].*feature.*['"]</regex>
-<file_pattern>*.test.ts</file_pattern>
-</search_files>
-          ]]></tool_use>
-        </step>
-        <step>
-          <action>Find config files.</action>
-          <tool_use><![CDATA[
-<search_files>
-<path>.</path>
-<regex>feature.*config|settings.*feature</regex>
-<file_pattern>*.json</file_pattern>
-</search_files>
-          ]]></tool_use>
-        </step>
-      </steps>
-    </strategy>
-
-    <strategy name="dependency_chain_analysis">
-      <description>
-        Follow import chains to map dependencies.
-      </description>
-      <process>
-        <step>Read main file.</step>
-        <step>Extract all imports.</step>
-        <step>Read each imported file.</step>
-        <step>Recursively analyze imports.</step>
-        <step>Build dependency graph.</step>
-      </process>
-      <import_patterns><![CDATA[
-<!-- TypeScript/JavaScript imports -->
-<search_files>
-<path>src/feature</path>
-<regex>import\s+(?:{[^}]+}|\*\s+as\s+\w+|\w+)\s+from\s+['"]([^'"]+)['"]</regex>
-</search_files>
-
-<!-- CommonJS requires -->
-<search_files>
-<path>src/feature</path>
-<regex>require\(['"]([^'"]+)['"]\)</regex>
-</search_files>
-      ]]></import_patterns>
-    </strategy>
-
-    <strategy name="api_documentation_extraction">
-      <description>
-        Extract API documentation from code.
-      </description>
-      <extraction_points>
-        <point>Route definitions, request/response schemas, auth requirements, rate limiting, error responses.</point>
-      </extraction_points>
-      <tools_sequence>
-        <sequence>
-          <step>Find route files.</step>
-          <step>Extract route definitions.</step>
-          <step>Find controllers.</step>
-          <step>Analyze request validation.</step>
-          <step>Document response formats.</step>
-        </sequence>
-      </tools_sequence>
-    </strategy>
-
-    <strategy name="test_driven_documentation">
-      <description>
-        Use tests to document expected behavior.
-      </description>
-      <benefits>
-        <benefit>Tests provide usage examples.</benefit>
-        <benefit>Test descriptions explain functionality.</benefit>
-        <benefit>Tests cover edge cases.</benefit>
-        <benefit>Tests document expected outputs.</benefit>
-      </benefits>
-      <extraction_approach><![CDATA[
-<!-- Find test descriptions -->
-<search_files>
-<path>__tests__</path>
-<regex>(describe|it|test)\(['"]([^'"]+)['"]</regex>
-</search_files>
-
-<!-- Extract test scenarios -->
-<read_file>
-<path>__tests__/feature.test.ts</path>
-</read_file>
-      ]]></extraction_approach>
-    </strategy>
-  </analysis_strategies>
-
-  <common_patterns>
-    <pattern name="configuration_documentation">
-      <search_locations>
-        <location>.env.example</location>
-        <location>config/*.json</location>
-        <location>src/config/*</location>
-        <location>README.md (configuration section)</location>
-      </search_locations>
-      <extraction_regex><![CDATA[
-# Environment variables
-process\.env\.(\w+)
-
-# Config object access
-config\.(\w+)\.(\w+)
-
-# Default values
-\w+\s*=\s*process\.env\.\w+\s*\|\|\s*['"]([^'"]+)['"]
-      ]]></extraction_regex>
-    </pattern>
-
-    <pattern name="error_documentation">
-      <error_patterns>
-        <pattern>Custom error classes</pattern>
-        <pattern>Error code constants</pattern>
-        <pattern>Error message templates</pattern>
-        <pattern>HTTP status codes</pattern>
-      </error_patterns>
-      <search_approach><![CDATA[
-<search_files>
-<path>src</path>
-<regex>class\s+\w*Error\s+extends|new Error\(|throw new|ERROR_CODE|HTTP_STATUS</regex>
-</search_files>
-      ]]></search_approach>
-    </pattern>
-
-    <pattern name="security_documentation">
-      <security_aspects>
-        <aspect>Authentication methods</aspect>
-        <aspect>Authorization rules</aspect>
-        <aspect>Data encryption</aspect>
-        <aspect>Input validation</aspect>
-        <aspect>Rate limiting</aspect>
-      </security_aspects>
-      <indicators><![CDATA[
-<search_files>
-<path>src</path>
-<regex>@Authorized|requireAuth|checkPermission|encrypt|decrypt|sanitize|validate|rateLimit</regex>
-</search_files>
-      ]]></indicators>
-    </pattern>
-  </common_patterns>
-
-  <output_optimization>
-    <guideline name="structure">
-      <description>Organize output for navigation.</description>
-      <structure>
-        - Clear hierarchy, consistent headings, ToC with links, cross-references.
-      </structure>
-    </guideline>
-
-    <guideline name="code_examples">
-      <description>Include relevant code examples.</description>
-      <best_practices>
-        - Use syntax highlighting, show request/response, include error cases.
-      </best_practices>
-    </guideline>
-
-    <guideline name="visuals">
-      <description>Suggest diagrams where helpful.</description>
-      <diagram_types>
-        - Architecture, sequence, data flow, state machine diagrams.
-      </diagram_types>
-    </guideline>
-
-    <guideline name="metadata">
-      <description>Include important metadata.</description>
-      <required_metadata>
-        - Version compatibility, last updated, status, performance, security.
-      </required_metadata>
-    </guideline>
-  </output_optimization>
-</tool_usage_guide>

.roo/rules-docs-extractor/5_complete_extraction_examples.xml

@@ -1,932 +0,0 @@
-<complete_extraction_examples>
-  <overview>
-    Examples of the documentation extraction workflow.
-  </overview>
-
-  <example name="authentication_system_extraction">
-    <scenario>
-      Extract documentation for a JWT-based authentication system, including login, token refresh, and RBAC.
-    </scenario>
-
-    <workflow>
-      <step number="1">
-        <description>Discover feature</description>
-        <tool_use><![CDATA[
-<codebase_search>
-<query>authentication JWT login logout token refresh auth middleware</query>
-</codebase_search>
-        ]]></tool_use>
-        <expected_findings>
-          - Auth controllers, services, middleware, models, and routes.
-        </expected_findings>
-      </step>
-
-      <step number="2">
-        <description>Analyze structure</description>
-        <tool_use><![CDATA[
-<list_code_definition_names>
-<path>src/auth</path>
-</list_code_definition_names>
-        ]]></tool_use>
-        <analysis>
-          - Identify main classes/functions.
-          - Map auth flow.
-          - Find token generation/validation logic.
-        </analysis>
-      </step>
-
-      <step number="3">
-        <description>Read core files</description>
-        <tool_use><![CDATA[
-<read_file>
-<args>
-  <file>
-    <path>src/auth/auth.controller.ts</path>
-  </file>
-  <file>
-    <path>src/auth/auth.service.ts</path>
-  </file>
-  <file>
-    <path>src/auth/jwt.strategy.ts</path>
-  </file>
-  <file>
-    <path>src/auth/auth.guard.ts</path>
-  </file>
-  <file>
-    <path>src/models/user.model.ts</path>
-  </file>
-</args>
-</read_file>
-        ]]></tool_use>
-      </step>
-
-      <step number="4">
-        <description>Extract API endpoints</description>
-        <tool_use><![CDATA[
-<search_files>
-<path>src/auth</path>
-<regex>@(Post|Get)\(['"]\/auth\/[^'"]+['"]|router\.(post|get)\(['"]\/auth\/[^'"]+['"]</regex>
-</search_files>
-        ]]></tool_use>
-        <findings>
-          - POST /auth/login, POST /auth/logout, POST /auth/refresh, GET /auth/profile, POST /auth/register
-        </findings>
-      </step>
-
-      <step number="5">
-        <description>Extract configuration</description>
-        <tool_use><![CDATA[
-<search_files>
-<path>src</path>
-<regex>JWT_SECRET|JWT_EXPIRATION|AUTH_.*|process\.env\.\w*AUTH\w*</regex>
-</search_files>
-        ]]></tool_use>
-      </step>
-
-      <step number="6">
-        <description>Analyze security</description>
-        <tool_use><![CDATA[
-<search_files>
-<path>src/auth</path>
-<regex>bcrypt|hash|salt|encrypt|sanitize|validate|@IsEmail|@MinLength</regex>
-</search_files>
-        ]]></tool_use>
-      </step>
-
-      <step number="7">
-        <description>Generate docs</description>
-        <tool_use><![CDATA[
-<write_to_file>
-<path>DOCS-TEMP-authentication-system.md</path>
-<content>
-# Authentication System Documentation
-
-## Table of Contents
-1. [Overview](#overview)
-2. [Quick Start](#quick-start)
-3. [Architecture](#architecture)
-4. [API Reference](#api-reference)
-5. [Configuration](#configuration)
-6. [Security](#security)
-7. [User Guide](#user-guide)
-8. [Developer Guide](#developer-guide)
-9. [Troubleshooting](#troubleshooting)
-
----
-
-## Overview
-
-### Purpose
-The authentication system provides secure user authentication using JWT (JSON Web Tokens) with support for:
-- User registration and login
-- Token-based authentication
-- Refresh token rotation
-- Role-based access control (RBAC)
-- Session management
-- Password reset functionality
-
-### Key Features
-- **JWT Authentication**: Stateless authentication using signed tokens
-- **Refresh Tokens**: Long-lived tokens for seamless user experience
-- **Role-Based Access**: Fine-grained permission control
-- **Security**: bcrypt password hashing, rate limiting, CSRF protection
-- **Multi-device Support**: Token management across devices
-
-### Version Information
-- **Current Version**: 2.1.0
-- **Minimum Node.js**: 14.0.0
-- **Dependencies**: 
-  - jsonwebtoken: ^9.0.0
-  - bcrypt: ^5.1.0
-  - passport: ^0.6.0
-
----
-
-## Quick Start
-
-### For Users
-1. Register a new account:
-   ```bash
-   POST /api/auth/register
-   {
-     "email": "user@example.com",
-     "password": "SecurePassword123!",
-     "name": "John Doe"
-   }
-   ```
-
-2. Login to receive tokens:
-   ```bash
-   POST /api/auth/login
-   {
-     "email": "user@example.com",
-     "password": "SecurePassword123!"
-   }
-   ```
-
-3. Use the access token in subsequent requests:
-   ```bash
-   Authorization: Bearer <access_token>
-   ```
-
-### For Developers
-```typescript
-// Import authentication module
-import { AuthModule } from './auth/auth.module';
-
-// Configure in app module
-@Module({
-  imports: [
-    AuthModule.forRoot({
-      jwtSecret: process.env.JWT_SECRET,
-      jwtExpiration: '15m',
-      refreshExpiration: '7d'
-    })
-  ]
-})
-export class AppModule {}
-```
-
----
-
-## Architecture
-
-### System Overview
-```
-┌─────────────┐     ┌──────────────┐     ┌─────────────┐
-│   Client    │────▶│ Auth Guard   │────▶│   Service   │
-└─────────────┘     └──────────────┘     └─────────────┘
-                            │                     │
-                            ▼                     ▼
-                    ┌──────────────┐     ┌─────────────┐
-                    │ JWT Strategy │     │  Database   │
-                    └──────────────┘     └─────────────┘
-```
-
-### Components
-- **AuthController**: Handles HTTP requests for authentication endpoints
-- **AuthService**: Core authentication logic and token management
-- **JwtStrategy**: Passport strategy for JWT validation
-- **AuthGuard**: Route protection middleware
-- **UserService**: User management and database operations
-
-### Token Flow
-1. User provides credentials
-2. System validates credentials against database
-3. Generate access token (short-lived) and refresh token (long-lived)
-4. Client stores tokens securely
-5. Access token used for API requests
-6. Refresh token used to obtain new access token
-
----
-
-## API Reference
-
-### Authentication Endpoints
-
-#### `POST /api/auth/register`
-Register a new user account.
-
-**Request Body**:
-```json
-{
-  "email": "string (required)",
-  "password": "string (required, min 8 chars)",
-  "name": "string (required)",
-  "role": "string (optional, default: 'user')"
-}
-```
-
-**Response** (201 Created):
-```json
-{
-  "user": {
-    "id": "uuid",
-    "email": "user@example.com",
-    "name": "John Doe",
-    "role": "user",
-    "createdAt": "2024-01-01T00:00:00Z"
-  },
-  "tokens": {
-    "accessToken": "jwt_token",
-    "refreshToken": "refresh_token",
-    "expiresIn": 900
-  }
-}
-```
-
-**Error Responses**:
-- `400 Bad Request`: Invalid input data
-- `409 Conflict`: Email already exists
-
-#### `POST /api/auth/login`
-Authenticate user and receive tokens.
-
-**Request Body**:
-```json
-{
-  "email": "string (required)",
-  "password": "string (required)"
-}
-```
-
-**Response** (200 OK):
-```json
-{
-  "user": {
-    "id": "uuid",
-    "email": "user@example.com",
-    "name": "John Doe",
-    "role": "user"
-  },
-  "tokens": {
-    "accessToken": "jwt_token",
-    "refreshToken": "refresh_token",
-    "expiresIn": 900
-  }
-}
-```
-
-**Error Responses**:
-- `401 Unauthorized`: Invalid credentials
-- `429 Too Many Requests`: Rate limit exceeded
-
-#### `POST /api/auth/refresh`
-Refresh access token using refresh token.
-
-**Request Body**:
-```json
-{
-  "refreshToken": "string (required)"
-}
-```
-
-**Response** (200 OK):
-```json
-{
-  "accessToken": "new_jwt_token",
-  "expiresIn": 900
-}
-```
-
-#### `POST /api/auth/logout`
-Invalidate refresh token.
-
-**Headers**:
-- `Authorization: Bearer <access_token>`
-
-**Request Body**:
-```json
-{
-  "refreshToken": "string (required)"
-}
-```
-
-**Response** (200 OK):
-```json
-{
-  "message": "Logged out successfully"
-}
-```
-
----
-
-## Configuration
-
-### Environment Variables
-
-| Variable | Type | Default | Description |
-|----------|------|---------|-------------|
-| `JWT_SECRET` | string | - | Secret key for signing JWT tokens (required) |
-| `JWT_EXPIRATION` | string | '15m' | Access token expiration time |
-| `REFRESH_TOKEN_EXPIRATION` | string | '7d' | Refresh token expiration time |
-| `BCRYPT_ROUNDS` | number | 10 | Number of bcrypt hashing rounds |
-| `AUTH_RATE_LIMIT` | number | 5 | Max login attempts per minute |
-| `ENABLE_2FA` | boolean | false | Enable two-factor authentication |
-
-### Configuration File (auth.config.ts)
-```typescript
-export const authConfig = {
-  jwt: {
-    secret: process.env.JWT_SECRET,
-    signOptions: {
-      expiresIn: process.env.JWT_EXPIRATION || '15m',
-      issuer: 'your-app-name',
-      audience: 'your-app-users'
-    }
-  },
-  bcrypt: {
-    rounds: parseInt(process.env.BCRYPT_ROUNDS || '10')
-  },
-  session: {
-    maxDevices: 5,
-    inactivityTimeout: '30d'
-  }
-};
-```
-
----
-
-## Security
-
-### Authentication Flow
-1. **Password Storage**: Passwords hashed using bcrypt with configurable rounds
-2. **Token Security**: JWT tokens signed with RS256 algorithm
-3. **Refresh Token Rotation**: New refresh token issued on each refresh
-4. **Rate Limiting**: Prevents brute force attacks on login endpoint
-
-### Security Best Practices
-- Store tokens securely (httpOnly cookies recommended)
-- Implement CSRF protection for cookie-based auth
-- Use HTTPS in production
-- Rotate JWT secrets periodically
-- Implement account lockout after failed attempts
-- Enable 2FA for sensitive accounts
-
-### Common Vulnerabilities Addressed
-- **SQL Injection**: Parameterized queries
-- **XSS**: Input sanitization and validation
-- **CSRF**: Token validation
-- **Brute Force**: Rate limiting and account lockout
-- **Token Hijacking**: Short expiration times and refresh rotation
-
----
-
-## User Guide
-
-### Registration Process
-1. Navigate to registration page
-2. Enter email, password, and name
-3. Verify email (if enabled)
-4. Login with credentials
-
-### Managing Sessions
-- View active sessions in account settings
-- Revoke sessions from other devices
-- Set session timeout preferences
-
-### Password Management
-- Change password from profile settings
-- Reset forgotten password via email
-- Password requirements:
-  - Minimum 8 characters
-  - At least one uppercase letter
-  - At least one number
-  - At least one special character
-
----
-
-## Developer Guide
-
-### Protecting Routes
-```typescript
-// Use AuthGuard decorator
-@UseGuards(AuthGuard('jwt'))
-@Get('protected')
-async getProtectedData() {
-  return { data: 'This is protected' };
-}
-
-// Role-based protection
-@UseGuards(AuthGuard('jwt'), RolesGuard)
-@Roles('admin')
-@Get('admin')
-async getAdminData() {
-  return { data: 'Admin only' };
-}
-```
-
-### Custom Authentication Logic
-```typescript
-// Extend AuthService
-export class CustomAuthService extends AuthService {
-  async validateUser(email: string, password: string): Promise<User> {
-    // Add custom validation logic
-    const user = await super.validateUser(email, password);
-    
-    // Additional checks
-    if (user.suspended) {
-      throw new UnauthorizedException('Account suspended');
-    }
-    
-    return user;
-  }
-}
-```
-
-### Testing Authentication
-```typescript
-describe('AuthController', () => {
-  it('should login user', async () => {
-    const response = await request(app.getHttpServer())
-      .post('/auth/login')
-      .send({
-        email: 'test@example.com',
-        password: 'TestPass123!'
-      })
-      .expect(200);
-    
-    expect(response.body).toHaveProperty('tokens.accessToken');
-  });
-});
-```
-
----
-
-## Troubleshooting
-
-### Common Issues
-
-#### Invalid Token Error
-**Problem**: "JsonWebTokenError: invalid token"
-**Solutions**:
-- Verify token format (Bearer prefix)
-- Check token expiration
-- Ensure JWT_SECRET matches
-
-#### Login Rate Limit
-**Problem**: "429 Too Many Requests"
-**Solutions**:
-- Wait for rate limit window to reset
-- Check AUTH_RATE_LIMIT configuration
-- Implement exponential backoff
-
-#### CORS Issues
-**Problem**: "Access blocked by CORS policy"
-**Solutions**:
-- Configure CORS middleware
-- Add origin to allowed list
-- Check preflight requests
-
-### Debug Mode
-Enable debug logging:
-```bash
-DEBUG=auth:* npm start
-```
-
-### Support
-- GitHub Issues: [github.com/yourapp/issues](https://github.com/yourapp/issues)
-- Documentation: [docs.yourapp.com/auth](https://docs.yourapp.com/auth)
-- Email: support@yourapp.com
-
----
-
-## Changelog
-
-### v2.1.0 (2024-01-15)
-- Added refresh token rotation
-- Improved rate limiting
-- Fixed security vulnerability in password reset
-
-### v2.0.0 (2023-12-01)
-- Breaking: Changed token format
-- Added 2FA support
-- Improved session management
-
-### Migration Guide (v1.x to v2.x)
-1. Update JWT_SECRET format
-2. Run token migration script
-3. Update client-side token handling
-
----
-
-## References
-- [JWT.io](https://jwt.io) - JWT Documentation
-- [OWASP Authentication Guide](https://owasp.org/www-project-cheat-sheets/cheatsheets/Authentication_Cheat_Sheet)
-- [Passport.js Documentation](http://www.passportjs.org/docs/)
-</content>
-<line_count>450</line_count>
-</write_to_file>
-        ]]></tool_use>
-      </step>
-    </workflow>
-
-    <key_takeaways>
-      <takeaway>Use semantic search to find related files.</takeaway>
-      <takeaway>Read multiple files for context.</takeaway>
-      <takeaway>Extract API docs from route definitions.</takeaway>
-      <takeaway>Use tests to understand behavior.</takeaway>
-      <takeaway>Document security measures.</takeaway>
-      <takeaway>Include troubleshooting for common errors.</takeaway>
-    </key_takeaways>
-  </example>
-
-  <example name="database_schema_extraction">
-    <scenario>
-      Extract documentation for database models, relationships, and migrations.
-    </scenario>
-
-    <workflow>
-      <step number="1">
-        <description>Find DB files</description>
-        <tool_use><![CDATA[
-<codebase_search>
-<query>database schema model entity migration table column relationship</query>
-</codebase_search>
-        ]]></tool_use>
-      </step>
-
-      <step number="2">
-        <description>Analyze models</description>
-        <tool_use><![CDATA[
-<search_files>
-<path>src/models</path>
-<regex>@(Entity|Table|Model)|class\s+\w+\s+extends\s+(Model|BaseEntity)</regex>
-</search_files>
-        ]]></tool_use>
-      </step>
-
-      <step number="3">
-        <description>Extract relationships</description>
-        <tool_use><![CDATA[
-<search_files>
-<path>src/models</path>
-<regex>@(OneToMany|ManyToOne|OneToOne|ManyToMany|BelongsTo|HasMany)</regex>
-</search_files>
-        ]]></tool_use>
-      </step>
-
-      <step number="4">
-        <description>Document migrations</description>
-        <tool_use><![CDATA[
-<list_files>
-<path>migrations</path>
-<recursive>true</recursive>
-</list_files>
-        ]]></tool_use>
-      </step>
-
-      <step number="5">
-        <description>Generate schema documentation</description>
-        <output>
-          - Entity relationship diagrams
-          - Table schemas with column types
-          - Index definitions
-          - Foreign key constraints
-          - Migration history
-          - Query patterns and optimizations
-        </output>
-      </step>
-    </workflow>
-  </example>
-
-  <example name="api_endpoint_extraction">
-    <scenario>
-      Extract comprehensive API documentation including all endpoints,
-      request/response formats, authentication, and examples.
-    </scenario>
-
-    <workflow>
-      <step number="1">
-        <description>Find all API routes</description>
-        <tool_use><![CDATA[
-<search_files>
-<path>src</path>
-<regex>(app|router)\.(get|post|put|patch|delete|all)\s*\(\s*['"`]([^'"`]+)['"`]</regex>
-</search_files>
-        ]]></tool_use>
-      </step>
-
-      <step number="2">
-        <description>Extract request validation</description>
-        <tool_use><![CDATA[
-<search_files>
-<path>src</path>
-<regex>@(Body|Query|Param|Headers)\(|joi\.object|yup\.object|zod\.object</regex>
-</search_files>
-        ]]></tool_use>
-      </step>
-
-      <step number="3">
-        <description>Find response schemas</description>
-        <tool_use><![CDATA[
-<search_files>
-<path>src</path>
-<regex>@ApiResponse|swagger|openapi|response\.json\(|res\.send\(</regex>
-</search_files>
-        ]]></tool_use>
-      </step>
-
-      <step number="4">
-        <description>Document authentication requirements</description>
-        <tool_use><![CDATA[
-<search_files>
-<path>src</path>
-<regex>@(UseGuards|Authorized|Public)|passport\.authenticate|requireAuth</regex>
-</search_files>
-        ]]></tool_use>
-      </step>
-
-      <step number="5">
-        <description>Generate OpenAPI/Swagger documentation</description>
-        <output_format>
-          - OpenAPI 3.0 specification
-          - Postman collection
-          - API client examples
-          - cURL commands
-          - SDK usage examples
-        </output_format>
-      </step>
-    </workflow>
-  </example>
-
-  <example name="frontend_component_extraction">
-    <scenario>
-      Document React/Vue/Angular components including props, events,
-      slots, styling, and usage examples.
-    </scenario>
-
-    <workflow>
-      <step number="1">
-        <description>Find component files</description>
-        <tool_use><![CDATA[
-<search_files>
-<path>src/components</path>
-<regex>export\s+(default\s+)?(function|class|const)\s+\w+|@Component</regex>
-<file_pattern>*.tsx</file_pattern>
-</search_files>
-        ]]></tool_use>
-      </step>
-
-      <step number="2">
-        <description>Extract component props/inputs</description>
-        <tool_use><![CDATA[
-<search_files>
-<path>src/components</path>
-<regex>interface\s+\w+Props|type\s+\w+Props|@Input\(\)|props:\s*{</regex>
-</search_files>
-        ]]></tool_use>
-      </step>
-
-      <step number="3">
-        <description>Find component usage examples</description>
-        <tool_use><![CDATA[
-<search_files>
-<path>src</path>
-<regex><ComponentName|import.*ComponentName</regex>
-</search_files>
-        ]]></tool_use>
-      </step>
-
-      <step number="4">
-        <description>Document styling and themes</description>
-        <tool_use><![CDATA[
-<search_files>
-<path>src/components</path>
-<regex>styled\.|makeStyles|@apply|className=|style=</regex>
-</search_files>
-        ]]></tool_use>
-      </step>
-
-      <step number="5">
-        <description>Extract Storybook stories</description>
-        <tool_use><![CDATA[
-<search_files>
-<path>src</path>
-<regex>export\s+default\s+{.*title:|\.stories\.</regex>
-<file_pattern>*.stories.tsx</file_pattern>
-</search_files>
-        ]]></tool_use>
-      </step>
-
-      <step number="6">
-        <description>Generate component documentation</description>
-        <output>
-          - Component API reference
-          - Props table with types and defaults
-          - Event documentation
-          - Styling guidelines
-          - Usage examples
-          - Accessibility notes
-          - Browser compatibility
-        </output>
-      </step>
-    </workflow>
-  </example>
-
-  <example name="configuration_system_extraction">
-    <scenario>
-      Document all configuration options, environment variables,
-      feature flags, and their impacts on system behavior.
-    </scenario>
-
-    <workflow>
-      <step number="1">
-        <description>Find configuration files</description>
-        <tool_use><![CDATA[
-<list_files>
-<path>.</path>
-<recursive>false</recursive>
-</list_files>
-        ]]></tool_use>
-        <look_for>
-          - .env.example
-          - config/
-          - settings.json
-          - app.config.ts
-        </look_for>
-      </step>
-
-      <step number="2">
-        <description>Extract environment variables</description>
-        <tool_use><![CDATA[
-<search_files>
-<path>.</path>
-<regex>process\.env\.(\w+)|getenv\(['"](\w+)['"]\)</regex>
-</search_files>
-        ]]></tool_use>
-      </step>
-
-      <step number="3">
-        <description>Find feature flags</description>
-        <tool_use><![CDATA[
-<search_files>
-<path>src</path>
-<regex>feature\.|featureFlag|isEnabled\(['"]|flags\.</regex>
-</search_files>
-        ]]></tool_use>
-      </step>
-
-      <step number="4">
-        <description>Document configuration impacts</description>
-        <analysis>
-          - How each config affects behavior
-          - Dependencies between configs
-          - Performance implications
-          - Security considerations
-          - Default values and overrides
-        </analysis>
-      </step>
-
-      <step number="5">
-        <description>Generate configuration guide</description>
-        <output>
-          - Complete configuration reference
-          - Environment setup guide
-          - Docker/Kubernetes configs
-          - CI/CD pipeline variables
-          - Production deployment checklist
-        </output>
-      </step>
-    </workflow>
-  </example>
-  <example name="documentation_review_example">
-    <scenario>
-      Review a user-provided documentation section for accuracy against the codebase
-      and provide recommendations for improvement in the chat.
-    </scenario>
-    <workflow>
-      <step number="1">
-        <description>User provides documentation for review</description>
-        <user_input>
-          "Here's our current draft for the JWT_SECRET setting. Can you check it for accuracy? 'The `JWT_SECRET` is an optional key for enhancing security.'"
-        </user_input>
-      </step>
-      <step number="2">
-        <description>Analyze relevant code</description>
-        <tool_use><![CDATA[
-<codebase_search>
-<query>JWT_SECRET configuration implementation</query>
-</codebase_search>
-        ]]></tool_use>
-        <expected_findings>
-          - Code where `JWT_SECRET` is read (e.g., `process.env.JWT_SECRET`)
-          - Logic that fails if the secret is missing
-          - Default values or error handling related to the secret
-        </expected_findings>
-      </step>
-      <step number="3">
-        <description>Formulate and provide feedback in chat</description>
-        <tool_use><![CDATA[
-<attempt_completion>
-<result>
-I have reviewed the documentation section provided for the `JWT_SECRET` setting. Here are my recommendations for improvement:
-
-**Overall Assessment**: The current draft is critically inaccurate and could lead to security vulnerabilities if followed.
-
-**Recommendations for Improvement**:
-
-*   **Critical Inaccuracy**:
-    *   The documentation states that `JWT_SECRET` is optional. However, the application will fail to start if it is not provided. It is a **required** setting for the application to function securely.
-    *   **Suggestion**: "The `JWT_SECRET` is a **required** environment variable used to sign and verify JSON Web Tokens. The application will not run without it."
-
-This feedback can be copied and pasted for your documentation team.
-</result>
-</attempt_completion>
-        ]]></tool_use>
-        <note>No file is written. The feedback is provided directly to the user in the chat interface.</note>
-      </step>
-    </workflow>
-  </example>
- 
-   <best_practices>
-     <practice name="comprehensive_coverage">
-       <description>Ensure all aspects are documented</description>
-      <checklist>
-        <item>Technical implementation details</item>
-        <item>Business logic and rules</item>
-        <item>User workflows and journeys</item>
-        <item>API specifications</item>
-        <item>Configuration options</item>
-        <item>Security measures</item>
-        <item>Performance characteristics</item>
-        <item>Error handling</item>
-        <item>Testing strategies</item>
-        <item>Deployment procedures</item>
-      </checklist>
-    </practice>
-
-    <practice name="multi_audience_writing">
-      <description>Tailor content for different readers</description>
-      <audiences>
-        <audience type="end_users">
-          Focus on how-to guides and troubleshooting
-        </audience>
-        <audience type="developers">
-          Include code examples and technical details
-        </audience>
-        <audience type="administrators">
-          Emphasize configuration and maintenance
-        </audience>
-        <audience type="stakeholders">
-          Highlight business value and metrics
-        </audience>
-      </audiences>
-    </practice>
-
-    <practice name="maintainable_documentation">
-      <description>Create documentation that's easy to update</description>
-      <guidelines>
-        <guideline>Use clear section headers</guideline>
-        <guideline>Include version information</guideline>
-        <guideline>Add last-updated timestamps</guideline>
-        <guideline>Cross-reference related sections</guideline>
-        <guideline>Provide migration guides</guideline>
-      </guidelines>
-    </practice>
-
-    <practice name="example_driven">
-      <description>Include practical examples throughout</description>
-      <example_types>
-        <type>Code snippets with syntax highlighting</type>
-        <type>API request/response pairs</type>
-        <type>Configuration examples</type>
-        <type>Command-line usage</type>
-        <type>Error scenarios and solutions</type>
-      </example_types>
-    </practice>
-  </best_practices>
-
-  <output_validation>
-    <checklist>
-      <item>Table of contents with working links</item>
-      <item>All sections properly formatted</item>
-      <item>Code examples are syntactically correct</item>
-      <item>No placeholder text remaining</item>
-      <item>Version information included</item>
-      <item>Cross-references are valid</item>
-      <item>Metadata is complete</item>
-      <item>File follows naming convention</item>
-    </checklist>
-  </output_validation>
-</complete_extraction_examples>

.roo/rules-docs-extractor/6_communication_guidelines.xml

@@ -1,283 +0,0 @@
-<communication_guidelines>
-  <overview>
-    Guidelines for user communication and output formatting.
-  </overview>
-
-  <user_interaction>
-    <initial_contact>
-      <principle>Act on the user's request immediately.</principle>
-      <principle>Only ask for clarification if the request is ambiguous.</principle>
-    </initial_contact>
-
-    <clarification>
-      <when_to_ask>
-        <scenario>Multiple features with similar names are found.</scenario>
-        <scenario>The request is ambiguous.</scenario>
-        <scenario>The user explicitly asks for options.</scenario>
-      </when_to_ask>
-      
-      <question_example><![CDATA[
-<ask_followup_question>
-<question>Found multiple auth systems. Which to document?</question>
-<follow_up>
-<suggest>JWT-based system (src/auth/jwt/*)</suggest>
-<suggest>OAuth2 integration (src/auth/oauth/*)</suggest>
-<suggest>Basic auth middleware (src/middleware/basic-auth.ts)</suggest>
-<suggest>All of them</suggest>
-</follow_up>
-</ask_followup_question>
-      ]]></question_example>
-    </clarification>
-
-    <progress_updates>
-      <when_to_update>
-        <trigger>Starting a major analysis phase.</trigger>
-        <trigger>Extraction is complete.</trigger>
-        <trigger>Unexpected complexity is found.</trigger>
-      </when_to_update>
-      
-      <update_format>
-        <template>
-          Analyzing [component]...
-          - Found [X] related files.
-          - Identified [Y] API endpoints.
-          - Found [Z] config options.
-        </template>
-      </update_format>
-    </progress_updates>
-
-    <findings_communication>
-      <important_findings>
-        <discovery type="security_issue">
-          Alert user to security concerns found during analysis.
-        </discovery>
-        <discovery type="deprecated_code">
-          Note deprecated features needing migration docs.
-        </discovery>
-        <discovery type="missing_docs">
-          Highlight code that lacks inline documentation.
-        </discovery>
-        <discovery type="complex_dependencies">
-          Warn about complex dependency chains.
-        </discovery>
-      </important_findings>
-      <review_findings>
-       <template><![CDATA[
-Review of the provided documentation section is complete.
-
-**Assessment**: [Summary of document quality]
-
-**Recommendations**:
-
-*   **Critical Inaccuracies**:
-    *   [Inaccuracy 1]: Docs state [X], but code implements [Y].
-    *   ...
-
-*   **Omissions**:
-    *   Missing info about [Missing Feature].
-    *   ...
-
-*   **Clarity Suggestions**:
-    *   The section on [Topic] can be clarified by [Suggestion].
-    *   ...
-
-Copy this feedback for your documentation team.
-       ]]></template>
-      </review_findings>
-    </findings_communication>
-  </user_interaction>
-
-  <output_formatting>
-    <markdown_standards>
-      <headings>
-        <rule>Use # for main title, ## for major sections, ### for subsections.</rule>
-        <rule>Never skip heading levels.</rule>
-      </headings>
-
-      <code_blocks>
-        <rule>Always specify language for syntax highlighting (e.g., typescript, json, bash).</rule>
-        <rule>Include file paths as comments where relevant.</rule>
-        <example><![CDATA[
-```typescript
-// src/auth/auth.service.ts
-export class AuthService {
-  async validateUser(email: string, password: string): Promise<User> {
-    // Implementation
-  }
-}
-```
-        ]]></example>
-      </code_blocks>
-
-      <tables>
-        <rule>Use tables for structured data like configs.</rule>
-        <rule>Include headers and align columns.</rule>
-        <rule>Keep cell content brief.</rule>
-        <example><![CDATA[
-| Variable | Type | Default | Description |
-|----------|------|---------|-------------|
-| `JWT_SECRET` | string | - | Secret key for JWT signing |
-| `JWT_EXPIRATION` | string | '15m' | Token expiration time |
-        ]]></example>
-      </tables>
-
-      <lists>
-        <rule>Use bullets for unordered lists, numbers for sequential steps.</rule>
-        <rule>Keep list items parallel in structure.</rule>
-      </lists>
-    </markdown_standards>
-
-    <cross_references>
-      <internal_links>
-        <format>[Link text](#section-anchor)</format>
-        <rule>Use lowercase, hyphenated anchors. Test all links.</rule>
-      </internal_links>
-
-      <external_links>
-        <format>[Link text](https://example.com)</format>
-        <rule>Use HTTPS. Link to official docs.</rule>
-      </external_links>
-
-      <file_references>
-        <format>`path/to/file.ts`</format>
-        <rule>Use relative paths from project root, in backticks.</rule>
-      </file_references>
-    </cross_references>
-
-    <special_sections>
-      <alerts>
-        <type name="warning">
-          <format>> ⚠️ **Warning**: [message]</format>
-          <use_for>Security, breaking changes, deprecations.</use_for>
-        </type>
-        <type name="note">
-          <format>> 📝 **Note**: [message]</format>
-          <use_for>Important info, clarifications.</use_for>
-        </type>
-        <type name="tip">
-          <format>> 💡 **Tip**: [message]</format>
-          <use_for>Best practices, optimizations.</use_for>
-        </type>
-      </alerts>
-
-      <metadata_blocks>
-        <version_info><![CDATA[
----
-Feature: Authentication System
-Version: 2.1.0
-Last Updated: 2024-01-15
-Status: Stable
----
-        ]]></version_info>
-      </metadata_blocks>
-    </special_sections>
-  </output_formatting>
-
-  <documentation_tone>
-    <general>
-      <principle>Be direct, not conversational.</principle>
-      <principle>Use active voice.</principle>
-      <principle>Lead with benefits.</principle>
-      <principle>Use concrete examples.</principle>
-      <principle>Keep paragraphs short.</principle>
-      <principle>Avoid unnecessary technical details.</principle>
-    </general>
-
-    <audience_tone>
-      <audience type="developer">
-        <tone>Technical and direct.</tone>
-        <vocabulary>Standard programming terms.</vocabulary>
-        <examples>Code snippets, implementation details.</examples>
-      </audience>
-      <audience type="end_user">
-        <tone>Instructional, step-by-step.</tone>
-        <vocabulary>Simple language, no jargon.</vocabulary>
-        <examples>Screenshots, real-world scenarios.</examples>
-      </audience>
-      <audience type="administrator">
-        <tone>Operational focus.</tone>
-        <vocabulary>IT/DevOps terms.</vocabulary>
-        <examples>CLI examples, configs.</examples>
-      </audience>
-    </audience_tone>
-  </documentation_tone>
-
-  <completion_message>
-    <structure>
-      <element>Summary of documented feature.</element>
-      <element>Key findings.</element>
-      <element>File location.</element>
-      <element>Next step suggestions (if applicable).</element>
-    </structure>
-
-    <example><![CDATA[
-Documentation extracted for the authentication system.
-
-**Generated File**: `DOCS-TEMP-authentication-system.md`
-
-**Key Findings**:
-- System uses JWT with refresh token rotation.
-- 5 API endpoints found.
-- 12 configuration options identified.
-- Security measures (bcrypt, rate limiting) documented.
-- Troubleshooting for 3 common issues included.
-
-**Coverage**:
-- ✅ Technical details
-- ✅ API reference
-- ✅ Configuration guide
-- ✅ Security guide
-- ✅ User and developer guides
-- ✅ Troubleshooting
-    ]]></example>
-    <example_review><![CDATA[
-Review of the documentation section is complete.
-
-**Action**:
-- Analyzed text against codebase.
-- Identified inaccuracies and omissions.
-- Formulated recommendations.
-
-**Next Steps**:
-- Feedback is in the chat. No files were created.
-    ]]></example_review>
-  </completion_message>
-
-  <error_handling>
-    <scenarios>
-      <scenario type="feature_not_found">
-        <response>
-          Could not find a feature matching "[feature name]". Similar features found:
-          - [List similar features]
-          Document one of these instead?
-        </response>
-      </scenario>
-
-      <scenario type="insufficient_docs">
-        <response>
-          Code for [feature] has limited inline documentation. Extracting from code structure, tests, and usage patterns.
-        </response>
-      </scenario>
-
-      <scenario type="complex_feature">
-        <response>
-          This feature is complex. Choose documentation scope:
-          - Document comprehensively
-          - Focus on core functionality
-          - Split into multiple documents
-        </response>
-      </scenario>
-    </scenarios>
-  </error_handling>
-
-  <quality_checks>
-    <before_completion>
-      <check>No placeholder content remains.</check>
-      <check>Code examples are correct.</check>
-      <check>Links and cross-references work.</check>
-      <check>Tables are formatted correctly.</check>
-      <check>Version info is included.</check>
-      <check>Filename follows conventions.</check>
-    </before_completion>
-  </quality_checks>
-</communication_guidelines>

.roo/rules-docs-extractor/7_user_friendly_examples.xml

@@ -1,218 +0,0 @@
-<user_friendly_examples>
-  <overview>
-    Examples for creating user-focused, practical documentation.
-  </overview>
-
-  <writing_principles>
-    <principle name="benefits_over_features">
-      <bad>The concurrent file read feature uses parallel processing.</bad>
-      <good>Read multiple files at once, reducing interruptions.</good>
-    </principle>
-
-    <principle name="use_scenarios">
-      <bad>This improves efficiency.</bad>
-      <good>Instead of approving 10 file reads one-by-one, approve them all at once.</good>
-    </principle>
-
-    <principle name="hide_implementation_details">
-      <bad>The feature uses a thread pool with configurable concurrency limits.</bad>
-      <good>Roo reads up to 100 files at once (changeable in settings).</good>
-    </principle>
-
-    <principle name="direct_tone">
-      <bad>Users must configure the concurrent file read limit parameter.</bad>
-      <good>Adjust how many files Roo reads at once in settings.</good>
-    </principle>
-  </writing_principles>
-
-  <structure_examples>
-    <example name="feature_intro">
-      <template><![CDATA[
-# [Feature Name]
-
-[One-sentence description of what it does.]
-
-### Key Features
-- [Benefit 1]
-- [Benefit 2]
-- [Benefit 3]
-
----
-      ]]></template>
-    </example>
-
-    <example name="use_case">
-      <template><![CDATA[
-## Use Case
-
-**Before**: [Description of the old way]
-- [Pain point]
-- [Pain point]
-
-**Now**: [Description of the new way]
-      ]]></template>
-    </example>
-
-    <example name="configuration">
-      <template><![CDATA[
-## Configuration
-
-Customize this feature in settings:
-
-1. **[Setting Name]**
-   - **Does**: [Plain language explanation.]
-   - **Default**: [Default value.] (Works for most.)
-   - **Change if**: [Specific scenarios to adjust this.]
-
-2. **[Setting Name]**
-   - **Does**: [Plain language explanation.]
-   - **Default**: [Default value.]
-   - **Change if**: [Specific use case.]
-      ]]></template>
-    </example>
-
-    <example name="faq">
-      <template><![CDATA[
-## FAQ
-
-**"[User question]"**
-- [Direct answer.]
-- [Optional tip.]
-
-**"[Another question]"**
-- [Direct answer.]
-- [Optional link.]
-      ]]></template>
-    </example>
-
-    <example name="troubleshooting">
-      <template><![CDATA[
-## Troubleshooting
-
-### [Problem symptom]
-**Cause**: [Brief explanation.]
-**Fix**: [Immediate solution.]
-**Alternate fix**: [Alternative solution.]
-
-### [Another issue]
-**Scenario**: [When this happens.]
-**Solution**:
-1. [Step 1]
-2. [Step 2]
-      ]]></template>
-    </example>
-
-  </structure_examples>
-
-  <tone_examples>
-    <explanations>
-      <example context="limit">
-        <technical>The system imposes a hard limit of 100 concurrent operations.</technical>
-        <direct>Roo handles up to 100 files at once.</direct>
-      </example>
-
-      <example context="error">
-        <technical>Error: Maximum concurrency threshold exceeded.</technical>
-        <direct>Too many files requested. Lower the file limit in settings.</direct>
-      </example>
-
-      <example context="benefit">
-        <technical>Reduces API call overhead through request batching.</technical>
-        <direct>Get answers faster by reading all needed files at once.</direct>
-      </example>
-    </explanations>
-
-    <visuals>
-      <emojis>
-        <when>Error: ⚠️</when>
-        <when>Tip: 💡</when>
-        <when>Note: 📝</when>
-        <when>Security: 🔒</when>
-      </emojis>
-
-      <formatting>
-        <bold>For emphasis</bold>
-        <code>For settings, file paths, or commands</code>
-        <blockquotes>For callouts or warnings</blockquotes>
-      </formatting>
-    </visuals>
-  </tone_examples>
-
-  <real_world_example>
-    <title>Concurrent File Reads Doc</title>
-    <content><![CDATA[
-# Concurrent File Reads
-
-Read multiple files from your workspace in a single step.
-
-### Key Features
-- Read up to 100 files in one request.
-- Enabled by default for faster workflow.
-- Configurable to match system capabilities.
-
----
-
-## Use Case
-
-**Before**: Multiple, sequential requests to read files:
-- "Read `src/app.js`?" → Approve
-- "Read `src/utils.js`?" → Approve
-- "Read `src/config.json`?" → Approve
-
-**Now**: Roo asks once to read all related files.
-
-## How it Works
-
-Roo automatically identifies and reads relevant files together for tasks requiring multi-file context, such as:
-
-- Understanding components split across multiple files.
-- Refactoring code with dependencies.
-- Answering questions requiring broad project context.
-
-The [`read_file`](/tools/read-file) tool accepts multiple files in a single request.
-
----
-
-## Configuration
-
-Customize in Roo's settings:
-
-1. **Enable/Disable Concurrent File Reads**
-   - **Does**: Toggles whether Roo can read multiple files at once.
-   - **Default**: Enabled.
-   - **Disable if**: Using a less capable AI model or requiring more access control.
-
-2. **Concurrent File Reads Limit**
-   - **Does**: Sets max number of files Roo can read at once.
-   - **Default**: 100.
-   - **Adjust**: Lower for memory constraints; raise for very large projects.
-
----
-
-## FAQ
-
-**"Too many files are requested at once."**
-- Lower the file limit in settings.
-- Deny individual files in the batch dialog.
-
-**"Some files were denied but others were approved."**
-- Normal behavior. Roo works with approved files.
-- Files may be blocked by `.rooignore` settings.
-
-**"Does this use more memory?"**
-- Yes, but the impact is usually minimal.
-- If you see slowdowns, reduce the file limit.
-
-    ]]></content>
-  </real_world_example>
-
-  <checklist>
-    <item>Does it start with benefits?</item>
-    <item>Are technical terms avoided?</item>
-    <item>Is the tone direct?</item>
-    <item>Are there practical examples?</item>
-    <item>Are sections short and scannable?</item>
-    <item>Does it answer user questions?</item>
-    <item>Is help accessible?</item>
-  </checklist>
-</user_friendly_examples>

.roo/rules-integration-tester/1_workflow.xml

@@ -1,198 +0,0 @@
-<workflow>
-  <step number="1">
-    <name>Understand Test Requirements</name>
-    <instructions>
-      Use ask_followup_question to determine what type of integration test is needed:
-      
-      <ask_followup_question>
-      <question>What type of integration test would you like me to create or work on?</question>
-      <follow_up>
-      <suggest>New E2E test for a specific feature or workflow</suggest>
-      <suggest>Fix or update an existing integration test</suggest>
-      <suggest>Create test utilities or helpers for common patterns</suggest>
-      <suggest>Debug failing integration tests</suggest>
-      </follow_up>
-      </ask_followup_question>
-    </instructions>
-  </step>
-
-  <step number="2">
-    <name>Gather Test Specifications</name>
-    <instructions>
-      Based on the test type, gather detailed requirements:
-      
-      For New E2E Tests:
-      - What specific user workflow or feature needs testing?
-      - What are the expected inputs and outputs?
-      - What edge cases or error scenarios should be covered?
-      - Are there specific API interactions to validate?
-      - What events should be monitored during the test?
-      
-      For Existing Test Issues:
-      - Which test file is failing or needs updates?
-      - What specific error messages or failures are occurring?
-      - What changes in the codebase might have affected the test?
-      
-      For Test Utilities:
-      - What common patterns are being repeated across tests?
-      - What helper functions would improve test maintainability?
-      
-      Use multiple ask_followup_question calls if needed to gather complete information.
-    </instructions>
-  </step>
-
-  <step number="3">
-    <name>Explore Existing Test Patterns</name>
-    <instructions>
-      Use codebase_search FIRST to understand existing test patterns and similar functionality:
-      
-      For New Tests:
-      - Search for similar test scenarios in apps/vscode-e2e/src/suite/
-      - Find existing test utilities and helpers
-      - Identify patterns for the type of functionality being tested
-      
-      For Test Fixes:
-      - Search for the failing test file and related code
-      - Find similar working tests for comparison
-      - Look for recent changes that might have broken the test
-      
-      Example searches:
-      - "file creation test mocha" for file operation tests
-      - "task completion waitUntilCompleted" for task monitoring patterns
-      - "api message validation" for API interaction tests
-      
-      After codebase_search, use:
-      - read_file on relevant test files to understand structure
-      - list_code_definition_names on test directories
-      - search_files for specific test patterns or utilities
-    </instructions>
-  </step>
-
-  <step number="4">
-    <name>Analyze Test Environment and Setup</name>
-    <instructions>
-      Examine the test environment configuration:
-      
-      1. Read the test runner configuration:
-         - apps/vscode-e2e/package.json for test scripts
-         - apps/vscode-e2e/src/runTest.ts for test setup
-         - Any test configuration files
-      
-      2. Understand the test workspace setup:
-         - How test workspaces are created
-         - What files are available during tests
-         - How the extension API is accessed
-      
-      3. Review existing test utilities:
-         - Helper functions for common operations
-         - Event listening patterns
-         - Assertion utilities
-         - Cleanup procedures
-      
-      Document findings including:
-      - Test environment structure
-      - Available utilities and helpers
-      - Common patterns and best practices
-    </instructions>
-  </step>
-
-  <step number="5">
-    <name>Design Test Structure</name>
-    <instructions>
-      Plan the test implementation based on gathered information:
-      
-      For New Tests:
-      - Define test suite structure with suite/test blocks
-      - Plan setup and teardown procedures
-      - Identify required test data and fixtures
-      - Design event listeners and validation points
-      - Plan for both success and failure scenarios
-      
-      For Test Fixes:
-      - Identify the root cause of the failure
-      - Plan the minimal changes needed to fix the issue
-      - Consider if the test needs to be updated due to code changes
-      - Plan for improved error handling or debugging
-      
-      Create a detailed test plan including:
-      - Test file structure and organization
-      - Required setup and cleanup
-      - Specific assertions and validations
-      - Error handling and edge cases
-    </instructions>
-  </step>
-
-  <step number="6">
-    <name>Implement Test Code</name>
-    <instructions>
-      Implement the test following established patterns:
-      
-      CRITICAL: Never write a test file with a single write_to_file call.
-      Always implement tests in parts:
-      
-      1. Start with the basic test structure (suite, setup, teardown)
-      2. Add individual test cases one by one
-      3. Implement helper functions separately
-      4. Add event listeners and validation logic incrementally
-      
-      Follow these implementation guidelines:
-      - Use suite() and test() blocks following Mocha TDD style
-      - Always use the global api object for extension interactions
-      - Implement proper async/await patterns with waitFor utility
-      - Use waitUntilCompleted and waitUntilAborted helpers for task monitoring
-      - Listen to and validate appropriate events (message, taskCompleted, etc.)
-      - Test both positive flows and error scenarios
-      - Validate message content using proper type assertions
-      - Create reusable test utilities when patterns emerge
-      - Use meaningful test descriptions that explain the scenario
-      - Always clean up tasks with cancelCurrentTask or clearCurrentTask
-      - Ensure tests are independent and can run in any order
-    </instructions>
-  </step>
-
-  <step number="7">
-    <name>Run and Validate Tests</name>
-    <instructions>
-      Execute the tests to ensure they work correctly:
-      
-      ALWAYS use the correct working directory and commands:
-      - Working directory: apps/vscode-e2e
-      - Test command: npm run test:run
-      - For specific tests: TEST_FILE="filename.test" npm run test:run
-      - Example: cd apps/vscode-e2e && TEST_FILE="apply-diff.test" npm run test:run
-      
-      Test execution process:
-      1. Run the specific test file first
-      2. Check for any failures or errors
-      3. Analyze test output and logs
-      4. Debug any issues found
-      5. Re-run tests after fixes
-      
-      If tests fail:
-      - Add console.log statements to track execution flow
-      - Log important events like task IDs, file paths, and AI responses
-      - Check test output carefully for error messages and stack traces
-      - Verify file creation in correct workspace directories
-      - Ensure proper event handling and timeouts
-    </instructions>
-  </step>
-
-  <step number="8">
-    <name>Document and Complete</name>
-    <instructions>
-      Finalize the test implementation:
-      
-      1. Add comprehensive comments explaining complex test logic
-      2. Document any new test utilities or patterns created
-      3. Ensure test descriptions clearly explain what is being tested
-      4. Verify all cleanup procedures are in place
-      5. Confirm tests can run independently and in any order
-      
-      Provide the user with:
-      - Summary of tests created or fixed
-      - Instructions for running the tests
-      - Any new patterns or utilities that can be reused
-      - Recommendations for future test improvements
-    </instructions>
-  </step>
-</workflow>

.roo/rules-integration-tester/2_test_patterns.xml

@@ -1,303 +0,0 @@
-<test_patterns>
-  <mocha_tdd_structure>
-    <description>Standard Mocha TDD structure for integration tests</description>
-    <pattern>
-      <name>Basic Test Suite Structure</name>
-      <example>
-        ```typescript
-        import { suite, test, suiteSetup, suiteTeardown } from 'mocha';
-        import * as assert from 'assert';
-        import * as vscode from 'vscode';
-        import { waitFor, waitUntilCompleted, waitUntilAborted } from '../utils/testUtils';
-
-        suite('Feature Name Tests', () => {
-          let testWorkspaceDir: string;
-          let testFiles: { [key: string]: string } = {};
-
-          suiteSetup(async () => {
-            // Setup test workspace and files
-            testWorkspaceDir = vscode.workspace.workspaceFolders![0].uri.fsPath;
-            // Create test files in workspace
-          });
-
-          suiteTeardown(async () => {
-            // Cleanup test files and tasks
-            await api.cancelCurrentTask();
-          });
-
-          test('should perform specific functionality', async () => {
-            // Test implementation
-          });
-        });
-        ```
-      </example>
-    </pattern>
-
-    <pattern>
-      <name>Event Listening Pattern</name>
-      <example>
-        ```typescript
-        test('should handle task completion events', async () => {
-          const events: any[] = [];
-          
-          const messageListener = (message: any) => {
-            events.push({ type: 'message', data: message });
-          };
-          
-          const taskCompletedListener = (result: any) => {
-            events.push({ type: 'taskCompleted', data: result });
-          };
-
-          api.onDidReceiveMessage(messageListener);
-          api.onTaskCompleted(taskCompletedListener);
-
-          try {
-            // Perform test actions
-            await api.startTask('test prompt');
-            await waitUntilCompleted();
-            
-            // Validate events
-            assert(events.some(e => e.type === 'taskCompleted'));
-          } finally {
-            // Cleanup listeners
-            api.onDidReceiveMessage(() => {});
-            api.onTaskCompleted(() => {});
-          }
-        });
-        ```
-      </example>
-    </pattern>
-
-    <pattern>
-      <name>File Creation Test Pattern</name>
-      <example>
-        ```typescript
-        test('should create files in workspace', async () => {
-          const fileName = 'test-file.txt';
-          const expectedContent = 'test content';
-          
-          await api.startTask(`Create a file named ${fileName} with content: ${expectedContent}`);
-          await waitUntilCompleted();
-          
-          // Check multiple possible locations
-          const possiblePaths = [
-            path.join(testWorkspaceDir, fileName),
-            path.join(process.cwd(), fileName),
-            // Add other possible locations
-          ];
-          
-          let fileFound = false;
-          let actualContent = '';
-          
-          for (const filePath of possiblePaths) {
-            if (fs.existsSync(filePath)) {
-              actualContent = fs.readFileSync(filePath, 'utf8');
-              fileFound = true;
-              break;
-            }
-          }
-          
-          assert(fileFound, `File ${fileName} not found in any expected location`);
-          assert.strictEqual(actualContent.trim(), expectedContent);
-        });
-        ```
-      </example>
-    </pattern>
-  </mocha_tdd_structure>
-
-  <api_interaction_patterns>
-    <pattern>
-      <name>Basic Task Execution</name>
-      <example>
-        ```typescript
-        // Start a task and wait for completion
-        await api.startTask('Your prompt here');
-        await waitUntilCompleted();
-        ```
-      </example>
-    </pattern>
-
-    <pattern>
-      <name>Task with Auto-Approval Settings</name>
-      <example>
-        ```typescript
-        // Enable auto-approval for specific actions
-        await api.updateSettings({
-          alwaysAllowWrite: true,
-          alwaysAllowExecute: true
-        });
-        
-        await api.startTask('Create and execute a script');
-        await waitUntilCompleted();
-        ```
-      </example>
-    </pattern>
-
-    <pattern>
-      <name>Message Validation</name>
-      <example>
-        ```typescript
-        const messages: any[] = [];
-        api.onDidReceiveMessage((message) => {
-          messages.push(message);
-        });
-
-        await api.startTask('test prompt');
-        await waitUntilCompleted();
-
-        // Validate specific message types
-        const toolMessages = messages.filter(m => 
-          m.type === 'say' && m.say === 'api_req_started'
-        );
-        assert(toolMessages.length > 0, 'Expected tool execution messages');
-        ```
-      </example>
-    </pattern>
-  </api_interaction_patterns>
-
-  <error_handling_patterns>
-    <pattern>
-      <name>Task Abortion Handling</name>
-      <example>
-        ```typescript
-        test('should handle task abortion', async () => {
-          await api.startTask('long running task');
-          
-          // Abort after short delay
-          setTimeout(() => api.abortTask(), 1000);
-          
-          await waitUntilAborted();
-          
-          // Verify task was properly aborted
-          const status = await api.getTaskStatus();
-          assert.strictEqual(status, 'aborted');
-        });
-        ```
-      </example>
-    </pattern>
-
-    <pattern>
-      <name>Error Message Validation</name>
-      <example>
-        ```typescript
-        test('should handle invalid input gracefully', async () => {
-          const errorMessages: any[] = [];
-          
-          api.onDidReceiveMessage((message) => {
-            if (message.type === 'error' || message.text?.includes('error')) {
-              errorMessages.push(message);
-            }
-          });
-
-          await api.startTask('invalid prompt that should fail');
-          await waitFor(() => errorMessages.length > 0, 5000);
-          
-          assert(errorMessages.length > 0, 'Expected error messages');
-        });
-        ```
-      </example>
-    </pattern>
-  </error_handling_patterns>
-
-  <utility_patterns>
-    <pattern>
-      <name>File Location Helper</name>
-      <example>
-        ```typescript
-        function findFileInWorkspace(fileName: string, workspaceDir: string): string | null {
-          const possiblePaths = [
-            path.join(workspaceDir, fileName),
-            path.join(process.cwd(), fileName),
-            path.join(os.tmpdir(), fileName),
-            // Add other common locations
-          ];
-          
-          for (const filePath of possiblePaths) {
-            if (fs.existsSync(filePath)) {
-              return filePath;
-            }
-          }
-          
-          return null;
-        }
-        ```
-      </example>
-    </pattern>
-
-    <pattern>
-      <name>Event Collection Helper</name>
-      <example>
-        ```typescript
-        class EventCollector {
-          private events: any[] = [];
-          
-          constructor(private api: any) {
-            this.setupListeners();
-          }
-          
-          private setupListeners() {
-            this.api.onDidReceiveMessage((message: any) => {
-              this.events.push({ type: 'message', timestamp: Date.now(), data: message });
-            });
-            
-            this.api.onTaskCompleted((result: any) => {
-              this.events.push({ type: 'taskCompleted', timestamp: Date.now(), data: result });
-            });
-          }
-          
-          getEvents(type?: string) {
-            return type ? this.events.filter(e => e.type === type) : this.events;
-          }
-          
-          clear() {
-            this.events = [];
-          }
-        }
-        ```
-      </example>
-    </pattern>
-  </utility_patterns>
-
-  <debugging_patterns>
-    <pattern>
-      <name>Comprehensive Logging</name>
-      <example>
-        ```typescript
-        test('should log execution flow for debugging', async () => {
-          console.log('Starting test execution');
-          
-          const events: any[] = [];
-          api.onDidReceiveMessage((message) => {
-            console.log('Received message:', JSON.stringify(message, null, 2));
-            events.push(message);
-          });
-
-          console.log('Starting task with prompt');
-          await api.startTask('test prompt');
-          
-          console.log('Waiting for task completion');
-          await waitUntilCompleted();
-          
-          console.log('Task completed, events received:', events.length);
-          console.log('Final workspace state:', fs.readdirSync(testWorkspaceDir));
-        });
-        ```
-      </example>
-    </pattern>
-
-    <pattern>
-      <name>State Validation</name>
-      <example>
-        ```typescript
-        function validateTestState(description: string) {
-          console.log(`=== ${description} ===`);
-          console.log('Workspace files:', fs.readdirSync(testWorkspaceDir));
-          console.log('Current working directory:', process.cwd());
-          console.log('Task status:', api.getTaskStatus?.() || 'unknown');
-          console.log('========================');
-        }
-        ```
-      </example>
-    </pattern>
-  </debugging_patterns>
-</test_patterns>

.roo/rules-integration-tester/3_best_practices.xml

@@ -1,104 +0,0 @@
-<best_practices>
-  <test_structure>
-    - Always use suite() and test() blocks following Mocha TDD style
-    - Use descriptive test names that explain the scenario being tested
-    - Implement proper setup and teardown in suiteSetup() and suiteTeardown()
-    - Create test files in the VSCode workspace directory during suiteSetup()
-    - Store file paths in a test-scoped object for easy reference across tests
-    - Ensure tests are independent and can run in any order
-    - Clean up all test files and tasks in suiteTeardown() to avoid test pollution
-  </test_structure>
-
-  <api_interactions>
-    - Always use the global api object for extension interactions
-    - Implement proper async/await patterns with the waitFor utility
-    - Use waitUntilCompleted and waitUntilAborted helpers for task monitoring
-    - Set appropriate auto-approval settings (alwaysAllowWrite, alwaysAllowExecute) for the functionality being tested
-    - Listen to and validate appropriate events (message, taskCompleted, taskAborted, etc.)
-    - Always clean up tasks with cancelCurrentTask or clearCurrentTask after tests
-    - Use meaningful timeouts that account for actual task execution time
-  </api_interactions>
-
-  <file_system_handling>
-    - Be aware that files may be created in the workspace directory (/tmp/roo-test-workspace-*) rather than expected locations
-    - Always check multiple possible file locations when verifying file creation
-    - Use flexible file location checking that searches workspace directories
-    - Verify files exist after creation to catch setup issues early
-    - Account for the fact that the workspace directory is created by runTest.ts
-    - The AI may use internal tools instead of the documented tools - verify outcomes rather than methods
-  </file_system_handling>
-
-  <event_handling>
-    - Add multiple event listeners (taskStarted, taskCompleted, taskAborted) for better debugging
-    - Don't rely on parsing AI messages to detect tool usage - the AI's message format may vary
-    - Use terminal shell execution events (onDidStartTerminalShellExecution, onDidEndTerminalShellExecution) for command tracking
-    - Tool executions are reported via api_req_started messages with type="say" and say="api_req_started"
-    - Focus on testing outcomes (files created, commands executed) rather than message parsing
-    - There is no "tool_result" message type - tool results appear in "completion_result" or "text" messages
-  </event_handling>
-
-  <error_scenarios>
-    - Test both positive flows and error scenarios
-    - Validate message content using proper type assertions
-    - Implement proper error handling and edge cases
-    - Use try-catch blocks around critical test operations
-    - Log important events like task IDs, file paths, and AI responses for debugging
-    - Check test output carefully for error messages and stack traces
-  </error_scenarios>
-
-  <test_reliability>
-    - Remove unnecessary waits for specific tool executions - wait for task completion instead
-    - Simplify message handlers to only capture essential error information
-    - Use the simplest possible test structure that verifies the outcome
-    - Avoid complex message parsing logic that depends on AI behavior
-    - Terminal events are more reliable than message parsing for command execution verification
-    - Keep prompts simple and direct - complex instructions may confuse the AI
-  </test_reliability>
-
-  <debugging_and_troubleshooting>
-    - Add console.log statements to track test execution flow
-    - Log important events like task IDs, file paths, and AI responses
-    - Use codebase_search first to find similar test patterns before writing new tests
-    - Create helper functions for common file location checks
-    - Use descriptive variable names for file paths and content
-    - Always log the expected vs actual locations when tests fail
-    - Add comprehensive comments explaining complex test logic
-  </debugging_and_troubleshooting>
-
-  <test_utilities>
-    - Create reusable test utilities when patterns emerge
-    - Implement helper functions for common operations like file finding
-    - Use event collection utilities for consistent event handling
-    - Create assertion helpers for common validation patterns
-    - Document any new test utilities or patterns created
-    - Share common utilities across test files to reduce duplication
-  </test_utilities>
-
-  <ai_interaction_considerations>
-    - Keep prompts simple and direct - complex instructions may lead to unexpected behavior
-    - Allow for variations in how the AI accomplishes tasks
-    - The AI may not always use the exact tool you specify in the prompt
-    - Be prepared to adapt tests based on actual AI behavior rather than expected behavior
-    - The AI may interpret instructions creatively - test results rather than implementation details
-    - The AI will not see the files in the workspace directory, you must tell it to assume they exist and proceed
-  </ai_interaction_considerations>
-
-  <test_execution>
-    - ALWAYS use the correct working directory: apps/vscode-e2e
-    - The test command is: npm run test:run
-    - To run specific tests use environment variable: TEST_FILE="filename.test" npm run test:run
-    - Example: cd apps/vscode-e2e && TEST_FILE="apply-diff.test" npm run test:run
-    - Never use npm test directly as it doesn't exist
-    - Always check available scripts with npm run if unsure
-    - Run tests incrementally during development to catch issues early
-  </test_execution>
-
-  <code_organization>
-    - Never write a test file with a single write_to_file tool call
-    - Always implement tests in parts: structure first, then individual test cases
-    - Group related tests in the same suite
-    - Use consistent naming conventions for test files and functions
-    - Separate test utilities into their own files when they become substantial
-    - Follow the existing project structure and conventions
-  </code_organization>
-</best_practices>

.roo/rules-integration-tester/4_common_mistakes.xml

@@ -1,109 +0,0 @@
-<common_mistakes_to_avoid>
-  <test_structure_mistakes>
-    - Writing a test file with a single write_to_file tool call instead of implementing in parts
-    - Not using proper Mocha TDD structure with suite() and test() blocks
-    - Forgetting to implement suiteSetup() and suiteTeardown() for proper cleanup
-    - Creating tests that depend on each other or specific execution order
-    - Not cleaning up tasks and files after test completion
-    - Using describe/it blocks instead of the required suite/test blocks
-  </test_structure_mistakes>
-
-  <api_interaction_mistakes>
-    - Not using the global api object for extension interactions
-    - Forgetting to set auto-approval settings (alwaysAllowWrite, alwaysAllowExecute) when testing functionality that requires user approval
-    - Not implementing proper async/await patterns with waitFor utilities
-    - Using incorrect timeout values that are too short for actual task execution
-    - Not properly cleaning up tasks with cancelCurrentTask or clearCurrentTask
-    - Assuming the AI will use specific tools instead of testing outcomes
-  </api_interaction_mistakes>
-
-  <file_system_mistakes>
-    - Assuming files will be created in the expected location without checking multiple paths
-    - Not accounting for the workspace directory being created by runTest.ts
-    - Creating test files in temporary directories instead of the VSCode workspace directory
-    - Not verifying files exist after creation during setup
-    - Forgetting that the AI may not see files in the workspace directory
-    - Not using flexible file location checking that searches workspace directories
-  </file_system_mistakes>
-
-  <event_handling_mistakes>
-    - Relying on parsing AI messages to detect tool usage instead of using proper event listeners
-    - Expecting tool results in "tool_result" message type (which doesn't exist)
-    - Not listening to terminal shell execution events for command tracking
-    - Depending on specific message formats that may vary
-    - Not implementing proper event cleanup after tests
-    - Parsing complex AI conversation messages instead of focusing on outcomes
-  </event_handling_mistakes>
-
-  <test_execution_mistakes>
-    - Using npm test instead of npm run test:run
-    - Not using the correct working directory (apps/vscode-e2e)
-    - Running tests from the wrong directory
-    - Not checking available scripts with npm run when unsure
-    - Forgetting to use TEST_FILE environment variable for specific tests
-    - Not running tests incrementally during development
-  </test_execution_mistakes>
-
-  <debugging_mistakes>
-    - Not adding sufficient logging to track test execution flow
-    - Not logging important events like task IDs, file paths, and AI responses
-    - Not using codebase_search to find similar test patterns before writing new tests
-    - Not checking test output carefully for error messages and stack traces
-    - Not validating test state at critical points
-    - Assuming test failures are due to code issues without checking test logic
-  </debugging_mistakes>
-
-  <ai_interaction_mistakes>
-    - Using complex instructions that may confuse the AI
-    - Expecting the AI to use exact tools specified in prompts
-    - Not allowing for variations in how the AI accomplishes tasks
-    - Testing implementation details instead of outcomes
-    - Not adapting tests based on actual AI behavior
-    - Forgetting to tell the AI to assume files exist in the workspace directory
-  </ai_interaction_mistakes>
-
-  <reliability_mistakes>
-    - Adding unnecessary waits for specific tool executions
-    - Using complex message parsing logic that depends on AI behavior
-    - Not using the simplest possible test structure
-    - Depending on specific AI message formats
-    - Not using terminal events for reliable command execution verification
-    - Making tests too brittle by depending on exact AI responses
-  </reliability_mistakes>
-
-  <workspace_mistakes>
-    - Not understanding that files may be created in /tmp/roo-test-workspace-* directories
-    - Assuming the AI can see files in the workspace directory
-    - Not checking multiple possible file locations when verifying creation
-    - Creating files outside the VSCode workspace during tests
-    - Not properly setting up the test workspace in suiteSetup()
-    - Forgetting to clean up workspace files in suiteTeardown()
-  </workspace_mistakes>
-
-  <message_handling_mistakes>
-    - Expecting specific message types for tool execution results
-    - Not understanding that ClineMessage types have specific values
-    - Trying to parse tool execution from AI conversation messages
-    - Not checking packages/types/src/message.ts for valid message types
-    - Depending on message parsing instead of outcome verification
-    - Not using api_req_started messages to verify tool execution
-  </message_handling_mistakes>
-
-  <timeout_and_timing_mistakes>
-    - Using timeouts that are too short for actual task execution
-    - Not accounting for AI processing time in test timeouts
-    - Waiting for specific tool executions instead of task completion
-    - Not implementing proper retry logic for flaky operations
-    - Using fixed delays instead of condition-based waiting
-    - Not considering that some operations may take longer in CI environments
-  </timeout_and_timing_mistakes>
-
-  <test_data_mistakes>
-    - Not creating test files in the correct workspace directory
-    - Using hardcoded paths that don't work across different environments
-    - Not storing file paths in test-scoped objects for easy reference
-    - Creating test data that conflicts with other tests
-    - Not cleaning up test data properly after tests complete
-    - Using test data that's too complex for the AI to handle reliably
-  </test_data_mistakes>
-</common_mistakes_to_avoid>

.roo/rules-integration-tester/5_test_environment.xml

@@ -1,209 +0,0 @@
-<test_environment_and_tools>
-  <test_framework>
-    <description>VSCode E2E testing framework using Mocha and VSCode Test</description>
-    <key_components>
-      - Mocha TDD framework for test structure
-      - VSCode Test framework for extension testing
-      - Custom test utilities and helpers
-      - Event-driven testing patterns
-      - Workspace-based test execution
-    </key_components>
-  </test_framework>
-
-  <directory_structure>
-    <test_files_location>apps/vscode-e2e/src/suite/</test_files_location>
-    <test_utilities>apps/vscode-e2e/src/utils/</test_utilities>
-    <test_runner>apps/vscode-e2e/src/runTest.ts</test_runner>
-    <package_config>apps/vscode-e2e/package.json</package_config>
-    <type_definitions>packages/types/</type_definitions>
-  </directory_structure>
-
-  <test_execution_commands>
-    <working_directory>apps/vscode-e2e</working_directory>
-    <commands>
-      <run_all_tests>npm run test:run</run_all_tests>
-      <run_specific_test>TEST_FILE="filename.test" npm run test:run</run_specific_test>
-      <example>cd apps/vscode-e2e && TEST_FILE="apply-diff.test" npm run test:run</example>
-      <check_scripts>npm run</check_scripts>
-    </commands>
-    <important_notes>
-      - Never use npm test directly as it doesn't exist
-      - Always use the correct working directory
-      - Use TEST_FILE environment variable for specific tests
-      - Check available scripts with npm run if unsure
-    </important_notes>
-  </test_execution_commands>
-
-  <api_object>
-    <description>Global api object for extension interactions</description>
-    <key_methods>
-      <task_management>
-        - api.startTask(prompt: string): Start a new task
-        - api.cancelCurrentTask(): Cancel the current task
-        - api.clearCurrentTask(): Clear the current task
-        - api.abortTask(): Abort the current task
-        - api.getTaskStatus(): Get current task status
-      </task_management>
-      <event_listeners>
-        - api.onDidReceiveMessage(callback): Listen to messages
-        - api.onTaskCompleted(callback): Listen to task completion
-        - api.onTaskAborted(callback): Listen to task abortion
-        - api.onTaskStarted(callback): Listen to task start
-        - api.onDidStartTerminalShellExecution(callback): Terminal start events
-        - api.onDidEndTerminalShellExecution(callback): Terminal end events
-      </event_listeners>
-      <settings>
-        - api.updateSettings(settings): Update extension settings
-        - api.getSettings(): Get current settings
-      </settings>
-    </key_methods>
-  </api_object>
-
-  <test_utilities>
-    <wait_functions>
-      <waitFor>
-        <description>Wait for a condition to be true</description>
-        <usage>await waitFor(() => condition, timeout)</usage>
-        <example>await waitFor(() => fs.existsSync(filePath), 5000)</example>
-      </waitFor>
-      <waitUntilCompleted>
-        <description>Wait until current task is completed</description>
-        <usage>await waitUntilCompleted()</usage>
-        <timeout>Default timeout for task completion</timeout>
-      </waitUntilCompleted>
-      <waitUntilAborted>
-        <description>Wait until current task is aborted</description>
-        <usage>await waitUntilAborted()</usage>
-        <timeout>Default timeout for task abortion</timeout>
-      </waitUntilAborted>
-    </wait_functions>
-    
-    <helper_patterns>
-      <file_location_helper>
-        <description>Helper to find files in multiple possible locations</description>
-        <usage>Use when files might be created in different workspace directories</usage>
-      </file_location_helper>
-      <event_collector>
-        <description>Utility to collect and analyze events during test execution</description>
-        <usage>Use for comprehensive event tracking and validation</usage>
-      </event_collector>
-      <assertion_helpers>
-        <description>Custom assertion functions for common test patterns</description>
-        <usage>Use for consistent validation across tests</usage>
-      </assertion_helpers>
-    </helper_patterns>
-  </test_utilities>
-
-  <workspace_management>
-    <workspace_creation>
-      <description>Test workspaces are created by runTest.ts</description>
-      <location>/tmp/roo-test-workspace-*</location>
-      <access>vscode.workspace.workspaceFolders![0].uri.fsPath</access>
-    </workspace_creation>
-    
-    <file_creation_strategy>
-      <setup_phase>Create all test files in suiteSetup() before any tests run</setup_phase>
-      <location>Always create files in the VSCode workspace directory</location>
-      <verification>Verify files exist after creation to catch setup issues early</verification>
-      <cleanup>Clean up all test files in suiteTeardown() to avoid test pollution</cleanup>
-      <storage>Store file paths in a test-scoped object for easy reference</storage>
-    </file_creation_strategy>
-
-    <ai_visibility>
-      <important_note>The AI will not see the files in the workspace directory</important_note>
-      <solution>Tell the AI to assume files exist and proceed as if they do</solution>
-      <verification>Always verify outcomes rather than relying on AI file visibility</verification>
-    </ai_visibility>
-  </workspace_management>
-
-  <message_types>
-    <description>Understanding message types for proper event handling</description>
-    <reference>Check packages/types/src/message.ts for valid message types</reference>
-    
-    <key_message_types>
-      <api_req_started>
-        <type>say</type>
-        <say>api_req_started</say>
-        <description>Indicates tool execution started</description>
-        <text_content>JSON with tool name and execution details</text_content>
-        <usage>Most reliable way to verify tool execution</usage>
-      </api_req_started>
-      
-      <completion_result>
-        <description>Contains tool execution results</description>
-        <usage>Tool results appear here, not in "tool_result" type</usage>
-      </completion_result>
-      
-      <text_messages>
-        <description>General AI conversation messages</description>
-        <caution>Format may vary, don't rely on parsing these for tool detection</caution>
-      </text_messages>
-    </key_message_types>
-  </message_types>
-
-  <auto_approval_settings>
-    <description>Settings to enable automatic approval of AI actions</description>
-    <critical_settings>
-      <alwaysAllowWrite>Enable for file creation/modification tests</alwaysAllowWrite>
-      <alwaysAllowExecute>Enable for command execution tests</alwaysAllowExecute>
-      <alwaysAllowBrowser>Enable for browser-related tests</alwaysAllowBrowser>
-    </critical_settings>
-    <usage>
-      ```typescript
-      await api.updateSettings({
-        alwaysAllowWrite: true,
-        alwaysAllowExecute: true
-      });
-      ```
-    </usage>
-    <importance>Without proper auto-approval settings, the AI won't be able to perform actions without user approval</importance>
-  </auto_approval_settings>
-
-  <debugging_tools>
-    <console_logging>
-      <description>Use console.log for tracking test execution flow</description>
-      <best_practices>
-        - Log test phase transitions
-        - Log important events and data
-        - Log file paths and workspace state
-        - Log expected vs actual outcomes
-      </best_practices>
-    </console_logging>
-    
-    <state_validation>
-      <description>Helper functions to validate test state at critical points</description>
-      <includes>
-        - Workspace file listing
-        - Current working directory
-        - Task status
-        - Event counts
-      </includes>
-    </state_validation>
-    
-    <error_analysis>
-      <description>Tools for analyzing test failures</description>
-      <techniques>
-        - Stack trace analysis
-        - Event timeline reconstruction
-        - File system state comparison
-        - Message flow analysis
-      </techniques>
-    </error_analysis>
-  </debugging_tools>
-
-  <performance_considerations>
-    <timeouts>
-      <description>Appropriate timeout values for different operations</description>
-      <task_completion>Use generous timeouts for task completion (30+ seconds)</task_completion>
-      <file_operations>Shorter timeouts for file system operations (5-10 seconds)</file_operations>
-      <event_waiting>Medium timeouts for event waiting (10-15 seconds)</event_waiting>
-    </timeouts>
-    
-    <resource_management>
-      <description>Proper cleanup to avoid resource leaks</description>
-      <event_listeners>Always clean up event listeners after tests</event_listeners>
-      <tasks>Cancel or clear tasks in teardown</tasks>
-      <files>Remove test files to avoid disk space issues</files>
-    </resource_management>
-  </performance_considerations>
-</test_environment_and_tools>

.roo/rules-issue-fixer-orchestrator/10_pr_template_format.xml

@@ -1,213 +0,0 @@
-<pr_template_format>
-  <overview>
-    This document defines the format for PR messages that are saved to the temp folder
-    before creating a pull request. The PR message is saved in two formats:
-    1. JSON format in pr_summary.json (for programmatic use)
-    2. Markdown format in pr_message.md (for manual PR creation)
-    
-    The PR message must follow the exact Roo Code contribution template.
-  </overview>
-
-  <json_format>
-    <description>
-      The pr_summary.json file contains the PR title and body in a structured format
-      that can be easily parsed by scripts and the GitHub CLI.
-    </description>
-    <structure>
-      {
-        "title": "fix: [description] (#[issue-number])",
-        "body": "[Full markdown body as described below]",
-        "issue_number": 123,
-        "repo_owner": "owner",
-        "repo_name": "repo",
-        "base_branch": "main",
-        "head_branch": "fix/issue-123-description"
-      }
-    </structure>
-  </json_format>
-
-  <markdown_format>
-    <description>
-      The pr_message.md file contains the complete PR message in a format that can be
-      directly copied and pasted when creating a PR manually.
-    </description>
-    <structure>
-      PR Title: [title from JSON]
-      
-      ---
-      
-      [Full PR body from JSON]
-    </structure>
-  </markdown_format>
-
-  <pr_body_template>
-    <description>
-      The PR body must follow this exact Roo Code PR template with all required sections.
-    </description>
-    <template><![CDATA[
-<!--
-Thank you for contributing to Roo Code!
-
-Before submitting your PR, please ensure:
-- It's linked to an approved GitHub Issue.
-- You've reviewed our [Contributing Guidelines](../CONTRIBUTING.md).
--->
-
-### Related GitHub Issue
-
-<!-- Every PR MUST be linked to an approved issue. -->
-
-Closes: #[ISSUE_NUMBER] <!-- Replace with the issue number, e.g., Closes: #123 -->
-
-### Roo Code Task Context (Optional)
-
-<!--
-If you used Roo Code to help create this PR, you can share public task links here.
-This helps reviewers understand your development process and provides additional context.
-Example: https://app.roocode.com/share/task-id
--->
-
-[TASK_CONTEXT]
-
-### Description
-
-<!--
-Briefly summarize the changes in this PR and how they address the linked issue.
-The issue should cover the "what" and "why"; this section should focus on:
-- The "how": key implementation details, design choices, or trade-offs made.
-- Anything specific reviewers should pay attention to in this PR.
--->
-
-[DESCRIPTION_CONTENT]
-
-### Test Procedure
-
-<!--
-Detail the steps to test your changes. This helps reviewers verify your work.
-- How did you test this specific implementation? (e.g., unit tests, manual testing steps)
-- How can reviewers reproduce your tests or verify the fix/feature?
-- Include relevant testing environment details if applicable.
--->
-
-[TEST_PROCEDURE_CONTENT]
-
-### Pre-Submission Checklist
-
-<!-- Go through this checklist before marking your PR as ready for review. -->
-
-- [x] **Issue Linked**: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
-- [x] **Scope**: My changes are focused on the linked issue (one major feature/fix per PR).
-- [x] **Self-Review**: I have performed a thorough self-review of my code.
-- [x] **Testing**: New and/or updated tests have been added to cover my changes (if applicable).
-- [x] **Documentation Impact**: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
-- [x] **Contribution Guidelines**: I have read and agree to the [Contributor Guidelines](/CONTRIBUTING.md).
-
-### Screenshots / Videos
-
-<!--
-For UI changes, please provide before-and-after screenshots or a short video of the *actual results*.
-This greatly helps in understanding the visual impact of your changes.
--->
-
-[SCREENSHOTS_CONTENT]
-
-### Documentation Updates
-
-<!--
-Does this PR necessitate updates to user-facing documentation?
-- [ ] No documentation updates are required.
-- [ ] Yes, documentation updates are required. (Please describe what needs to be updated or link to a PR in the docs repository).
--->
-
-[DOCUMENTATION_UPDATES_CONTENT]
-
-### Additional Notes
-
-<!-- Add any other context, questions, or information for reviewers here. -->
-
-[ADDITIONAL_NOTES_CONTENT]
-
-### Get in Touch
-
-<!--
-Please provide your Discord username for reviewers or maintainers to reach you if they have questions about your PR
--->
-
-[DISCORD_USERNAME]
-    ]]></template>
-  </pr_body_template>
-
-  <template_placeholders>
-    <placeholder name="[ISSUE_NUMBER]">The GitHub issue number being fixed</placeholder>
-    <placeholder name="[TASK_CONTEXT]">Optional Roo Code task links (remove section if not applicable)</placeholder>
-    <placeholder name="[DESCRIPTION_CONTENT]">
-      Summary of changes and implementation details. Should include:
-      - Key implementation details
-      - Design choices or trade-offs made
-      - Specific areas reviewers should focus on
-    </placeholder>
-    <placeholder name="[TEST_PROCEDURE_CONTENT]">
-      Detailed testing steps including:
-      - Unit tests added/modified
-      - Manual testing steps performed
-      - How reviewers can reproduce tests
-      - Testing environment details
-    </placeholder>
-    <placeholder name="[SCREENSHOTS_CONTENT]">
-      For UI changes: before/after screenshots or video
-      For non-UI changes: "N/A - No UI changes"
-    </placeholder>
-    <placeholder name="[DOCUMENTATION_UPDATES_CONTENT]">
-      Check appropriate box:
-      - "- [x] No documentation updates are required." OR
-      - "- [x] Yes, documentation updates are required. [describe updates]"
-    </placeholder>
-    <placeholder name="[ADDITIONAL_NOTES_CONTENT]">
-      Any additional context, or remove entire section if not needed
-    </placeholder>
-    <placeholder name="[DISCORD_USERNAME]">User's Discord username for contact</placeholder>
-  </template_placeholders>
-
-  <file_locations>
-    <file>
-      <name>pr_summary.json</name>
-      <path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json</path>
-      <purpose>Structured data for programmatic PR creation</purpose>
-    </file>
-    <file>
-      <name>pr_message.md</name>
-      <path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md</path>
-      <purpose>Human-readable format for manual PR creation</purpose>
-    </file>
-  </file_locations>
-
-  <usage_guidelines>
-    <guideline>
-      Always save both formats when preparing a PR to give users flexibility
-      in how they create the pull request.
-    </guideline>
-    <guideline>
-      The pr_message.md file should be self-contained and ready to copy/paste
-      without any additional formatting needed.
-    </guideline>
-    <guideline>
-      Include all sections in the template, maintaining the exact format
-      and HTML comments as shown.
-    </guideline>
-    <guideline>
-      Pre-check all checklist items that can be verified programmatically.
-      Leave documentation checkbox unchecked for user to decide.
-    </guideline>
-    <guideline>
-      For sections that don't apply, use appropriate placeholder text
-      rather than removing the section entirely.
-    </guideline>
-  </usage_guidelines>
-
-  <translation_handling>
-    <note>
-      If translations were added during the issue fix, include details in the
-      Description section about which languages were updated.
-    </note>
-  </translation_handling>
-</pr_template_format>

.roo/rules-issue-fixer-orchestrator/1_Workflow.xml

@@ -1,874 +0,0 @@
-<workflow>
-  <step number="1">
-    <name>Initialize Task Context</name>
-    <instructions>
-      The user will provide a GitHub issue URL.
-      
-      1.  **Parse URL**: Extract the `owner`, `repo`, and `issue_number`.
-      2.  **Create Task Directory**: Create a dedicated directory to store all context for this task. Use a unique identifier for the directory name, like the task ID. For example: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/`.
-          <execute_command>
-          <command>mkdir -p .roo/temp/issue-fixer-orchestrator/[TASK_ID]</command>
-          </execute_command>
-      3.  **Retrieve Issue Details**: Fetch the issue details and its comments as a single JSON object.
-          <execute_command>
-          <command>gh issue view [issue_number] --repo [owner]/[repo] --json number,title,body,state,labels,assignees,milestone,createdAt,updatedAt,closedAt,author,comments > .roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json</command>
-          </execute_command>
-      4.  **Handle Auth Errors**: If the `gh` command fails with an authentication error, prompt the user to log in.
-          <ask_followup_question>
-          <question>GitHub CLI is not authenticated. Please run 'gh auth login' in your terminal, then let me know when you're ready to continue.</question>
-          <follow_up>
-            <suggest>I've authenticated, please continue</suggest>
-          </follow_up>
-          </ask_followup_question>
-      5.  **Confirm Context**: Inform the user that the context has been saved.
-    </instructions>
-  </step>
-
-  <step number="2">
-    <name>Delegate: Analyze Requirements & Explore Codebase</name>
-    <instructions>
-      Launch a subtask in `architect` mode to perform a detailed analysis of the issue and the codebase. The subtask will be responsible for identifying affected files and creating an implementation plan.
-
-      The context file `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json` will be the input for this subtask. The subtask should write its findings (the implementation plan) to a new file: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md`.
-
-      <new_task>
-        <mode>architect</mode>
-        <message>
-          **Task: Analyze Issue and Create Implementation Plan**
-
-          You are an expert software architect. Your task is to analyze the provided GitHub issue and the current codebase to create a detailed implementation plan with a focus on understanding component interactions and dependencies.
-
-          1.  **Read Issue Context**: The full issue details and comments are in `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json`. Read this file to understand all requirements, acceptance criteria, and technical discussions.
-
-          2.  **Perform Architectural Analysis**:
-              - **Map Component Interactions**: Trace the complete data flow from entry points to outputs
-              - **Identify Paired Operations**: For any operation (e.g., export), find its counterpart (e.g., import)
-              - **Find Similar Patterns**: Search for existing implementations of similar features
-              - **Analyze Dependencies**: Identify all consumers of the functionality being modified
-              - **Assess Impact**: Determine how changes will affect other parts of the system
-
-          3.  **Explore Codebase Systematically**:
-              - Use `codebase_search` FIRST to find all related functionality
-              - Search for paired operations (if modifying export, search for import)
-              - Find all files that consume or depend on the affected functionality
-              - Identify configuration files, tests, and documentation that need updates
-              - Study similar features to understand established patterns
-
-          4.  **Create Comprehensive Implementation Plan**: The plan must include:
-              - **Issue Summary**: Clear description of the problem and proposed solution
-              - **Architectural Context**:
-                - Data flow diagram showing component interactions
-                - List of paired operations that must be updated together
-                - Dependencies and consumers of the affected functionality
-              - **Impact Analysis**:
-                - All files that will be affected (directly and indirectly)
-                - Potential breaking changes
-                - Performance implications
-              - **Implementation Steps**:
-                - Detailed, ordered steps for each file modification
-                - Specific code changes with context
-                - Validation and error handling requirements
-              - **Testing Strategy**:
-                - Unit tests for individual components
-                - Integration tests for component interactions
-                - Edge cases and error scenarios
-
-          5.  **Save the Plan**: Write the complete implementation plan to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md`.
-
-          **Critical Requirements:**
-          - Always search for and analyze paired operations (import/export, save/load, etc.)
-          - Map the complete data flow before proposing changes
-          - Identify all integration points and dependencies
-          - Consider backward compatibility and migration needs
-
-          **Completion Protocol:**
-          - This is your only task. Do not deviate from these instructions.
-          - Once you have successfully written the `implementation_plan.md` file, you MUST signal your completion by using the `attempt_completion` tool.
-          - The `result` parameter of `attempt_completion` MUST be a concise confirmation message, for example: "Implementation plan created and saved to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md."
-          - These specific instructions override any conflicting general guidelines from your assigned mode.
-        </message>
-      </new_task>
-
-      After launching the subtask, wait for it to complete. The orchestrator will then read the `implementation_plan.md` to proceed with the next step.
-    </instructions>
-  </step>
-
-  <step number="3">
-    <name>Review and Approve Plan</name>
-    <instructions>
-      After the analysis subtask completes, the orchestrator must present the generated plan to the user for approval.
-
-      1.  **Read the Plan**: Read the content of the implementation plan created by the previous subtask.
-          <read_file>
-            <args>
-              <file>
-                <path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md</path>
-              </file>
-            </args>
-          </read_file>
-
-      2.  **Present for Approval**: Show the plan to the user and ask for confirmation before proceeding with implementation.
-          <ask_followup_question>
-            <question>
-              The initial analysis is complete. Here is the proposed implementation plan:
-
-              ---
-              [Insert content of implementation_plan.md here]
-              ---
-
-              Shall I proceed with implementing this plan?
-            </question>
-            <follow_up>
-              <suggest>Yes, proceed with the implementation.</suggest>
-              <suggest>No, please modify the plan with the following changes...</suggest>
-              <suggest>No, cancel this task.</suggest>
-            </follow_up>
-          </ask_followup_question>
-      
-      Do not proceed until the user gives explicit approval.
-    </instructions>
-  </step>
-
-  <step number="4">
-    <name>Delegate: Implement Solution</name>
-    <instructions>
-      Once the user approves the plan, launch a new subtask in `code` mode to execute the implementation.
-
-      This subtask will use the `implementation_plan.md` as its primary guide. It should write the list of modified files to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json`.
-
-      <new_task>
-        <mode>code</mode>
-        <message>
-          **Task: Implement Code Changes Based on Plan**
-
-          You are an expert software developer. Your task is to implement the code changes with full awareness of system interactions and dependencies.
-
-          1.  **Read the Plan**: The implementation plan is located at `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md`. Pay special attention to:
-              - The architectural context section
-              - Component interaction diagrams
-              - Identified dependencies and related operations
-              - Impact analysis
-
-          2.  **Validate Understanding**: Before coding, ensure you understand:
-              - How data flows through the system
-              - All related operations that must be updated together
-              - Dependencies that could be affected
-              - Integration points with other components
-
-          3.  **Implement Holistically**:
-              - **Update Related Operations Together**: If modifying one operation, update all related operations
-              - **Maintain Consistency**: Ensure data structures, validation, and error handling are consistent
-              - **Consider Side Effects**: Account for how changes propagate through the system
-              - **Follow Existing Patterns**: Use established patterns from similar features
-
-          4.  **Implement Tests**:
-              - Write tests that verify component interactions
-              - Test related operations together
-              - Include edge cases and error scenarios
-              - Verify data consistency across operations
-
-          5.  **Track Modified Files**: As you modify or create files, keep a running list.
-
-          6.  **Save Modified Files List**: After all changes are implemented and tested, save the list of all file paths you created or modified to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json`. The format should be a JSON array of strings.
-              Example: `["src/components/NewFeature.tsx", "src/__tests__/NewFeature.spec.ts"]`
-
-          **Critical Reminders:**
-          - Never implement changes in isolation - consider the full system impact
-          - Always update related operations together to maintain consistency
-          - Test component interactions, not just individual functions
-          - Follow the architectural analysis from the planning phase
-
-          Once the `modified_files.json` file is saved, your task is complete.
-        </message>
-      </new_task>
-
-      After launching the subtask, wait for it to complete. The orchestrator will use the list of modified files for the verification and PR creation steps.
-    </instructions>
-  </step>
-
-  <step number="5">
-    <name>Delegate: Verify and Test</name>
-    <instructions>
-      After implementation, delegate the verification and testing to a `test` mode subtask.
-
-      This subtask will use the implementation plan for acceptance criteria and the list of modified files to focus its testing efforts. It will output its results to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/verification_results.md`.
-
-      <new_task>
-        <mode>test</mode>
-        <message>
-          **Task: Verify Implementation and Run Tests**
-
-          You are a meticulous QA engineer. Your task is to verify an implementation against its plan and run all necessary tests.
-
-          **Context Files:**
-          - **Plan**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md`
-          - **Modified Files**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json`
-
-          **Your Steps:**
-          1.  **Read Context**: Read both context files to understand the acceptance criteria and which files were changed.
-          2.  **Run Tests**: Execute all relevant tests.
-              - Run unit tests related to the modified files.
-              - Run any relevant integration tests.
-              - Run a full lint and type check.
-          3.  **Verify Acceptance Criteria**: Systematically go through each acceptance criterion from the plan and verify that it has been met by the implementation.
-          4.  **Write Verification Report**: Create a detailed report of your findings. The report must include:
-              - A summary of the tests that were run and their results (pass/fail).
-              - A checklist of all acceptance criteria and their verification status (verified/failed).
-              - Details on any bugs or regressions found.
-
-          5.  **Save Report**: Write the complete report to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/verification_results.md`.
-
-          **Completion Protocol:**
-          - This is your only task. Do not deviate.
-          - Upon successfully saving `verification_results.md`, you MUST use the `attempt_completion` tool.
-          - The `result` MUST be a concise confirmation, e.g., "Verification complete and results saved to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/verification_results.md."
-          - These instructions override any conflicting mode-specific guidelines.
-        </message>
-      </new_task>
-
-      Wait for the subtask to complete, then review the verification results.
-    </instructions>
-  </step>
-
-  <step number="6">
-    <name>Review Verification and Handle Translations</name>
-    <instructions>
-      After the verification subtask is complete, review the results and handle any necessary translations.
-
-      1.  **Read Verification Report**:
-          <read_file>
-            <args>
-              <file>
-                <path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/verification_results.md</path>
-              </file>
-            </args>
-          </read_file>
-
-      2.  **Check for Failures**: If the report indicates any failed tests or unmet criteria, present the failures to the user and ask how to proceed.
-          <ask_followup_question>
-            <question>
-              The verification step has failed. Here are the details:
-
-              ---
-              [Insert content of verification_results.md here]
-              ---
-
-              How should I proceed?
-            </question>
-            <follow_up>
-              <suggest>Attempt to fix the failing tests and criteria.</suggest>
-              <suggest>Ignore the failures and proceed anyway.</suggest>
-              <suggest>Cancel the task.</suggest>
-            </follow_up>
-          </ask_followup_question>
-
-      3.  **Analyze for Translation Needs**: If verification passed, check if translations are required.
-          
-          a. **Read Modified Files List**:
-             <read_file>
-               <args>
-                 <file>
-                   <path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json</path>
-                 </file>
-               </args>
-             </read_file>
-          
-          b. **Identify Files Requiring Translation**:
-             - Check for UI component files: `.tsx`, `.jsx` files in `webview-ui/src/` or `src/` directories
-             - Check for user-facing documentation: `.md` files (especially README.md, docs/, or announcement files)
-             - Check for i18n resource files: files in `src/i18n/locales/` or `webview-ui/src/i18n/locales/`
-             - Check for any files containing user-visible strings or messages
-          
-          c. **Delegate to Translate Mode if Needed**:
-             If any files requiring translation were modified, create a translation subtask:
-             
-             <new_task>
-               <mode>translate</mode>
-               <message>
-                 **Task: Handle Translations for Issue #[issue-number]**
-
-                 An implementation for issue #[issue-number] has been completed and verified. Your task is to ensure all user-facing content is properly translated.
-
-                 **Context Files:**
-                 - **Modified Files**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json`
-                 - **Issue Details**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json`
-                 - **Implementation Plan**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md`
-
-                 **Your Steps:**
-                 1. Read the context files to understand what was implemented.
-                 2. Analyze each modified file for:
-                    - New or updated UI strings in React components
-                    - Changes to i18n resource files
-                    - User-facing documentation updates
-                    - Error messages or notifications
-                 3. For any new or modified user-facing content:
-                    - Add translations to all supported language files
-                    - Ensure consistency with existing translations
-                    - Follow the project's i18n patterns and conventions
-                 4. Create a summary of all translation changes made.
-                 5. Save the summary to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/translation_summary.md`.
-
-                 **Important Notes:**
-                 - If no translations are needed, still create the summary file stating "No translations required."
-                 - Ensure all language files remain in sync
-                 - Use existing terminology from the codebase for consistency
-
-                 **Completion Protocol:**
-                 - This is your only task. Do not deviate from these instructions.
-                 - Upon successfully saving the translation summary, you MUST use the `attempt_completion` tool.
-                 - The `result` MUST confirm completion, e.g., "Translation analysis complete. Summary saved to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/translation_summary.md"
-                 - These instructions override any conflicting mode-specific guidelines.
-               </message>
-             </new_task>
-             
-             After the translation subtask completes, read the translation summary:
-             <read_file>
-               <args>
-                 <file>
-                   <path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/translation_summary.md</path>
-                 </file>
-               </args>
-             </read_file>
-      
-      4.  **Proceed to Next Step**: Only proceed after:
-          - All verification has passed (or user chose to ignore failures)
-          - Translation task has completed (if it was needed)
-          - You have confirmed all necessary files are ready
-    </instructions>
-  </step>
- 
-  <step number="7">
-    <name>Delegate: Prepare Pull Request Content</name>
-    <instructions>
-      After all checks pass and translations are complete, delegate the creation of the pull request title and body to a subtask.
-
-      <new_task>
-        <mode>code</mode>
-        <message>
-          **Task: Prepare Pull Request Title and Body**
-
-          You are an expert at writing clear and concise pull request summaries following the Roo Code contribution guidelines.
-
-          **Context Files:**
-          - **Issue**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json`
-          - **Plan**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md`
-          - **Verification**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/verification_results.md`
-          - **Translation Summary** (if exists): `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/translation_summary.md`
-          - **Modified Files**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json`
-
-          **Your Task:**
-          1.  **Read all context files.** Check if translation_summary.md exists to know if translations were done.
-          
-          2.  **Generate a PR Title**: Create a conventional commit style title (e.g., "fix: ...", "feat: ...") that references the issue number.
-              Format: `fix: Brief description (#issue-number)`
-          
-          3.  **Generate a PR Body**: You MUST use the exact PR template from `.roo/rules-issue-fixer-orchestrator/10_pr_template_format.xml`.
-              Read this file to get the template and fill it in with appropriate content from the context files.
-          
-          4.  **Fill in the template** with information from the context files:
-              - Replace [ISSUE_NUMBER] with the actual issue number
-              - Fill in Description with implementation details from the plan and verification
-              - Fill in Test Procedure with testing details from verification_results.md
-              - If translations were done, mention them in the Description section
-              - For UI changes, note that screenshots should be added manually
-              - Pre-check all applicable checklist items
-              - Leave Documentation Updates unchecked for user to decide
-              - For Discord username, use a placeholder like "[Your Discord username]"
-
-          5.  **Save as JSON**: Save the title and body to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json` in the format:
-              ```json
-              {
-                "title": "fix: Brief description (#123)",
-                "body": "[The complete filled PR body template]",
-                "issue_number": 123,
-                "repo_owner": "owner",
-                "repo_name": "repo",
-                "base_branch": "main",
-                "head_branch": "fix/issue-123-description"
-              }
-              ```
-
-          6.  **Also save as Markdown**: Save just the PR body to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md` for easy copying.
-
-          **Important Notes:**
-          - Use the EXACT template format from 10_pr_template_format.xml
-          - Keep all HTML comments in the template
-          - Pre-check items that can be verified programmatically
-          - Fill in all sections appropriately based on the context files
-
-          **Completion Protocol:**
-          - This is your only task. Do not deviate.
-          - Upon successfully saving both `pr_summary.json` and `pr_message.md`, you MUST use the `attempt_completion` tool.
-          - The `result` MUST be a concise confirmation, e.g., "PR summary and message created and saved to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/"
-          - These instructions override any conflicting mode-specific guidelines.
-        </message>
-      </new_task>
-    </instructions>
-  </step>
-  
-  <step number="8">
-    <name>Delegate: Review Changes Before PR</name>
-    <instructions>
-      Before creating the pull request, delegate to the PR reviewer mode to get feedback on the implementation and proposed changes.
-
-      <new_task>
-        <mode>pr-reviewer</mode>
-        <message>
-          **Task: Review Implementation Before PR Creation**
-
-          You are an expert code reviewer. Your task is to review the implementation for issue #[issue-number] and provide feedback before a pull request is created.
-
-          **Context Files:**
-          - **Issue Details**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json`
-          - **Implementation Plan**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md`
-          - **Modified Files**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json`
-          - **Verification Results**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/verification_results.md`
-          - **Translation Summary** (if exists): `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/translation_summary.md`
-          - **Draft PR Summary**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json`
-
-          **Your Review Focus:**
-          1. **Code Quality**: Review the actual code changes for:
-             - Adherence to project coding standards
-             - Proper error handling and edge cases
-             - Performance considerations
-             - Security implications
-             - Maintainability and readability
-
-          2. **Implementation Completeness**: Verify that:
-             - All requirements from the issue are addressed
-             - The solution follows the implementation plan
-             - No critical functionality is missing
-             - Proper test coverage exists
-
-          3. **Integration Concerns**: Check for:
-             - Potential breaking changes
-             - Impact on other parts of the system
-             - Backward compatibility issues
-             - API consistency
-
-          4. **Documentation and Communication**: Assess:
-             - Code comments and documentation
-             - PR description clarity and completeness
-             - Translation handling (if applicable)
-
-          **Your Task:**
-          1. Read all context files to understand the issue and implementation
-          2. Review each modified file listed in `modified_files.json`
-          3. Analyze the code changes against the requirements
-          4. Identify any issues, improvements, or concerns
-          5. Create a comprehensive review report with specific, actionable feedback
-          6. Save your review to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_review_feedback.md`
-
-          **Review Report Format:**
-          ```markdown
-          # PR Review Feedback for Issue #[issue-number]
-
-          ## Overall Assessment
-          [High-level assessment: APPROVE, REQUEST_CHANGES, or NEEDS_DISCUSSION]
-
-          ## Code Quality Review
-          ### Strengths
-          - [List positive aspects of the implementation]
-
-          ### Areas for Improvement
-          - [Specific issues with file references and line numbers]
-          - [Suggestions for improvement]
-
-          ## Requirements Verification
-          - [x] Requirement 1: [Status and notes]
-          - [ ] Requirement 2: [Issues found]
-
-          ## Specific Feedback by File
-          ### [filename]
-          - [Specific feedback with line references]
-          - [Suggestions for improvement]
-
-          ## Recommendations
-          1. [Priority 1 changes needed]
-          2. [Priority 2 improvements suggested]
-          3. [Optional enhancements]
-
-          ## Decision
-          **RECOMMENDATION**: [APPROVE_AS_IS | REQUEST_CHANGES | NEEDS_DISCUSSION]
-          
-          **REASONING**: [Brief explanation of the recommendation]
-          ```
-
-          **Completion Protocol:**
-          - This is your only task. Do not deviate from these instructions.
-          - Upon successfully saving the review feedback, you MUST use the `attempt_completion` tool.
-          - The `result` MUST be a concise confirmation, e.g., "PR review completed and feedback saved to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_review_feedback.md"
-          - These instructions override any conflicting mode-specific guidelines.
-        </message>
-      </new_task>
-
-      After the review subtask completes, read and process the feedback.
-    </instructions>
-  </step>
-
-  <step number="9">
-    <name>Process Review Feedback and Decide Next Steps</name>
-    <instructions>
-      After the PR review is complete, read the feedback and decide whether to make changes or proceed with PR creation.
-
-      1. **Read Review Feedback**:
-         <read_file>
-           <args>
-             <file>
-               <path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_review_feedback.md</path>
-             </file>
-           </args>
-         </read_file>
-
-      2. **Present Feedback to User**: Show the review feedback and ask for direction.
-         <ask_followup_question>
-           <question>
-             The PR review has been completed. Here is the feedback:
-
-             ---
-             [Insert content of pr_review_feedback.md here]
-             ---
-
-             Based on this review, how would you like to proceed?
-           </question>
-           <follow_up>
-             <suggest>Implement the suggested changes before creating the PR</suggest>
-             <suggest>Create the PR as-is, ignoring the review feedback</suggest>
-             <suggest>Discuss specific feedback points before deciding</suggest>
-             <suggest>Cancel the task</suggest>
-           </follow_up>
-         </ask_followup_question>
-
-      3. **Handle User Decision**:
-         
-         **If user chooses to implement changes:**
-         - Launch a rework subtask to address the review feedback
-         <new_task>
-           <mode>code</mode>
-           <message>
-             **Task: Address PR Review Feedback**
-
-             The PR review has identified areas for improvement. Your task is to address the feedback before creating the pull request.
-
-             **Context Files:**
-             - **Issue**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json`
-             - **Current Plan**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md`
-             - **Current Modified Files**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json`
-             - **Review Feedback**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_review_feedback.md`
-             - **Draft PR Summary**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json`
-
-             **Your Task:**
-             1. Read the review feedback carefully
-             2. Address each point raised by the reviewer
-             3. Make the necessary code changes
-             4. Update tests if needed
-             5. **Update the `modified_files.json` file** to reflect any new or changed files
-             6. **Update the `implementation_plan.md`** if the approach has changed significantly
-
-             **Important Notes:**
-             - Focus on the specific issues identified in the review
-             - Maintain the overall solution approach unless the review suggests otherwise
-             - Ensure all changes are properly tested
-             - Do not proceed with any other workflow steps
-
-             **Completion Protocol:**
-             - Upon successfully addressing the feedback and updating context files, you MUST use the `attempt_completion` tool.
-             - The `result` MUST be a concise confirmation, e.g., "Review feedback addressed and context files updated."
-           </message>
-         </new_task>
-         - **After rework completion**: Return to **Step 5** (Verify and Test) to re-verify the changes
-
-         **If user chooses to proceed as-is:**
-         - Continue to the next step (Create Pull Request)
-
-         **If user wants to discuss or cancel:**
-         - Handle accordingly based on user input
-    </instructions>
-  </step>
-
-  <step number="10">
-    <name>Prepare Branch and Review Changes</name>
-    <instructions>
-      This step prepares the branch, reviews the changes, and gets user confirmation before committing.
-
-      1. Read Issue Context and PR Summary:
-         - Read issue context from .roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json
-         - Read PR summary from .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json
-
-      2. Create Branch:
-         Extract issue number from context and create appropriate branch:
-         <execute_command>
-         <command>
-         # Extract issue number from context
-         ISSUE_NUM=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json | jq -r '.number')
-         # Determine branch type based on labels or title
-         BRANCH_NAME="fix/issue-${ISSUE_NUM}-solution"
-         git checkout -b $BRANCH_NAME
-         </command>
-         </execute_command>
-
-      3. Review Files to be Committed:
-         a. Read the modified files list:
-            <read_file>
-            <path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json</path>
-            </read_file>
-         
-         b. Check git status to ensure only intended files are staged:
-            <execute_command>
-            <command>git status --porcelain</command>
-            </execute_command>
-         
-         c. Stage only the files from modified_files.json:
-            <execute_command>
-            <command>
-            # Stage only the files we actually modified
-            cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json | jq -r '.[]' | while read file; do
-              if [ -f "$file" ]; then
-                git add "$file"
-              fi
-            done
-            # Show what will be committed
-            git status --short
-            </command>
-            </execute_command>
-
-      4. Generate and Save Merge Diff:
-         <execute_command>
-         <command>
-         # Generate diff of staged changes
-         git diff --cached > .roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes.diff
-         # Count lines in diff
-         LINE_COUNT=$(wc -l < .roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes.diff)
-         echo "Diff contains $LINE_COUNT lines"
-         
-         # If diff is too large, create a summary instead
-         if [ $LINE_COUNT -gt 2000 ]; then
-           echo "Creating summary due to large diff size..."
-           git diff --cached --stat > .roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes_summary.txt
-           git diff --cached --name-status >> .roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes_summary.txt
-           echo -e "\n\nNote: Full diff exceeds 2000 lines. Showing summary only." >> .roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes_summary.txt
-         fi
-         </command>
-         </execute_command>
-
-      5. Save PR Message to File:
-         Read the PR summary and save the formatted PR message:
-         <execute_command>
-         <command>
-         # Extract title and body from pr_summary.json
-         PR_TITLE=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json | jq -r '.title')
-         PR_BODY=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json | jq -r '.body')
-         
-         # Save PR message to file
-         echo "PR Title: $PR_TITLE" > .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md
-         echo -e "\n---\n" >> .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md
-         echo "$PR_BODY" >> .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md
-         
-         echo "PR message saved to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md"
-         </command>
-         </execute_command>
-
-      6. Present Changes for User Confirmation:
-         Read the diff (or summary) and PR message, then ask for confirmation:
-         
-         a. Read the appropriate diff file:
-            <read_file>
-            <path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes.diff</path>
-            </read_file>
-            OR (if summary exists):
-            <read_file>
-            <path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes_summary.txt</path>
-            </read_file>
-         
-         b. Read the PR message:
-            <read_file>
-            <path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md</path>
-            </read_file>
-         
-         c. Ask for user confirmation:
-            <ask_followup_question>
-            <question>
-              I've prepared the changes for commit. Here's what will be included:
-
-              **Files to be committed:**
-              [List files from modified_files.json]
-
-              **Changes summary:**
-              [Include diff or summary content]
-
-              **Proposed PR message:**
-              [Include PR message content]
-
-              How would you like to proceed?
-            </question>
-            <follow_up>
-              <suggest>Looks good, go ahead and commit the changes</suggest>
-              <suggest>I tested the changes, and something is wrong - let me explain...</suggest>
-              <suggest>I still need to test the changes manually before committing</suggest>
-              <suggest>I want to modify the PR message before proceeding</suggest>
-              <suggest>Cancel this task</suggest>
-            </follow_up>
-            </ask_followup_question>
-
-      7. Handle User Decision:
-         Based on user response:
-         
-         **If "Looks good, go ahead and commit":**
-         - Proceed to commit and push:
-           <execute_command>
-           <command>
-           # Get PR title for commit message
-           PR_TITLE=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json | jq -r '.title')
-           git commit -m "$PR_TITLE"
-           git push -u origin $(git branch --show-current)
-           </command>
-           </execute_command>
-         - Continue to next step
-         
-         **If "something is wrong":**
-         - Ask for details about the issue
-         - Launch a fix subtask in code mode to address the problems
-         - Return to Step 5 (Verify and Test) after fixes
-         
-         **If "need to test manually":**
-         - Inform user that changes are staged but not committed
-         - Provide instructions for testing
-         - Wait for user to confirm testing is complete
-         
-         **If "modify PR message":**
-         - Ask for the new PR title and body
-         - Update pr_summary.json with new content
-         - Return to step 5 of this workflow
-         
-         **If "cancel":**
-         - Clean up staged changes and branch
-         - End workflow
-    </instructions>
-  </step>
-
-  <step number="11">
-    <name>Finalize and Create PR</name>
-    <instructions>
-      After user confirmation and successful commit, finalize the process.
-
-      1. Verify Push Success:
-         <execute_command>
-         <command>
-         # Verify the branch was pushed
-         git branch -r | grep $(git branch --show-current)
-         # Get the remote URL for PR creation
-         git remote get-url origin
-         </command>
-         </execute_command>
-
-      2. Present Final PR Creation Options:
-         <ask_followup_question>
-         <question>
-           The changes have been committed and pushed to the branch. The PR message has been saved to:
-           `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md`
-
-           You can now:
-           1. Create the PR manually using the saved message
-           2. Let me create the PR automatically
-           3. Make additional changes before creating the PR
-
-           What would you like to do?
-         </question>
-         <follow_up>
-           <suggest>Create the PR automatically using the saved message</suggest>
-           <suggest>I'll create the PR manually - just show me the branch name</suggest>
-           <suggest>I want to make more changes first</suggest>
-         </follow_up>
-         </ask_followup_question>
-
-      3. Handle Final Decision:
-         
-         **If "Create PR automatically":**
-         - Read PR details and create:
-           <execute_command>
-           <command>
-           # Extract PR details
-           PR_TITLE=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json | jq -r '.title')
-           PR_BODY=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json | jq -r '.body')
-           ISSUE_NUM=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json | jq -r '.number')
-           
-           # Create PR
-           gh pr create --title "$PR_TITLE" --body "$PR_BODY" --base main
-           
-           # Get PR number and link to issue
-           PR_NUM=$(gh pr list --head $(git branch --show-current) --json number -q '.[0].number')
-           gh issue comment $ISSUE_NUM --body "PR #$PR_NUM has been created to address this issue."
-           </command>
-           </execute_command>
-         
-         **If "Create manually":**
-         - Show branch name and location of PR message:
-           <execute_command>
-           <command>
-           echo "Branch name: $(git branch --show-current)"
-           echo "PR message saved at: .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md"
-           echo "You can copy the PR message from the file above when creating the PR."
-           </command>
-           </execute_command>
-         
-         **If "Make more changes":**
-         - Inform user they can continue working on the branch
-         - Provide the task directory location for reference
-
-      4. Cleanup:
-         Ask if user wants to clean up the temporary files:
-         <ask_followup_question>
-         <question>
-           Would you like me to clean up the temporary task files now, or keep them for reference?
-         </question>
-         <follow_up>
-           <suggest>Yes, clean up the temporary files</suggest>
-           <suggest>No, keep the files for now</suggest>
-         </follow_up>
-         </ask_followup_question>
-         
-         If yes, clean up:
-         <execute_command>
-         <command>rm -rf .roo/temp/issue-fixer-orchestrator/[TASK_ID]</command>
-         </execute_command>
-    </instructions>
-  </step>
-
-  <step number="12">
-    <name>Monitor PR (Optional)</name>
-    <instructions>
-      If a PR was created automatically, offer to monitor its status.
-
-      1. Check if PR exists:
-         <execute_command>
-         <command>
-         # Check if there's a PR for the current branch
-         BRANCH=$(git branch --show-current)
-         gh pr list --head $BRANCH --json number,state,checks
-         </command>
-         </execute_command>
-
-      2. If PR exists, offer monitoring:
-         <ask_followup_question>
-         <question>
-           Would you like me to monitor the PR checks and CI status?
-         </question>
-         <follow_up>
-           <suggest>Yes, monitor the PR checks</suggest>
-           <suggest>No, I'll check it myself</suggest>
-         </follow_up>
-         </ask_followup_question>
-
-      3. If user wants monitoring:
-         <execute_command>
-         <command>
-         PR_NUM=$(gh pr list --head $(git branch --show-current) --json number -q '.[0].number')
-         echo "Monitoring PR #$PR_NUM checks..."
-         gh pr checks $PR_NUM --watch
-         </command>
-         </execute_command>
-
-      This concludes the orchestration workflow.
-    </instructions>
-  </step>
-</workflow>

.roo/rules-issue-fixer-orchestrator/2_best_practices.xml

@@ -1,120 +0,0 @@
-<best_practices>
-  - Always read the entire issue and all comments before starting
-  - Follow the project's coding standards and patterns
-  - Focus exclusively on addressing the issue's requirements.
-  - Make minimal, high-quality changes for bug fixes. The goal is a narrow, targeted fix, not a one-line hack.
-  - Test thoroughly - both automated and manual testing
-  - Document complex logic with comments
-  - Keep commits focused and well-described
-  - Reference the issue number in commits
-  - Verify all acceptance criteria are met
-  - Consider performance and security implications
-  - Update documentation when needed
-  - Add tests for any new functionality
-  - Check for accessibility issues (for UI changes)
-  - Always delegate translation tasks to translate mode when implementing user-facing changes
-  - Check all modified files for hard-coded strings and internationalization needs
-  - Wait for translation completion before proceeding to PR creation
-  - Translation is required for:
-    - Any new or modified UI components (.tsx, .jsx files)
-    - User-facing documentation changes (.md files)
-    - Error messages and notifications
-    - Any strings visible to end users
-  - The translate mode will handle:
-    - Adding translations to all supported language files
-    - Ensuring consistency with existing terminology
-    - Maintaining sync across all language resources
-  
-  <commit_and_pr_best_practices>
-    <principle>Always verify files before committing</principle>
-    <guidelines>
-      - Review git status to ensure only intended files are staged
-      - Stage only files listed in modified_files.json
-      - Never commit unrelated changes or temporary files
-      - Always get user confirmation before committing
-    </guidelines>
-    
-    <diff_management>
-      - Save full diff to staged_changes.diff for review
-      - If diff exceeds 2000 lines, create a summary instead
-      - Summary should include file stats and change types
-      - Always inform user when showing summary vs full diff
-    </diff_management>
-    
-    <pr_message_handling>
-      - Save PR message in both JSON and Markdown formats
-      - pr_summary.json for programmatic use
-      - pr_message.md for manual PR creation
-      - Include all standard template sections
-      - Make PR message self-contained and ready to use
-    </pr_message_handling>
-    
-    <user_confirmation_flow>
-      - Always ask for confirmation with clear options
-      - First option should be "Looks good, go ahead"
-      - Provide options for testing and issue reporting
-      - Allow PR message modification before proceeding
-      - Handle each user response appropriately
-    </user_confirmation_flow>
-    
-    <temp_file_management>
-      - All delegated tasks must save outputs to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/
-      - Keep all context files until user confirms cleanup
-      - Offer cleanup option after PR creation
-      - Never delete files without user permission
-    </temp_file_management>
-  </commit_and_pr_best_practices>
-  <codebase_exploration_guidelines>
-    <principle>Always use `codebase_search` FIRST to understand the codebase structure and find all related files before using other tools like `read_file`.</principle>
-    
-    <architectural_understanding>
-      <title>Critical: Understand Component Interactions</title>
-      <mandatory_steps>
-        <step>Map the complete data flow from input to output</step>
-        <step>Identify ALL paired operations (import/export, save/load, encode/decode)</step>
-        <step>Find all consumers and dependencies of the affected code</step>
-        <step>Trace how data transformations occur throughout the system</step>
-        <step>Understand error propagation and handling patterns</step>
-      </mandatory_steps>
-    </architectural_understanding>
-    
-    <for_bug_fixes>
-      <title>Investigation Checklist for Bug Fixes</title>
-      <item>Search for the specific error message or broken functionality.</item>
-      <item>Find all relevant error handling and logging statements.</item>
-      <item>Locate related test files to understand expected behavior.</item>
-      <item>Identify all dependencies and import/export patterns for the affected code.</item>
-      <item>Find similar, working patterns in the codebase to use as a reference.</item>
-      <item>**CRITICAL**: For any operation being fixed, find and analyze its paired operations</item>
-      <item>Trace the complete data flow to understand all affected components</item>
-    </for_bug_fixes>
-    
-    <for_features>
-      <title>Investigation Checklist for New Features</title>
-      <item>Search for any similar existing features to use as a blueprint.</item>
-      <item>Find potential integration points (e.g., API routes, UI component registries).</item>
-      <item>Locate relevant configuration files that may need to be updated.</item>
-      <item>Identify common patterns, components, and utilities that should be reused.</item>
-      <item>**CRITICAL**: Design paired operations together (e.g., both import AND export)</item>
-      <item>Map all data transformations and state changes</item>
-      <item>Identify all downstream consumers of the new functionality</item>
-    </for_features>
-
-    <paired_operations_principle>
-      <title>Always Implement Paired Operations Together</title>
-      <examples>
-        <example>When fixing export, ALWAYS check and update import</example>
-        <example>When modifying save, ALWAYS verify load handles the changes</example>
-        <example>When changing serialization, ALWAYS update deserialization</example>
-        <example>When updating create, consider read/update/delete operations</example>
-      </examples>
-      <rationale>
-        Paired operations must maintain consistency. Changes to one without the other leads to data corruption, import failures, or broken functionality.
-      </rationale>
-    </paired_operations_principle>
-
-    <critical_note>
-      Always read multiple related files together to understand the full context. Never assume a change is isolated - trace its impact through the entire system.
-    </critical_note>
-  </codebase_exploration_guidelines>
-</best_practices>

.roo/rules-issue-fixer-orchestrator/3_common_patterns.xml

@@ -1,38 +0,0 @@
-<common_patterns>
-  <bug_fix_pattern>
-    1. Reproduce the issue
-    2. Identify root cause
-    3. Implement minimal fix
-    4. Add regression test
-    5. Verify fix works
-    6. Check for side effects
-  </bug_fix_pattern>
-  
-  <feature_implementation_pattern>
-    1. Understand all requirements
-    2. Design the solution
-    3. Implement incrementally
-    4. Test each component
-    5. Integrate components
-    6. Verify acceptance criteria
-    7. Add comprehensive tests
-    8. Update documentation
-  </feature_implementation_pattern>
-  
-  <commit_and_pr_pattern>
-    1. Review git status to identify all changes
-    2. Stage only files from modified_files.json
-    3. Generate diff for review (full or summary based on size)
-    4. Create PR message and save to temp directory
-    5. Present changes to user for confirmation
-    6. Handle user response:
-       - If approved: commit and proceed to PR options
-       - If issues found: return to implementation
-       - If manual testing needed: wait for user
-    7. After commit, offer PR creation options:
-       - Create PR automatically
-       - Save PR message for manual creation
-       - Skip PR creation
-    8. Optionally monitor PR and offer cleanup
-  </commit_and_pr_pattern>
-</common_patterns>

.roo/rules-issue-fixer-orchestrator/4_github_cli_usage.xml

@@ -1,221 +0,0 @@
-<github_cli_usage>
-  <overview>
-    This mode uses the GitHub CLI (gh) for all GitHub operations.
-    The mode assumes the user has gh installed and authenticated. If authentication errors occur,
-    the mode will prompt the user to authenticate.
-    
-    Users must provide full GitHub issue URLs (e.g., https://github.com/owner/repo/issues/123)
-    so the mode can extract the repository information dynamically.
-  </overview>
-  
-  <url_parsing>
-    <pattern>https://github.com/[owner]/[repo]/issues/[number]</pattern>
-    <extraction>
-      - Owner: The organization or username
-      - Repo: The repository name
-      - Number: The issue number
-    </extraction>
-  </url_parsing>
-
-  <authentication_handling>
-    <approach>Assume authenticated, handle errors gracefully</approach>
-    <when>Only check authentication if a gh command fails with auth error</when>
-    <error_patterns>
-      - "gh: Not authenticated"
-      - "HTTP 401"
-      - "HTTP 403: Resource not accessible"
-    </error_patterns>
-  </authentication_handling>
-
-  <primary_commands>
-    <command name="gh_issue_view">
-      <purpose>Retrieve the issue details at the start</purpose>
-      <when>Always use first to get the full issue content</when>
-      <syntax>gh issue view [issue-number] --repo [owner]/[repo] --json number,title,body,state,labels,assignees,milestone,createdAt,updatedAt,closedAt,author</syntax>
-      <example>
-        <execute_command>
-        <command>gh issue view 123 --repo octocat/hello-world --json number,title,body,state,labels,assignees,milestone,createdAt,updatedAt,closedAt,author</command>
-        </execute_command>
-      </example>
-    </command>
-    
-    <command name="gh_issue_comments">
-      <purpose>Get additional context and requirements from issue comments</purpose>
-      <when>Always use after viewing issue to see full discussion</when>
-      <syntax>gh issue view [issue-number] --repo [owner]/[repo] --comments</syntax>
-      <example>
-        <execute_command>
-        <command>gh issue view 123 --repo octocat/hello-world --comments</command>
-        </execute_command>
-      </example>
-    </command>
-    
-    
-    <command name="gh_repo_view_commits">
-      <purpose>Find recent changes to affected files</purpose>
-      <when>Use during codebase exploration</when>
-      <syntax>gh api repos/[owner]/[repo]/commits?path=[file-path]&per_page=10</syntax>
-      <example>
-        <execute_command>
-        <command>gh api repos/octocat/hello-world/commits?path=src/api/index.ts&per_page=10 --jq '.[].sha + " " + .[].commit.message'</command>
-        </execute_command>
-      </example>
-    </command>
-    
-    <command name="gh_search_code">
-      <purpose>Search for code patterns on GitHub</purpose>
-      <when>Use to supplement local codebase_search</when>
-      <syntax>gh search code "[search-query]" --repo [owner]/[repo]</syntax>
-      <example>
-        <execute_command>
-        <command>gh search code "function handleError" --repo octocat/hello-world --limit 10</command>
-        </execute_command>
-      </example>
-    </command>
-  </primary_commands>
-  
-  <optional_commands>
-    <command name="gh_issue_comment">
-      <purpose>Add progress updates or ask questions on issues</purpose>
-      <when>Use if clarification needed or to show progress</when>
-      <syntax>gh issue comment [issue-number] --repo [owner]/[repo] --body "[comment]"</syntax>
-      <example>
-        <execute_command>
-        <command>gh issue comment 123 --repo octocat/hello-world --body "Working on this issue. Found the root cause in the theme detection logic."</command>
-        </execute_command>
-      </example>
-    </command>
-    
-    <command name="gh_pr_list">
-      <purpose>Find related or similar PRs</purpose>
-      <when>Use to understand similar changes</when>
-      <syntax>gh pr list --repo [owner]/[repo] --search "[search-terms]"</syntax>
-      <example>
-        <execute_command>
-        <command>gh pr list --repo octocat/hello-world --search "dark theme" --limit 10</command>
-        </execute_command>
-      </example>
-    </command>
-    
-    <command name="gh_pr_diff">
-      <purpose>View the diff of a pull request</purpose>
-      <when>Use to understand changes in a PR</when>
-      <syntax>gh pr diff [pr-number] --repo [owner]/[repo]</syntax>
-      <example>
-        <execute_command>
-        <command>gh pr diff 456 --repo octocat/hello-world</command>
-        </execute_command>
-      </example>
-    </command>
-  </optional_commands>
-  
-  <pull_request_commands>
-    <command name="gh_pr_create">
-      <purpose>Create a pull request</purpose>
-      <when>Use in step 11 after user approval</when>
-      <important>
-        - Target the repository from the provided URL
-        - Use "main" as the base branch unless specified otherwise
-        - Include issue number in PR title
-        - Use --maintainer-can-modify flag
-      </important>
-      <syntax>gh pr create --repo [owner]/[repo] --base main --title "[title]" --body "[body]" --maintainer-can-modify</syntax>
-      <example>
-        <execute_command>
-        <command>gh pr create --repo octocat/hello-world --base main --title "fix: Resolve dark theme button visibility (#123)" --body "## Description
-
-Fixes #123
-
-[Full PR description]" --maintainer-can-modify</command>
-        </execute_command>
-      </example>
-      <note>
-        If working from a fork, ensure the fork is set as the remote and push the branch there first.
-        The gh CLI will automatically handle the fork workflow.
-      </note>
-    </command>
-    
-    <command name="gh_repo_fork">
-      <purpose>Fork the repository if user doesn't have push access</purpose>
-      <when>Use if user needs to work from a fork</when>
-      <syntax>gh repo fork [owner]/[repo] --clone</syntax>
-      <example>
-        <execute_command>
-        <command>gh repo fork octocat/hello-world --clone</command>
-        </execute_command>
-      </example>
-    </command>
-    
-    <command name="gh_pr_checks">
-      <purpose>Monitor CI/CD checks on a pull request</purpose>
-      <when>Use after creating PR to ensure checks pass</when>
-      <syntax>gh pr checks [pr-number] --repo [owner]/[repo] --watch</syntax>
-      <example>
-        <execute_command>
-        <command>gh pr checks 789 --repo octocat/hello-world --watch</command>
-        </execute_command>
-      </example>
-    </command>
-  </pull_request_commands>
-  
-  <workflow_helpers>
-    <command name="gh_api">
-      <purpose>Access GitHub API directly for advanced operations</purpose>
-      <when>Use when specific gh commands don't provide needed functionality</when>
-      <examples>
-        <!-- Get repository information -->
-        <execute_command>
-        <command>gh api repos/[owner]/[repo] --jq '.default_branch'</command>
-        </execute_command>
-        
-        <!-- Get file contents -->
-        <execute_command>
-        <command>gh api repos/[owner]/[repo]/contents/README.md --jq '.content' | base64 -d</command>
-        </execute_command>
-        
-        <!-- Get workflow runs -->
-        <execute_command>
-        <command>gh api repos/[owner]/[repo]/actions/runs --jq '.workflow_runs[0:5] | .[] | .id, .status, .conclusion'</command>
-        </execute_command>
-      </examples>
-    </command>
-    
-    <command name="gh_run_list">
-      <purpose>Check GitHub Actions workflow status</purpose>
-      <when>Use to monitor CI/CD pipeline</when>
-      <syntax>gh run list --repo [owner]/[repo] --limit 5</syntax>
-      <example>
-        <execute_command>
-        <command>gh run list --repo octocat/hello-world --limit 5</command>
-        </execute_command>
-      </example>
-    </command>
-  </workflow_helpers>
-  
-  <error_handling>
-    <scenario name="not_authenticated">
-      <error>gh: Not authenticated. Run 'gh auth login' to authenticate.</error>
-      <action>
-        Ask user to authenticate:
-        <ask_followup_question>
-        <question>GitHub CLI is not authenticated. Please run 'gh auth login' in your terminal to authenticate, then let me know when you're ready to continue.</question>
-        <follow_up>
-        <suggest>I've authenticated, please continue</suggest>
-        <suggest>I need help with authentication</suggest>
-        <suggest>Let's use a different approach</suggest>
-        </follow_up>
-        </ask_followup_question>
-      </action>
-    </scenario>
-    
-    <scenario name="no_permissions">
-      <error>HTTP 403: Resource not accessible by integration</error>
-      <action>
-        Check if working from a fork is needed:
-        <execute_command>
-        <command>gh repo fork [owner]/[repo] --clone</command>
-        </execute_command>
-      </action>
-    </scenario>
-  </error_handling>
-</github_cli_usage>

.roo/rules-issue-fixer-orchestrator/5_pull_request_workflow.xml

@@ -1,106 +0,0 @@
-<pull_request_workflow>
-  <preparation>
-    1. Ensure all changes are committed with proper message format
-    2. Push to appropriate branch (fork or direct)
-    3. Prepare comprehensive PR description
-    4. Get user approval before creating PR
-    5. Extract owner and repo from the provided GitHub URL
-  </preparation>
-  
-  <pr_title_format>
-    - Bug fixes: "fix: [description] (#[issue-number])"
-    - Features: "feat: [description] (#[issue-number])"
-    - Follow conventional commit format
-  </pr_title_format>
-  <pr_description_template>
-    A comprehensive PR description is critical. The subtask responsible for preparing the PR content should generate a body that includes the following markdown structure:
-
-    ```markdown
-    ## Description
-    
-    Fixes #[issue number]
-    
-    [Detailed description of what was changed and why]
-    
-    ## Changes Made
-    
-    - [Specific change 1 with file references]
-    - [Specific change 2 with technical details]
-    - [Any refactoring or cleanup done]
-    
-    ## Testing
-    
-    - [x] All existing tests pass
-    - [x] Added tests for [specific functionality]
-    - [x] Manual testing completed:
-      - [Specific manual test 1]
-      - [Specific manual test 2]
-    
-    ## Translations
-    
-    [If translations were added/updated]
-    - [x] All user-facing strings have been translated
-    - [x] Updated language files: [list of languages]
-    - [x] Translations reviewed for consistency
-    
-    [If no translations needed]
-    - No user-facing string changes in this PR
-    
-    ## Verification of Acceptance Criteria
-    
-    [For each criterion from the issue, show it's met]
-    - [x] Criterion 1: [How it's verified]
-    - [x] Criterion 2: [How it's verified]
-    
-    ## Checklist
-    
-    - [x] Code follows project style guidelines
-    - [x] Self-review completed
-    - [x] Comments added for complex logic
-    - [x] Documentation updated (if needed)
-    - [x] No breaking changes (or documented if any)
-    - [x] Accessibility checked (for UI changes)
-    - [x] Translations added/updated (for UI changes)
-    
-    ## Screenshots/Demo (if applicable)
-    
-    [Add before/after screenshots for UI changes]
-    [Add terminal output for CLI changes]
-    ```
-  </pr_description_template>
-
-  <branch_naming_conventions>
-    <rule>Use a consistent format for branch names.</rule>
-    <format>
-      - Bug fixes: `fix/issue-[number]-[brief-description]`
-      - Features: `feat/issue-[number]-[brief-description]`
-    </format>
-  </branch_naming_conventions>
-  
-  <creating_pr_with_cli>
-    Use GitHub CLI to create the pull request:
-    <execute_command>
-    <command>gh pr create --repo [owner]/[repo] --base main --title "[title]" --body "[description]" --maintainer-can-modify</command>
-    </execute_command>
-    
-    If working from a fork, ensure you've forked first:
-    <execute_command>
-    <command>gh repo fork [owner]/[repo] --clone</command>
-    </execute_command>
-    
-    The gh CLI automatically handles fork workflows.
-  </creating_pr_with_cli>
-  
-  <after_creation>
-    1. Comment on original issue with PR link:
-       <execute_command>
-       <command>gh issue comment [issue-number] --repo [owner]/[repo] --body "PR #[pr-number] has been created to address this issue: [PR URL]"</command>
-       </execute_command>
-    2. Inform user of successful creation
-    3. Provide next steps and tracking info
-    4. Monitor PR checks:
-       <execute_command>
-       <command>gh pr checks [pr-number] --repo [owner]/[repo] --watch</command>
-       </execute_command>
-  </after_creation>
-</pull_request_workflow>

.roo/rules-issue-fixer-orchestrator/6_testing_guidelines.xml

@@ -1,10 +0,0 @@
-<testing_guidelines>
-  - Always run existing tests before making changes (baseline)
-  - Add tests for any new functionality
-  - Add regression tests for bug fixes
-  - Test edge cases and error conditions
-  - Run the full test suite before completing
-  - For UI changes, test in multiple themes
-  - Verify accessibility (keyboard navigation, screen readers)
-  - Test performance impact for large operations
-</testing_guidelines>

.roo/rules-issue-fixer-orchestrator/7_communication_style.xml

@@ -1,27 +0,0 @@
-<communication_style>
-  - Be clear about what you're doing at each step
-  - Explain technical decisions and trade-offs
-  - Ask for clarification if requirements are ambiguous
-  - Provide regular progress updates for complex issues
-  - Summarize changes clearly for non-technical stakeholders
-  - Use issue numbers and links for reference
-  - Inform the user when delegating to translate mode
-  - Include translation status in progress updates
-  - Mention in PR description if translations were added
-  
-  <pre_commit_communication>
-    - Clearly list all files that will be committed
-    - Explain when showing a summary vs full diff (>2000 lines)
-    - Provide file statistics for large diffs
-    - Mention that PR message has been saved to temp directory
-    - Offer clear options for user to proceed or report issues
-  </pre_commit_communication>
-  
-  <post_commit_communication>
-    - Confirm successful commit with commit hash
-    - Explain PR creation options clearly
-    - Mention that PR message is saved and ready to use
-    - Provide path to PR message file for manual creation
-    - Offer cleanup option after PR is created
-  </post_commit_communication>
-</communication_style>

.roo/rules-issue-fixer-orchestrator/8_github_communication_guidelines.xml

@@ -1,16 +0,0 @@
-<github_communication_guidelines>
-  <issue_comments>
-    - Provide brief status updates when working on complex issues
-    - Ask specific questions if requirements are unclear
-    - Share findings when investigation reveals important context
-    - Keep progress updates factual and concise
-    - Example: "Found the root cause in the theme detection logic. Working on a fix that preserves backward compatibility."
-  </issue_comments>
-  
-  <commit_messages>
-    - Follow conventional commit format: "type: description (#issue-number)"
-    - Keep first line under 72 characters
-    - Be specific about what changed
-    - Example: "fix: resolve button visibility in dark theme (#123)"
-  </commit_messages>
-</github_communication_guidelines>

.roo/rules-issue-fixer-orchestrator/9_translation_handling.xml

@@ -1,125 +0,0 @@
-<translation_handling_guidelines>
-  <overview>
-    The issue-fixer-orchestrator mode must ensure all user-facing content is properly translated before creating a pull request. This is achieved by delegating translation tasks to the specialized translate mode.
-  </overview>
-
-  <when_translations_required>
-    <scenario name="ui_components">
-      <description>Any changes to React/Vue/Angular components</description>
-      <file_patterns>
-        - webview-ui/src/**/*.tsx
-        - webview-ui/src/**/*.jsx
-        - src/**/*.tsx (if contains UI elements)
-      </file_patterns>
-      <what_to_check>
-        - New text strings in JSX
-        - Updated button labels, tooltips, or placeholders
-        - Error messages displayed to users
-        - Any hardcoded strings that should use i18n
-      </what_to_check>
-    </scenario>
-
-    <scenario name="documentation">
-      <description>User-facing documentation changes</description>
-      <file_patterns>
-        - README.md
-        - docs/**/*.md
-        - webview-ui/src/components/chat/Announcement.tsx
-        - Any markdown files visible to end users
-      </file_patterns>
-    </scenario>
-
-    <scenario name="i18n_resources">
-      <description>Direct changes to translation files</description>
-      <file_patterns>
-        - src/i18n/locales/**/*.json
-        - webview-ui/src/i18n/locales/**/*.json
-      </file_patterns>
-      <note>When English (en) locale is updated, all other locales must be synchronized</note>
-    </scenario>
-
-    <scenario name="error_messages">
-      <description>New or modified error messages</description>
-      <locations>
-        - API error responses
-        - Validation messages
-        - System notifications
-        - Status messages
-      </locations>
-    </scenario>
-  </when_translations_required>
-
-  <translation_workflow>
-    <step number="1">
-      <name>Detect Translation Needs</name>
-      <actions>
-        - Read the modified_files.json from the implementation step
-        - Check each file against the patterns above
-        - Determine if any user-facing content was changed
-      </actions>
-    </step>
-
-    <step number="2">
-      <name>Prepare Translation Context</name>
-      <actions>
-        - Gather all context files (issue details, implementation plan, modified files)
-        - Identify specific strings or content that need translation
-        - Note any special terminology or context from the issue
-      </actions>
-    </step>
-
-    <step number="3">
-      <name>Delegate to Translate Mode</name>
-      <actions>
-        - Use new_task to create a translation subtask
-        - Provide clear instructions about what needs translation
-        - Include paths to all context files
-        - Specify expected output (translation_summary.md)
-      </actions>
-    </step>
-
-    <step number="4">
-      <name>Verify Translation Completion</name>
-      <actions>
-        - Wait for the translate mode subtask to complete
-        - Read the translation_summary.md file
-        - Confirm all necessary translations were handled
-        - Only proceed to PR creation after confirmation
-      </actions>
-    </step>
-  </translation_workflow>
-
-  <translation_subtask_template>
-    <purpose>Template for creating translation subtasks</purpose>
-    <key_elements>
-      - Clear identification of the issue being fixed
-      - List of modified files requiring translation review
-      - Path to context files for understanding the changes
-      - Specific instructions for what to translate
-      - Expected output format and location
-    </key_elements>
-  </translation_subtask_template>
-
-  <best_practices>
-    <practice>Always check for translations AFTER verification passes</practice>
-    <practice>Don't skip translation even for "minor" UI changes</practice>
-    <practice>Ensure the translate mode has access to full context</practice>
-    <practice>Wait for translation completion before creating PR</practice>
-    <practice>Include translation changes in the PR description</practice>
-  </best_practices>
-
-  <common_mistakes_to_avoid>
-    <mistake>
-      <description>Assuming no translations needed without checking</description>
-      <solution>Always analyze modified files for user-facing content</solution>
-    </mistake>
-    <mistake>
-      <description>Proceeding to PR creation before translations complete</description>
-      <solution>Wait for translation_summary.md confirmation</solution>
-    </mistake>
-    <mistake>
-      <description>Not providing enough context to translate mode</description>
-      <solution>Include issue details and implementation plan</solution>
-    </mistake>
-  </common_mistakes_to_avoid>
-</translation_handling_guidelines>

.roo/rules-issue-fixer/1_Workflow.xml

@@ -17,7 +17,7 @@
       Then retrieve the issue:
       
       <execute_command>
-      <command>gh issue view [issue-number] --repo [owner]/[repo] --json number,title,body,state,labels,assignees,milestone,createdAt,updatedAt,closedAt,author</command>
+      <command>gh api repos/[owner]/[repo]/issues/[issue-number] --jq '{number,title,body,state,labels,assignees,milestone,createdAt:.created_at,updatedAt:.updated_at,closedAt:.closed_at,author:.user.login}'</command>
       </execute_command>
       
       If the command fails with an authentication error (e.g., "gh: Not authenticated" or "HTTP 401"), ask the user to authenticate:
@@ -49,7 +49,7 @@
       - Any decisions or changes to requirements
       
       <execute_command>
-      <command>gh issue view [issue number] --repo [owner]/[repo] --comments</command>
+      <command>gh api repos/[owner]/[repo]/issues/[issue-number]/comments --paginate --jq '.[].body'</command>
       </execute_command>
       
       Also check for:
@@ -191,7 +191,6 @@
       Use appropriate tools:
       - apply_diff for targeted changes
       - write_to_file for new files
-      - search_and_replace for systematic updates
       
       After each significant change, run relevant tests:
       - execute_command to run test suites
@@ -273,6 +272,13 @@
        - [Note any technical terms or constraints]
  
        Please ensure all translations maintain consistency with existing terminology and follow the project's localization guidelines.</message>
+       <todos>
+[ ] Identify all user-facing strings that need translation
+[ ] Update i18n JSON files for all supported languages
+[ ] Translate any markdown documentation files
+[ ] Verify translations maintain consistency with existing terminology
+[ ] Test translations in the application context
+       </todos>
        </new_task>
        
        Wait for the translation task to complete before proceeding to testing.
@@ -478,7 +484,7 @@
       3. Inform the user of the successful creation
       
       <execute_command>
-      <command>gh issue comment [original issue number] --repo [owner]/[repo] --body "PR #[new PR number] has been created to address this issue: [PR URL]"</command>
+      <command>gh issue comment [original issue number] --repo [owner]/[repo] --body "PR #[new PR number] has been created to address this issue"</command>
       </execute_command>
       
       Final message to user:

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

@@ -14,5 +14,6 @@
   - Check for accessibility issues (for UI changes)
   - Delegate translation tasks to translate mode when implementing user-facing changes
   - Always check for hard-coded strings and internationalization needs
+  - When using new_task to delegate work, always include a comprehensive todos list
   - Wait for translation completion before proceeding to final testing
 </best_practices>

.roo/rules-issue-fixer/4_github_cli_usage.xml

@@ -29,23 +29,23 @@
 
   <primary_commands>
     <command name="gh_issue_view">
-      <purpose>Retrieve the issue details at the start</purpose>
+      <purpose>Retrieve the issue details at the start using the REST Issues API.</purpose>
       <when>Always use first to get the full issue content</when>
-      <syntax>gh issue view [issue-number] --repo [owner]/[repo] --json number,title,body,state,labels,assignees,milestone,createdAt,updatedAt,closedAt,author</syntax>
+      <syntax>gh api repos/[owner]/[repo]/issues/[issue-number] --jq '{number,title,body,state,labels,assignees,milestone,createdAt:.created_at,updatedAt:.updated_at,closedAt:.closed_at,author:.user.login}'</syntax>
       <example>
         <execute_command>
-        <command>gh issue view 123 --repo octocat/hello-world --json number,title,body,state,labels,assignees,milestone,createdAt,updatedAt,closedAt,author</command>
+        <command>gh api repos/octocat/hello-world/issues/123 --jq '{number,title,body,state,labels,assignees,milestone,createdAt:.created_at,updatedAt:.updated_at,closedAt:.closed_at,author:.user.login}'</command>
         </execute_command>
       </example>
     </command>
     
     <command name="gh_issue_comments">
-      <purpose>Get additional context and requirements from issue comments</purpose>
+      <purpose>Get additional context and requirements from issue comments.</purpose>
       <when>Always use after viewing issue to see full discussion</when>
-      <syntax>gh issue view [issue-number] --repo [owner]/[repo] --comments</syntax>
+      <syntax>gh api repos/[owner]/[repo]/issues/[issue-number]/comments --paginate --jq '.[].body'</syntax>
       <example>
         <execute_command>
-        <command>gh issue view 123 --repo octocat/hello-world --comments</command>
+        <command>gh api repos/octocat/hello-world/issues/123/comments --paginate --jq '.[].body'</command>
         </execute_command>
       </example>
     </command>
@@ -109,6 +109,30 @@
     </command>
   </optional_commands>
   
+  <projects_v2_commands>
+    <command name="gh_projects_v2_for_issue">
+      <purpose>Inspect associations with GitHub Projects (new Projects experience) for a given issue</purpose>
+      <when>Use when project context is relevant to understanding priority, ownership, or workflow</when>
+      <syntax>gh api graphql -f query='
+query($owner:String!, $repo:String!, $number:Int!) {
+ repository(owner:$owner, name:$repo) {
+   issue(number:$number) {
+     projectsV2(first:20) {
+       nodes {
+         title
+         url
+       }
+     }
+   }
+ }
+}
+' -F owner=[owner] -F repo=[repo] -F number=[issue-number]</syntax>
+      <note>
+        This uses the projectsV2 field from the new GitHub Projects experience for issue-level project context.
+      </note>
+    </command>
+  </projects_v2_commands>
+
   <pull_request_commands>
     <command name="gh_pr_create">
       <purpose>Create a pull request</purpose>

.roo/rules-issue-fixer/5_pull_request_workflow.xml

@@ -40,7 +40,7 @@
   <after_creation>
     1. Comment on original issue with PR link:
        <execute_command>
-       <command>gh issue comment [issue-number] --repo [owner]/[repo] --body "PR #[pr-number] has been created to address this issue: [PR URL]"</command>
+       <command>gh issue comment [issue-number] --repo [owner]/[repo] --body "PR #[pr-number] has been created to address this issue"</command>
        </execute_command>
     2. Inform user of successful creation
     3. Provide next steps and tracking info

.roo/rules-issue-fixer/9_pr_template.xml

@@ -0,0 +1,205 @@
+<pr_template_instructions>
+  <overview>
+    This file contains the official Roo Code PR template that must be used when creating pull requests.
+    All PRs must follow this exact format to ensure consistency and proper documentation.
+  </overview>
+
+  <pr_body_template>
+    <description>
+      The PR body must follow this exact Roo Code PR template with all required sections.
+      Replace placeholder content in square brackets with actual information.
+    </description>
+    <template><![CDATA[
+<!--
+Thank you for contributing to Roo Code!
+
+Before submitting your PR, please ensure:
+- It's linked to an approved GitHub Issue.
+- You've reviewed our [Contributing Guidelines](../CONTRIBUTING.md).
+-->
+
+### Related GitHub Issue
+
+<!-- Every PR MUST be linked to an approved issue. -->
+
+Closes: #[ISSUE_NUMBER] <!-- Replace with the issue number, e.g., Closes: #123 -->
+
+### Roo Code Task Context (Optional)
+
+<!--
+If you used Roo Code to help create this PR, you can share public task links here.
+This helps reviewers understand your development process and provides additional context.
+Example: https://app.roocode.com/share/task-id
+-->
+
+[TASK_CONTEXT]
+
+### Description
+
+<!--
+Briefly summarize the changes in this PR and how they address the linked issue.
+The issue should cover the "what" and "why"; this section should focus on:
+- The "how": key implementation details, design choices, or trade-offs made.
+- Anything specific reviewers should pay attention to in this PR.
+-->
+
+[DESCRIPTION_CONTENT]
+
+### Test Procedure
+
+<!--
+Detail the steps to test your changes. This helps reviewers verify your work.
+- How did you test this specific implementation? (e.g., unit tests, manual testing steps)
+- How can reviewers reproduce your tests or verify the fix/feature?
+- Include relevant testing environment details if applicable.
+-->
+
+[TEST_PROCEDURE_CONTENT]
+
+### Pre-Submission Checklist
+
+<!-- Go through this checklist before marking your PR as ready for review. -->
+
+- [x] **Issue Linked**: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
+- [x] **Scope**: My changes are focused on the linked issue (one major feature/fix per PR).
+- [x] **Self-Review**: I have performed a thorough self-review of my code.
+- [x] **Testing**: New and/or updated tests have been added to cover my changes (if applicable).
+- [x] **Documentation Impact**: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
+- [x] **Contribution Guidelines**: I have read and agree to the [Contributor Guidelines](/CONTRIBUTING.md).
+
+### Screenshots / Videos
+
+<!--
+For UI changes, please provide before-and-after screenshots or a short video of the *actual results*.
+This greatly helps in understanding the visual impact of your changes.
+-->
+
+[SCREENSHOTS_CONTENT]
+
+### Documentation Updates
+
+<!--
+Does this PR necessitate updates to user-facing documentation?
+- [ ] No documentation updates are required.
+- [ ] Yes, documentation updates are required. (Please describe what needs to be updated or link to a PR in the docs repository).
+-->
+
+[DOCUMENTATION_UPDATES_CONTENT]
+
+### Additional Notes
+
+<!-- Add any other context, questions, or information for reviewers here. -->
+
+[ADDITIONAL_NOTES_CONTENT]
+
+### Get in Touch
+
+<!--
+Please provide your Discord username for reviewers or maintainers to reach you if they have questions about your PR
+-->
+
+[DISCORD_USERNAME]
+    ]]></template>
+  </pr_body_template>
+
+  <github_cli_commands>
+    <description>
+      Valid GitHub CLI commands for creating PRs with the proper template
+    </description>
+    
+    <create_pr_command>
+      <description>Create a PR using the filled template</description>
+      <command><![CDATA[
+gh pr create \
+  --repo [owner]/[repo] \
+  --base main \
+  --title "[Type]: [Brief description] (#[issue-number])" \
+  --body-file pr-body.md \
+  --maintainer-can-modify
+      ]]></command>
+      <note>The PR body should be saved to a temporary file first, then referenced with --body-file</note>
+    </create_pr_command>
+
+    <create_pr_inline>
+      <description>Alternative: Create PR with inline body (for shorter content)</description>
+      <command><![CDATA[
+gh pr create \
+  --repo [owner]/[repo] \
+  --base main \
+  --title "[Type]: [Brief description] (#[issue-number])" \
+  --body "[Complete PR body content]" \
+  --maintainer-can-modify
+      ]]></command>
+      <note>Use this only if the body content doesn't contain special characters that need escaping</note>
+    </create_pr_inline>
+
+    <fork_if_needed>
+      <description>Fork repository if user doesn't have push access</description>
+      <command><![CDATA[
+gh repo fork [owner]/[repo] --clone=false
+      ]]></command>
+      <note>The --clone=false flag prevents cloning since we're already in the repo</note>
+    </fork_if_needed>
+  </github_cli_commands>
+
+  <pr_title_format>
+    <description>PR titles should follow conventional commit format</description>
+    <formats>
+      <format type="bug_fix">fix: [brief description] (#[issue-number])</format>
+      <format type="feature">feat: [brief description] (#[issue-number])</format>
+      <format type="docs">docs: [brief description] (#[issue-number])</format>
+      <format type="refactor">refactor: [brief description] (#[issue-number])</format>
+      <format type="test">test: [brief description] (#[issue-number])</format>
+      <format type="chore">chore: [brief description] (#[issue-number])</format>
+    </formats>
+  </pr_title_format>
+
+  <placeholder_guidance>
+    <description>How to fill in the template placeholders</description>
+    <placeholders>
+      <placeholder name="ISSUE_NUMBER">
+        <description>The GitHub issue number being addressed</description>
+        <example>123</example>
+      </placeholder>
+      <placeholder name="TASK_CONTEXT">
+        <description>Optional Roo Code task links if used during development</description>
+        <example>https://app.roocode.com/share/task-abc123</example>
+        <default>_No Roo Code task context for this PR_</default>
+      </placeholder>
+      <placeholder name="DESCRIPTION_CONTENT">
+        <description>Detailed explanation of implementation approach</description>
+        <guidance>
+          - Focus on HOW you solved the problem
+          - Mention key design decisions
+          - Highlight any trade-offs made
+          - Point out areas needing special review attention
+        </guidance>
+      </placeholder>
+      <placeholder name="TEST_PROCEDURE_CONTENT">
+        <description>Steps to verify the changes work correctly</description>
+        <guidance>
+          - List specific test commands run
+          - Describe manual testing performed
+          - Include steps for reviewers to reproduce tests
+          - Mention test environment details if relevant
+        </guidance>
+      </placeholder>
+      <placeholder name="SCREENSHOTS_CONTENT">
+        <description>Visual evidence of changes for UI modifications</description>
+        <default>_No UI changes in this PR_</default>
+      </placeholder>
+      <placeholder name="DOCUMENTATION_UPDATES_CONTENT">
+        <description>Documentation impact assessment</description>
+        <default>- [x] No documentation updates are required.</default>
+      </placeholder>
+      <placeholder name="ADDITIONAL_NOTES_CONTENT">
+        <description>Any extra context for reviewers</description>
+        <default>_No additional notes_</default>
+      </placeholder>
+      <placeholder name="DISCORD_USERNAME">
+        <description>Discord username for communication</description>
+        <example>@username</example>
+      </placeholder>
+    </placeholders>
+  </placeholder_guidance>
+</pr_template_instructions>

.roo/rules-issue-investigator/1_workflow.xml

@@ -0,0 +1,98 @@
+<workflow_instructions>
+  <mode_overview>
+    This mode investigates GitHub issues to find the probable root cause and suggest a theoretical solution. It uses a structured, iterative search process and communicates findings in a conversational tone.
+  </mode_overview>
+
+  <initialization_steps>
+    <step number="1">
+      <action>Understand the user's request</action>
+      <details>
+        The user will provide a GitHub issue URL or number. Your first step is to fetch the issue details using the `gh` CLI.
+      </details>
+      <tool_use>
+        <command>gh issue view ISSUE_URL --json title,body,labels,comments</command>
+      </tool_use>
+    </step>
+    <step number="2">
+      <action>Create an investigation plan</action>
+      <details>
+        Based on the issue details, create a todo list to track the investigation.
+      </details>
+      <tool_use><![CDATA[
+<update_todo_list>
+<todos>
+[ ] Extract keywords from the issue title and body.
+[ ] Perform initial codebase search with keywords.
+[ ] Analyze search results and form a hypothesis.
+[ ] Attempt to disprove the hypothesis.
+[ ] Formulate a theoretical solution.
+[ ] Draft a comment for the user.
+</todos>
+</update_todo_list>
+      ]]></tool_use>
+    </step>
+  </initialization_steps>
+
+  <main_workflow>
+    <phase name="investigation">
+      <description>
+        Systematically search the codebase to identify the root cause. This is an iterative process.
+      </description>
+      <steps>
+        <step>
+            <title>Extract Keywords</title>
+            <description>Identify key terms, function names, error messages, and concepts from the issue title, body, and comments.</description>
+        </step>
+        <step>
+            <title>Iterative Codebase Search</title>
+            <description>Use `codebase_search` with the extracted keywords. Start broad and then narrow down your search based on the results. Continue searching with new keywords discovered from relevant files until you have a clear understanding of the related code.</description>
+            <tool_use>
+                <command>codebase_search</command>
+            </tool_use>
+        </step>
+        <step>
+            <title>Form a Hypothesis</title>
+            <description>Based on the search results, form a hypothesis about the probable cause of the issue. Document this hypothesis.</description>
+        </step>
+        <step>
+            <title>Attempt to Disprove Hypothesis</title>
+            <description>Actively try to find evidence that contradicts your hypothesis. This might involve searching for alternative implementations, looking for configurations that change behavior, or considering edge cases. If the hypothesis is disproven, return to the search step with new insights.</description>
+        </step>
+      </steps>
+    </phase>
+
+    <phase name="solution">
+      <description>Formulate a solution and prepare to communicate it.</description>
+      <steps>
+        <step>
+            <title>Formulate Theoretical Solution</title>
+            <description>Once the hypothesis is stable, describe a potential solution. Frame it as a suggestion, using phrases like "It seems like the issue could be resolved by..." or "A possible fix would be to...".</description>
+        </step>
+        <step>
+            <title>Draft Comment</title>
+            <description>Draft a comment for the GitHub issue that explains your findings and suggested solution in a conversational, human-like tone. Start the comment with "Hey @roomote-agent,".</description>
+        </step>
+      </steps>
+    </phase>
+
+    <phase name="user_confirmation">
+        <description>Ask the user for confirmation before posting any comments.</description>
+        <tool_use><![CDATA[
+<ask_followup_question>
+<question>I've investigated the issue and drafted a comment with my findings and a suggested solution. Would you like me to post it to the GitHub issue?</question>
+<follow_up>
+<suggest>Yes, please post the comment to the issue.</suggest>
+<suggest>Show me the draft comment first.</suggest>
+<suggest>No, do not post the comment.</suggest>
+</follow_up>
+</ask_followup_question>
+        ]]></tool_use>
+    </phase>
+  </main_workflow>
+
+  <completion_criteria>
+    <criterion>A probable cause has been identified and validated.</criterion>
+    <criterion>A theoretical solution has been proposed.</criterion>
+    <criterion>The user has decided whether to post a comment on the issue.</criterion>
+  </completion_criteria>
+</workflow_instructions>

.roo/rules-issue-investigator/2_best_practices.xml

@@ -0,0 +1,60 @@
+<best_practices>
+  <general_principles>
+    <principle priority="high">
+      <name>Be Methodical</name>
+      <description>Follow the workflow steps precisely. Do not skip the hypothesis validation step. A rigorous process leads to more accurate conclusions.</description>
+      <rationale>Skipping steps can lead to incorrect assumptions and wasted effort. The goal is to be confident in the proposed solution.</rationale>
+    </principle>
+    <principle priority="high">
+      <name>Embrace Iteration</name>
+      <description>The investigation is not linear. Be prepared to go back to the search phase multiple times as you uncover new information. Each search should build on the last.</description>
+      <rationale>Complex issues rarely have a single, obvious cause. Iterative searching helps peel back layers and reveal the true root of the problem.</rationale>
+    </principle>
+    <principle priority="medium">
+      <name>Think like a Skeptic</name>
+      <description>Your primary goal when you have a hypothesis is to try and break it. Actively look for evidence that you are wrong. This makes your final conclusion much stronger.</description>
+      <rationale>Confirmation bias is a common pitfall. By trying to disprove your own theories, you ensure a more objective and reliable investigation.</rationale>
+    </principle>
+  </general_principles>
+
+  <code_conventions>
+    <convention category="searching">
+      <rule>Start with broad keywords from the issue, then narrow down your search using specific function names, variable names, or file paths discovered in the initial results.</rule>
+      <examples>
+        <good>Initial search: "user authentication fails". Follow-up search: "getUserById invalid token".</good>
+        <bad>Searching for a generic term like "error" without context.</bad>
+      </examples>
+    </convention>
+  </code_conventions>
+
+  <common_pitfalls>
+    <pitfall>
+      <description>Jumping to conclusions after the first search.</description>
+      <why_problematic>The first set of results might be misleading or only part of the story.</why_problematic>
+      <correct_approach>Always perform multiple rounds of searches, and always try to disprove your initial hypothesis.</correct_approach>
+    </pitfall>
+    <pitfall>
+      <description>Forgetting to use the todo list.</description>
+      <why_problematic>The todo list is essential for tracking the complex, multi-step investigation process. Without it, you can lose track of your progress and findings.</why_problematic>
+      <correct_approach>Update the todo list after each major step in the workflow.</correct_approach>
+    </pitfall>
+  </common_pitfalls>
+
+  <quality_checklist>
+    <category name="investigation">
+      <item>Have I extracted all relevant keywords from the issue?</item>
+      <item>Have I performed at least two rounds of codebase searches?</item>
+      <item>Have I genuinely tried to disprove my hypothesis?</item>
+    </category>
+    <category name="solution">
+      <item>Is the proposed solution theoretical and not stated as a definitive fact?</item>
+      <item>Is the explanation clear and easy to understand?</item>
+    </category>
+    <category name="communication">
+      <item>Does the draft comment sound conversational and human?</item>
+      <item>Does the draft comment start with "Hey @roomote-agent,"?</item>
+      <item>Have I avoided technical jargon where possible?</item>
+      <item>Is the tone helpful and not condescending?</item>
+    </category>
+  </quality_checklist>
+</best_practices>

.roo/rules-issue-investigator/3_common_patterns.xml

@@ -0,0 +1,45 @@
+<common_patterns>
+    <pattern name="bug_investigation">
+        <usage>For investigating bug reports where something is broken.</usage>
+        <template>
+            <workflow>
+                <step>1. Identify the exact error message from the issue.</step>
+                <step>2. Search for the error message in the codebase using `codebase_search`.</step>
+                <step>3. Analyze the code that throws the error to understand the context.</step>
+                <step>4. Trace the execution path backward from the error to find where the problem originates.</step>
+                <step>5. Form a hypothesis about the incorrect logic or state.</step>
+                <step>6. Try to disprove the hypothesis by checking for alternative paths or configurations.</step>
+                <step>7. Propose a code change to correct the logic.</step>
+            </workflow>
+        </template>
+    </pattern>
+
+    <pattern name="unexpected_behavior_investigation">
+        <usage>For investigating issues where the system works but not as expected.</usage>
+        <template>
+            <workflow>
+                <step>1. Identify the feature or component exhibiting the unexpected behavior.</step>
+                <step>2. Use `codebase_search` to find the main implementation files for that feature.</step>
+                <step>3. Read the relevant code to understand the intended logic.</step>
+                <step>4. Form a hypothesis about which part of the logic is producing the unexpected result.</step>
+                <step>5. Look for related code, configurations, or data that might influence the behavior in an unexpected way.</step>
+                <step>6. Try to disprove the hypothesis. For example, if you think a configuration flag is the cause, check where it's used and if it could be set differently.</step>
+                <step>7. Suggest a change to the logic or configuration to align it with the expected behavior.</step>
+            </workflow>
+        </template>
+    </pattern>
+
+    <pattern name="performance_issue_investigation">
+        <usage>For investigating issues related to slowness or high resource usage.</usage>
+        <template>
+            <workflow>
+                <step>1. Identify the specific action or process that is slow.</step>
+                <step>2. Use `codebase_search` to find the code responsible for that action.</step>
+                <step>3. Look for common performance anti-patterns: loops with expensive operations, redundant database queries, inefficient algorithms, etc.</step>
+                <step>4. Form a hypothesis about the performance bottleneck.</step>
+                <step>5. Try to disprove the hypothesis. Could another part of the system be contributing to the slowness?</step>
+                <step>6. Propose a more efficient implementation, such as caching, batching operations, or using a better algorithm.</step>
+            </workflow>
+        </template>
+    </pattern>
+</common_patterns>

.roo/rules-issue-investigator/4_tool_usage.xml

@@ -0,0 +1,84 @@
+<tool_usage_guide>
+  <tool_priorities>
+    <priority level="1">
+      <tool>gh issue view</tool>
+      <when>Always use first to get the issue context.</when>
+      <why>This provides the foundational information for the entire investigation.</why>
+    </priority>
+    <priority level="2">
+      <tool>codebase_search</tool>
+      <when>For all investigation steps to find relevant code.</when>
+      <why>Semantic search is critical for finding the root cause based on concepts, not just exact keywords.</why>
+    </priority>
+    <priority level="3">
+      <tool>update_todo_list</tool>
+      <when>After major steps or when the investigation plan changes.</when>
+      <why>Maintains a clear record of the investigation's state and next steps.</why>
+    </priority>
+  </tool_priorities>
+
+  <tool_specific_guidance>
+    <tool name="execute_command (gh CLI)">
+      <best_practices>
+        <practice>Use `gh issue view [URL] --json title,body,labels,comments` to fetch initial details.</practice>
+        <practice>Use `gh issue comment [URL] --body "..."` to add comments, but only after explicit user approval.</practice>
+        <practice>Always wrap the comment body in quotes to handle special characters.</practice>
+        <practice>When posting a comment, the body must start with "Hey @roomote-agent," exactly.</practice>
+      </best_practices>
+      <example><![CDATA[
+<execute_command>
+<command>gh issue view https://github.com/RooCodeInc/Roo-Code/issues/123 --json title,body</command>
+</execute_command>
+      ]]></example>
+      <example><![CDATA[
+<execute_command>
+<command>gh issue comment https://github.com/RooCodeInc/Roo-Code/issues/123 --body "Hey @roomote-agent, I've investigated and proposed a theoretical fix above."</command>
+</execute_command>
+      ]]></example>
+    </tool>
+
+    <tool name="codebase_search">
+        <best_practices>
+            <practice>Extract multiple keywords from the issue. Combine them in your search query.</practice>
+            <practice>If initial results are too broad, add more specific terms from the results (like function or variable names) to your next query.</practice>
+            <practice>Use this tool iteratively. Don't rely on a single search.</practice>
+        </best_practices>
+        <example><![CDATA[
+<codebase_search>
+<query>user login authentication error "invalid credentials"</query>
+</codebase_search>
+        ]]></example>
+    </tool>
+
+    <tool name="ask_followup_question">
+      <best_practices>
+        <practice>Only use this tool to ask for confirmation before posting a comment.</practice>
+        <practice>The suggestions should be clear and directly related to the action of commenting.</practice>
+      </best_practices>
+      <example><![CDATA[
+<ask_followup_question>
+<question>I have analyzed the issue and drafted a comment. Would you like me to post it?</question>
+<follow_up>
+<suggest>Yes, go ahead and post the comment.</suggest>
+<suggest>Let me see the comment first before you post it.</suggest>
+<suggest>No, do not post anything. I will handle it.</suggest>
+</follow_up>
+</ask_followup_question>
+      ]]></example>
+    </tool>
+  </tool_specific_guidance>
+
+  <tool_combination_patterns>
+    <pattern name="investigate_and_report">
+      <sequence>
+        <step>execute_command (gh issue view) - Get issue details.</step>
+        <step>update_todo_list - Create an investigation plan.</step>
+        <step>codebase_search - Perform initial search.</step>
+        <step>read_file - Analyze relevant file contents.</step>
+        <step>codebase_search - Perform follow-up search to confirm/deny hypothesis.</step>
+        <step>ask_followup_question - Ask user to confirm before commenting.</step>
+        <step>execute_command (gh issue comment) - Post the comment if approved.</step>
+      </sequence>
+    </pattern>
+  </tool_combination_patterns>
+</tool_usage_guide>

.roo/rules-issue-investigator/5_examples.xml

@@ -0,0 +1,99 @@
+<complete_examples>
+  <example name="investigating_a_login_bug">
+    <scenario>
+      A user has reported a bug where they are unable to log in with valid credentials, but no error message is shown.
+    </scenario>
+    
+    <user_request>
+      "Please investigate issue #456. Users are reporting that they can't log in."
+    </user_request>
+
+    <workflow>
+      <step number="1">
+        <description>Fetch issue details from GitHub.</description>
+        <tool_use><![CDATA[
+<execute_command>
+<command>gh issue view 456 --json title,body,comments</command>
+</execute_command>
+        ]]></tool_use>
+        <expected_outcome>Get the title "Login fails silently" and body "Users with valid credentials are not able to log in. The page just refreshes without any error message."</expected_outcome>
+      </step>
+
+      <step number="2">
+        <description>Create the initial investigation plan.</description>
+        <tool_use><![CDATA[
+<update_todo_list>
+<todos>
+[x] Extract keywords from the issue title and body.
+[-] Perform initial codebase search with keywords.
+[ ] Analyze search results and form a hypothesis.
+[ ] Attempt to disprove the hypothesis.
+[ ] Formulate a theoretical solution.
+[ ] Draft a comment for the user.
+</todos>
+</update_todo_list>
+        ]]></tool_use>
+      </step>
+
+      <step number="3">
+          <description>Perform initial codebase search using keywords "login", "authentication", "silent fail".</description>
+          <tool_use><![CDATA[
+<codebase_search>
+<query>user login authentication silent fail</query>
+</codebase_search>
+          ]]></tool_use>
+          <analysis>The search results point to `src/auth/login.ts` as a highly relevant file.</analysis>
+      </step>
+
+      <step number="4">
+          <description>Read the contents of the relevant file.</description>
+          <tool_use><![CDATA[
+<read_file>
+<path>src/auth/login.ts</path>
+</read_file>
+          ]]></tool_use>
+          <analysis>
+            The file contains a `try...catch` block in the `handleLogin` function. The `catch` block is empty, which explains the silent failure. This is the likely cause. Hypothesis: The login process is failing inside the try block, but the error is swallowed by the empty catch block.
+          </analysis>
+      </step>
+      
+      <step number="5">
+          <description>Attempt to disprove the hypothesis by looking for other error handling mechanisms.</description>
+          <tool_use><![CDATA[
+<codebase_search>
+<query>global error handling middleware Express</query>
+</codebase_search>
+          ]]></tool_use>
+          <analysis>No global error handling middleware seems to be in use that would override this local empty catch block. The hypothesis stands.</analysis>
+      </step>
+
+      <step number="6">
+          <description>Formulate a solution and draft a comment.</description>
+          <draft>
+"Hey @roomote-agent, I took a look at this issue and it seems like the problem is in the `handleLogin` function in `src/auth/login.ts`. There's an empty `try...catch` block that is likely catching the login error and preventing any message from being shown to the user.
+
+A good first step to fixing this would be to add some logging to the `catch` block to see what error is actually happening. Then, we should probably implement proper error feedback to the user on the login page. This should solve the issue of the silent failure."
+          </draft>
+      </step>
+
+      <step number="7">
+        <description>Ask the user for confirmation before posting the comment.</description>
+        <tool_use><![CDATA[
+<ask_followup_question>
+<question>I've investigated the issue and drafted a comment with my findings and a suggested solution. Would you like me to post it to the GitHub issue?</question>
+<follow_up>
+<suggest>Yes, please post the comment to the issue.</suggest>
+<suggest>Show me the draft comment first.</suggest>
+<suggest>No, do not post the comment.</suggest>
+</follow_up>
+</ask_followup_question>
+        ]]></tool_use>
+      </step>
+    </workflow>
+
+    <key_takeaways>
+      <takeaway>Empty catch blocks are a strong indicator of silent failures.</takeaway>
+      <takeaway>Always try to disprove a hypothesis by looking for conflicting code patterns.</takeaway>
+    </key_takeaways>
+  </example>
+</complete_examples>

.roo/rules-issue-investigator/6_communication.xml

@@ -0,0 +1,37 @@
+<communication_guidelines>
+  <tone_and_style>
+    <principle>Be conversational and helpful, not robotic.</principle>
+    <principle>Write comments as if you are a human developer collaborating on the project.</principle>
+    <principle>Always start any GitHub issue comment body with "Hey @roomote-agent,".</principle>
+    <avoid>
+      <phrase>Analysis complete.</phrase>
+      <phrase>The investigation has yielded the following result.</phrase>
+      <phrase>Starting comments with "Hey," instead of "Hey @roomote-agent,".</phrase>
+    </avoid>
+    <prefer>
+      <phrase>Hey @roomote-agent, I took a look at this and found something interesting...</phrase>
+      <phrase>Hey @roomote-agent, I've been digging into this issue, and I think I've found a possible cause.</phrase>
+    </prefer>
+  </tone_and_style>
+
+  <comment_structure>
+      <element>Start every GitHub issue comment with "Hey @roomote-agent,".</element>
+      <element>State your main finding or hypothesis clearly but not definitively.</element>
+      <element>Provide context, like file paths and function names.</element>
+      <element>Propose a next step or a theoretical solution.</element>
+      <element>Keep it concise and easy to read. Avoid large blocks of text.</element>
+      <element>Use markdown for code snippets or file paths only when necessary for clarity.</element>
+  </comment_structure>
+
+  <completion_messages>
+    <structure>
+      <element>What was accomplished (e.g., "Investigation complete.").</element>
+      <element>A summary of the findings and the proposed solution.</element>
+      <element>A final statement indicating that the user has been prompted on how to proceed with the comment.</element>
+    </structure>
+    <avoid>
+      <element>Ending with a question.</element>
+      <element>Offers for further assistance.</element>
+    </avoid>
+  </completion_messages>
+</communication_guidelines>

.roo/rules-issue-writer/1_workflow.xml

@@ -1,330 +1,391 @@
 <workflow>
-  <step number="1">
-    <name>Determine Issue Type</name>
-    <instructions>
-      Use ask_followup_question to determine if the user wants to create:
-      
-      <ask_followup_question>
-      <question>What type of issue would you like to create?</question>
-      <follow_up>
-      <suggest>Bug Report - Report a problem with existing functionality</suggest>
-      <suggest>Detailed Feature Proposal - Propose a new feature or enhancement</suggest>
-      </follow_up>
-      </ask_followup_question>
-    </instructions>
-  </step>
+  <mode_overview>
+    This mode focuses solely on assembling a template-free GitHub issue prompt for an AI coding agent.
+    It integrates codebase exploration to ground the prompt in reality while keeping the output non-technical.
+    It also captures the user-facing value/impact (who is affected, how often, and why it matters) to support prioritization, all in plain language.
+  </mode_overview>
 
-  <step number="2">
-    <name>Gather Initial Information</name>
-    <instructions>
-      Based on the user's initial prompt or request, extract key information.
-      If the user hasn't provided enough detail, use ask_followup_question to gather
-      the required fields from the appropriate template.
-      
-      For Bug Reports, ensure you have:
-      - App version (ask user to check in VSCode extension panel if unknown)
-      - API provider being used
-      - Model being used
-      - Clear steps to reproduce
-      - What happened vs what was expected
-      - Any error messages or logs
-      
-      For Feature Requests, ensure you have:
-      - Specific problem description with impact (who is affected, when it happens, current vs expected behavior, impact)
-      - Additional context if available (mockups, screenshots, links)
-      
-      IMPORTANT: Do NOT ask for solution design, acceptance criteria, or technical details 
-      unless the user explicitly states they want to contribute the implementation.
-      
-      Use multiple ask_followup_question calls if needed to gather all information.
-      Be specific in your questions based on what's missing.
-    </instructions>
-  </step>
+  <iteration_policy>
+    <principles>
+      - Codebase exploration is iterative and may repeat as many times as needed based on user-agent back-and-forth.
+      - Early-stop and escalate-once apply per iteration; when new info arrives, start a fresh iteration.
+      - One-tool-per-message is respected; narrate succinct progress and update TODOs each iteration.
+    </principles>
+    <loop_triggers>
+      - New details from the user (environment, steps, screenshots, constraints)
+      - Clarifications that change scope or target component/feature
+      - Discrepancies found between user claims and code
+      - Reclassification between Bug and Enhancement
+    </loop_triggers>
+  </iteration_policy>
 
-  <step number="3">
-    <name>Search GitHub Discussions</name>
-    <instructions>
-      Search GitHub Discussions for related feature requests or bug reports:
-      
-      1. Use the GitHub web interface or API to search discussions in:
-         https://github.com/RooCodeInc/Roo-Code/discussions/categories/feature-requests
-      
-      2. Search for keywords related to the user's issue:
-         - For feature requests: Look for similar feature ideas or requests
-         - For bug reports: Look for users reporting similar problems
-      
-      3. Document any related discussions found:
-         - Discussion number and title
-         - Link to the discussion
-         - Whether it should be marked as "Closes #[number]" (if this issue fully addresses it)
-         - Or "Related to #[number]" (if partially related)
-      
-      4. If multiple related discussions exist, list them all for inclusion in the issue
-    </instructions>
-  </step>
+  <initialization>
+    <notes>
+      - Treat the user's FIRST message as the issue description; do not ask if they want to create an issue.
+      - Begin immediately: initialize a focused TODO list and start repository detection before discovery.
+      - CLI submission via gh happens only after the user confirms during the merged review/submit step.
+    </notes>
+    <update_todo_list>
+      <todos>
+      [ ] Detect repository context (OWNER/REPO, monorepo, roots)
+      [ ] Perform targeted codebase discovery (iteration 1)
+      [ ] Clarify missing details (repro or desired outcome)
+      [ ] Classify type (Bug | Enhancement)
+      [ ] Assemble Issue Body
+      [ ] Review and submit (Submit now | Submit now and assign to me)
+      </todos>
+    </update_todo_list>
+  </initialization>
 
-  <step number="4">
-    <name>Determine if User Wants to Contribute</name>
-    <instructions>
-      Before exploring the codebase, determine if the user wants to contribute the implementation:
-      
-      <ask_followup_question>
-      <question>Are you interested in implementing this feature yourself, or are you just reporting the problem for the Roo team to solve?</question>
-      <follow_up>
-      <suggest>Just reporting the problem - the Roo team can design the solution</suggest>
-      <suggest>I want to contribute and implement this feature myself</suggest>
-      <suggest>I'm not sure yet, but I'd like to provide technical analysis</suggest>
-      </follow_up>
-      </ask_followup_question>
-      
-      Based on their response:
-      - If just reporting: Skip to step 6 (Draft Issue - Problem Only)
-      - If contributing: Continue to step 5 (Explore Codebase)
-      - If providing analysis: Continue to step 5 but make technical sections optional
-    </instructions>
-  </step>
+  <steps>
+    <step number="1">
+      <name>Kickoff</name>
+      <instructions>
+        Rephrase the user's goal and outline a brief plan, then proceed without delay.
+        Maintain low narrative verbosity; use structured outputs for details.
+      </instructions>
+    </step>
 
-  <step number="5">
-    <name>Explore Codebase for Contributors</name>
-    <instructions>
-      ONLY perform this step if the user wants to contribute or provide technical analysis.
-      
-      Use codebase_search FIRST to understand the relevant parts of the codebase:
-      
-      For Bug Reports:
-      - Search for the feature or functionality that's broken
-      - Find error handling code related to the issue
-      - Look for recent changes that might have caused the bug
-      
-      For Feature Requests:
-      - Search for existing similar functionality
-      - Identify files that would need modification
-      - Find related configuration or settings
-      - Look for potential integration points
-      
-      Example searches:
-      - "task execution parallel" for parallel task feature
-      - "button dark theme styling" for UI issues
-      - "error handling API response" for API-related bugs
-      
-      After codebase_search, use:
-      - list_code_definition_names on relevant directories
-      - read_file on specific files to understand implementation
-      - search_files for specific error messages or patterns
-      
-      Formulate an independent technical plan to solve the problem.
-      
-      Document all relevant findings including:
-      - File paths and line numbers
-      - Current implementation details
-      - Your proposed implementation plan
-      - Related code that might be affected
-      
-      Then gather additional technical details:
-      - Ask for proposed solution approach
-      - Request acceptance criteria in Given/When/Then format
-      - Discuss technical considerations and trade-offs
-    </instructions>
-  </step>
+    <step number="2">
+      <name>Detect Current Repository Information</name>
+      <instructions>
+        Verify we're in a Git repository and capture the GitHub remote for safe submission.
 
-  <step number="6">
-    <name>Draft Issue Content</name>
-    <instructions>
-      Create the issue body based on whether the user is just reporting or contributing.
-      
-      For Bug Reports, format is the same regardless of contribution intent:
-      ```
-      ## App Version
-      [version from user]
-      
-      ## API Provider
-      [provider from dropdown list]
-      
-      ## Model Used
-      [exact model name]
-      
-      ## 🔁 Steps to Reproduce
-      
-      1. [First step with specific details]
-      2. [Second step with exact actions]
-      3. [Continue numbering all steps]
-      
-      Include:
-      - Exact button clicks or menu selections
-      - Specific input text or prompts used
-      - File names and paths involved
-      - Any settings or configuration
-      
-      ## 💥 Outcome Summary
-      
-      Expected: [what should have happened]
-      Actual: [what actually happened]
-      
-      ## 📄 Relevant Logs or Errors
-      
-      ```[language]
-      [paste any error messages or logs]
-      ```
-      
-      [If user is contributing, add:]
-      ## Technical Analysis
-      
-      Based on my investigation:
-      - The issue appears to be in [file:line]
-      - Related code: [brief description with file references]
-      - Possible cause: [technical explanation]
-      - **Proposed Fix:** [Detail the fix from your implementation plan.]
-      ```
-      
-      For Feature Requests - PROBLEM REPORTERS (not contributing):
-      ```
-      ## What specific problem does this solve?
-      
-      [Detailed problem description following the template guidelines]
-      
-      **Who is affected:** [user groups]
-      **When this happens:** [specific scenarios]
-      **Current behavior:** [what happens now]
-      **Expected behavior:** [what should happen]
-      **Impact:** [time wasted, errors, productivity loss]
-      
-      ## Additional context
-      
-      [Any mockups, screenshots, links, or other supporting information]
-      
-      ## Related Discussions
-      
-      [If any related discussions were found, list them here]
-      - Closes #[discussion number] - [discussion title]
-      - Related to #[discussion number] - [discussion title]
-      ```
-      
-      For Feature Requests - CONTRIBUTORS (implementing the feature):
-      ```
-      ## What specific problem does this solve?
-      
-      [Detailed problem description following the template guidelines]
-      
-      **Who is affected:** [user groups]
-      **When this happens:** [specific scenarios]
-      **Current behavior:** [what happens now]
-      **Expected behavior:** [what should happen]
-      **Impact:** [time wasted, errors, productivity loss]
-      
-      ## Additional context
-      
-      [Any mockups, screenshots, links, or other supporting information]
-      
-      ---
-      
-      ## 🛠️ Contributing & Technical Analysis
-      
-      ✅ **I'm interested in implementing this feature**
-      ✅ **I understand this needs approval before implementation begins**
-      
-      ## How should this be solved?
-      
-      [Based on your analysis, describe the proposed solution]
-      
-      **What will change:**
-      - [Specific change 1]
-      - [Specific change 2]
-      
-      **User interaction:**
-      - [How users will use this feature]
-      - [What they'll see in the UI]
-      
-      ## Acceptance Criteria
-      
-      ```
-      Given [context]
-      When [action]
-      Then [result]
-      And [additional expectation]
-      But [what should not happen]
-      ```
-      
-      [Add multiple scenarios as needed]
-      
-      ## Technical Considerations
-      
-      **Implementation approach:**
-      - Key files to modify: [list with paths]
-      - Current architecture: [brief description]
-      - Integration points: [where this fits]
-      - Similar patterns in codebase: [examples]
-      
-      **Performance implications:**
-      [Any performance considerations]
-      
-      **Compatibility concerns:**
-      [Any compatibility issues]
-      
-      ## Trade-offs and Risks
-      
-      **Alternatives considered:**
-      - [Alternative 1]: [Why not chosen]
-      - [Alternative 2]: [Why not chosen]
-      
-      **Potential risks:**
-      - [Risk 1]: [Mitigation strategy]
-      - [Risk 2]: [Mitigation strategy]
-      
-      **Breaking changes:**
-      [Any breaking changes or migration needs]
-      
-      ## Related Discussions
-      
-      [If any related discussions were found, list them here]
-      - Closes #[discussion number] - [discussion title]
-      - Related to #[discussion number] - [discussion title]
-      ```
-    </instructions>
-  </step>
+        1) Check if inside a git repository:
+        <execute_command>
+        <command>git rev-parse --is-inside-work-tree 2>/dev/null || echo "not-git-repo"</command>
+        </execute_command>
 
-  <step number="7">
-    <name>Review and Confirm with User</name>
-    <instructions>
-      Present the complete drafted issue to the user for review:
-      
-      <ask_followup_question>
-      <question>I've prepared the following GitHub issue. Please review it carefully:
+        If the output is "not-git-repo", stop:
+        <attempt_completion>
+        <result>
+        This mode must be run from within a GitHub repository. Navigate to a git repository and try again.
+        </result>
+        </attempt_completion>
 
-      [Show the complete formatted issue content]
+        2) Get origin remote and normalize to OWNER/REPO:
+        <execute_command>
+        <command>git remote get-url origin 2>/dev/null | sed -E 's/.*[:/]([^/]+)\/([^/]+)(\.git)?$/\1\/\2/' | sed 's/\.git$//'</command>
+        </execute_command>
 
-      Would you like me to create this issue, or would you like to make any changes?</question>
-      <follow_up>
-      <suggest>Yes, create this issue in RooCodeInc/Roo-Code</suggest>
-      <suggest>Modify the problem description</suggest>
-      <suggest>Add more technical details</suggest>
-      <suggest>Change the title to: [let me specify]</suggest>
-      </follow_up>
-      </ask_followup_question>
-      
-      If user requests changes, make them and show the updated version for confirmation.
-    </instructions>
-  </step>
+        If no origin remote exists, stop:
+        <attempt_completion>
+        <result>
+        No GitHub 'origin' remote found. Configure a GitHub remote and retry.
+        </result>
+        </attempt_completion>
 
-  <step number="8">
-    <name>Create GitHub Issue</name>
-    <instructions>
-      Once user confirms, create the issue using the GitHub MCP tool:
-      
-      <use_mcp_tool>
-      <server_name>github</server_name>
-      <tool_name>create_issue</tool_name>
-      <arguments>
-      {
-        "owner": "RooCodeInc",
-        "repo": "Roo-Code",
-        "title": "[Create a descriptive title based on the issue content]",
-        "body": "[The complete formatted issue body from step 6]",
-        "labels": [Use ["bug"] for bug reports or ["proposal", "enhancement"] for features]
-      }
-      </arguments>
-      </use_mcp_tool>
-      
-      After creation, inform the user of the issue number and URL.
-    </instructions>
-  </step>
+        Record the normalized OWNER/REPO (e.g., owner/repo) as [OWNER_REPO] to pass via --repo during submission.
+ 
+         3) Combined monorepo check and roots discovery (single command):
+         <execute_command>
+         <command>set -e; if ! git rev-parse --is-inside-work-tree >/dev/null 2>&1; then echo "not-git-repo"; exit 0; fi; OWNER_REPO=$(git remote get-url origin 2>/dev/null | sed -E 's/.*[:/]([^/]+)\/([^/]+)(\.git)?$/\1\/\2/' | sed 's/\.git$//'); IS_MONO=false; [ -f package.json ] && grep -q '"workspaces"' package.json && IS_MONO=true; for f in lerna.json pnpm-workspace.yaml rush.json; do [ -f "$f" ] && IS_MONO=true; done; ROOTS="."; if [ "$IS_MONO" = true ]; then ROOTS=$(git ls-files -z | tr '\0' '\n' | grep -E '^(apps|packages|services|libs)/[^/]+/package\.json$' | sed -E 's#/package\.json$##' | sort -u | paste -sd, -); [ -z "$ROOTS" ] && ROOTS=$(find . -maxdepth 3 -name package.json -not -path "./node_modules/*" -print0 | xargs -0 -n1 dirname | grep -E '^(\.|\.\/(apps|packages|services|libs)\/[^/]+)$' | sort -u | paste -sd, -); fi; echo "OWNER_REPO=$OWNER_REPO"; echo "IS_MONOREPO=$IS_MONO"; echo "ROOTS=$ROOTS"</command>
+         </execute_command>
+ 
+         Interpretation:
+         - If output contains OWNER_REPO, IS_MONOREPO, and ROOTS, record them and treat Step 3 as satisfied.
+         - If output is "not-git-repo", stop as above.
+         - If IS_MONOREPO=true but ROOTS is empty, perform Step 3 to determine roots manually.
+ 
+         <update_todo_list>
+           <todos>
+           [x] Detect repository context (OWNER/REPO, monorepo, roots)
+           [ ] Perform targeted codebase discovery (iteration N)
+           [ ] Clarify missing details (repro or desired outcome)
+           [ ] Classify type (Bug | Enhancement)
+           [ ] Assemble Issue Body
+           [ ] Review and submit (Submit now | Submit now and assign to me)
+           </todos>
+         </update_todo_list>
+      </instructions>
+    </step>
+
+    <step number="3">
+      <name>Determine Repository Structure (Monorepo/Standard)</name>
+      <instructions>
+        If Step 2's combined detection output includes IS_MONOREPO and ROOTS, mark this step complete and proceed to Step 4. Otherwise, use the manual process below.
+
+        Identify whether this is a monorepo and record the search root(s).
+
+        1) List top-level entries:
+        <list_files>
+        <path>.</path>
+        <recursive>false</recursive>
+        </list_files>
+
+        2) Monorepo indicators:
+        - package.json with "workspaces"
+        - lerna.json, pnpm-workspace.yaml, rush.json
+        - Top-level directories like apps/, packages/, services/, libs/
+
+        If monorepo is detected:
+        - Discover package roots by locating package.json files under these directories
+        - Prefer scoping searches to the package most aligned with the user's description
+        - Ask for package selection if ambiguous
+
+        If standard repository:
+        - Use repository root for searches
+
+        <update_todo_list>
+          <todos>
+          [x] Detect repository context (OWNER/REPO, monorepo, roots)
+          [-] Perform targeted codebase discovery (iteration N)
+          [ ] Clarify missing details (repro or desired outcome)
+          [ ] Classify type (Bug | Enhancement)
+          [ ] Assemble Issue Body
+          [ ] Review and submit (Submit now | Submit now and assign to me)
+          </todos>
+        </update_todo_list>
+      </instructions>
+    </step>
+
+    <step number="4">
+      <name>Codebase-Aware Context Discovery (Iterative)</name>
+      <instructions>
+        Purpose: Understand the context of the user's description by exploring the codebase. This step is repeatable.
+
+        Discovery workflow (respect one-tool-per-message):
+        1) Extract keywords, component names, error phrases, and concepts from the user's message or latest reply.
+        2) Run semantic search:
+        <codebase_search>
+        <query>[Keywords from user's description or latest reply]</query>
+        </codebase_search>
+
+        3) Refine with targeted regex where helpful:
+        <search_files>
+        <path>.</path>
+        <regex>[exact error strings|component names|feature flags]</regex>
+        </search_files>
+
+        4) Read key files for verification when necessary:
+        <read_file>
+        <path>[relevant file path from search hits]</path>
+        </read_file>
+
+        Guidance:
+        - Early-stop per iteration when top hits converge (~70%) or you can name the exact feature/component involved.
+        - Escalate-once per iteration if signals conflict: run one refined batch, then proceed.
+        - Keep findings internal; do NOT include file paths, line numbers, stack traces, or diffs in the final prompt.
+
+        Iteration rules:
+        - After ANY new user input or clarification, return to this step with updated keywords.
+        - Update internal notes and TODOs to reflect the current iteration (e.g., iteration 2, 3, ...).
+
+        <update_todo_list>
+          <todos>
+          [x] Detect repository context (OWNER/REPO, monorepo, roots)
+          [-] Perform targeted codebase discovery (iteration N)
+          [ ] Clarify missing details (repro or desired outcome)
+          [ ] Classify type (Bug | Enhancement)
+          [ ] Assemble Issue Body
+          [ ] Review and submit (Submit now | Submit now and assign to me)
+          </todos>
+        </update_todo_list>
+      </instructions>
+    </step>
+
+    <step number="5">
+      <name>Clarify Missing Details (Guided by Findings)</name>
+      <instructions>
+        Ask minimal, targeted questions grounded by what you found in code.
+
+        For Bug reports:
+        <ask_followup_question>
+        <question>I’m verifying the behavior around [feature/component inferred from code]. Could you provide a minimal reproduction and quick impact details?</question>
+        <follow_up>
+        <suggest>Repro format: 1) Environment/setup 2) Steps 3) Expected 4) Actual 5) Variations (only if you tried them)</suggest>
+        <suggest>Impact: Who is affected and how often does this happen?</suggest>
+        <suggest>Cost: Approximate time or outcome cost per occurrence (optional)</suggest>
+        </follow_up>
+        </ask_followup_question>
+
+        For Enhancements:
+        <ask_followup_question>
+        <question>To capture the improvement well, what is the user goal and value in plain language?</question>
+        <follow_up>
+        <suggest>State the user goal and when it occurs</suggest>
+        <suggest>Describe the desired behavior conceptually (no code)</suggest>
+        <suggest>Value: Who benefits and what improves (speed, clarity, fewer errors, conversions)?</suggest>
+        </follow_up>
+        </ask_followup_question>
+
+        Discrepancies:
+        - If you found contradictions between description and code, present concrete, plain-language examples (no code) and ask for confirmation.
+
+        Loop-back:
+        - After receiving any answer, return to Step 4 (Discovery) with the new information and repeat as needed.
+
+        <update_todo_list>
+          <todos>
+          [x] Detect repository context (OWNER/REPO, monorepo, roots)
+          [x] Perform targeted codebase discovery (iteration N)
+          [-] Clarify missing details (repro or desired outcome)
+          [ ] Classify type (Bug | Enhancement)
+          [ ] Assemble Issue Body
+          [ ] Review and submit (Submit now | Submit now and assign to me)
+          </todos>
+        </update_todo_list>
+      </instructions>
+    </step>
+
+    <step number="6">
+      <name>Classify Type (Provisional and Repeatable)</name>
+      <instructions>
+        Use the user's description plus verified findings to choose:
+        - Bug indicators: matched error strings; broken behavior in existing features; regression indicators.
+        - Enhancement indicators: capability absent; extension of existing feature; workflow improvement.
+        - Impact snapshot (optional): Severity (Blocker/High/Medium/Low) and Reach (Few/Some/Many). If uncertain, omit and proceed.
+
+        Confirm with the user if uncertain:
+        <ask_followup_question>
+        <question>Based on the behavior around [feature/component], should we frame this as a Bug or an Enhancement?</question>
+        <follow_up>
+        <suggest>Bug Report</suggest>
+        <suggest>Enhancement</suggest>
+        </follow_up>
+        </ask_followup_question>
+
+        Reclassification:
+        - If later evidence or user info changes the type, reclassify and loop back to Step 4 for a fresh discovery iteration.
+
+        <update_todo_list>
+          <todos>
+          [x] Detect repository context (OWNER/REPO, monorepo, roots)
+          [x] Perform targeted codebase discovery (iteration N)
+          [x] Clarify missing details (repro or desired outcome)
+          [-] Classify type (Bug | Enhancement)
+          [ ] Assemble Issue Body
+          [ ] Review and submit (Submit now | Submit now and assign to me)
+          </todos>
+        </update_todo_list>
+      </instructions>
+    </step>
+
+    <step number="7">
+      <name>Assemble Issue Body</name>
+      <instructions>
+        Build a concise, non-technical issue body. Omit empty sections entirely.
+
+        Format:
+        ```
+        ## Type
+        Bug | Enhancement
+
+        ## Problem / Value
+        [One or two sentences that capture the problem and why it matters in plain language]
+
+        ## Context
+        [Who is affected and when it happens]
+        [Enhancement: desired behavior conceptually, in the user's words]
+        [Bug: current observed behavior in plain language]
+
+        ## Reproduction (Bug only, if available)
+        1) Steps (each action/command)
+        2) Expected result
+        3) Actual result
+        4) Variations tried (include only if the user explicitly provided them)
+
+        ## Constraints/Preferences
+        [Performance, accessibility, UX, or other considerations]
+        ```
+
+        Rules:
+        - Keep non-technical; do NOT include code paths, line numbers, stack traces, or diffs.
+        - Ground the wording in verified behavior, but keep implementation details internal.
+        - Sourcing: Do not infer or fabricate reproduction details or “Variations tried.” Include them only if explicitly provided by the user; otherwise omit the line.
+        - Quoting fidelity: If the user lists “Variations tried,” include them faithfully (verbatim or clearly paraphrased without adding new items).
+        - Value framing: Ensure the “Problem / Value” explains why it matters (impact on users or outcomes) in plain language.
+        - Title: Produce a concise Title (≤ 80 chars) prefixed with [BUG] or [ENHANCEMENT]; when helpful, append a brief value phrase in parentheses, e.g., “(blocks new runs)”.
+
+        Iteration note:
+        - If new info arrives after drafting, loop back to Step 4, then update this draft accordingly.
+
+        <update_todo_list>
+          <todos>
+          [x] Detect repository context (OWNER/REPO, monorepo, roots)
+          [x] Perform targeted codebase discovery (iteration N)
+          [x] Clarify missing details (repro or desired outcome)
+          [x] Classify type (Bug | Enhancement)
+          [-] Assemble Issue Body
+          [ ] Review and submit (Submit now | Submit now and assign to me)
+          </todos>
+        </update_todo_list>
+      </instructions>
+    </step>
+
+    <step number="8">
+      <name>Review and Submit (Single-Step)</name>
+      <instructions>
+        Present the full current issue details in a code block. Offer two submission options; any other response is treated as a change request.
+
+        <ask_followup_question>
+        <question>Review the current issue details. Select one of the options below or specify any changes or other workflow you would like me to perform:
+
+```md
+Title: [ISSUE_TITLE]
+
+[ISSUE_BODY]
+```</question>
+        <follow_up>
+        <suggest>Submit now</suggest>
+        <suggest>Submit now and assign to me</suggest>
+        </follow_up>
+        </ask_followup_question>
+
+        Responses:
+        - If "Submit now":
+          Prepare:
+            - Title: derive from Summary (≤ 80 chars, plain language)
+            - Body: the finalized issue body
+
+          Execute:
+          <execute_command>
+          <command>gh issue create --repo "[OWNER_REPO]" --title "[ISSUE_TITLE]" --body "$(printf '%s\n' "[ISSUE_BODY]")"</command>
+          </execute_command>
+
+        - If "Submit now and assign to me":
+          Execute (assignment at creation; falls back to edit if needed):
+          <execute_command>
+          <command>ISSUE_URL=$(gh issue create --repo "[OWNER_REPO]" --title "[ISSUE_TITLE]" --body "$(printf '%s\n' "[ISSUE_BODY]")" --assignee "@me") || true; if [ -z "$ISSUE_URL" ]; then ISSUE_URL=$(gh issue create --repo "[OWNER_REPO]" --title "[ISSUE_TITLE]" --body "$(printf '%s\n' "[ISSUE_BODY]")"); gh issue edit "$ISSUE_URL" --add-assignee "@me"; fi; echo "$ISSUE_URL"</command>
+          </execute_command>
+
+        - Any other response:
+          - Collect requested edits and apply them
+          - Loop back to Step 4 (Discovery) if new information affects context
+          - Re-assemble in Step 7
+          - Rerun this step and present the updated issue details
+
+        On success: Capture the created issue URL from stdout and complete:
+        <attempt_completion>
+        <result>
+        Created issue: [URL]
+        </result>
+        </attempt_completion>
+
+        On failure: Present the error succinctly and offer to retry after fixing gh setup (installation/auth). Provide the computed Title and Body inline so the user can submit manually if needed.
+
+        <update_todo_list>
+          <todos>
+          [x] Detect repository context (OWNER/REPO, monorepo, roots)
+          [x] Perform targeted codebase discovery (iteration N)
+          [x] Clarify missing details (repro or desired outcome)
+          [x] Classify type (Bug | Enhancement)
+          [x] Assemble Issue Body
+          [x] Review and submit (Submit now | Submit now and assign to me)
+          </todos>
+        </update_todo_list>
+      </instructions>
+    </step>
+  </steps>
+
+  <completion_criteria>
+    <criterion>Repository detection (git repo present and origin remote configured) is performed before any submission.</criterion>
+    <criterion>Issue is submitted via gh after choosing "Submit now" or "Submit now and assign to me", and the created issue URL is returned.</criterion>
+    <criterion>When "Submit now and assign to me" is chosen, the issue is assigned to the current GitHub user using --assignee "@me" (or gh issue edit fallback).</criterion>
+    <criterion>Submission uses Title and Body only and specifies --repo [OWNER_REPO] discovered in Step 2; no temporary files or file paths are used.</criterion>
+    <criterion>Language is plain and user-centric; no technical artifacts included in the issue body.</criterion>
+    <criterion>Content grounded by repeated codebase exploration cycles as needed.</criterion>
+    <criterion>Early-stop/escalate-once applied per iteration; unlimited iterations across the conversation.</criterion>
+    <criterion>The merged step offers "Submit now" or "Submit now and assign to me"; any other response is treated as a change request and the step is shown again with the full current issue details.</criterion>
+  </completion_criteria>
 </workflow>

.roo/rules-issue-writer/2_github_issue_templates.xml

@@ -1,219 +0,0 @@
-<github_issue_templates>
-  <bug_report_template>
-    <name>Bug Report</name>
-    <description>Clearly report a bug with detailed repro steps</description>
-    <labels>["bug"]</labels>
-    <fields>
-      <field name="version" type="input" required="true">
-        <label>App Version</label>
-        <description>What version of Roo Code are you using? (e.g., v3.3.1)</description>
-      </field>
-      <field name="provider" type="dropdown" required="true">
-        <label>API Provider</label>
-        <options>
-          - Anthropic
-          - AWS Bedrock
-          - Chutes AI
-          - DeepSeek
-          - Glama
-          - Google Gemini
-          - Google Vertex AI
-          - Groq
-          - Human Relay Provider
-          - LiteLLM
-          - LM Studio
-          - Mistral AI
-          - Ollama
-          - OpenAI
-          - OpenAI Compatible
-          - OpenRouter
-          - Requesty
-          - Unbound
-          - VS Code Language Model API
-          - xAI (Grok)
-          - Not Applicable / Other
-        </options>
-      </field>
-      <field name="model" type="input" required="true">
-        <label>Model Used</label>
-        <description>Exact model name (e.g., Claude 3.7 Sonnet). Use N/A if irrelevant.</description>
-      </field>
-      <field name="steps" type="textarea" required="true">
-        <label>🔁 Steps to Reproduce</label>
-        <description>
-          Help us see what you saw. Give clear, numbered steps:
-          
-          1. Setup (OS, extension version, settings)
-          2. Exact actions (clicks, input, files, commands)
-          3. What happened after each step
-          
-          Think like you're writing a recipe. Without this, we can't reproduce the issue.
-        </description>
-      </field>
-      <field name="what-happened" type="textarea" required="true">
-        <label>💥 Outcome Summary</label>
-        <description>
-          Recap what went wrong in one or two lines.
-          
-          Example: "Expected code to run, but got an empty response and no error."
-        </description>
-        <placeholder>Expected ___, but got ___.</placeholder>
-      </field>
-      <field name="logs" type="textarea" required="false">
-        <label>📄 Relevant Logs or Errors (Optional)</label>
-        <description>Paste API logs, terminal output, or errors here. Use triple backticks (```) for code formatting.</description>
-        <render>shell</render>
-      </field>
-    </fields>
-  </bug_report_template>
-  
-  <feature_request_template>
-    <name>Detailed Feature Proposal</name>
-    <description>Report a specific problem that needs solving in Roo Code</description>
-    <labels>["proposal", "enhancement"]</labels>
-    <required_fields>
-      <field name="problem-description" type="textarea" required="true">
-        <label>What specific problem does this solve?</label>
-        <description>
-          **Be concrete and detailed.** Explain the problem from a user's perspective.
-          
-          ✅ **Good examples (specific, clear impact):**
-          - "When running large tasks, users wait 5+ minutes because tasks execute sequentially instead of in parallel, blocking productivity"
-          - "AI can only read one file per request, forcing users to make multiple requests for multi-file projects, increasing wait time from 30s to 5+ minutes"
-          - "Dark theme users can't see the submit button because it uses white text on light grey background"
-          
-          ❌ **Poor examples (vague, unclear impact):**
-          - "The UI looks weird" -> What specifically looks weird? On which screen? What's the impact?
-          - "System prompt is not good" -> What's wrong with it? What behaviour does it cause? What should it do instead?
-          - "Performance could be better" -> Where? How slow is it currently? What's the user impact?
-          
-          **Your problem description should answer:**
-          - Who is affected? (all users, specific user types, etc.)
-          - When does this happen? (specific scenarios/steps)
-          - What's the current behaviour vs expected behaviour?
-          - What's the impact? (time wasted, errors caused, etc.)
-        </description>
-        <placeholder>Be specific about the problem, who it affects, and the impact. Avoid generic statements like "it's slow" or "it's confusing."</placeholder>
-      </field>
-      <field name="additional-context" type="textarea" required="false">
-        <label>Additional context (optional)</label>
-        <description>Mockups, screenshots, links, user quotes, or other relevant information that supports your proposal.</description>
-      </field>
-    </required_fields>
-    
-    <contributor_fields>
-      <field name="willingness-to-contribute" type="checkbox">
-        <label>Interested in implementing this?</label>
-        <description>
-          **Important:** If you check "Yes" below, the technical sections become REQUIRED.
-          We need detailed technical analysis from contributors to ensure quality implementation.
-        </description>
-        <option>Yes, I'd like to help implement this feature</option>
-      </field>
-      <field name="implementation-approval" type="checkbox">
-        <label>Implementation requirements</label>
-        <option>I understand this needs approval before implementation begins</option>
-      </field>
-      <field name="proposed-solution" type="textarea" required_if_contributing="true">
-        <label>How should this be solved? (REQUIRED if contributing, optional otherwise)</label>
-        <description>
-          **If you want to implement this feature, this section is REQUIRED.**
-          
-          **Describe your solution in detail.** Explain not just what to build, but how it should work.
-          
-          ✅ **Good examples:**
-          - "Add parallel task execution: Allow up to 3 tasks to run simultaneously with a queue system for additional tasks. Show progress for each active task in the UI."
-          - "Enable multi-file AI processing: Modify the request handler to accept multiple files in a single request and process them together, reducing round trips."
-          - "Fix button contrast: Change submit button to use primary colour on dark theme (white text on blue background) instead of current grey."
-          
-          ❌ **Poor examples:**
-          - "Make it faster" -> How? What specific changes?
-          - "Improve the UI" -> Which part? What specific improvements?
-          - "Fix the prompt" -> What should the new prompt do differently?
-          
-          **Your solution should explain:**
-          - What exactly will change?
-          - How will users interact with it?
-          - What will the new behaviour look like?
-        </description>
-        <placeholder>Describe the specific changes and how they will work. Include user interaction details if relevant.</placeholder>
-      </field>
-      <field name="acceptance-criteria" type="textarea" required_if_contributing="true">
-        <label>How will we know it works? (Acceptance Criteria - REQUIRED if contributing, optional otherwise)</label>
-        <description>
-          **If you want to implement this feature, this section is REQUIRED.**
-          
-          **This is crucial - don't skip it.** Define what "working" looks like with specific, testable criteria.
-          
-          **Format suggestion:**
-          ```
-          Given [context/situation]
-          When [user action]
-          Then [expected result]
-          And [additional expectations]
-          But [what should NOT happen]
-          ```
-          
-          **Example:**
-          ```
-          Given I have 5 large tasks to run
-          When I start all of them
-          Then they execute in parallel (max 3 at once, can be configured)
-          And I see progress for each active task
-          And queued tasks show "waiting" status
-          But the UI doesn't freeze or become unresponsive
-          ```
-        </description>
-        <placeholder>
-          Define specific, testable criteria. What should users be able to do? What should happen? What should NOT happen?
-          Use the Given/When/Then format above or your own clear structure.
-        </placeholder>
-      </field>
-      <field name="technical-considerations" type="textarea" required_if_contributing="true">
-        <label>Technical considerations (REQUIRED if contributing, optional otherwise)</label>
-        <description>
-          **If you want to implement this feature, this section is REQUIRED.**
-          
-          Share technical insights that could help planning:
-          - Implementation approach or architecture changes
-          - Performance implications
-          - Compatibility concerns
-          - Systems that might be affected
-          - Potential blockers you can foresee
-        </description>
-        <placeholder>e.g., "Will need to refactor task manager", "Could impact memory usage on large files", "Requires a large portion of code to be rewritten"</placeholder>
-      </field>
-      <field name="trade-offs-and-risks" type="textarea" required_if_contributing="true">
-        <label>Trade-offs and risks (REQUIRED if contributing, optional otherwise)</label>
-        <description>
-          **If you want to implement this feature, this section is REQUIRED.**
-          
-          What could go wrong or what alternatives did you consider?
-          - Alternative approaches and why you chose this one
-          - Potential negative impacts (performance, UX, etc.)
-          - Breaking changes or migration concerns
-          - Edge cases that need careful handling
-        </description>
-        <placeholder>e.g., "Alternative: use library X but it is 500KB larger", "Risk: might slow older devices", "Breaking: changes API response format"</placeholder>
-      </field>
-    </contributor_fields>
-  </feature_request_template>
-  
-  <template_changes_summary>
-    <change type="focus_shift">
-      Template now focuses on problem reporting first, with solution contribution as optional
-    </change>
-    <change type="required_fields">
-      Only problem description and context are required for basic submission
-    </change>
-    <change type="contributor_section">
-      Technical fields (solution, acceptance criteria, etc.) are only required if user wants to contribute
-    </change>
-    <change type="clear_exit_point">
-      Users can submit after describing the problem without technical details
-    </change>
-    <change type="guidance_separation">
-      Implementation guidance moved to contributor section only
-    </change>
-  </template_changes_summary>
-</github_issue_templates>

.roo/rules-issue-writer/3_best_practices.xml

@@ -1,38 +1,147 @@
 <best_practices>
-  <problem_reporting_focus>
-    - Focus on helping users describe problems clearly, not solutions
-    - The Roo team will design solutions unless the user explicitly wants to contribute
-    - Don't push users to provide technical details they may not have
-    - Make it easy for non-technical users to report issues effectively
-  </problem_reporting_focus>
-  
-  <general_practices>
-    - Always search for existing similar issues before creating a new one
-    - Search GitHub Discussions (especially feature-requests category) for related topics
-    - Include specific version numbers and environment details
-    - Use code blocks with syntax highlighting for code snippets
-    - Make titles descriptive but concise (e.g., "Dark theme: Submit button invisible due to white-on-grey text")
-    - For bugs, always test if the issue is reproducible
-    - Include screenshots or mockups when relevant (ask user to provide)
-    - Link to related issues or PRs if found during exploration
-    - Add "Closes #[number]" for discussions that would be fully addressed by the issue
-    - Add "Related to #[number]" for partially related discussions
-  </general_practices>
-  
-  <contributor_specific>
-    - Only explore codebase if user wants to contribute
-    - Reference specific files and line numbers from codebase exploration
-    - Ensure technical proposals align with project architecture
-    - Include implementation steps and technical analysis
-    - Provide clear acceptance criteria in Given/When/Then format
-    - Consider trade-offs and alternative approaches
-  </contributor_specific>
-  
+  <mode_scope>
+    This mode assembles a template-free issue body grounded by codebase exploration and can submit it via GitHub CLI after explicit confirmation.
+    Submission uses Title and Body only and targets the detected repository after the merged Review and Submit step.
+  </mode_scope>
+
+  <mode_behavior>
+    - Treat the user's FIRST message as the issue description; do not ask if they want to create an issue.
+    - Start with repository detection (verify git repo; resolve OWNER/REPO from origin), then determine repository structure (monorepo/standard).
+    - After detection, begin codebase discovery scoped to the repository root or the selected package (in monorepos).
+    - Keep final output non-technical; implementation details remain internal.
+  </mode_behavior>
+
+  <value_framing>
+    <principles>
+      - Always pair the problem with user-facing value: who is impacted, when it occurs, and why it matters.
+      - Keep value non-technical (clarity, time saved, fewer errors, better UX, improved accessibility, reduced confusion).
+    </principles>
+    <lightweight_impact_options>
+      - Severity: Blocker | High | Medium | Low (optional)
+      - Reach: Few | Some | Many (optional)
+    </lightweight_impact_options>
+  </value_framing>
+
+  <sourcing_and_provenance>
+    <direct_from_user_only>
+      - Reproduction steps
+      - Variations tried
+      - Environment details
+    </direct_from_user_only>
+    <inference_allowed_with_care>
+      - Problem/Value statement (plain-language synthesis from user wording)
+      - Context (who/when) based on user input; keep code-based signals internal
+    </inference_allowed_with_care>
+    <hallucination_guards>
+      - Never fabricate “Variations tried.” If not provided, omit.
+      - If critical details are missing, ask targeted questions; otherwise proceed with omissions.
+    </hallucination_guards>
+  </sourcing_and_provenance>
+
+  <cli_submission>
+    <confirmation>
+      Use a single merged "Review and Submit" step with options:
+      - Submit now
+      - Submit now and assign to me
+      Any other response is treated as a change request and the step is rerun after applying edits.
+    </confirmation>
+    <repo_detection>
+      Submission requires repository detection (git present, origin configured). Capture normalized OWNER/REPO (e.g., owner/repo) and store as [OWNER_REPO] for submission.
+    </repo_detection>
+    <target_repo>
+      Always specify the target using --repo "[OWNER_REPO]" to avoid ambiguity and ensure the correct repository is used.
+    </target_repo>
+    <assignment>
+      When "Submit now and assign to me" is chosen, create using: --assignee "@me".
+      If creation with --assignee fails (e.g., permissions), create the issue without an assignee and immediately run:
+      gh issue edit <issue-url-or-number> --add-assignee "@me".
+    </assignment>
+    <command_safety>
+      Use --body with robust quoting (for example: --body "$(printf '%s\n' "[ISSUE_BODY]")") or a heredoc; do not create temporary files or reference file paths. Always include --repo "[OWNER_REPO]" and echo the resulting issue URL.
+      In execute_command calls, output only the command string; never include XML tags, CDATA markers, code fences, or backticks in the command payload.
+    </command_safety>
+    <error_handling>
+      On gh errors (installation/auth), present the error and offer to retry after fixing gh setup. Surface the computed Title and Body inline
+      so the user can submit manually if needed.
+    </error_handling>
+  </cli_submission>
+
+  <codebase_exploration>
+    <principles>
+      - Use semantic search first to find relevant areas.
+      - Refine with targeted regex for exact strings (errors, component names, flags).
+      - Read key files to verify behavior; keep evidence internal.
+      - Early-stop when hits converge (~70%) or you can name the exact feature/component.
+      - Escalate-once if signals conflict; run one refined batch, then proceed.
+    </principles>
+    <tool_sequence>
+      1) codebase_search → 2) search_files → 3) read_file (as needed)
+    </tool_sequence>
+    <scoping>
+      In monorepos, scope searches to the selected package when the context is clear; otherwise ask for the relevant package/app if ambiguous.
+    </scoping>
+    <internal_only>
+      Keep language plain and exclude technical artifacts (paths, line numbers, stack traces, diffs) from the final issue body.
+    </internal_only>
+  </codebase_exploration>
+
+  <questioning>
+    <guidelines>
+      - Ask minimal, targeted questions based on what you found in code.
+      - For bugs: request a minimal reproduction (environment, steps, expected, actual, variations).
+      - For enhancements: capture user goal, desired behavior in plain language, and any constraints.
+      - Present discrepancies in plain language (no code) and confirm understanding.
+    </guidelines>
+  </questioning>
+
+  <issue_output_rules>
+    <format>
+      <![CDATA[
+## Type
+Bug | Enhancement
+
+## Problem / Value
+[One or two sentences that capture the problem and why it matters in plain language]
+
+## Context
+[Who is affected and when it happens]
+[Enhancement: desired behavior conceptually, in the user's words]
+[Bug: current observed behavior in plain language]
+
+## Reproduction (Bug only, if available)
+1) Steps (each action/command)
+2) Expected result
+3) Actual result
+4) Variations tried (only if explicitly provided)
+
+## Constraints/Preferences
+[Performance, accessibility, UX, or other considerations]
+      ]]>
+    </format>
+    <rules>
+      - Omit sections that would be empty.
+      - Do not include "Variations tried" unless explicitly provided by the user.
+      - Keep language plain and user-centric.
+      - Exclude technical artifacts (paths, lines, stacks, diffs).
+    </rules>
+  </issue_output_rules>
+
+  <review_stage_presentation>
+    - At each review stage, present the full current issue details (Title + Body) in a markdown code block.
+    - Offer "Submit now" or "Submit now and assign to me" suggestions; treat any other response as a change request and rerun the step after applying edits.
+  </review_stage_presentation>
+
+  <autonomy_and_budgets>
+    - Tool preambles: restate goal briefly, outline a short plan, narrate progress succinctly, summarize final delta.
+    - One-tool-per-message: await results before continuing.
+    - Discovery budget: default max 3 searches before escalate-once; stop when sufficient.
+    - Early-stop: when top hits converge or target is identifiable.
+    - Verbosity: low narrative; detail appears only in structured outputs.
+  </autonomy_and_budgets>
+
   <communication_guidelines>
-    - Be supportive and encouraging to problem reporters
-    - Don't overwhelm users with technical questions upfront
-    - Clearly indicate when technical sections are optional
-    - Guide contributors through the additional requirements
-    - Make the "submit now" option clear for problem reporters
+    - Be direct and concise; avoid jargon in the final issue body.
+    - Keep questions optional and easy to answer with suggested options.
+    - Emphasize WHO is affected and WHEN it happens.
   </communication_guidelines>
 </best_practices>

.roo/rules-issue-writer/4_common_mistakes_to_avoid.xml

@@ -1,30 +1,109 @@
 <common_mistakes_to_avoid>
+  <mode_initialization_mistakes>
+    - Asking "What would you like to do?" at start instead of treating the first message as the issue description
+    - Delaying the workflow with unnecessary questions before discovery
+    - Not immediately beginning codebase-aware discovery (semantic search → regex refine → read key files)
+    - Skipping repository detection (git + origin) before discovery or submission
+    - Not validating repository context before gh commands
+  </mode_initialization_mistakes>
+
+  <scope_mistakes>
+    - Submitting without explicit user confirmation ("Submit now")
+    - Targeting the wrong repository by relying on current directory defaults; always pass --repo OWNER/REPO detected in Step 2
+    - Performing PR prep, complexity estimates, or technical scoping
+  </scope_mistakes>
+
+  <submission_mistakes>
+    <mistake_block>
+      <mistake>Splitting final review and submission into multiple steps</mistake>
+      <impact>Creates redundant prompts and inconsistent state; leads to janky UX</impact>
+      <correct_approach>Use a single merged "Review and Submit" step offering only: Submit now, Submit now and assign to me; treat any other response as a change request</correct_approach>
+    </mistake_block>
+    <mistake_block>
+      <mistake>Not offering "Submit now and assign to me"</mistake>
+      <impact>Forces manual assignment later; reduces efficiency</impact>
+      <correct_approach>Provide the assignment option and use gh issue create --assignee "@me"; if that fails, immediately run gh issue edit <issue-url-or-number> --add-assignee "@me"</correct_approach>
+    </mistake_block>
+    <mistake_block>
+      <mistake>Using temporary files or --body-file for issue body submission</mistake>
+      <impact>Introduces filesystem dependencies and leaks paths; contradicts single-command policy</impact>
+      <correct_approach>Use inline --body with robust quoting, e.g., --body "$(printf '%s\n' "[ISSUE_BODY]")"; do not reference any file paths</correct_approach>
+    </mistake_block>
+    <mistake_block>
+      <mistake>Omitting --repo or relying on current directory defaults</mistake>
+      <impact>May submit to the wrong repository in multi-repo or worktree contexts</impact>
+      <correct_approach>Always pass --repo [OWNER_REPO] detected in Step 2</correct_approach>
+    </mistake_block>
+    <mistake_block>
+      <mistake>Attempting submission without prior repository detection</mistake>
+      <impact>Commands may target the wrong repo or fail</impact>
+      <correct_approach>Detect git repo and ensure origin is configured before any gh commands</correct_approach>
+    </mistake_block>
+  </submission_mistakes>
+
+  <sourcing_mistakes>
+    <mistake_block>
+      <mistake>Inventing or inferring “Variations tried” when the user didn’t provide any</mistake>
+      <impact>Misleads triage and wastes time reproducing non-existent attempts</impact>
+      <correct_approach>Omit the “Variations tried” line entirely unless explicitly provided; if needed, ask a targeted question first</correct_approach>
+    </mistake_block>
+    <mistake_block>
+      <mistake>Framing only the problem without the value/impact</mistake>
+      <impact>Makes prioritization harder; obscures who benefits and why it matters</impact>
+      <correct_approach>Pair the problem with a plain-language value statement (who, when, why it matters)</correct_approach>
+    </mistake_block>
+    <mistake_block>
+      <mistake>Overstating impact without user signal</mistake>
+      <impact>Damages credibility and misguides prioritization</impact>
+      <correct_approach>Use conservative, plain language; if unsure, omit severity/reach or ask a single targeted question</correct_approach>
+    </mistake_block>
+  </sourcing_mistakes>
+
   <problem_reporting_mistakes>
-    - Vague descriptions like "doesn't work" or "broken"
-    - Missing reproduction steps for bugs
-    - Feature requests without clear problem statements
-    - Not explaining the impact on users
-    - Forgetting to specify when/how the problem occurs
-    - Using wrong labels or no labels
-    - Titles that don't summarize the issue
-    - Not checking for duplicates
+    - Vague descriptions like "doesn't work" without who/when impact
+    - Missing minimal reproduction for bugs (environment, steps, expected, actual, variations)
+    - Enhancement requests that skip the user goal or desired behavior in plain language
+    - Titles/summaries that don't quickly communicate the issue
   </problem_reporting_mistakes>
-  
-  <workflow_mistakes>
-    - Asking for technical details from non-contributing users
-    - Exploring codebase before confirming user wants to contribute
-    - Requiring acceptance criteria from problem reporters
-    - Making the process too complex for simple problem reports
-    - Not clearly indicating the "submit now" option
-    - Overwhelming users with contributor requirements upfront
-  </workflow_mistakes>
-  
-  <contributor_mistakes>
-    - Starting implementation before approval
-    - Not providing detailed technical analysis when contributing
-    - Missing acceptance criteria for contributed features
-    - Forgetting to include technical context from code exploration
-    - Not considering trade-offs and alternatives
-    - Proposing solutions without understanding current architecture
-  </contributor_mistakes>
+
+  <output_mistakes>
+    - Including code paths, line numbers, stack traces, or diffs in the final issue body
+    - Adding labels, metadata, or repository details to the body
+    - Leaving empty section placeholders instead of omitting the section
+    - Using technical jargon instead of plain, user-centric language
+  </output_mistakes>
+
+  <code_exploration_mistakes>
+    <mistake>Skipping semantic search and jumping straight to assumptions</mistake>
+    <impact>Leads to misclassification and inaccurate context</impact>
+    <correct_approach>
+      - Start with codebase_search on extracted keywords
+      - Refine with search_files for exact strings (errors, component names, flags)
+      - read_file only as needed to verify behavior; keep evidence internal
+      - Early-stop when hits converge or you can name the exact feature/component
+      - Escalate-once if signals conflict (one refined pass), then proceed
+    </correct_approach>
+  </code_exploration_mistakes>
+
+  <discrepancy_handling_mistakes>
+    <mistake>Accepting user claims that contradict the codebase without verification</mistake>
+    <impact>Produces misleading or incorrect issue framing</impact>
+    <correct_approach>
+      - Verify claims against the implementation; trace data from creation → usage
+      - Compare with similar working features to ground expectations
+      - If discrepancies arise, present concrete, plain-language examples (no code) and confirm
+    </correct_approach>
+  </discrepancy_handling_mistakes>
+
+  <questioning_mistakes>
+    - Asking broad, unfocused questions instead of targeted ones based on findings
+    - Demanding technical details from non-technical users
+    - Failing to provide easy, suggested answer formats (repro scaffold, goal statement)
+  </questioning_mistakes>
+
+  <consistency_mistakes>
+    - Mixing internal technical evidence into the final body
+    - Ignoring the issue format or adding extra sections
+    - Using inconsistent tone or switching between technical and non-technical language
+  </consistency_mistakes>
 </common_mistakes_to_avoid>

.roo/rules-issue-writer/5_examples.xml

@@ -0,0 +1,134 @@
+<issue_examples>
+  <overview>
+    Examples of assembling template-free issue prompts grounded by codebase exploration, with optional CLI submission after explicit confirmation.
+    Repository detection precedes submission; review and submission occur in a single merged step offering "Submit now" or "Submit now and assign to me". Any other response is treated as a change request.
+  </overview>
+
+  <example name="bug_dark_theme_button_invisible">
+    <user_input>
+      In dark theme the Submit button is almost invisible on the New Run page.
+    </user_input>
+    <discovery>
+      <tool_calls>
+        <![CDATA[
+<codebase_search>
+<query>dark theme submit button visibility</query>
+</codebase_search>
+
+<search_files>
+<path>.</path>
+<regex>Submit|button|dark|theme</regex>
+</search_files>
+        ]]>
+      </tool_calls>
+      <notes>
+        Internal: matches found in UI components related to theme; wording grounded to user impact.
+      </notes>
+    </discovery>
+    <final_issue_body><![CDATA[
+## Type
+Bug
+
+## Problem / Value
+In dark theme, the Submit button is hard to see on the new run form, making it difficult for users to complete new runs.
+
+## Context
+Affects users creating new runs with dark theme enabled; the button appears low-contrast and is difficult to locate.
+
+## Reproduction
+1) Steps: Open "New Run" -> Scroll to bottom -> Look for Submit
+2) Expected result: Clearly visible, high-contrast Submit button
+3) Actual result: Button appears nearly invisible in dark theme
+4) Variations tried: Different browsers (Chrome/Firefox) show same result
+    ]]></final_issue_body>
+  </example>
+
+  <example name="enhancement_copy_run_confirmation">
+    <user_input>
+      I accidentally click "Copy Run" sometimes; would be great to have a simple confirmation.
+    </user_input>
+    <discovery>
+      <tool_calls>
+        <![CDATA[
+<codebase_search>
+<query>Copy Run confirmation</query>
+</codebase_search>
+        ]]>
+      </tool_calls>
+      <notes>
+        Internal: feature entry point identified; keep final output non-technical and user-centric.
+      </notes>
+    </discovery>
+    <final_issue_body><![CDATA[
+## Type
+Enhancement
+
+## Problem / Value
+Add a confirmation dialog before copying an existing run to prevent accidental duplication.
+
+## Context
+Users sometimes click "Copy Run" by mistake when browsing runs; a simple confirmation would prevent accidental duplication.
+
+## Constraints/Preferences
+Keep the flow lightweight and unobtrusive; avoid slowing down intentional copies.
+    ]]></final_issue_body>
+  </example>
+
+  <example name="bug_submission_review_and_assign">
+    <user_input>
+      Dark theme Submit button is invisible; I'd like to file this.
+    </user_input>
+    <final_issue_body><![CDATA[
+## Type
+Bug
+
+## Problem / Value
+In dark theme, the Submit button is hard to see on the new run form, making it difficult for users to complete new runs.
+
+## Context
+Affects users creating new runs with dark theme enabled; the button appears low-contrast and is difficult to locate.
+
+## Reproduction
+1) Steps: Open "New Run" -> Scroll to bottom -> Look for Submit
+2) Expected result: Clearly visible, high-contrast Submit button
+3) Actual result: Button appears nearly invisible in dark theme
+    ]]></final_issue_body>
+    <review_and_submit>
+      <ask_followup_question>
+        <question>Review the current issue details. Select one of the options below or specify any changes or other workflow you would like me to perform:
+
+```md
+Title: [ISSUE_TITLE]
+
+[ISSUE_BODY]
+```</question>
+        <follow_up>
+          <suggest>Submit now</suggest>
+          <suggest>Submit now and assign to me</suggest>
+        </follow_up>
+      </ask_followup_question>
+
+      <execute_command for="submit_now">
+        <command>gh issue create --repo "[OWNER_REPO]" --title "[ISSUE_TITLE]" --body "$(printf '%s\n' "[ISSUE_BODY]")"</command>
+      </execute_command>
+
+      <execute_command for="submit_now_and_assign_to_me">
+        <command>ISSUE_URL=$(gh issue create --repo "[OWNER_REPO]" --title "[ISSUE_TITLE]" --body "$(printf '%s\n' "[ISSUE_BODY]")" --assignee "@me") || true; if [ -z "$ISSUE_URL" ]; then ISSUE_URL=$(gh issue create --repo "[OWNER_REPO]" --title "[ISSUE_TITLE]" --body "$(printf '%s\n' "[ISSUE_BODY]")"); gh issue edit "$ISSUE_URL" --add-assignee "@me"; fi; echo "$ISSUE_URL"</command>
+      </execute_command>
+
+      <loopback_note>
+        If a change request is provided, collect the requested edits, update the draft (re-run discovery if new info affects context), then rerun this merged step.
+      </loopback_note>
+
+      <expected_output>https://github.com/OWNER/REPO/issues/123</expected_output>
+    </review_and_submit>
+  </example>
+
+  <policies>
+    <policy>Issues are template-free (Title + Body only).</policy>
+    <policy>Repository detection (git + origin → OWNER/REPO) occurs before submission and is passed explicitly via --repo [OWNER_REPO].</policy>
+    <policy>Never use --body-file or temporary files; submit with inline --body only (no file paths).</policy>
+    <policy>Review and submission happen in one merged step offering "Submit now" or "Submit now and assign to me"; any other response is treated as a change request.</policy>
+    <policy>All discovery is internal; keep final output plain-language.</policy>
+  </policies>
+</issue_examples>

.roo/rules-issue-writer/5_github_mcp_tool_usage.xml

@@ -1,352 +0,0 @@
-<github_mcp_tools_usage>
-  <overview>
-    The GitHub MCP server provides multiple tools for interacting with GitHub.
-    Here's when and how to use each tool in the issue creation workflow.
-    
-    Note: Issue body formatting should follow the templates defined in
-    2_github_issue_templates.xml, with different formats for problem reporters
-    vs contributors.
-  </overview>
-
-  <pre_creation_tools>
-    <tool name="search_issues">
-      <when_to_use>
-        ALWAYS use this FIRST before creating any issue to check for duplicates.
-        Search for keywords from the user's problem description.
-      </when_to_use>
-      <example>
-        <use_mcp_tool>
-        <server_name>github</server_name>
-        <tool_name>search_issues</tool_name>
-        <arguments>
-        {
-          "q": "repo:RooCodeInc/Roo-Code dark theme button visibility",
-          "sort": "updated",
-          "order": "desc"
-        }
-        </arguments>
-        </use_mcp_tool>
-      </example>
-    </tool>
-
-    <tool name="list_issues">
-      <when_to_use>
-        Use to browse recent issues if search doesn't find specific matches.
-        Helpful for understanding issue patterns and formatting.
-      </when_to_use>
-      <example>
-        <use_mcp_tool>
-        <server_name>github</server_name>
-        <tool_name>list_issues</tool_name>
-        <arguments>
-        {
-          "owner": "RooCodeInc",
-          "repo": "Roo-Code",
-          "state": "all",
-          "labels": ["bug"],
-          "sort": "created",
-          "direction": "desc",
-          "perPage": 10
-        }
-        </arguments>
-        </use_mcp_tool>
-      </example>
-    </tool>
-
-    <tool name="get_issue">
-      <when_to_use>
-        Use when you find a potentially related issue and need full details.
-        Check if the user's issue is already reported or related.
-      </when_to_use>
-      <example>
-        <use_mcp_tool>
-        <server_name>github</server_name>
-        <tool_name>get_issue</tool_name>
-        <arguments>
-        {
-          "owner": "RooCodeInc",
-          "repo": "Roo-Code",
-          "issue_number": 123
-        }
-        </arguments>
-        </use_mcp_tool>
-      </example>
-    </tool>
-
-    <tool name="get_issue_comments">
-      <when_to_use>
-        Use on related issues to understand discussion context.
-        Helps avoid creating issues for already-discussed topics.
-      </when_to_use>
-      <example>
-        <use_mcp_tool>
-        <server_name>github</server_name>
-        <tool_name>get_issue_comments</tool_name>
-        <arguments>
-        {
-          "owner": "RooCodeInc",
-          "repo": "Roo-Code",
-          "issue_number": 123
-        }
-        </arguments>
-        </use_mcp_tool>
-      </example>
-    </tool>
-  </pre_creation_tools>
-
-  <contributor_only_tools>
-    <note>
-      These tools should ONLY be used if the user has indicated they want to
-      contribute the implementation. Skip these for problem reporters.
-    </note>
-    
-    <tool name="list_commits">
-      <when_to_use>
-        For bug reports from contributors, check recent commits that might have introduced the issue.
-        Look for commits touching the affected files.
-      </when_to_use>
-      <example>
-        <use_mcp_tool>
-        <server_name>github</server_name>
-        <tool_name>list_commits</tool_name>
-        <arguments>
-        {
-          "owner": "RooCodeInc",
-          "repo": "Roo-Code",
-          "perPage": 20
-        }
-        </arguments>
-        </use_mcp_tool>
-      </example>
-    </tool>
-
-    <tool name="get_commit">
-      <when_to_use>
-        When you identify a potentially problematic commit.
-        Get details about what changed.
-      </when_to_use>
-      <example>
-        <use_mcp_tool>
-        <server_name>github</server_name>
-        <tool_name>get_commit</tool_name>
-        <arguments>
-        {
-          "owner": "RooCodeInc",
-          "repo": "Roo-Code",
-          "sha": "abc123def456"
-        }
-        </arguments>
-        </use_mcp_tool>
-      </example>
-    </tool>
-
-    <tool name="search_code">
-      <when_to_use>
-        Use to find code patterns across the repository on GitHub.
-        Complements local codebase_search tool for contributors.
-      </when_to_use>
-      <example>
-        <use_mcp_tool>
-        <server_name>github</server_name>
-        <tool_name>search_code</tool_name>
-        <arguments>
-        {
-          "q": "repo:RooCodeInc/Roo-Code language:typescript dark theme button"
-        }
-        </arguments>
-        </use_mcp_tool>
-      </example>
-    </tool>
-
-    <tool name="list_pull_requests">
-      <when_to_use>
-        Check recent PRs that might be related to the issue.
-        Look for PRs that modified relevant code.
-      </when_to_use>
-      <example>
-        <use_mcp_tool>
-        <server_name>github</server_name>
-        <tool_name>list_pull_requests</tool_name>
-        <arguments>
-        {
-          "owner": "RooCodeInc",
-          "repo": "Roo-Code",
-          "state": "all",
-          "sort": "updated",
-          "direction": "desc",
-          "perPage": 10
-        }
-        </arguments>
-        </use_mcp_tool>
-      </example>
-    </tool>
-  </contributor_only_tools>
-
-  <issue_creation_tool>
-    <tool name="create_issue">
-      <when_to_use>
-        Only use after:
-        1. Confirming no duplicates exist
-        2. Gathering all required information
-        3. Determining if user is contributing or just reporting
-        4. Getting user confirmation
-      </when_to_use>
-      <bug_report_example>
-        <use_mcp_tool>
-        <server_name>github</server_name>
-        <tool_name>create_issue</tool_name>
-        <arguments>
-        {
-          "owner": "RooCodeInc",
-          "repo": "Roo-Code",
-          "title": "[Descriptive title of the bug]",
-          "body": "[Format according to bug report template]",
-          "labels": ["bug"]
-        }
-        </arguments>
-        </use_mcp_tool>
-      </bug_report_example>
-      <feature_request_problem_reporter_example>
-        <use_mcp_tool>
-        <server_name>github</server_name>
-        <tool_name>create_issue</tool_name>
-        <arguments>
-        {
-          "owner": "RooCodeInc",
-          "repo": "Roo-Code",
-          "title": "[Problem-focused title]",
-          "body": "[Problem description only - no technical details]",
-          "labels": ["proposal", "enhancement"]
-        }
-        </arguments>
-        </use_mcp_tool>
-      </feature_request_problem_reporter_example>
-      <feature_request_contributor_example>
-        <use_mcp_tool>
-        <server_name>github</server_name>
-        <tool_name>create_issue</tool_name>
-        <arguments>
-        {
-          "owner": "RooCodeInc",
-          "repo": "Roo-Code",
-          "title": "[Problem-focused title with implementation intent]",
-          "body": "[Full template including technical analysis sections]",
-          "labels": ["proposal", "enhancement"]
-        }
-        </arguments>
-        </use_mcp_tool>
-      </feature_request_contributor_example>
-    </tool>
-  </issue_creation_tool>
-
-  <post_creation_tools>
-    <tool name="add_issue_comment">
-      <when_to_use>
-        ONLY use if user wants to add additional information after creation.
-      </when_to_use>
-      <example>
-        <use_mcp_tool>
-        <server_name>github</server_name>
-        <tool_name>add_issue_comment</tool_name>
-        <arguments>
-        {
-          "owner": "RooCodeInc",
-          "repo": "Roo-Code",
-          "issue_number": 456,
-          "body": "Additional context or comments."
-        }
-        </arguments>
-        </use_mcp_tool>
-      </example>
-    </tool>
-
-    <tool name="update_issue">
-      <when_to_use>
-        Use if user realizes they need to update the issue after creation.
-        Can update title, body, or state.
-      </when_to_use>
-      <example>
-        <use_mcp_tool>
-        <server_name>github</server_name>
-        <tool_name>update_issue</tool_name>
-        <arguments>
-        {
-          "owner": "RooCodeInc",
-          "repo": "Roo-Code",
-          "issue_number": 456,
-          "title": "[Updated title if needed]",
-          "body": "[Updated body if needed]"
-        }
-        </arguments>
-        </use_mcp_tool>
-      </example>
-    </tool>
-  </post_creation_tools>
-
-  <workflow_integration>
-    <step_1_integration>
-      After user selects issue type, immediately search for related issues:
-      1. Use search_issues with keywords from their description
-      2. Show any similar issues found
-      3. Ask if they want to continue or comment on existing issue
-    </step_1_integration>
-
-    <step_3_integration>
-      When searching GitHub Discussions:
-      1. Note that GitHub MCP tools don't currently support discussions API
-      2. Instruct user to manually search discussions at:
-         https://github.com/RooCodeInc/Roo-Code/discussions/categories/feature-requests
-      3. Ask user to provide any related discussion numbers they find
-      4. Include these in the "Related Discussions" section of the issue
-    </step_3_integration>
-
-    <step_4_integration>
-      Decision point for contribution:
-      1. Ask user if they want to contribute implementation
-      2. If yes: Use contributor tools for codebase investigation
-      3. If no: Skip directly to creating a problem-focused issue
-      4. This saves time for problem reporters
-    </step_4_integration>
-
-    <step_5_integration>
-      During codebase exploration (CONTRIBUTORS ONLY):
-      1. Use list_commits to find recent changes to affected files
-      2. Use search_code for additional code references
-      3. Check list_pull_requests for related PRs
-      4. Include findings in the technical context section
-    </step_5_integration>
-
-    <step_6_integration>
-      When creating the issue:
-      1. Format differently based on contributor vs problem reporter
-      2. Problem reporters: Simple problem description + context
-      3. Contributors: Full template with technical sections
-      4. Use create_issue with appropriate body format
-      5. Capture the returned issue number
-      6. Show user the created issue URL
-    </step_6_integration>
-  </workflow_integration>
-
-  <error_handling>
-    <duplicate_found>
-      If search_issues finds exact duplicate:
-      - Show the existing issue to user
-      - Ask if they want to add a comment instead
-      - Use add_issue_comment if they agree
-    </duplicate_found>
-
-    <creation_failed>
-      If create_issue fails:
-      - Check error message (permissions, rate limit, etc.)
-      - Save the drafted issue content
-      - Provide user with the content to create manually
-    </creation_failed>
-
-    <api_limits>
-      Be aware of GitHub API rate limits:
-      - Authenticated requests: 5000/hour
-      - Search API: 30 requests/minute
-      - Use searches efficiently
-    </api_limits>
-  </error_handling>
-</github_mcp_tools_usage>

.roo/rules-merge-resolver/1_workflow.xml

@@ -0,0 +1,157 @@
+<merge_resolver_workflow>
+  <mode_overview>
+    This mode resolves merge conflicts for a specific pull request by analyzing git history,
+    commit messages, and code changes to make intelligent resolution decisions. It receives
+    a PR number (e.g., "#123") and handles the entire conflict resolution process.
+  </mode_overview>
+
+  <initialization_steps>
+    <step number="1">
+      <action>Parse PR number from user input</action>
+      <details>
+        Extract the PR number from input like "#123" or "PR #123"
+        Validate that a PR number was provided
+      </details>
+    </step>
+    
+    <step number="2">
+      <action>Fetch PR information</action>
+      <tools>
+        <tool>gh pr view [PR_NUMBER] --json title,body,headRefName,baseRefName</tool>
+      </tools>
+      <details>
+        Get PR title and description to understand the intent
+        Identify the source and target branches
+      </details>
+    </step>
+
+    <step number="3">
+      <action>Checkout PR branch and prepare for rebase</action>
+      <tools>
+        <tool>gh pr checkout [PR_NUMBER] --force</tool>
+        <tool>git fetch origin main</tool>
+        <tool>GIT_EDITOR=true git rebase origin/main</tool>
+      </tools>
+      <details>
+        Force checkout the PR branch to ensure clean state
+        Fetch the latest main branch
+        Attempt to rebase onto main to reveal conflicts
+        Use GIT_EDITOR=true to ensure non-interactive rebase
+      </details>
+    </step>
+
+    <step number="4">
+      <action>Check for merge conflicts</action>
+      <tools>
+        <tool>git status --porcelain</tool>
+        <tool>git diff --name-only --diff-filter=U</tool>
+      </tools>
+      <details>
+        Identify files with merge conflicts (marked with 'UU')
+        Create a list of files that need resolution
+      </details>
+    </step>
+  </initialization_steps>
+
+  <main_workflow>
+    <phase name="conflict_analysis">
+      <description>Analyze each conflicted file to understand the changes</description>
+      <steps>
+        <step>Read the conflicted file to identify conflict markers</step>
+        <step>Extract the conflicting sections between <<<<<<< and >>>>>>></step>
+        <step>Run git blame on both sides of the conflict</step>
+        <step>Fetch commit messages and diffs for relevant commits</step>
+        <step>Analyze the intent behind each change</step>
+      </steps>
+    </phase>
+
+    <phase name="resolution_strategy">
+      <description>Determine the best resolution strategy for each conflict</description>
+      <steps>
+        <step>Categorize changes by intent (bugfix, feature, refactor, etc.)</step>
+        <step>Evaluate recency and relevance of changes</step>
+        <step>Check for structural overlap vs formatting differences</step>
+        <step>Identify if changes can be combined or if one should override</step>
+        <step>Consider test updates and related changes</step>
+      </steps>
+    </phase>
+
+    <phase name="conflict_resolution">
+      <description>Apply the resolution strategy to resolve conflicts</description>
+      <steps>
+        <step>For each conflict, apply the chosen resolution</step>
+        <step>Ensure proper escaping of conflict markers in diffs</step>
+        <step>Validate that resolved code is syntactically correct</step>
+        <step>Stage resolved files with git add</step>
+      </steps>
+    </phase>
+
+    <phase name="validation">
+      <description>Verify the resolution and prepare for commit</description>
+      <steps>
+        <step>Run git status to confirm all conflicts are resolved</step>
+        <step>Check for any compilation or syntax errors</step>
+        <step>Review the final diff to ensure sensible resolutions</step>
+        <step>Prepare a summary of resolution decisions</step>
+      </steps>
+    </phase>
+  </main_workflow>
+
+  <git_commands>
+    <command name="checkout_pr">
+      <syntax>gh pr checkout [PR_NUMBER] --force</syntax>
+      <purpose>Force checkout the PR branch to ensure clean state</purpose>
+    </command>
+    
+    <command name="fetch_main">
+      <syntax>git fetch origin main</syntax>
+      <purpose>Get the latest main branch from origin</purpose>
+    </command>
+    
+    <command name="rebase_main">
+      <syntax>GIT_EDITOR=true git rebase origin/main</syntax>
+      <purpose>Rebase current branch onto main to reveal conflicts (non-interactive)</purpose>
+    </command>
+    
+    <command name="get_blame_info">
+      <syntax>git blame -L [start_line],[end_line] [commit_sha] -- [file_path]</syntax>
+      <purpose>Get commit information for specific lines</purpose>
+    </command>
+    
+    <command name="get_commit_details">
+      <syntax>git show --format="%H%n%an%n%ae%n%ad%n%s%n%b" --no-patch [commit_sha]</syntax>
+      <purpose>Get commit metadata including message</purpose>
+    </command>
+    
+    <command name="get_commit_diff">
+      <syntax>git show [commit_sha] -- [file_path]</syntax>
+      <purpose>Get the actual changes made in a commit</purpose>
+    </command>
+    
+    <command name="check_merge_status">
+      <syntax>git ls-files -u</syntax>
+      <purpose>List unmerged files with stage information</purpose>
+    </command>
+  </git_commands>
+
+    <command name="continue_rebase">
+      <syntax>GIT_EDITOR=true git rebase --continue</syntax>
+      <purpose>Continue rebase after resolving conflicts (non-interactive)</purpose>
+    </command>
+  </git_commands>
+
+  <environment_variables>
+    <variable name="GIT_EDITOR">
+      <value>true</value>
+      <purpose>Set to 'true' (a no-op command) to prevent interactive prompts during rebase operations</purpose>
+      <usage>Prefix git rebase commands with GIT_EDITOR=true to ensure non-interactive execution</usage>
+    </variable>
+  </environment_variables>
+
+  <completion_criteria>
+    <criterion>All merge conflicts have been resolved</criterion>
+    <criterion>Resolved files have been staged</criterion>
+    <criterion>No syntax errors in resolved code</criterion>
+    <criterion>Resolution decisions are documented</criterion>
+  </completion_criteria>
+</merge_resolver_workflow>

.roo/rules-merge-resolver/2_best_practices.xml

@@ -0,0 +1,165 @@
+<merge_resolver_best_practices>
+  <general_principles>
+    <principle priority="high">
+      <name>Intent-Based Resolution</name>
+      <description>
+        Always prioritize understanding the intent behind changes rather than
+        just looking at the code differences. Commit messages, PR descriptions,
+        and issue references provide crucial context.
+      </description>
+      <rationale>
+        Code changes have purpose - bugfixes should be preserved, features
+        should be integrated properly, and refactors should maintain consistency.
+      </rationale>
+      <example>
+        <scenario>Conflict between a bugfix and a refactor</scenario>
+        <good>Apply the bugfix logic within the refactored structure</good>
+        <bad>Simply choose one side without considering both intents</bad>
+      </example>
+    </principle>
+
+    <principle priority="high">
+      <name>Preserve All Valuable Changes</name>
+      <description>
+        When possible, combine non-conflicting changes from both sides rather
+        than discarding one side entirely.
+      </description>
+      <rationale>
+        Both sides of a conflict often contain valuable changes that can coexist
+        if properly integrated.
+      </rationale>
+    </principle>
+
+    <principle priority="high">
+      <name>Escape Conflict Markers</name>
+      <description>
+        When using apply_diff, always escape merge
+        conflict markers with backslashes to prevent parsing errors.
+      </description>
+      <example><![CDATA[
+        Correct: \<<<<<<< HEAD
+        Wrong: <<<<<<< HEAD
+      ]]></example>
+    </principle>
+
+    <principle priority="medium">
+      <name>Consider Related Changes</name>
+      <description>
+        Look beyond the immediate conflict to understand related changes in
+        tests, documentation, or dependent code.
+      </description>
+      <rationale>
+        A change might seem isolated but could be part of a larger feature
+        or fix that spans multiple files.
+      </rationale>
+    </principle>
+  </general_principles>
+
+  <resolution_heuristics>
+    <heuristic category="bugfix_vs_feature">
+      <rule>Bugfixes generally take precedence over features</rule>
+      <reasoning>
+        Bugfixes address existing problems and should be preserved,
+        while features can be reintegrated around the fix.
+      </reasoning>
+    </heuristic>
+
+    <heuristic category="recent_vs_old">
+      <rule>More recent changes are often more relevant</rule>
+      <reasoning>
+        Recent changes likely reflect the current understanding of
+        requirements and may supersede older implementations.
+      </reasoning>
+      <exception>
+        When older changes are bugfixes or security patches that
+        haven't been addressed in newer code.
+      </exception>
+    </heuristic>
+
+    <heuristic category="test_updates">
+      <rule>Changes that include test updates are likely more complete</rule>
+      <reasoning>
+        Developers who update tests alongside code changes demonstrate
+        thoroughness and understanding of the impact.
+      </reasoning>
+    </heuristic>
+
+    <heuristic category="formatting_vs_logic">
+      <rule>Logic changes take precedence over formatting changes</rule>
+      <reasoning>
+        Formatting can be reapplied, but logic changes represent
+        functional improvements or fixes.
+      </reasoning>
+    </heuristic>
+  </resolution_heuristics>
+
+  <common_pitfalls>
+    <pitfall>
+      <description>Blindly choosing one side without analysis</description>
+      <why_problematic>
+        You might lose important changes or introduce regressions
+      </why_problematic>
+      <correct_approach>
+        Always analyze both sides using git blame and commit history
+      </correct_approach>
+    </pitfall>
+
+    <pitfall>
+      <description>Ignoring the PR description and context</description>
+      <why_problematic>
+        The PR description often explains the why behind changes,
+        which is crucial for proper resolution
+      </why_problematic>
+      <correct_approach>
+        Always fetch and read the PR information before resolving
+      </correct_approach>
+    </pitfall>
+
+    <pitfall>
+      <description>Not validating the resolved code</description>
+      <why_problematic>
+        Merged code might be syntactically incorrect or introduce
+        logical errors
+      </why_problematic>
+      <correct_approach>
+        Always check for syntax errors and review the final diff
+      </correct_approach>
+    </pitfall>
+
+    <pitfall>
+      <description>Not escaping conflict markers in diffs</description>
+      <why_problematic>
+        Unescaped conflict markers (<<<<<<, =======, >>>>>>) in SEARCH
+        or REPLACE sections will be interpreted as actual diff syntax,
+        causing the apply_diff tool to fail or produce incorrect results
+      </why_problematic>
+      <correct_approach>
+        Always escape conflict markers with a backslash (\) when they
+        appear in the content you're searching for or replacing.
+        Example: \<<<<<<< HEAD instead of <<<<<<< HEAD
+      </correct_approach>
+    </pitfall>
+  </common_pitfalls>
+
+  <quality_checklist>
+    <category name="before_resolution">
+      <item>Fetch PR title and description for context</item>
+      <item>Identify all files with conflicts</item>
+      <item>Understand the overall change being merged</item>
+    </category>
+    
+    <category name="during_resolution">
+      <item>Run git blame on conflicting sections</item>
+      <item>Read commit messages for intent</item>
+      <item>Consider if changes can be combined</item>
+      <item>Escape conflict markers in diffs</item>
+    </category>
+    
+    <category name="after_resolution">
+      <item>Verify no conflict markers remain</item>
+      <item>Check for syntax/compilation errors</item>
+      <item>Review the complete diff</item>
+      <item>Document resolution decisions</item>
+    </category>
+  </quality_checklist>
+</merge_resolver_best_practices>

.roo/rules-merge-resolver/3_tool_usage.xml

@@ -0,0 +1,258 @@
+<merge_resolver_tool_usage>
+  <tool_priorities>
+    <priority level="1">
+      <tool>execute_command</tool>
+      <when>For all git and gh CLI operations</when>
+      <why>Git commands provide the historical context needed for intelligent resolution</why>
+    </priority>
+    
+    <priority level="2">
+      <tool>read_file</tool>
+      <when>To examine conflicted files and understand the conflict structure</when>
+      <why>Need to see the actual conflict markers and code</why>
+    </priority>
+    
+    <priority level="3">
+      <tool>apply_diff</tool>
+      <when>To resolve conflicts by replacing conflicted sections</when>
+      <why>Precise editing of specific conflict blocks</why>
+    </priority>
+  </tool_priorities>
+
+  <tool_specific_guidance>
+    <tool name="execute_command">
+      <best_practices>
+        <practice>Always use gh CLI for GitHub operations instead of MCP tools</practice>
+        <practice>Chain git commands with && for efficiency</practice>
+        <practice>Use --format options for structured output</practice>
+        <practice>Capture command output for parsing</practice>
+        <practice>Use GIT_EDITOR=true for non-interactive git rebase operations</practice>
+        <practice>Set environment variables inline to avoid prompts during automation</practice>
+      </best_practices>
+      
+      <common_commands>
+        <command>
+          <purpose>Get PR information</purpose>
+          <syntax>gh pr view [PR_NUMBER] --json title,body,headRefName,baseRefName</syntax>
+        </command>
+        
+        <command>
+          <purpose>Checkout PR branch</purpose>
+          <syntax>gh pr checkout [PR_NUMBER] --force</syntax>
+        </command>
+        
+        <command>
+          <purpose>Fetch latest main branch</purpose>
+          <syntax>git fetch origin main</syntax>
+        </command>
+        
+        <command>
+          <purpose>Rebase onto main to reveal conflicts</purpose>
+          <syntax>GIT_EDITOR=true git rebase origin/main</syntax>
+        </command>
+        
+        <command>
+          <purpose>Check conflict status</purpose>
+          <syntax>git status --porcelain | grep "^UU"</syntax>
+        </command>
+        
+        <command>
+          <purpose>Get blame for specific lines</purpose>
+          <syntax>git blame -L [start],[end] HEAD -- [file] | cut -d' ' -f1</syntax>
+        </command>
+        
+        <command>
+          <purpose>Get commit message</purpose>
+          <syntax>git log -1 --format="%s%n%n%b" [commit_sha]</syntax>
+        </command>
+        
+        <command>
+          <purpose>Stage resolved file</purpose>
+          <syntax>git add [file_path]</syntax>
+        </command>
+        
+        <command>
+          <purpose>Continue rebase after resolution</purpose>
+          <syntax>GIT_EDITOR=true git rebase --continue</syntax>
+        </command>
+      </common_commands>
+    </tool>
+
+    <tool name="read_file">
+      <best_practices>
+        <practice>Read the entire conflicted file first to understand structure</practice>
+        <practice>Note line numbers of conflict markers for precise editing</practice>
+        <practice>Identify the pattern of conflicts (multiple vs single)</practice>
+      </best_practices>
+      
+      <conflict_parsing>
+        <marker><<<<<<< HEAD - Start of current branch changes</marker>
+        <marker>======= - Separator between versions</marker>
+        <marker>>>>>>>> [branch] - End of incoming changes</marker>
+      </conflict_parsing>
+    </tool>
+
+    <tool name="apply_diff">
+      <best_practices>
+        <practice>Always escape conflict markers with backslash</practice>
+        <practice>Include enough context to ensure unique matches</practice>
+        <practice>Use :start_line: for precision</practice>
+        <practice>Combine multiple resolutions in one diff when possible</practice>
+      </best_practices>
+      
+      <example><![CDATA[
+<apply_diff>
+<path>src/feature.ts</path>
+<diff>
+<<<<<<< SEARCH
+:start_line:45
+-------
+\<<<<<<< HEAD
+function oldImplementation() {
+  return "old";
+}
+\=======
+function newImplementation() {
+  return "new";
+}
+\>>>>>>> feature-branch
+=======
+function mergedImplementation() {
+  // Combining both approaches
+  return "merged";
+}
+>>>>>>> REPLACE
+</diff>
+</apply_diff>
+      ]]></example>
+    </tool>
+
+  </tool_specific_guidance>
+
+  <tool_combination_patterns>
+    <pattern name="initialize_pr_resolution">
+      <sequence>
+        <step>execute_command - Get PR info with gh CLI</step>
+        <step>execute_command - Checkout PR with gh pr checkout --force</step>
+        <step>execute_command - Fetch origin main</step>
+        <step>execute_command - Rebase onto origin/main with GIT_EDITOR=true</step>
+        <step>execute_command - Check for conflicts with git status</step>
+      </sequence>
+    </pattern>
+    
+    <pattern name="analyze_conflict">
+      <sequence>
+        <step>execute_command - List conflicted files</step>
+        <step>read_file - Examine conflict structure</step>
+        <step>execute_command - Git blame on conflict regions</step>
+        <step>execute_command - Fetch commit messages</step>
+      </sequence>
+    </pattern>
+    
+    <pattern name="resolve_conflict">
+      <sequence>
+        <step>read_file - Get exact conflict content</step>
+        <step>apply_diff - Replace conflict with resolution</step>
+        <step>execute_command - Stage resolved file</step>
+        <step>execute_command - Verify resolution status</step>
+      </sequence>
+    </pattern>
+    
+    <pattern name="complete_rebase">
+      <sequence>
+        <step>execute_command - Check all conflicts resolved</step>
+        <step>execute_command - Continue rebase with GIT_EDITOR=true git rebase --continue</step>
+        <step>execute_command - Verify clean status</step>
+      </sequence>
+    </pattern>
+  </tool_combination_patterns>
+
+  <error_handling>
+    <scenario name="interactive_prompt_blocking">
+      <description>Git commands waiting for interactive input</description>
+      <approach>
+        Use GIT_EDITOR=true to bypass editor prompts
+        Set GIT_SEQUENCE_EDITOR=true for sequence editing
+        Consider --no-edit flag for commit operations
+      </approach>
+    </scenario>
+    
+    <scenario name="no_conflicts_after_rebase">
+      <description>Rebase completes without conflicts</description>
+      <approach>
+        Inform user that PR can be merged without conflicts
+        No resolution needed
+      </approach>
+    </scenario>
+    
+    <scenario name="rebase_in_progress">
+      <description>A rebase is already in progress</description>
+      <approach>
+        Check status with git status
+        Either continue existing rebase or abort with git rebase --abort
+      </approach>
+    </scenario>
+    
+    <scenario name="malformed_conflicts">
+      <description>Conflict markers are incomplete or nested</description>
+      <approach>
+        Use apply_diff with precise search blocks; split into multiple targeted edits if needed
+        Manual inspection may be required
+      </approach>
+    </scenario>
+    
+    <scenario name="binary_conflicts">
+      <description>Binary files cannot be merged automatically</description>
+      <approach>
+        Identify which version to keep based on PR intent
+        Use git checkout --theirs or --ours
+      </approach>
+    </scenario>
+    
+    <scenario name="escaped_markers">
+      <description>Code contains literal conflict marker strings</description>
+      <approach>
+        Extra careful escaping in diffs
+        Prefer apply_diff with precise search blocks
+      </approach>
+    </scenario>
+  </error_handling>
+
+  <non_interactive_operations>
+    <overview>
+      Ensuring git operations run without requiring user interaction is critical
+      for automated conflict resolution. The mode uses environment variables to
+      bypass interactive prompts.
+    </overview>
+    
+    <techniques>
+      <technique name="GIT_EDITOR">
+        <description>Set to 'true' (a no-op command) to skip editor prompts</description>
+        <usage>GIT_EDITOR=true git rebase --continue</usage>
+        <when>During rebase operations that would normally open an editor</when>
+      </technique>
+      
+      <technique name="GIT_SEQUENCE_EDITOR">
+        <description>Skip interactive rebase todo editing</description>
+        <usage>GIT_SEQUENCE_EDITOR=true git rebase -i HEAD~3</usage>
+        <when>When interactive rebase is triggered but no editing needed</when>
+      </technique>
+      
+      <technique name="commit_flags">
+        <description>Use flags to avoid interactive prompts</description>
+        <examples>
+          <example>git commit --no-edit (use existing message)</example>
+          <example>git merge --no-edit (skip merge message editing)</example>
+          <example>git cherry-pick --no-edit (keep original message)</example>
+        </examples>
+      </technique>
+    </techniques>
+    
+    <best_practices>
+      <practice>Always test commands locally first to identify potential prompts</practice>
+      <practice>Combine environment variables when multiple editors might be invoked</practice>
+      <practice>Document why non-interactive mode is used in comments</practice>
+      <practice>Have fallback strategies if automation fails</practice>
+    </best_practices>
+  </non_interactive_operations>
+</merge_resolver_tool_usage>

.roo/rules-merge-resolver/4_complete_example.xml

@@ -0,0 +1,316 @@
+<merge_resolver_example>
+  <scenario>
+    User provides PR #123 which has merge conflicts between a bugfix branch
+    and a feature branch that refactored the same code.
+  </scenario>
+
+  <user_request>
+    #123
+  </user_request>
+
+  <workflow>
+    <step number="1">
+      <description>Parse PR number and fetch PR information</description>
+      <tool_use><![CDATA[
+<execute_command>
+<command>gh pr view 123 --json title,body,headRefName,baseRefName</command>
+</execute_command>
+      ]]></tool_use>
+      <expected_output><![CDATA[
+{
+  "title": "Fix memory leak in data processor",
+  "body": "This PR fixes a memory leak that occurs when processing large datasets. The leak was caused by event listeners not being properly removed.",
+  "headRefName": "fix/memory-leak",
+  "baseRefName": "main"
+}
+      ]]></expected_output>
+      <analysis>
+        The PR is a bugfix for a memory leak issue. This context will help
+        prioritize preserving the fix during conflict resolution.
+      </analysis>
+    </step>
+
+    <step number="2">
+      <description>Checkout PR branch and prepare for rebase</description>
+      <tool_use><![CDATA[
+<execute_command>
+<command>gh pr checkout 123 --force</command>
+</execute_command>
+      ]]></tool_use>
+      <expected_output><![CDATA[
+Switched to branch 'fix/memory-leak'
+Your branch is up to date with 'origin/fix/memory-leak'.
+      ]]></expected_output>
+      
+      <tool_use><![CDATA[
+<execute_command>
+<command>git fetch origin main</command>
+</execute_command>
+      ]]></tool_use>
+      <expected_output><![CDATA[
+From github.com:user/repo
+ * branch            main       -> FETCH_HEAD
+      ]]></expected_output>
+      
+      <tool_use><![CDATA[
+<execute_command>
+<command>GIT_EDITOR=true git rebase origin/main</command>
+</execute_command>
+      ]]></tool_use>
+      <expected_output><![CDATA[
+Auto-merging src/data/processor.ts
+CONFLICT (content): Merge conflict in src/data/processor.ts
+Auto-merging src/data/processor.test.ts
+CONFLICT (content): Merge conflict in src/data/processor.test.ts
+error: could not apply abc123... Fix memory leak in data processor
+Resolve all conflicts manually, mark them as resolved with
+"git add/rm <conflicted_files>", then run "git rebase --continue".
+      ]]></expected_output>
+    </step>
+
+    <step number="3">
+      <description>Check for merge conflicts</description>
+      <tool_use><![CDATA[
+<execute_command>
+<command>git status --porcelain | grep "^UU"</command>
+</execute_command>
+      ]]></tool_use>
+      <expected_output><![CDATA[
+UU src/data/processor.ts
+UU src/data/processor.test.ts
+      ]]></expected_output>
+      <analysis>
+        Two files have conflicts: the main processor file and its test file.
+        Both need to be resolved before continuing the rebase.
+      </analysis>
+    </step>
+
+    <step number="4">
+      <description>Examine the conflicted processor file</description>
+      <tool_use><![CDATA[
+<read_file>
+<path>src/data/processor.ts</path>
+</read_file>
+      ]]></tool_use>
+      <expected_output><![CDATA[
+45 | export class DataProcessor {
+46 |   private listeners: Map<string, EventListener> = new Map();
+47 | 
+48 | <<<<<<< HEAD
+49 |   async processData(data: DataInput): Promise<ProcessedData> {
+50 |     // Refactored to use async/await
+51 |     const result = await this.transform(data);
+52 |     return result;
+53 |   }
+54 | =======
+55 |   processData(data: any[]): ProcessedData {
+56 |     const listener = this.createListener();
+57 |     this.listeners.set(data.id, listener);
+58 |     
+59 |     return this.transform(data);
+60 |   }
+61 | >>>>>>> abc123 (Fix memory leak in data processor)
+62 | 
+63 |   cleanup() {
+64 | <<<<<<< HEAD
+65 |     // TODO: Implement cleanup
+66 | =======
+67 |     // Fix: Clear all listeners to prevent memory leak
+68 |     this.listeners.forEach(listener => {
+69 |       listener.removeAllListeners();
+70 |     });
+71 |     this.listeners.clear();
+72 | >>>>>>> abc123 (Fix memory leak in data processor)
+73 |   }
+74 | }
+      ]]></expected_output>
+    </step>
+
+    <step number="5">
+      <description>Analyze the conflicts using git blame</description>
+      <tool_use><![CDATA[
+<execute_command>
+<command>git blame -L 49,53 HEAD -- src/data/processor.ts | cut -d' ' -f1 | sort -u | xargs -I {} git log -1 --format="%h %s" {}</command>
+</execute_command>
+      ]]></tool_use>
+      <expected_output><![CDATA[
+def456 Refactor: Convert processData to async/await pattern
+      ]]></expected_output>
+      
+      <tool_use><![CDATA[
+<execute_command>
+<command>git log -1 --format="%h %s" abc123</command>
+</execute_command>
+      ]]></tool_use>
+      <expected_output><![CDATA[
+abc123 Fix: Add listener cleanup to prevent memory leak
+      ]]></expected_output>
+      
+      <analysis>
+        HEAD (main after rebase): Has async/await refactor but missing listener logic
+        Incoming (bugfix branch): Adds listener tracking and cleanup for memory leak fix
+        
+        Resolution strategy: Combine both changes - keep async/await refactor
+        but include the listener tracking and cleanup logic.
+      </analysis>
+    </step>
+
+    <step number="6">
+      <description>Resolve the conflicts</description>
+      <tool_use><![CDATA[
+<apply_diff>
+<path>src/data/processor.ts</path>
+<diff>
+<<<<<<< SEARCH
+:start_line:48
+-------
+\<<<<<<< HEAD
+  async processData(data: DataInput): Promise<ProcessedData> {
+    // Refactored to use async/await
+    const result = await this.transform(data);
+    return result;
+  }
+\=======
+  processData(data: any[]): ProcessedData {
+    const listener = this.createListener();
+    this.listeners.set(data.id, listener);
+    
+    return this.transform(data);
+  }
+\>>>>>>> abc123 (Fix memory leak in data processor)
+=======
+  async processData(data: DataInput): Promise<ProcessedData> {
+    // Create and track listener for cleanup (memory leak fix)
+    const listener = this.createListener();
+    this.listeners.set(data.id, listener);
+    
+    // Refactored to use async/await
+    const result = await this.transform(data);
+    return result;
+  }
+>>>>>>> REPLACE
+
+<<<<<<< SEARCH
+:start_line:63
+-------
+  cleanup() {
+\<<<<<<< HEAD
+    // TODO: Implement cleanup
+\=======
+    // Fix: Clear all listeners to prevent memory leak
+    this.listeners.forEach(listener => {
+      listener.removeAllListeners();
+    });
+    this.listeners.clear();
+\>>>>>>> abc123 (Fix memory leak in data processor)
+  }
+=======
+  cleanup() {
+    // Fix: Clear all listeners to prevent memory leak
+    this.listeners.forEach(listener => {
+      listener.removeAllListeners();
+    });
+    this.listeners.clear();
+  }
+>>>>>>> REPLACE
+</diff>
+</apply_diff>
+      ]]></tool_use>
+      <explanation>
+        Combined both changes: kept the async/await refactor from main
+        while preserving the memory leak fix (listener tracking and cleanup)
+        from the bugfix branch.
+      </explanation>
+    </step>
+
+    <step number="7">
+      <description>Resolve test file conflicts</description>
+      <tool_use><![CDATA[
+<read_file>
+<path>src/data/processor.test.ts</path>
+</read_file>
+      ]]></tool_use>
+      <!-- Similar process for test file -->
+      <tool_use><![CDATA[
+<apply_diff>
+<path>src/data/processor.test.ts</path>
+<diff>
+<!-- Test resolution would go here -->
+</diff>
+</apply_diff>
+      ]]></tool_use>
+    </step>
+
+    <step number="8">
+      <description>Stage resolved files and continue rebase</description>
+      <tool_use><![CDATA[
+<execute_command>
+<command>git add src/data/processor.ts src/data/processor.test.ts</command>
+</execute_command>
+      ]]></tool_use>
+      
+      <tool_use><![CDATA[
+<execute_command>
+<command>GIT_EDITOR=true git rebase --continue</command>
+</execute_command>
+      ]]></tool_use>
+      <expected_output><![CDATA[
+[detached HEAD def789] Fix memory leak in data processor
+ 2 files changed, 12 insertions(+), 2 deletions(-)
+Successfully rebased and updated refs/heads/fix/memory-leak.
+      ]]></expected_output>
+    </step>
+
+    <step number="9">
+      <description>Final validation</description>
+      <tool_use><![CDATA[
+<execute_command>
+<command>git status</command>
+</execute_command>
+      ]]></tool_use>
+      <expected_output><![CDATA[
+On branch fix/memory-leak
+Your branch is ahead of 'origin/fix/memory-leak' by 1 commit.
+  (use "git push" to publish your local commits)
+
+nothing to commit, working tree clean
+      ]]></expected_output>
+      
+      <tool_use><![CDATA[
+<execute_command>
+<command>git diff origin/main --stat</command>
+</execute_command>
+      ]]></tool_use>
+      <expected_output><![CDATA[
+ src/data/processor.ts      | 8 ++++++--
+ src/data/processor.test.ts | 4 ++--
+ 2 files changed, 8 insertions(+), 4 deletions(-)
+      ]]></expected_output>
+    </step>
+  </workflow>
+
+  <completion><![CDATA[
+<attempt_completion>
+<result>
+Successfully resolved merge conflicts for PR #123 "Fix memory leak in data processor".
+
+Resolution Summary:
+- src/data/processor.ts: Combined the async/await refactor with the memory leak fix by preserving listener tracking and cleanup logic within the refactored async method
+- src/data/processor.test.ts: Updated tests to work with the async implementation while maintaining memory leak test coverage
+
+Both the feature refactor and the critical bugfix have been preserved in the resolution. The rebase has been completed successfully and the branch is ready to be pushed.
+</result>
+</attempt_completion>
+  ]]></completion>
+
+  <key_takeaways>
+    <takeaway>Always checkout PR with --force and rebase to reveal conflicts</takeaway>
+    <takeaway>Fetch PR context to understand the intent of changes</takeaway>
+    <takeaway>Use git blame and commit messages to understand the history</takeaway>
+    <takeaway>Combine non-conflicting improvements when possible</takeaway>
+    <takeaway>Prioritize bugfixes while accommodating refactors</takeaway>
+    <takeaway>Use GIT_EDITOR=true to ensure non-interactive rebase operations</takeaway>
+    <takeaway>Complete the rebase process with GIT_EDITOR=true git rebase --continue</takeaway>
+    <takeaway>Validate that both sets of changes work together</takeaway>
+  </key_takeaways>
+</merge_resolver_example>

.roo/rules-merge-resolver/5_communication.xml

@@ -0,0 +1,153 @@
+<merge_resolver_communication>
+  <tone_and_style>
+    <principle>Be direct and technical when explaining resolution decisions</principle>
+    <principle>Focus on the rationale behind each conflict resolution</principle>
+    <principle>Provide clear summaries of what was merged and why</principle>
+    
+    <avoid>
+      <phrase>I'll help you resolve these conflicts...</phrase>
+      <phrase>Let me handle this for you...</phrase>
+      <phrase>Don't worry about the conflicts...</phrase>
+    </avoid>
+    
+    <prefer>
+      <phrase>Analyzing PR #123 for merge conflicts...</phrase>
+      <phrase>Resolving conflicts based on commit history analysis...</phrase>
+      <phrase>Applied resolution strategy: [specific strategy]</phrase>
+    </prefer>
+  </tone_and_style>
+
+  <initial_response>
+    <structure>
+      <element>Acknowledge the PR number</element>
+      <element>State that you're fetching PR information</element>
+      <element>Indicate the analysis will begin</element>
+    </structure>
+    
+    <example>
+      Fetching information for PR #123 to understand the context and identify merge conflicts...
+    </example>
+  </initial_response>
+
+  <progress_updates>
+    <when>During each major phase of resolution</when>
+    <format>
+      <update>Analyzing [X] conflicted files...</update>
+      <update>Running git blame on [file] to understand change history...</update>
+      <update>Resolving conflicts in [file] by [strategy]...</update>
+      <update>Validating resolved changes...</update>
+    </format>
+    
+    <include_details>
+      <detail>Number of conflicts found</detail>
+      <detail>Files being processed</detail>
+      <detail>Resolution strategy being applied</detail>
+    </include_details>
+  </progress_updates>
+
+  <conflict_explanations>
+    <guideline>Explain each significant resolution decision</guideline>
+    <guideline>Reference specific commits when relevant</guideline>
+    <guideline>Justify why certain changes were kept or merged</guideline>
+    
+    <format>
+      <explanation>
+        Conflict in [file]:
+        - HEAD: [brief description of changes]
+        - Incoming: [brief description of changes]
+        - Resolution: [what was decided and why]
+      </explanation>
+    </format>
+  </conflict_explanations>
+
+  <error_handling>
+    <scenario name="no_pr_number">
+      <response>
+        Expected a PR number (e.g., "#123" or "123"). Please provide the PR number to resolve conflicts for.
+      </response>
+    </scenario>
+    
+    <scenario name="no_conflicts">
+      <response>
+        PR #[number] does not have any merge conflicts. The branch can be merged without conflict resolution.
+      </response>
+    </scenario>
+    
+    <scenario name="pr_not_found">
+      <response>
+        Could not find PR #[number]. Please verify the PR number and ensure you have access to the repository.
+      </response>
+    </scenario>
+    
+    <scenario name="complex_conflicts">
+      <response>
+        Found complex conflicts in [file] that require careful analysis. Examining commit history to determine the best resolution strategy...
+      </response>
+    </scenario>
+  </error_handling>
+
+  <completion_messages>
+    <structure>
+      <element>State that conflicts are resolved</element>
+      <element>Provide resolution summary</element>
+      <element>List files that were resolved</element>
+      <element>Mention key decisions made</element>
+    </structure>
+    
+    <template><![CDATA[
+Successfully resolved merge conflicts for PR #[number] "[title]".
+
+Resolution Summary:
+- [file1]: [brief description of resolution]
+- [file2]: [brief description of resolution]
+
+[Key decision explanation if applicable]
+
+All conflicts have been resolved and files have been staged for commit.
+    ]]></template>
+    
+    <avoid>
+      <element>Questions about next steps</element>
+      <element>Offers to do additional work</element>
+      <element>Uncertain language about the resolution</element>
+    </avoid>
+  </completion_messages>
+
+  <decision_documentation>
+    <principle>Document why specific resolutions were chosen</principle>
+    <principle>Reference commit SHAs when they influenced decisions</principle>
+    <principle>Explain trade-offs when both sides had valid changes</principle>
+    
+    <examples>
+      <example>
+        Preserved bugfix from commit abc123 while adapting it to the refactored structure from def456
+      </example>
+      <example>
+        Combined both implementations as they addressed different aspects of the same feature
+      </example>
+      <example>
+        Chose the more recent implementation as it included additional error handling
+      </example>
+    </examples>
+  </decision_documentation>
+
+  <special_cases>
+    <case name="binary_files">
+      <message>
+        Binary file conflict in [file]. Based on PR intent "[title]", choosing [which version] version.
+      </message>
+    </case>
+    
+    <case name="deleted_vs_modified">
+      <message>
+        Conflict: [file] was deleted in one branch but modified in another. Based on the changes, [keeping/removing] the file because [reason].
+      </message>
+    </case>
+    
+    <case name="whitespace_only">
+      <message>
+        Conflict in [file] involves only whitespace/formatting. Applying consistent formatting from [which] branch.
+      </message>
+    </case>
+  </special_cases>
+</merge_resolver_communication>

.roo/rules-mode-writer/1_mode_creation_workflow.xml

@@ -1,142 +0,0 @@
-<mode_creation_workflow>
-  <overview>
-    This workflow guides you through creating a new custom mode to be used in the Roo Code Software,
-    from initial requirements gathering to final implementation.
-  </overview>
-
-  <detailed_steps>
-    <step number="1">
-      <title>Gather Requirements</title>
-      <description>
-        Understand what the user wants the mode to accomplish
-      </description>
-      <actions>
-        <action>Ask about the mode's primary purpose and use cases</action>
-        <action>Identify what types of tasks the mode should handle</action>
-        <action>Determine what tools and file access the mode needs</action>
-        <action>Clarify any special behaviors or restrictions</action>
-      </actions>
-      <example>
-        <ask_followup_question>
-          <question>What is the primary purpose of this new mode? What types of tasks should it handle?</question>
-          <follow_up>
-            <suggest>A mode for writing and maintaining documentation</suggest>
-            <suggest>A mode for database schema design and migrations</suggest>
-            <suggest>A mode for API endpoint development and testing</suggest>
-            <suggest>A mode for performance optimization and profiling</suggest>
-          </follow_up>
-        </ask_followup_question>
-      </example>
-    </step>
-
-    <step number="2">
-      <title>Design Mode Configuration</title>
-      <description>
-        Create the mode definition with all required fields
-      </description>
-      <required_fields>
-        <field name="slug">
-          <description>Unique identifier (lowercase, hyphens allowed)</description>
-          <best_practice>Keep it short and descriptive (e.g., "api-dev", "docs-writer")</best_practice>
-        </field>
-        <field name="name">
-          <description>Display name with optional emoji</description>
-          <best_practice>Use an emoji that represents the mode's purpose</best_practice>
-        </field>
-        <field name="roleDefinition">
-          <description>Detailed description of the mode's role and expertise</description>
-          <best_practice>
-            Start with "You are Roo Code, a [specialist type]..."
-            List specific areas of expertise
-            Mention key technologies or methodologies
-          </best_practice>
-        </field>
-        <field name="groups">
-          <description>Tool groups the mode can access</description>
-          <options>
-            <option name="read">File reading and searching tools</option>
-            <option name="edit">File editing tools (can be restricted by regex)</option>
-            <option name="command">Command execution tools</option>
-            <option name="browser">Browser interaction tools</option>
-            <option name="mcp">MCP server tools</option>
-          </options>
-        </field>
-      </required_fields>
-      <recommended_fields>
-        <field name="whenToUse">
-          <description>Clear description for the Orchestrator</description>
-          <best_practice>Explain specific scenarios and task types</best_practice>
-        </field>
-      </recommended_fields>
-      <important_note>
-        Do not include customInstructions in the .roomodes configuration.
-        All detailed instructions should be placed in XML files within
-        the .roo/rules-[mode-slug]/ directory instead.
-      </important_note>
-    </step>
-
-    <step number="3">
-      <title>Implement File Restrictions</title>
-      <description>
-        Configure appropriate file access permissions
-      </description>
-      <example>
-        <comment>Restrict edit access to specific file types</comment>
-        <code>
-groups:
-  - read
-  - - edit
-    - fileRegex: \.(md|txt|rst)$
-      description: Documentation files only
-  - command
-        </code>
-      </example>
-      <guidelines>
-        <guideline>Use regex patterns to limit file editing scope</guideline>
-        <guideline>Provide clear descriptions for restrictions</guideline>
-        <guideline>Consider the principle of least privilege</guideline>
-      </guidelines>
-    </step>
-
-    <step number="4">
-      <title>Create XML Instruction Files</title>
-      <description>
-        Design structured instruction files in .roo/rules-[mode-slug]/
-      </description>
-      <file_structure>
-        <file name="1_workflow.xml">Main workflow and step-by-step processes</file>
-        <file name="2_best_practices.xml">Guidelines and conventions</file>
-        <file name="3_common_patterns.xml">Reusable code patterns and examples</file>
-        <file name="4_tool_usage.xml">Specific tool usage instructions</file>
-        <file name="5_examples.xml">Complete workflow examples</file>
-      </file_structure>
-      <xml_best_practices>
-        <practice>Use semantic tag names that describe content</practice>
-        <practice>Nest tags hierarchically for better organization</practice>
-        <practice>Include code examples in CDATA sections when needed</practice>
-        <practice>Add comments to explain complex sections</practice>
-      </xml_best_practices>
-    </step>
-
-    <step number="5">
-      <title>Test and Refine</title>
-      <description>
-        Verify the mode works as intended
-      </description>
-      <checklist>
-        <item>Mode appears in the mode list</item>
-        <item>File restrictions work correctly</item>
-        <item>Instructions are clear and actionable</item>
-        <item>Mode integrates well with Orchestrator</item>
-        <item>All examples are accurate and helpful</item>
-      </checklist>
-    </step>
-  </detailed_steps>
-
-  <quick_reference>
-    <command>Create mode in .roomodes for project-specific modes</command>
-    <command>Create mode in global custom_modes.yaml for system-wide modes</command>
-    <command>Use list_files to verify .roo folder structure</command>
-    <command>Test file regex patterns with search_files</command>
-  </quick_reference>
-</mode_creation_workflow>

.roo/rules-mode-writer/2_xml_structuring_best_practices.xml

@@ -1,220 +0,0 @@
-<xml_structuring_best_practices>
-  <overview>
-    XML tags help Claude parse prompts more accurately, leading to higher-quality outputs.
-    This guide covers best practices for structuring mode instructions using XML.
-  </overview>
-
-  <why_use_xml_tags>
-    <benefit type="clarity">
-      Clearly separate different parts of your instructions and ensure well-structured content
-    </benefit>
-    <benefit type="accuracy">
-      Reduce errors caused by Claude misinterpreting parts of your instructions
-    </benefit>
-    <benefit type="flexibility">
-      Easily find, add, remove, or modify parts of instructions without rewriting everything
-    </benefit>
-    <benefit type="parseability">
-      Having Claude use XML tags in its output makes it easier to extract specific parts of responses
-    </benefit>
-  </why_use_xml_tags>
-
-  <core_principles>
-    <principle name="consistency">
-      <description>Use the same tag names throughout your instructions</description>
-      <example>
-        Always use <step> for workflow steps, not sometimes <action> or <task>
-      </example>
-    </principle>
-    
-    <principle name="semantic_naming">
-      <description>Tag names should clearly describe their content</description>
-      <good_examples>
-        <tag>detailed_steps</tag>
-        <tag>error_handling</tag>
-        <tag>validation_rules</tag>
-      </good_examples>
-      <bad_examples>
-        <tag>stuff</tag>
-        <tag>misc</tag>
-        <tag>data1</tag>
-      </bad_examples>
-    </principle>
-
-    <principle name="hierarchical_nesting">
-      <description>Nest tags to show relationships and structure</description>
-      <example>
-        <workflow>
-          <phase name="preparation">
-            <step>Gather requirements</step>
-            <step>Validate inputs</step>
-          </phase>
-          <phase name="execution">
-            <step>Process data</step>
-            <step>Generate output</step>
-          </phase>
-        </workflow>
-      </example>
-    </principle>
-  </core_principles>
-
-  <common_tag_patterns>
-    <pattern name="workflow_structure">
-      <usage>For step-by-step processes</usage>
-      <template><![CDATA[
-<workflow>
-  <overview>High-level description</overview>
-  <prerequisites>
-    <prerequisite>Required condition 1</prerequisite>
-    <prerequisite>Required condition 2</prerequisite>
-  </prerequisites>
-  <steps>
-    <step number="1">
-      <title>Step Title</title>
-      <description>What this step accomplishes</description>
-      <actions>
-        <action>Specific action to take</action>
-      </actions>
-      <validation>How to verify success</validation>
-    </step>
-  </steps>
-</workflow>
-      ]]></template>
-    </pattern>
-
-    <pattern name="examples_structure">
-      <usage>For providing code examples and demonstrations</usage>
-      <template><![CDATA[
-<examples>
-  <example name="descriptive_name">
-    <description>What this example demonstrates</description>
-    <context>When to use this approach</context>
-    <code language="typescript">
-      // Your code example here
-    </code>
-    <explanation>
-      Key points about the implementation
-    </explanation>
-  </example>
-</examples>
-      ]]></template>
-    </pattern>
-
-    <pattern name="guidelines_structure">
-      <usage>For rules and best practices</usage>
-      <template><![CDATA[
-<guidelines category="category_name">
-  <guideline priority="high">
-    <rule>The specific rule or guideline</rule>
-    <rationale>Why this is important</rationale>
-    <exceptions>When this doesn't apply</exceptions>
-  </guideline>
-</guidelines>
-      ]]></template>
-    </pattern>
-
-    <pattern name="tool_usage_structure">
-      <usage>For documenting how to use specific tools</usage>
-      <template><![CDATA[
-<tool_usage tool="tool_name">
-  <purpose>What this tool accomplishes</purpose>
-  <when_to_use>Specific scenarios for this tool</when_to_use>
-  <syntax>
-    <command>The exact command format</command>
-    <parameters>
-      <parameter name="param1" required="true">
-        <description>What this parameter does</description>
-        <type>string|number|boolean</type>
-        <example>example_value</example>
-      </parameter>
-    </parameters>
-  </syntax>
-  <examples>
-    <example scenario="common_use_case">
-      <code>Actual usage example</code>
-      <output>Expected output</output>
-    </example>
-  </examples>
-</tool_usage>
-      ]]></template>
-    </pattern>
-  </common_tag_patterns>
-
-  <formatting_guidelines>
-    <guideline name="indentation">
-      Use consistent indentation (2 or 4 spaces) for nested elements
-    </guideline>
-    <guideline name="line_breaks">
-      Add line breaks between major sections for readability
-    </guideline>
-    <guideline name="comments">
-      Use XML comments <!-- like this --> to explain complex sections
-    </guideline>
-    <guideline name="cdata_sections">
-      Use CDATA for code blocks or content with special characters:
-      <![CDATA[<code><![CDATA[your code here]]></code>]]>
-    </guideline>
-    <guideline name="attributes_vs_elements">
-      Use attributes for metadata, elements for content:
-      <example type="good">
-        <step number="1" priority="high">
-          <description>The actual step content</description>
-        </step>
-      </example>
-    </guideline>
-  </formatting_guidelines>
-
-  <anti_patterns>
-    <anti_pattern name="flat_structure">
-      <description>Avoid completely flat structures without hierarchy</description>
-      <bad><![CDATA[
-<instructions>
-<item1>Do this</item1>
-<item2>Then this</item2>
-<item3>Finally this</item3>
-</instructions>
-      ]]></bad>
-      <good><![CDATA[
-<instructions>
-  <steps>
-    <step order="1">Do this</step>
-    <step order="2">Then this</step>
-    <step order="3">Finally this</step>
-  </steps>
-</instructions>
-      ]]></good>
-    </anti_pattern>
-
-    <anti_pattern name="inconsistent_naming">
-      <description>Don't mix naming conventions</description>
-      <bad>
-        Mixing camelCase, snake_case, and kebab-case in tag names
-      </bad>
-      <good>
-        Pick one convention (preferably snake_case for XML) and stick to it
-      </good>
-    </anti_pattern>
-
-    <anti_pattern name="overly_generic_tags">
-      <description>Avoid tags that don't convey meaning</description>
-      <bad>data, info, stuff, thing, item</bad>
-      <good>user_input, validation_result, error_message, configuration</good>
-    </anti_pattern>
-  </anti_patterns>
-
-  <integration_tips>
-    <tip>
-      Reference XML content in instructions:
-      "Using the workflow defined in &lt;workflow&gt; tags..."
-    </tip>
-    <tip>
-      Combine XML structure with other techniques like multishot prompting
-    </tip>
-    <tip>
-      Use XML tags in expected outputs to make parsing easier
-    </tip>
-    <tip>
-      Create reusable XML templates for common patterns
-    </tip>
-  </integration_tips>
-</xml_structuring_best_practices>

.roo/rules-mode-writer/3_mode_configuration_patterns.xml

@@ -1,261 +0,0 @@
-<mode_configuration_patterns>
-  <overview>
-    Common patterns and templates for creating different types of modes, with examples from existing modes in the Roo-Code software.
-  </overview>
-
-  <mode_types>
-    <type name="specialist_mode">
-      <description>
-        Modes focused on specific technical domains or tasks
-      </description>
-      <characteristics>
-        <characteristic>Deep expertise in a particular area</characteristic>
-        <characteristic>Restricted file access based on domain</characteristic>
-        <characteristic>Specialized tool usage patterns</characteristic>
-      </characteristics>
-      <example_template><![CDATA[
-- slug: api-specialist
-  name: 🔌 API Specialist
-  roleDefinition: >-
-    You are Roo Code, an API development specialist with expertise in:
-    - RESTful API design and implementation
-    - GraphQL schema design
-    - API documentation with OpenAPI/Swagger
-    - Authentication and authorization patterns
-    - Rate limiting and caching strategies
-    - API versioning and deprecation
-    
-    You ensure APIs are:
-    - Well-documented and discoverable
-    - Following REST principles or GraphQL best practices
-    - Secure and performant
-    - Properly versioned and maintainable
-  whenToUse: >-
-    Use this mode when designing, implementing, or refactoring APIs.
-    This includes creating new endpoints, updating API documentation,
-    implementing authentication, or optimizing API performance.
-  groups:
-    - read
-    - - edit
-      - fileRegex: (api/.*\.(ts|js)|.*\.openapi\.yaml|.*\.graphql|docs/api/.*)$
-        description: API implementation files, OpenAPI specs, and API documentation
-    - command
-    - mcp
-      ]]></example_template>
-    </type>
-
-    <type name="workflow_mode">
-      <description>
-        Modes that guide users through multi-step processes
-      </description>
-      <characteristics>
-        <characteristic>Step-by-step workflow guidance</characteristic>
-        <characteristic>Heavy use of ask_followup_question</characteristic>
-        <characteristic>Process validation at each step</characteristic>
-      </characteristics>
-      <example_template><![CDATA[
-- slug: migration-guide
-  name: 🔄 Migration Guide
-  roleDefinition: >-
-    You are Roo Code, a migration specialist who guides users through
-    complex migration processes:
-    - Database schema migrations
-    - Framework version upgrades
-    - API version migrations
-    - Dependency updates
-    - Breaking change resolutions
-    
-    You provide:
-    - Step-by-step migration plans
-    - Automated migration scripts
-    - Rollback strategies
-    - Testing approaches for migrations
-  whenToUse: >-
-    Use this mode when performing any kind of migration or upgrade.
-    This mode will analyze the current state, plan the migration,
-    and guide you through each step with validation.
-  groups:
-    - read
-    - edit
-    - command
-      ]]></example_template>
-    </type>
-
-    <type name="analysis_mode">
-      <description>
-        Modes focused on code analysis and reporting
-      </description>
-      <characteristics>
-        <characteristic>Read-heavy operations</characteristic>
-        <characteristic>Limited or no edit permissions</characteristic>
-        <characteristic>Comprehensive reporting outputs</characteristic>
-      </characteristics>
-      <example_template><![CDATA[
-- slug: security-auditor
-  name: 🔒 Security Auditor
-  roleDefinition: >-
-    You are Roo Code, a security analysis specialist focused on:
-    - Identifying security vulnerabilities
-    - Analyzing authentication and authorization
-    - Reviewing data validation and sanitization
-    - Checking for common security anti-patterns
-    - Evaluating dependency vulnerabilities
-    - Assessing API security
-    
-    You provide detailed security reports with:
-    - Vulnerability severity ratings
-    - Specific remediation steps
-    - Security best practice recommendations
-  whenToUse: >-
-    Use this mode to perform security audits on codebases.
-    This mode will analyze code for vulnerabilities, check
-    dependencies, and provide actionable security recommendations.
-  groups:
-    - read
-    - command
-    - - edit
-      - fileRegex: (SECURITY\.md|\.github/security/.*|docs/security/.*)$
-        description: Security documentation files only
-      ]]></example_template>
-    </type>
-
-    <type name="creative_mode">
-      <description>
-        Modes for generating new content or features
-      </description>
-      <characteristics>
-        <characteristic>Broad file creation permissions</characteristic>
-        <characteristic>Template and boilerplate generation</characteristic>
-        <characteristic>Interactive design process</characteristic>
-      </characteristics>
-      <example_template><![CDATA[
-- slug: component-designer
-  name: 🎨 Component Designer
-  roleDefinition: >-
-    You are Roo Code, a UI component design specialist who creates:
-    - Reusable React/Vue/Angular components
-    - Component documentation and examples
-    - Storybook stories
-    - Unit tests for components
-    - Accessibility-compliant interfaces
-    
-    You follow design system principles and ensure components are:
-    - Highly reusable and composable
-    - Well-documented with examples
-    - Fully tested
-    - Accessible (WCAG compliant)
-    - Performance optimized
-  whenToUse: >-
-    Use this mode when creating new UI components or refactoring
-    existing ones. This mode helps design component APIs, implement
-    the components, and create comprehensive documentation.
-  groups:
-    - read
-    - - edit
-      - fileRegex: (components/.*|stories/.*|__tests__/.*\.test\.(tsx?|jsx?))$
-        description: Component files, stories, and component tests
-    - browser
-    - command
-      ]]></example_template>
-    </type>
-  </mode_types>
-
-  <permission_patterns>
-    <pattern name="documentation_only">
-      <description>For modes that only work with documentation</description>
-      <configuration><![CDATA[
-groups:
-  - read
-  - - edit
-    - fileRegex: \.(md|mdx|rst|txt)$
-      description: Documentation files only
-      ]]></configuration>
-    </pattern>
-
-    <pattern name="test_focused">
-      <description>For modes that work with test files</description>
-      <configuration><![CDATA[
-groups:
-  - read
-  - command
-  - - edit
-    - fileRegex: (__tests__/.*|__mocks__/.*|.*\.test\.(ts|tsx|js|jsx)$|.*\.spec\.(ts|tsx|js|jsx)$)
-      description: Test files and mocks
-      ]]></configuration>
-    </pattern>
-
-    <pattern name="config_management">
-      <description>For modes that manage configuration</description>
-      <configuration><![CDATA[
-groups:
-  - read
-  - - edit
-    - fileRegex: (.*\.config\.(js|ts|json)|.*rc\.json|.*\.yaml|.*\.yml|\.env\.example)$
-      description: Configuration files (not .env)
-      ]]></configuration>
-    </pattern>
-
-    <pattern name="full_stack">
-      <description>For modes that need broad access</description>
-      <configuration><![CDATA[
-groups:
-  - read
-  - edit  # No restrictions
-  - command
-  - browser
-  - mcp
-      ]]></configuration>
-    </pattern>
-  </permission_patterns>
-
-  <naming_conventions>
-    <convention category="slug">
-      <rule>Use lowercase with hyphens</rule>
-      <good>api-dev, test-writer, docs-manager</good>
-      <bad>apiDev, test_writer, DocsManager</bad>
-    </convention>
-    
-    <convention category="name">
-      <rule>Use title case with descriptive emoji</rule>
-      <good>🔧 API Developer, 📝 Documentation Writer</good>
-      <bad>api developer, DOCUMENTATION WRITER</bad>
-    </convention>
-
-    <convention category="emoji_selection">
-      <common_emojis>
-        <emoji meaning="testing">🧪</emoji>
-        <emoji meaning="documentation">📝</emoji>
-        <emoji meaning="design">🎨</emoji>
-        <emoji meaning="debugging">🪲</emoji>
-        <emoji meaning="building">🏗️</emoji>
-        <emoji meaning="security">🔒</emoji>
-        <emoji meaning="api">🔌</emoji>
-        <emoji meaning="database">🗄️</emoji>
-        <emoji meaning="performance">⚡</emoji>
-        <emoji meaning="configuration">⚙️</emoji>
-      </common_emojis>
-    </convention>
-  </naming_conventions>
-
-  <integration_guidelines>
-    <guideline name="orchestrator_compatibility">
-      <description>Ensure whenToUse is clear for Orchestrator mode</description>
-      <checklist>
-        <item>Specify concrete task types the mode handles</item>
-        <item>Include trigger keywords or phrases</item>
-        <item>Differentiate from similar modes</item>
-        <item>Mention specific file types or areas</item>
-      </checklist>
-    </guideline>
-
-    <guideline name="mode_boundaries">
-      <description>Define clear boundaries between modes</description>
-      <checklist>
-        <item>Avoid overlapping responsibilities</item>
-        <item>Make handoff points explicit</item>
-        <item>Use switch_mode when appropriate</item>
-        <item>Document mode interactions</item>
-      </checklist>
-    </guideline>
-  </integration_guidelines>
-</mode_configuration_patterns>

.roo/rules-mode-writer/4_instruction_file_templates.xml

@@ -1,367 +0,0 @@
-<instruction_file_templates>
-  <overview>
-    Templates and examples for creating XML instruction files that provide
-    detailed guidance for each mode's behavior and workflows.
-  </overview>
-
-  <file_organization>
-    <principle>Number files to indicate execution order</principle>
-    <principle>Use descriptive names that indicate content</principle>
-    <principle>Keep related instructions together</principle>
-    <standard_structure>
-      <file>1_workflow.xml - Main workflow and processes</file>
-      <file>2_best_practices.xml - Guidelines and conventions</file>
-      <file>3_common_patterns.xml - Reusable code patterns</file>
-      <file>4_tool_usage.xml - Specific tool instructions</file>
-      <file>5_examples.xml - Complete workflow examples</file>
-      <file>6_error_handling.xml - Error scenarios and recovery</file>
-      <file>7_communication.xml - User interaction guidelines</file>
-    </standard_structure>
-  </file_organization>
-
-  <workflow_file_template>
-    <description>Template for main workflow files (1_workflow.xml)</description>
-    <template><![CDATA[
-<workflow_instructions>
-  <mode_overview>
-    Brief description of what this mode does and its primary purpose
-  </mode_overview>
-
-  <initialization_steps>
-    <step number="1">
-      <action>Understand the user's request</action>
-      <details>
-        Parse the user's input to identify:
-        - Primary objective
-        - Specific requirements
-        - Constraints or limitations
-      </details>
-    </step>
-    
-    <step number="2">
-      <action>Gather necessary context</action>
-      <tools>
-        <tool>codebase_search - Find relevant existing code</tool>
-        <tool>list_files - Understand project structure</tool>
-        <tool>read_file - Examine specific implementations</tool>
-      </tools>
-    </step>
-  </initialization_steps>
-
-  <main_workflow>
-    <phase name="analysis">
-      <description>Analyze the current state and requirements</description>
-      <steps>
-        <step>Identify affected components</step>
-        <step>Assess impact of changes</step>
-        <step>Plan implementation approach</step>
-      </steps>
-    </phase>
-
-    <phase name="implementation">
-      <description>Execute the planned changes</description>
-      <steps>
-        <step>Create/modify necessary files</step>
-        <step>Ensure consistency across codebase</step>
-        <step>Add appropriate documentation</step>
-      </steps>
-    </phase>
-
-    <phase name="validation">
-      <description>Verify the implementation</description>
-      <steps>
-        <step>Check for errors or inconsistencies</step>
-        <step>Validate against requirements</step>
-        <step>Ensure no regressions</step>
-      </steps>
-    </phase>
-  </main_workflow>
-
-  <completion_criteria>
-    <criterion>All requirements have been addressed</criterion>
-    <criterion>Code follows project conventions</criterion>
-    <criterion>Changes are properly documented</criterion>
-    <criterion>No breaking changes introduced</criterion>
-  </completion_criteria>
-</workflow_instructions>
-    ]]></template>
-  </workflow_file_template>
-
-  <best_practices_template>
-    <description>Template for best practices files (2_best_practices.xml)</description>
-    <template><![CDATA[
-<best_practices>
-  <general_principles>
-    <principle priority="high">
-      <name>Principle Name</name>
-      <description>Detailed explanation of the principle</description>
-      <rationale>Why this principle is important</rationale>
-      <example>
-        <scenario>When this applies</scenario>
-        <good>Correct approach</good>
-        <bad>What to avoid</bad>
-      </example>
-    </principle>
-  </general_principles>
-
-  <code_conventions>
-    <convention category="naming">
-      <rule>Specific naming convention</rule>
-      <examples>
-        <good>goodExampleName</good>
-        <bad>bad_example-name</bad>
-      </examples>
-    </convention>
-    
-    <convention category="structure">
-      <rule>How to structure code/files</rule>
-      <template>
-        // Example structure
-      </template>
-    </convention>
-  </code_conventions>
-
-  <common_pitfalls>
-    <pitfall>
-      <description>Common mistake to avoid</description>
-      <why_problematic>Explanation of issues it causes</why_problematic>
-      <correct_approach>How to do it properly</correct_approach>
-    </pitfall>
-  </common_pitfalls>
-
-  <quality_checklist>
-    <category name="before_starting">
-      <item>Understand requirements fully</item>
-      <item>Check existing implementations</item>
-    </category>
-    <category name="during_implementation">
-      <item>Follow established patterns</item>
-      <item>Write clear documentation</item>
-    </category>
-    <category name="before_completion">
-      <item>Review all changes</item>
-      <item>Verify requirements met</item>
-    </category>
-  </quality_checklist>
-</best_practices>
-    ]]></template>
-  </best_practices_template>
-
-  <tool_usage_template>
-    <description>Template for tool usage files (4_tool_usage.xml)</description>
-    <template><![CDATA[
-<tool_usage_guide>
-  <tool_priorities>
-    <priority level="1">
-      <tool>codebase_search</tool>
-      <when>Always use first to find relevant code</when>
-      <why>Semantic search finds functionality better than keywords</why>
-    </priority>
-    <priority level="2">
-      <tool>read_file</tool>
-      <when>After identifying files with codebase_search</when>
-      <why>Get full context of implementations</why>
-    </priority>
-  </tool_priorities>
-
-  <tool_specific_guidance>
-    <tool name="apply_diff">
-      <best_practices>
-        <practice>Always read file first to ensure exact content match</practice>
-        <practice>Make multiple changes in one diff when possible</practice>
-        <practice>Include line numbers for accuracy</practice>
-      </best_practices>
-      <example><![CDATA[
-<apply_diff>
-<path>src/config.ts</path>
-<diff>
-<<<<<<< SEARCH
-:start_line:10
--------
-export const config = {
-  apiUrl: 'http://localhost:3000',
-  timeout: 5000
-};
-=======
-export const config = {
-  apiUrl: process.env.API_URL || 'http://localhost:3000',
-  timeout: parseInt(process.env.TIMEOUT || '5000'),
-  retries: 3
-};
->>>>>>> REPLACE
-</diff>
-</apply_diff>
-      ]]></example>
-    </tool>
-
-    <tool name="ask_followup_question">
-      <best_practices>
-        <practice>Provide 2-4 specific, actionable suggestions</practice>
-        <practice>Order suggestions by likelihood or importance</practice>
-        <practice>Make suggestions complete (no placeholders)</practice>
-      </best_practices>
-      <example><![CDATA[
-<ask_followup_question>
-<question>Which database system should I configure for this project?</question>
-<follow_up>
-<suggest>PostgreSQL with the default configuration</suggest>
-<suggest>MySQL 8.0 with InnoDB storage engine</suggest>
-<suggest>SQLite for local development only</suggest>
-<suggest>MongoDB for document-based storage</suggest>
-</follow_up>
-</ask_followup_question>
-      ]]></example>
-    </tool>
-  </tool_specific_guidance>
-
-  <tool_combination_patterns>
-    <pattern name="explore_then_modify">
-      <sequence>
-        <step>codebase_search - Find relevant files</step>
-        <step>list_code_definition_names - Understand structure</step>
-        <step>read_file - Get full context</step>
-        <step>apply_diff or write_to_file - Make changes</step>
-      </sequence>
-    </pattern>
-    
-    <pattern name="verify_then_proceed">
-      <sequence>
-        <step>list_files - Check file exists</step>
-        <step>read_file - Verify current content</step>
-        <step>ask_followup_question - Confirm approach</step>
-        <step>apply_diff - Implement changes</step>
-      </sequence>
-    </pattern>
-  </tool_combination_patterns>
-</tool_usage_guide>
-    ]]></template>
-  </tool_usage_template>
-
-  <examples_file_template>
-    <description>Template for example files (5_examples.xml)</description>
-    <template><![CDATA[
-<complete_examples>
-  <example name="descriptive_example_name">
-    <scenario>
-      Detailed description of the use case this example covers
-    </scenario>
-    
-    <user_request>
-      The initial request from the user
-    </user_request>
-
-    <workflow>
-      <step number="1">
-        <description>First step description</description>
-        <tool_use><![CDATA[
-<codebase_search>
-<query>search query here</query>
-</codebase_search>
-        ]]></tool_use>
-        <expected_outcome>What we learn from this step</expected_outcome>
-      </step>
-
-      <step number="2">
-        <description>Second step description</description>
-        <tool_use><![CDATA[
-<read_file>
-<path>path/to/file.ts</path>
-</read_file>
-        ]]></tool_use>
-        <analysis>How we interpret the results</analysis>
-      </step>
-
-      <step number="3">
-        <description>Implementation step</description>
-        <tool_use><![CDATA[
-<apply_diff>
-<path>path/to/file.ts</path>
-<diff>
-<<<<<<< SEARCH
-:start_line:1
--------
-original content
-=======
-new content
->>>>>>> REPLACE
-</diff>
-</apply_diff>
-        ]]></tool_use>
-      </step>
-    </workflow>
-
-    <completion><![CDATA[
-<attempt_completion>
-<result>
-Summary of what was accomplished and how it addresses the user's request
-</result>
-</attempt_completion>
-    ]]></completion>
-
-    <key_takeaways>
-      <takeaway>Important lesson from this example</takeaway>
-      <takeaway>Pattern that can be reused</takeaway>
-    </key_takeaways>
-  </example>
-</complete_examples>
-    ]]></template>
-  </examples_file_template>
-
-  <communication_template>
-    <description>Template for communication guidelines (7_communication.xml)</description>
-    <template><![CDATA[
-<communication_guidelines>
-  <tone_and_style>
-    <principle>Be direct and technical, not conversational</principle>
-    <principle>Focus on actions taken and results achieved</principle>
-    <avoid>
-      <phrase>Great! I'll help you with that...</phrase>
-      <phrase>Certainly! Let me...</phrase>
-      <phrase>Sure thing!</phrase>
-    </avoid>
-    <prefer>
-      <phrase>I'll analyze the codebase to...</phrase>
-      <phrase>Implementing the requested changes...</phrase>
-      <phrase>The analysis shows...</phrase>
-    </prefer>
-  </tone_and_style>
-
-  <user_interaction>
-    <when_to_ask_questions>
-      <scenario>Missing critical information</scenario>
-      <scenario>Multiple valid approaches exist</scenario>
-      <scenario>Potential breaking changes</scenario>
-    </when_to_ask_questions>
-    
-    <question_format>
-      <guideline>Be specific about what you need</guideline>
-      <guideline>Provide actionable options</guideline>
-      <guideline>Explain implications of choices</guideline>
-    </question_format>
-  </user_interaction>
-
-  <progress_updates>
-    <when>During long-running operations</when>
-    <format>
-      <update>Analyzing [X] files for [purpose]...</update>
-      <update>Implementing [feature] in [location]...</update>
-      <update>Validating changes against [criteria]...</update>
-    </format>
-  </progress_updates>
-
-  <completion_messages>
-    <structure>
-      <element>What was accomplished</element>
-      <element>Key changes made</element>
-      <element>Any important notes or warnings</element>
-    </structure>
-    <avoid>
-      <element>Questions at the end</element>
-      <element>Offers for further assistance</element>
-      <element>Conversational closings</element>
-    </avoid>
-  </completion_messages>
-</communication_guidelines>
-    ]]></template>
-  </communication_template>
-</instruction_file_templates>

.roo/rules-mode-writer/5_complete_mode_examples.xml

@@ -1,96 +0,0 @@
-<![CDATA[
-<api_documentation_example>
-  <scenario>
-    Generate OpenAPI documentation for a REST API with user management endpoints
-  </scenario>
-
-  <workflow>
-    <step number="1">
-      <description>Discover API endpoints</description>
-      <tool_use><![CDATA[
-<codebase_search>
-<query>express router app.get app.post app.put app.delete @Route @Get @Post</query>
-</codebase_search>
-      ]]></tool_use>
-      <result>Found routes in src/routes/users.ts</result>
-    </step>
-
-    <step number="2">
-      <description>Analyze endpoint implementation</description>
-      <tool_use><![CDATA[
-<read_file>
-<path>src/routes/users.ts</path>
-</read_file>
-      ]]></tool_use>
-    </step>
-
-    <step number="3">
-      <description>Generate OpenAPI specification</description>
-      <tool_use><![CDATA[
-<write_to_file>
-<path>docs/api/openapi.yaml</path>
-<content>
-openapi: 3.0.0
-info:
-  title: User Management API
-  version: 1.0.0
-  description: API for managing user accounts
-
-servers:
-  - url: https://api.example.com/v1
-    description: Production server
-  - url: http://localhost:3000/v1
-    description: Development server
-
-paths:
-  /users:
-    get:
-      summary: List all users
-      operationId: listUsers
-      tags:
-        - Users
-      parameters:
-        - name: page
-          in: query
-          schema:
-            type: integer
-            default: 1
-        - name: limit
-          in: query
-          schema:
-            type: integer
-            default: 20
-      responses:
-        '200':
-          description: Successful response
-          content:
-            application/json:
-              schema:
-                type: object
-                properties:
-                  users:
-                    type: array
-                    items:
-                      $ref: '#/components/schemas/User'
-                  pagination:
-                    $ref: '#/components/schemas/Pagination'
-
-components:
-  schemas:
-    User:
-      type: object
-      required:
-        - id
-        - email
-      properties:
-        id:
-          type: string
-          format: uuid
-        email:
-          type: string
-          format: email
-        name:
-          type: string
-        createdAt:
-          type: string
-          format: date-time

.roo/rules-mode-writer/6_mode_testing_validation.xml

@@ -1,207 +0,0 @@
-<mode_testing_validation>
-  <overview>
-    Guidelines for testing and validating newly created modes to ensure they function correctly and integrate well with the Roo Code ecosystem.
-  </overview>
-
-  <validation_checklist>
-    <category name="configuration_validation">
-      <item priority="critical">
-        <check>Mode slug is unique and follows naming conventions</check>
-        <validation>No spaces, lowercase, hyphens only</validation>
-      </item>
-      <item priority="critical">
-        <check>All required fields are present and non-empty</check>
-        <fields>slug, name, roleDefinition, groups</fields>
-      </item>
-      <item priority="critical">
-        <check>No customInstructions field in .roomodes</check>
-        <validation>All instructions must be in XML files in .roo/rules-[slug]/</validation>
-      </item>
-      <item priority="high">
-        <check>File restrictions use valid regex patterns</check>
-        <test_method><![CDATA[
-<search_files>
-<path>.</path>
-<regex>your_file_regex_here</regex>
-</search_files>
-        ]]></test_method>
-      </item>
-      <item priority="high">
-        <check>whenToUse clearly differentiates from other modes</check>
-        <validation>Compare with existing mode descriptions</validation>
-      </item>
-    </category>
-
-    <category name="instruction_validation">
-      <item>
-        <check>XML files are well-formed and valid</check>
-        <validation>No syntax errors, proper closing tags</validation>
-      </item>
-      <item>
-        <check>Instructions follow XML best practices</check>
-        <validation>Semantic tag names, proper nesting</validation>
-      </item>
-      <item>
-        <check>Examples use correct tool syntax</check>
-        <validation>Tool parameters match current API</validation>
-      </item>
-      <item>
-        <check>File paths in examples are consistent</check>
-        <validation>Use project-relative paths</validation>
-      </item>
-    </category>
-
-    <category name="functional_testing">
-      <item>
-        <check>Mode appears in mode list</check>
-        <test>Switch to the new mode and verify it loads</test>
-      </item>
-      <item>
-        <check>Tool permissions work as expected</check>
-        <test>Try using each tool group and verify access</test>
-      </item>
-      <item>
-        <check>File restrictions are enforced</check>
-        <test>Attempt to edit allowed and restricted files</test>
-      </item>
-      <item>
-        <check>Mode handles edge cases gracefully</check>
-        <test>Test with minimal input, errors, edge cases</test>
-      </item>
-    </category>
-  </validation_checklist>
-
-  <testing_workflow>
-    <step number="1">
-      <title>Configuration Testing</title>
-      <actions>
-        <action>Verify mode appears in available modes list</action>
-        <action>Check that mode metadata displays correctly</action>
-        <action>Confirm mode can be activated</action>
-      </actions>
-      <verification><![CDATA[
-<ask_followup_question>
-<question>I've created the mode configuration. Can you see the new mode in your mode list?</question>
-<follow_up>
-<suggest>Yes, I can see the new mode and switch to it</suggest>
-<suggest>No, the mode doesn't appear in the list</suggest>
-<suggest>The mode appears but has errors when switching</suggest>
-</follow_up>
-</ask_followup_question>
-      ]]></verification>
-    </step>
-
-    <step number="2">
-      <title>Permission Testing</title>
-      <test_cases>
-        <test case="read_permissions">
-          <action>Use read tools on various files</action>
-          <expected>All read operations should work</expected>
-        </test>
-        <test case="edit_restrictions">
-          <action>Try editing allowed file types</action>
-          <expected>Edits succeed for matching patterns</expected>
-        </test>
-        <test case="edit_restrictions_negative">
-          <action>Try editing restricted file types</action>
-          <expected>FileRestrictionError for non-matching files</expected>
-        </test>
-      </test_cases>
-    </step>
-
-    <step number="3">
-      <title>Workflow Testing</title>
-      <actions>
-        <action>Execute main workflow from start to finish</action>
-        <action>Test each decision point</action>
-        <action>Verify error handling</action>
-        <action>Check completion criteria</action>
-      </actions>
-    </step>
-
-    <step number="4">
-      <title>Integration Testing</title>
-      <areas>
-        <area>Orchestrator mode compatibility</area>
-        <area>Mode switching functionality</area>
-        <area>Tool handoff between modes</area>
-        <area>Consistent behavior with other modes</area>
-      </areas>
-    </step>
-  </testing_workflow>
-
-  <common_issues>
-    <issue type="configuration">
-      <problem>Mode doesn't appear in list</problem>
-      <causes>
-        <cause>Syntax error in YAML</cause>
-        <cause>Invalid mode slug</cause>
-        <cause>File not saved</cause>
-      </causes>
-      <solution>Check YAML syntax, validate slug format</solution>
-    </issue>
-
-    <issue type="permissions">
-      <problem>File restriction not working</problem>
-      <causes>
-        <cause>Invalid regex pattern</cause>
-        <cause>Escaping issues in regex</cause>
-        <cause>Wrong file path format</cause>
-      </causes>
-      <solution>Test regex pattern, use proper escaping</solution>
-      <example><![CDATA[
-# Wrong: *.ts (glob pattern)
-# Right: .*\.ts$ (regex pattern)
-      ]]></example>
-    </issue>
-
-    <issue type="behavior">
-      <problem>Mode not following instructions</problem>
-      <causes>
-        <cause>Instructions not in .roo/rules-[slug]/ folder</cause>
-        <cause>XML parsing errors</cause>
-        <cause>Conflicting instructions</cause>
-      </causes>
-      <solution>Verify file locations and XML validity</solution>
-    </issue>
-  </common_issues>
-
-  <debugging_tools>
-    <tool name="list_files">
-      <usage>Verify instruction files exist in correct location</usage>
-      <command><![CDATA[
-<list_files>
-<path>.roo</path>
-<recursive>true</recursive>
-</list_files>
-      ]]></command>
-    </tool>
-
-    <tool name="read_file">
-      <usage>Check mode configuration syntax</usage>
-      <command><![CDATA[
-<read_file>
-<path>.roomodes</path>
-</read_file>
-      ]]></command>
-    </tool>
-
-    <tool name="search_files">
-      <usage>Test file restriction patterns</usage>
-      <command><![CDATA[
-<search_files>
-<path>.</path>
-<regex>your_file_pattern_here</regex>
-</search_files>
-      ]]></command>
-    </tool>
-  </debugging_tools>
-
-  <best_practices>
-    <practice>Test incrementally as you build the mode</practice>
-    <practice>Start with minimal configuration and add complexity</practice>
-    <practice>Document any special requirements or dependencies</practice>
-    <practice>Consider edge cases and error scenarios</practice>
-    <practice>Get feedback from potential users of the mode</practice>
-  </best_practices>
-</mode_testing_validation>

.roo/rules-pr-fixer-orchestrator/1_Workflow.xml

@@ -1,771 +0,0 @@
-<workflow>
-  <step number="1">
-    <name>Initialize PR Context</name>
-    <instructions>
-      The user will provide a GitHub PR URL or number.
-      
-      1.  **Parse Input**: Extract the `owner`, `repo`, and `pr_number` from the URL or use provided number.
-      2.  **Create Task Directory**: Create a dedicated directory to store all context for this PR fix task.
-          <execute_command>
-          <command>mkdir -p .roo/temp/pr-fixer-orchestrator/[TASK_ID]</command>
-          </execute_command>
-      3.  **Retrieve PR Details**: Fetch the PR details, comments, and check status as a comprehensive JSON object.
-          <execute_command>
-          <command>gh pr view [pr_number] --repo [owner]/[repo] --json number,title,body,state,labels,author,headRefName,baseRefName,mergeable,mergeStateStatus,isDraft,isCrossRepository,headRepositoryOwner,reviews,statusCheckRollup,comments > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_context.json</command>
-          </execute_command>
-      4.  **Get Review Comments**: Fetch detailed review comments separately for better analysis.
-          <execute_command>
-          <command>gh pr view [pr_number] --repo [owner]/[repo] --comments > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_comments.txt</command>
-          </execute_command>
-      5.  **Check CI Status**: Get current check status and any failing workflows.
-          <execute_command>
-          <command>gh pr checks [pr_number] --repo [owner]/[repo] --json name,state,conclusion,detailsUrl > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_checks.json</command>
-          </execute_command>
-      6.  **Get Associated Issue**: Check if PR is linked to an issue and fetch issue details if available.
-          <execute_command>
-          <command>gh pr view [pr_number] --repo [owner]/[repo] --json closingIssuesReferences > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/linked_issues.json</command>
-          </execute_command>
-          If linked issues exist, fetch the first issue's details:
-          <execute_command>
-          <command>gh issue view [issue_number] --repo [owner]/[repo] --json number,title,body,state,labels,assignees,milestone,createdAt,updatedAt,closedAt,author,comments > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/issue_context.json</command>
-          </execute_command>
-      7.  **Handle Auth Errors**: If any `gh` command fails with authentication error, prompt the user to log in.
-      8.  **Confirm Context**: Inform the user that the PR context has been gathered.
-    </instructions>
-  </step>
-
-  <step number="2">
-    <name>Checkout PR Branch and Initial Analysis</name>
-    <instructions>
-      Before delegating analysis, ensure the PR branch is checked out locally.
-
-      1.  **Checkout PR Branch**: Use gh to checkout the PR branch locally.
-          <execute_command>
-          <command>gh pr checkout [pr_number] --repo [owner]/[repo] --force</command>
-          </execute_command>
-          
-      2.  **Determine Remote Type**: Check if this is a cross-repository PR (from a fork).
-          <execute_command>
-          <command>gh pr view [pr_number] --repo [owner]/[repo] --json isCrossRepository,headRepositoryOwner,headRefName > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_remote_info.json</command>
-          </execute_command>
-          
-      3.  **Setup Fork Remote if Needed**: If it's a cross-repository PR, ensure fork remote is configured.
-          Read the pr_remote_info.json file. If isCrossRepository is true:
-          <execute_command>
-          <command>git remote add fork https://github.com/[headRepositoryOwner]/[repo].git || git remote set-url fork https://github.com/[headRepositoryOwner]/[repo].git</command>
-          </execute_command>
-          
-      4.  **Fetch Latest Main**: Ensure we have the latest main branch for comparison.
-          <execute_command>
-          <command>git fetch origin main</command>
-          </execute_command>
-          
-      5.  **Check for Conflicts**: Determine if there are merge conflicts with main.
-          <execute_command>
-          <command>git merge-tree $(git merge-base HEAD origin/main) HEAD origin/main > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/merge_conflicts.txt</command>
-          </execute_command>
-          
-      6.  **Get PR Diff**: Fetch the files changed in this PR for context.
-          <execute_command>
-          <command>gh pr diff [pr_number] --repo [owner]/[repo] --name-only > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_changed_files.txt</command>
-          </execute_command>
-          
-      7.  **Check Merge Diff Size**: Get the full diff and check line count.
-          <execute_command>
-          <command>git diff origin/main...HEAD > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/full_merge_diff.txt</command>
-          </execute_command>
-          <execute_command>
-          <command>wc -l .roo/temp/pr-fixer-orchestrator/[TASK_ID]/full_merge_diff.txt</command>
-          </execute_command>
-          
-          If the diff has over 2000 lines, create a summary instead:
-          <execute_command>
-          <command>git diff origin/main...HEAD --stat > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/merge_diff_summary.txt</command>
-          </execute_command>
-          <execute_command>
-          <command>rm .roo/temp/pr-fixer-orchestrator/[TASK_ID]/full_merge_diff.txt</command>
-          </execute_command>
-    </instructions>
-  </step>
-
-  <step number="3">
-    <name>Delegate: Comprehensive Requirements and PR Analysis</name>
-    <instructions>
-      Launch a subtask in `architect` mode to perform a detailed analysis of the PR, its underlying requirements, and all issues that need to be addressed.
-
-      The context files in `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/` will be the input for this subtask. 
-      The subtask should write its findings to: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_analysis_report.md`.
-
-      <new_task>
-        <mode>architect</mode>
-        <message>
-          **Task: Analyze Pull Request Requirements and Create Comprehensive Fix Plan**
-
-          You are an expert software architect. Your task is to analyze a pull request, understand its underlying requirements, and create a comprehensive plan to address all issues.
-
-          1.  **Read PR Context**: The PR details are in:
-              - `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_context.json` - Full PR metadata
-              - `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_comments.txt` - Review comments
-              - `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_checks.json` - CI/CD check status
-              - `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/merge_conflicts.txt` - Conflict analysis
-              - `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_changed_files.txt` - Files changed in PR
-              - `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/linked_issues.json` - Associated issues (if any)
-              - `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/issue_context.json` - Issue details (if linked)
-              - `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/full_merge_diff.txt` OR `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/merge_diff_summary.txt` - Diff information
-
-          2.  **Understand the PR's Purpose**:
-              - Extract the feature or bug being addressed from PR title, body, and linked issues
-              - Identify the acceptance criteria (from PR description or linked issue)
-              - Understand the intended functionality and expected behavior
-              - Note any design decisions or architectural choices made
-
-          3.  **Perform Architectural Analysis**:
-              - **Map Component Interactions**: Trace the complete data flow for the PR's changes
-              - **Identify Paired Operations**: For any operation (e.g., export), find its counterpart (e.g., import)
-              - **Find Similar Patterns**: Search for existing implementations of similar features
-              - **Analyze Dependencies**: Identify all consumers of the functionality being modified
-              - **Assess Impact**: Determine how changes affect other parts of the system
-
-          4.  **Explore Codebase Systematically**:
-              - Use `codebase_search` FIRST to understand the feature area
-              - Search for related functionality that might be affected
-              - Find all files that consume or depend on the changed functionality
-              - Identify configuration files, tests, and documentation that need updates
-              - Study similar features to understand established patterns
-
-          5.  **Analyze Review Feedback**:
-              - Categorize review comments by type (bug, enhancement, style, etc.)
-              - Identify which comments are actionable vs informational
-              - Prioritize changes based on reviewer authority and importance
-              - Note any conflicting feedback that needs clarification
-
-          6.  **Investigate Failing Tests**:
-              - For each failing check, determine the root cause
-              - Use `gh run view --log-failed` to get detailed error logs
-              - Identify if failures are due to code issues, flaky tests, or environment problems
-              - Determine which files need modification to fix test failures
-
-          7.  **Assess Merge Conflicts**:
-              - Analyze the merge_conflicts.txt file
-              - Identify which files have conflicts
-              - Determine the complexity of conflict resolution
-              - Plan the rebase/merge strategy
-
-          8.  **Create Comprehensive Fix Plan**: The plan must include:
-              - **PR Purpose Summary**: Clear description of what the PR is trying to achieve
-              - **Requirements Analysis**:
-                - Original requirements from issue or PR description
-                - Acceptance criteria that must be met
-                - Any missing functionality that needs to be added
-              - **Architectural Context**:
-                - Data flow diagram showing component interactions
-                - List of paired operations that must be updated together
-                - Dependencies and consumers of the affected functionality
-              - **Issue Summary**: Clear categorization of all issues found
-              - **Priority Order**: Which issues to tackle first and why
-              - **Review Feedback Analysis**:
-                - List of all actionable review comments
-                - Specific code changes required for each
-                - Any clarifications needed from reviewers
-              - **Test Failure Resolution**:
-                - Root cause of each failing test
-                - Files and changes needed to fix
-                - Any test updates required
-              - **Conflict Resolution Strategy**:
-                - Whether to rebase or merge
-                - Order of operations for conflict resolution
-                - Risk assessment of conflicts
-              - **Implementation Steps**:
-                - Detailed, ordered steps for fixing all issues
-                - Specific commands and file modifications
-                - Validation steps after each change
-              - **Risk Assessment**:
-                - Potential side effects of changes
-                - Areas requiring extra testing
-                - Backward compatibility concerns
-
-          9.  **Save the Analysis**: Write the complete analysis to `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_analysis_report.md`.
-
-          **Critical Requirements:**
-          - Always understand the PR's underlying purpose before analyzing issues
-          - Be thorough in analyzing all aspects of the PR
-          - Consider the interaction between different fixes
-          - Provide specific, actionable steps
-          - Include exact commands where applicable
-          - **IMPORTANT**: Save your analysis to the specified file in .roo/temp/pr-fixer-orchestrator/[TASK_ID]/
-
-          **Completion Protocol:**
-          - This is your only task. Do not deviate from these instructions.
-          - Once you have successfully written the analysis report, you MUST signal completion by using the `attempt_completion` tool.
-          - The `result` parameter MUST be: "PR analysis complete and saved to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_analysis_report.md"
-        </message>
-      </new_task>
-
-      After launching the subtask, wait for it to complete. The orchestrator will then read the analysis report to proceed.
-    </instructions>
-  </step>
-
-  <step number="4">
-    <name>Review Analysis and Get User Approval</name>
-    <instructions>
-      After the analysis subtask completes, present the findings to the user for approval.
-
-      1.  **Read the Analysis Report**:
-          <read_file>
-            <args>
-              <file>
-                <path>.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_analysis_report.md</path>
-              </file>
-            </args>
-          </read_file>
-
-      2.  **Present for Approval**: Show the analysis to the user and ask how to proceed.
-          <ask_followup_question>
-            <question>
-              I've completed the analysis of PR #[pr_number]. Here's what I found:
-
-              ---
-              [Insert content of pr_analysis_report.md here]
-              ---
-
-              How would you like to proceed with fixing these issues?
-            </question>
-            <follow_up>
-              <suggest>Fix all issues in the recommended priority order</suggest>
-              <suggest>Only fix the review comments, skip failing tests for now</suggest>
-              <suggest>Only fix failing tests and conflicts, skip review comments</suggest>
-              <suggest>Let me choose specific issues to fix</suggest>
-            </follow_up>
-          </ask_followup_question>
-      
-      3.  **Handle User Choice**: Based on the user's selection, prepare the implementation scope.
-          Save the user's choice to `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/implementation_scope.txt`
-    </instructions>
-  </step>
-
-  <step number="5">
-    <name>Fetch Latest from Main and Check Differences</name>
-    <instructions>
-      Before implementing fixes, ensure we're working with the latest code and understand what has changed.
-
-      1.  **Fetch Latest Changes**:
-          <execute_command>
-          <command>git fetch origin main</command>
-          </execute_command>
-
-      2.  **Analyze Differences**: Create a detailed diff report.
-          <execute_command>
-          <command>git diff origin/main...HEAD --name-status > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_file_changes.txt</command>
-          </execute_command>
-          
-      3.  **Check Commit History**: Understand what commits are in this PR.
-          <execute_command>
-          <command>git log origin/main..HEAD --oneline > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_commits.txt</command>
-          </execute_command>
-
-      4.  **Identify New Commits on Main**: See what has been merged to main since the PR was created.
-          <execute_command>
-          <command>git log HEAD..origin/main --oneline > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/new_main_commits.txt</command>
-          </execute_command>
-
-      5.  **Save Merge Strategy**: Based on the analysis, determine if we should rebase or merge.
-          Create `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/merge_strategy.txt` with either "rebase" or "merge"
-    </instructions>
-  </step>
-
-  <step number="6">
-    <name>Delegate: Implement Fixes</name>
-    <instructions>
-      Launch a subtask in `code` mode to implement all the fixes based on the analysis and user's choices.
-
-      <new_task>
-        <mode>code</mode>
-        <message>
-          **Task: Implement PR Fixes Based on Analysis**
-
-          You are an expert software developer. Your task is to implement fixes for a pull request based on the analysis and plan.
-
-          1.  **Read Context Files**:
-              - Analysis Report: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_analysis_report.md`
-              - Implementation Scope: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/implementation_scope.txt`
-              - File Changes: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_file_changes.txt`
-              - Merge Strategy: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/merge_strategy.txt`
-
-          2.  **Handle Merge/Rebase First** (if conflicts exist):
-              - If merge_strategy.txt says "rebase":
-                <execute_command>
-                <command>GIT_EDITOR=true git rebase origin/main</command>
-                </execute_command>
-              - If conflicts occur, resolve them by editing the conflicted files
-              - Remember to escape conflict markers when using apply_diff
-              - After resolving each file: `git add [file]`
-              - Continue rebase: `git rebase --continue`
-
-          3.  **Implement Missing Functionality** (if identified in analysis):
-              - Add any missing features or functionality noted in the requirements analysis
-              - Follow the architectural patterns identified in the analysis
-              - Ensure all acceptance criteria are met
-              - Update related operations to maintain consistency
-
-          4.  **Implement Review Feedback**:
-              - Address each actionable review comment from the analysis
-              - Make code changes using appropriate file editing tools
-              - Ensure changes follow project coding standards
-              - Add comments where complex logic is introduced
-
-          5.  **Fix Failing Tests**:
-              - Based on the root cause analysis, fix test failures
-              - This may involve fixing source code or updating tests
-              - Run tests locally if possible to verify fixes
-              - Document any test changes made
-
-          6.  **Track All Changes**: As you make changes, maintain a list of:
-              - Files modified with brief description of changes
-              - Review comments addressed
-              - Tests fixed
-              - Missing functionality added
-              - Any additional improvements made
-
-          7.  **Create Change Summary**: Write a comprehensive summary to:
-              `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/changes_implemented.md`
-              Include:
-              - List of all files modified
-              - Review comments addressed (with file:line references)
-              - Test fixes applied
-              - Conflict resolutions performed
-              - Missing functionality implemented
-              - Any additional improvements
-
-          **Important Reminders:**
-          - Follow the implementation plan from the analysis
-          - Respect the user's chosen scope
-          - Make minimal, targeted changes
-          - Preserve existing functionality
-          - When resolving conflicts, understand both sides before choosing
-          - Ensure all original PR requirements are met
-          - **IMPORTANT**: Save all output files to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/
-
-          **Completion Protocol:**
-          - Once all fixes are implemented and the summary is saved, use `attempt_completion`.
-          - Result: "PR fixes implemented and summary saved to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/changes_implemented.md"
-        </message>
-      </new_task>
-
-      Wait for the implementation subtask to complete before proceeding.
-    </instructions>
-  </step>
-
-  <step number="7">
-    <name>Delegate: Test and Validate Changes</name>
-    <instructions>
-      After implementation, delegate testing and validation to ensure all fixes work correctly.
-
-      <new_task>
-        <mode>test</mode>
-        <message>
-          **Task: Validate PR Fixes and Run Tests**
-
-          You are a meticulous QA engineer. Your task is to validate that all PR fixes have been properly implemented.
-
-          **Context Files:**
-          - Original Analysis: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_analysis_report.md`
-          - Changes Made: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/changes_implemented.md`
-          - Original PR Checks: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_checks.json`
-
-          **Your Steps:**
-          1.  **Verify Requirements**: Check that all original PR requirements and acceptance criteria are met.
-          
-          2.  **Verify Review Comments**: Check that each review comment marked as addressed in changes_implemented.md has been properly fixed.
-          
-          3.  **Run Local Tests**: Execute relevant test suites.
-              - Identify test files related to changed code
-              - Run unit tests for modified components
-              - Run integration tests if applicable
-              - Document all test results
-
-          4.  **Validate Code Quality**:
-              - Run linters on changed files
-              - Check for type errors (if TypeScript)
-              - Verify no console.logs or debug code remains
-              - Ensure proper error handling
-
-          5.  **Check for Regressions**:
-              - Verify existing functionality still works
-              - Look for potential side effects of changes
-              - Test edge cases around modified code
-
-          6.  **Create Validation Report**: Write findings to `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/validation_report.md`
-              Include:
-              - Test results summary (pass/fail counts)
-              - Requirements verification checklist
-              - Review comment verification checklist
-              - Any issues or concerns found
-              - Recommendations for additional testing
-              - Overall assessment: READY or NEEDS_WORK
-
-          **Critical Focus Areas:**
-          - Ensure all originally failing tests now pass
-          - Verify no new test failures introduced
-          - Confirm review feedback properly addressed
-          - Check that all PR requirements are fulfilled
-          - Check for unintended consequences
-          - **IMPORTANT**: Save your report to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/
-
-          **Completion Protocol:**
-          - Save validation report and use `attempt_completion`
-          - Result: "Validation complete. Report saved to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/validation_report.md"
-        </message>
-      </new_task>
-
-      Wait for validation to complete before proceeding.
-    </instructions>
-  </step>
-
-  <step number="8">
-    <name>Handle Validation Results and Translation Needs</name>
-    <instructions>
-      Review validation results and check if translation updates are needed.
-
-      1.  **Read Validation Report**:
-          <read_file>
-            <args>
-              <file>
-                <path>.roo/temp/pr-fixer-orchestrator/[TASK_ID]/validation_report.md</path>
-              </file>
-            </args>
-          </read_file>
-
-      2.  **If Validation Failed**: Present issues to user and ask how to proceed.
-          If the report indicates NEEDS_WORK, use ask_followup_question to get direction.
-
-      3.  **Check for Translation Requirements**:
-          Read the changes_implemented.md file and check for:
-          - Changes to i18n JSON files
-          - Modifications to UI components with user-facing text
-          - Updates to announcement files or documentation
-          - New error messages or notifications
-
-      4.  **Delegate Translation if Needed**:
-          If translation is required:
-          <new_task>
-            <mode>translate</mode>
-            <message>
-              **Task: Update Translations for PR Fixes**
-
-              PR #[pr_number] fixes have been implemented. Please handle translation updates for the following changes:
-
-              **Changed Files:**
-              [List specific files from changes_implemented.md that need translation]
-
-              **Specific Changes:**
-              [Detail what text was added/modified]
-
-              Please ensure all supported languages are updated with appropriate translations.
-              Save a summary of translation changes to `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/translation_summary.md`
-
-              **IMPORTANT**: Save your summary to the specified file in .roo/temp/pr-fixer-orchestrator/[TASK_ID]/
-            </message>
-          </new_task>
-
-      5.  **Proceed When Ready**: Only continue after validation passes and translations complete (if needed).
-    </instructions>
-  </step>
-
-  <step number="9">
-    <name>Prepare PR Message and Get User Approval</name>
-    <instructions>
-      Before committing changes, prepare the PR update message and get user approval.
-
-      1.  **Check Files to be Committed**: List all modified files.
-          <execute_command>
-          <command>git status --porcelain > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/files_to_commit.txt</command>
-          </execute_command>
-          
-      2.  **Read Implementation Summary**:
-          <read_file>
-            <args>
-              <file>
-                <path>.roo/temp/pr-fixer-orchestrator/[TASK_ID]/changes_implemented.md</path>
-              </file>
-            </args>
-          </read_file>
-
-      3.  **Create PR Update Message**: Based on the changes, create a comprehensive PR update message following the template.
-          Save to `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_update_message.md`:
-          
-          ```markdown
-          ## PR Update Summary
-          
-          This update addresses the review feedback and fixes identified issues.
-          
-          ## Changes Made
-          
-          [List from changes_implemented.md]
-          - Fixed [specific issue] in [file]
-          - Addressed review comment about [topic]
-          - Updated tests for [functionality]
-          - Resolved merge conflicts in [files]
-          
-          ## Review Comments Addressed
-          
-          [For each review comment addressed]
-          - ✅ Comment: "[reviewer comment]"
-            - Fix: [what was done]
-            - Files: [files modified]
-          
-          ## Test Fixes
-          
-          [If tests were fixed]
-          - Fixed failing test: [test name]
-            - Issue: [root cause]
-            - Solution: [fix applied]
-          
-          ## Translations Updated
-          
-          [If translations were updated]
-          - Updated [X] language files for [changes]
-          - All user-facing strings properly translated
-          
-          ## Verification
-          
-          - [x] All review comments addressed
-          - [x] All tests passing locally
-          - [x] No regressions introduced
-          - [x] Code follows project standards
-          - [x] Translations updated (if applicable)
-          
-          ## Files Modified
-          
-          [List all files that will be committed]
-          ```
-
-      4.  **Get User Approval**: Present the changes and ask for confirmation.
-          <ask_followup_question>
-            <question>
-              I've completed all the fixes for PR #[pr_number]. Here's a summary of what will be committed:
-
-              **Files to be committed:**
-              [Content of files_to_commit.txt]
-
-              **PR Update Message:**
-              [Content of pr_update_message.md]
-
-              Would you like me to proceed with committing these changes?
-            </question>
-            <follow_up>
-              <suggest>Looks good, go ahead and commit the changes</suggest>
-              <suggest>I tested the changes and something is wrong - let me describe the issue</suggest>
-              <suggest>I still need to test the changes manually before committing</suggest>
-              <suggest>Let me review specific files before committing</suggest>
-            </follow_up>
-          </ask_followup_question>
-
-      5.  **Handle User Response**:
-          - If approved: Continue to commit
-          - If issues found: Document the issue and determine next steps
-          - If manual testing needed: Wait for user to complete testing
-          - If review requested: Show requested files and wait for approval
-    </instructions>
-  </step>
-
-  <step number="10">
-    <name>Commit Changes and Prepare for Push</name>
-    <instructions>
-      Once user approves, commit the changes with appropriate message.
-
-      1.  **Stage Only Necessary Files**: Review files and stage appropriately.
-          Read files_to_commit.txt and ensure only relevant files are staged.
-          <execute_command>
-          <command>git add [specific files from the implementation]</command>
-          </execute_command>
-          
-          Note: Do NOT use `git add -A` to avoid adding unintended files.
-
-      2.  **Create Commit Message**: Based on the changes made, create an appropriate commit message.
-          <execute_command>
-          <command>git commit -m "fix: address PR feedback and fix failing tests
-
-- addressed review comments
-- fixed failing tests
-- resolved conflicts (if applicable)
-- updated translations (if needed)
-
-See PR for detailed changes"</command>
-          </execute_command>
-
-      3.  **Verify Remote Configuration**: Check which remote to push to.
-          <read_file>
-            <args>
-              <file>
-                <path>.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_remote_info.json</path>
-              </file>
-            </args>
-          </read_file>
-
-      4.  **Determine Push Target**: 
-          - If isCrossRepository is false: push to origin
-          - If isCrossRepository is true: push to fork
-    </instructions>
-  </step>
-
-  <step number="11">
-    <name>Delegate: Final PR Review</name>
-    <instructions>
-      Before pushing changes, have the PR reviewer mode review all changes to ensure quality.
-
-      <new_task>
-        <mode>pr-reviewer</mode>
-        <message>
-          **Task: Review PR Fix Implementation**
-
-          You are reviewing the fixes applied to PR #[pr_number]. Your task is to ensure all changes are high quality and properly address the original feedback.
-
-          **Context Files:**
-          - Original PR Analysis: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_analysis_report.md`
-          - Changes Implemented: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/changes_implemented.md`
-          - Validation Report: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/validation_report.md`
-          - Translation Summary (if exists): `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/translation_summary.md`
-          - PR Update Message: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_update_message.md`
-
-          **Review Focus:**
-          1. **Completeness**: Verify all identified issues have been addressed
-          2. **Requirements**: Confirm all original PR requirements are met
-          3. **Code Quality**: Check that fixes follow best practices
-          4. **No Regressions**: Ensure no new issues introduced
-          5. **Review Feedback**: Confirm all reviewer comments properly addressed
-          6. **Test Coverage**: Verify tests cover the changes
-          7. **Documentation**: Check if docs/comments are adequate
-
-          **Your Task:**
-          1. Review the actual code changes using git diff
-          2. Cross-reference with the original review feedback
-          3. Verify all PR requirements are fulfilled
-          4. Assess the quality of the implementation
-          5. Check for any missed requirements
-          6. Create a final review report
-
-          Save your review to `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/final_review.md` with:
-          - Overall Assessment: APPROVED or NEEDS_REVISION
-          - Quality Score: 1-10
-          - Detailed feedback on the implementation
-          - Any remaining concerns
-          - Recommendations for improvement
-
-          **IMPORTANT**: Save your review to the specified file in .roo/temp/pr-fixer-orchestrator/[TASK_ID]/
-
-          **Completion Protocol:**
-          - Save review and use `attempt_completion`
-          - Result: "Final review complete and saved to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/final_review.md"
-        </message>
-      </new_task>
-
-      Wait for the review to complete.
-    </instructions>
-  </step>
-
-  <step number="12">
-    <name>Process Final Review and Push Changes</name>
-    <instructions>
-      Based on the final review, either push changes or address remaining issues.
-
-      1.  **Read Final Review**:
-          <read_file>
-            <args>
-              <file>
-                <path>.roo/temp/pr-fixer-orchestrator/[TASK_ID]/final_review.md</path>
-              </file>
-            </args>
-          </read_file>
-
-      2.  **If Review Requests Revisions**:
-          Present the feedback to the user and ask if they want to address the issues now or push as-is.
-
-      3.  **Push Changes**: If approved or user chooses to push:
-          Based on pr_remote_info.json, push to the correct remote:
-          
-          For same-repository PRs:
-          <execute_command>
-          <command>git push --force-with-lease origin [branch_name]</command>
-          </execute_command>
-          
-          For cross-repository PRs:
-          <execute_command>
-          <command>git push --force-with-lease fork [branch_name]</command>
-          </execute_command>
-
-      4.  **Monitor Push Result**: Ensure the push succeeds.
-          If --force-with-lease fails, fetch and retry with --force.
-    </instructions>
-  </step>
-
-  <step number="13">
-    <name>Verify PR Status and Monitor Checks</name>
-    <instructions>
-      After pushing, verify the PR is in good state and monitor CI/CD checks.
-
-      1.  **Verify PR is Up to Date**:
-          <execute_command>
-          <command>gh pr view [pr_number] --repo [owner]/[repo] --json mergeable,mergeStateStatus</command>
-          </execute_command>
-
-      2.  **Monitor CI/CD Checks in Real-Time**:
-          <execute_command>
-          <command>gh pr checks [pr_number] --repo [owner]/[repo] --watch</command>
-          </execute_command>
-          This will continuously monitor until all checks complete.
-
-      3.  **Get Final Status**: Once monitoring completes, get the final state.
-          <execute_command>
-          <command>gh pr checks [pr_number] --repo [owner]/[repo] --json name,state,conclusion > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/final_checks.json</command>
-          </execute_command>
-
-      4.  **Comment on PR**: Add a summary comment about the fixes applied.
-          Read the PR update message we prepared:
-          <read_file>
-            <args>
-              <file>
-                <path>.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_update_message.md</path>
-              </file>
-            </args>
-          </read_file>
-          
-          Then post it as a comment:
-          <execute_command>
-          <command>gh pr comment [pr_number] --repo [owner]/[repo] --body-file .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_update_message.md</command>
-          </execute_command>
-
-      5.  **Save PR Message**: Keep the PR message for reference.
-          The PR update message has already been saved to `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_update_message.md`
-
-      6.  **Final Summary**: Present the final status to the user, confirming:
-          - All requested changes have been implemented
-          - The branch is synced with main
-          - CI/CD checks status
-          - The PR is ready for maintainer review and merge
-          - PR update message has been posted and saved
-
-      7.  **Optional Cleanup**: Ask user if they want to clean up temporary files.
-          <ask_followup_question>
-            <question>
-              PR #[pr_number] has been successfully updated!
-              
-              - All changes committed and pushed
-              - CI/CD checks are [status]
-              - PR comment posted with update summary
-              - PR message saved to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_update_message.md
-              
-              Would you like me to clean up the temporary files?
-            </question>
-            <follow_up>
-              <suggest>Yes, clean up temporary files</suggest>
-              <suggest>No, keep the files for reference</suggest>
-            </follow_up>
-          </ask_followup_question>
-          
-          If user chooses cleanup:
-          <execute_command>
-          <command>rm -rf .roo/temp/pr-fixer-orchestrator/[TASK_ID]</command>
-          </execute_command>
-    </instructions>
-  </step>
-</workflow>

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

@@ -1,186 +0,0 @@
-<best_practices>
-  <orchestration_principles>
-    <principle priority="critical">
-      <name>Always Delegate Specialized Work</name>
-      <description>The orchestrator coordinates but doesn't implement. Use specialized modes for analysis, coding, testing, and review.</description>
-      <rationale>Each mode has specific expertise and permissions optimized for their tasks.</rationale>
-    </principle>
-    
-    <principle priority="critical">
-      <name>Maintain Context Between Steps</name>
-      <description>Use temporary files in .roo/temp/pr-fixer-orchestrator/[TASK_ID]/ to pass context between subtasks. ALL delegated tasks must save outputs to this directory.</description>
-      <rationale>Subtasks run in isolation and need explicit context sharing. Files saved elsewhere will be inaccessible to subsequent steps.</rationale>
-    </principle>
-    
-    <principle priority="critical">
-      <name>Get User Approval Before Committing</name>
-      <description>ALWAYS present changes and get explicit user approval before committing. Show modified files, summarize changes, and ask for confirmation.</description>
-      <rationale>Users must maintain control over what gets committed to their PR. Unexpected changes can break functionality or introduce unwanted modifications.</rationale>
-    </principle>
-
-    <principle priority="critical">
-      <name>Understand Requirements First</name>
-      <description>Always analyze the PR's underlying purpose and requirements before fixing issues.</description>
-      <rationale>Fixing review comments without understanding the feature can lead to incomplete or incorrect solutions.</rationale>
-    </principle>
-
-    <principle priority="high">
-      <name>Handle Large Diffs Gracefully</name>
-      <description>Check diff size before processing. If over 2000 lines, create a summary instead of including the full diff.</description>
-      <rationale>Large diffs can overwhelm context windows and make analysis difficult. Summaries maintain clarity.</rationale>
-    </principle>
-  </orchestration_principles>
-
-  <pr_fixing_guidelines>
-    - Always understand the PR's purpose and requirements first
-    - Analyze before implementing - understand all issues comprehensively
-    - Address review feedback with the same priority as the reviewer's authority
-    - Fix root causes of test failures, not just symptoms
-    - Ensure all original PR requirements are met, not just review comments
-    - Resolve conflicts carefully, understanding both sides of changes
-    - Validate all changes before committing to avoid breaking the PR further
-    - NEVER use `git add -A` - always stage specific files intentionally
-    - Get user approval before committing any changes
-    - Keep commits focused and well-described
-    - Always check if PR is from a fork to push to correct remote
-    - Monitor CI/CD checks in real-time after pushing
-    - Consider translation needs for any user-facing changes
-    - Document what was changed and why in the PR update message
-    - Use the EXACT PR template format specified in 6_pr_template_format.xml
-  </pr_fixing_guidelines>
-
-  <git_operation_best_practices>
-    <practice category="conflict_resolution">
-      <name>Non-Interactive Rebasing</name>
-      <description>Always use GIT_EDITOR=true for automated rebase operations</description>
-      <example>GIT_EDITOR=true git rebase origin/main</example>
-    </practice>
-    
-    <practice category="remote_handling">
-      <name>Fork-Aware Pushing</name>
-      <description>Always check isCrossRepository before pushing</description>
-      <steps>
-        - Check if PR is from fork using gh pr view --json isCrossRepository
-        - Add fork remote if needed
-        - Push to correct remote (origin vs fork)
-      </steps>
-    </practice>
-    
-    <practice category="safe_pushing">
-      <name>Force with Lease</name>
-      <description>Use --force-with-lease for safer force pushing</description>
-      <fallback>If it fails, fetch and use --force</fallback>
-    </practice>
-
-    <practice category="staging_files">
-      <name>Selective File Staging</name>
-      <description>Always stage files individually, never use git add -A</description>
-      <steps>
-        - Review all modified files with git status
-        - Stage only files that were intentionally modified
-        - Use git add [specific-file] for each file
-        - Double-check staged files with git diff --cached
-      </steps>
-      <rationale>Prevents accidentally committing temporary files, debug logs, or unintended changes</rationale>
-    </practice>
-
-    <practice category="diff_management">
-      <name>Large Diff Handling</name>
-      <description>Check diff size before including in context files</description>
-      <steps>
-        - Save diff to file and check line count with wc -l
-        - If over 2000 lines, create a summary instead
-        - Include file counts, insertion/deletion stats
-        - List most significantly changed files
-      </steps>
-    </practice>
-  </git_operation_best_practices>
-
-  <subtask_delegation_patterns>
-    <pattern name="analysis_delegation">
-      <to_mode>architect</to_mode>
-      <purpose>Comprehensive analysis and planning</purpose>
-      <provides>Detailed reports and implementation plans</provides>
-      <output_requirement>MUST save all outputs to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/</output_requirement>
-    </pattern>
-    
-    <pattern name="implementation_delegation">
-      <to_mode>code</to_mode>
-      <purpose>Executing code changes and fixes</purpose>
-      <provides>Implemented solutions and change summaries</provides>
-      <output_requirement>MUST save changes_implemented.md to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/</output_requirement>
-    </pattern>
-    
-    <pattern name="validation_delegation">
-      <to_mode>test</to_mode>
-      <purpose>Testing and validating changes</purpose>
-      <provides>Test results and validation reports</provides>
-      <output_requirement>MUST save validation_report.md to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/</output_requirement>
-    </pattern>
-    
-    <pattern name="review_delegation">
-      <to_mode>pr-reviewer</to_mode>
-      <purpose>Final quality review before submission</purpose>
-      <provides>Quality assessment and recommendations</provides>
-      <output_requirement>MUST save final_review.md to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/</output_requirement>
-    </pattern>
-    
-    <pattern name="translation_delegation">
-      <to_mode>translate</to_mode>
-      <purpose>Updating translations for UI changes</purpose>
-      <provides>Synchronized translations across languages</provides>
-      <output_requirement>MUST save translation_summary.md to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/</output_requirement>
-    </pattern>
-  </subtask_delegation_patterns>
-
-  <error_handling>
-    <scenario name="auth_failure">
-      <error>GitHub CLI authentication error</error>
-      <action>Prompt user to run 'gh auth login'</action>
-    </scenario>
-    
-    <scenario name="no_linked_issue">
-      <error>No linked issue found</error>
-      <action>Extract requirements from PR description and comments</action>
-    </scenario>
-    
-    <scenario name="push_failure">
-      <error>Force-with-lease push fails</error>
-      <action>Fetch latest and retry with --force</action>
-    </scenario>
-
-    <scenario name="large_diff">
-      <error>Diff exceeds 2000 lines</error>
-      <action>Create summary with stats instead of full diff</action>
-    </scenario>
-
-    <scenario name="missing_context_files">
-      <error>Expected context files not found in temp directory</error>
-      <action>Check if delegated task saved to correct location, re-run if needed</action>
-    </scenario>
-  </error_handling>
-
-  <user_interaction_guidelines>
-    <guideline priority="critical">
-      <name>Pre-Commit Approval</name>
-      <description>Always get explicit user approval before committing changes</description>
-      <implementation>
-        - Show list of modified files
-        - Summarize key changes made
-        - Present clear approval options
-        - Wait for user confirmation
-      </implementation>
-    </guideline>
-
-    <guideline priority="high">
-      <name>Clear Communication</name>
-      <description>Present information clearly and concisely</description>
-      <implementation>
-        - Use bullet points for lists
-        - Highlight important warnings
-        - Provide actionable suggestions
-        - Avoid technical jargon when possible
-      </implementation>
-    </guideline>
-  </user_interaction_guidelines>
-</best_practices>

.roo/rules-pr-fixer-orchestrator/3_github_cli_usage.xml

@@ -1,68 +0,0 @@
-<github_cli_usage>
-  <overview>
-    This mode uses the GitHub CLI (gh) for all GitHub operations.
-    The mode assumes the user has gh installed and authenticated.
-    It can work with PRs from both the main repository and forks.
-  </overview>
-
-  <pr_specific_commands>
-    <command name="gh_pr_view">
-      <purpose>Get comprehensive PR details</purpose>
-      <syntax>gh pr view [pr-number] --repo [owner]/[repo] --json [fields]</syntax>
-      <fields>number,title,body,state,labels,author,headRefName,baseRefName,mergeable,mergeStateStatus,isDraft,isCrossRepository,headRepositoryOwner,reviews,statusCheckRollup,comments</fields>
-    </command>
-
-    <command name="gh_pr_checkout">
-      <purpose>Checkout PR branch locally</purpose>
-      <syntax>gh pr checkout [pr-number] --repo [owner]/[repo] --force</syntax>
-      <note>Automatically handles fork setup</note>
-    </command>
-
-    <command name="gh_pr_checks">
-      <purpose>Monitor CI/CD status</purpose>
-      <syntax>gh pr checks [pr-number] --repo [owner]/[repo] --watch</syntax>
-      <note>Use --json for programmatic access</note>
-    </command>
-
-    <command name="gh_pr_diff">
-      <purpose>Get PR changes</purpose>
-      <syntax>gh pr diff [pr-number] --repo [owner]/[repo] --name-only</syntax>
-      <note>Use without --name-only for full diff</note>
-    </command>
-
-    <command name="gh_pr_comment">
-      <purpose>Add comment to PR</purpose>
-      <syntax>gh pr comment [pr-number] --repo [owner]/[repo] --body "[message]"</syntax>
-    </command>
-  </pr_specific_commands>
-
-  <issue_integration>
-    <command name="gh_pr_linked_issues">
-      <purpose>Get issues linked to PR</purpose>
-      <syntax>gh pr view [pr-number] --repo [owner]/[repo] --json closingIssuesReferences</syntax>
-      <note>Returns array of linked issues</note>
-    </command>
-
-    <command name="gh_issue_view">
-      <purpose>Get issue details if linked</purpose>
-      <syntax>gh issue view [issue-number] --repo [owner]/[repo] --json [fields]</syntax>
-      <fields>number,title,body,state,labels,assignees,milestone,createdAt,updatedAt,closedAt,author,comments</fields>
-    </command>
-  </issue_integration>
-
-  <workflow_commands>
-    <command name="gh_run_view">
-      <purpose>Get detailed CI logs</purpose>
-      <syntax>gh run view [run-id] --repo [owner]/[repo] --log-failed</syntax>
-      <note>Use to debug failing tests</note>
-    </command>
-
-    <command name="gh_api">
-      <purpose>Direct API access for advanced operations</purpose>
-      <examples>
-        - Get PR reviews: gh api repos/[owner]/[repo]/pulls/[pr-number]/reviews
-        - Get review comments: gh api repos/[owner]/[repo]/pulls/[pr-number]/comments
-      </examples>
-    </command>
-  </workflow_commands>
-</github_cli_usage>

.roo/rules-pr-fixer-orchestrator/4_requirements_analysis.xml

@@ -1,120 +0,0 @@
-<requirements_analysis_guidelines>
-  <overview>
-    The PR Fixer Orchestrator must understand the underlying requirements
-    of a PR before fixing issues. This ensures fixes align with the
-    original intent and all acceptance criteria are met.
-  </overview>
-
-  <sources_of_requirements>
-    <source priority="1">
-      <name>Linked GitHub Issues</name>
-      <description>Primary source of requirements and acceptance criteria</description>
-      <extraction>
-        - Issue title and body
-        - Acceptance criteria sections
-        - Technical specifications
-        - User stories or use cases
-      </extraction>
-    </source>
-
-    <source priority="2">
-      <name>PR Description</name>
-      <description>Often contains implementation notes and context</description>
-      <extraction>
-        - Feature description
-        - Implementation approach
-        - Testing notes
-        - Breaking changes
-      </extraction>
-    </source>
-
-    <source priority="3">
-      <name>PR Comments</name>
-      <description>May contain clarifications and additional requirements</description>
-      <extraction>
-        - Author clarifications
-        - Reviewer questions and answers
-        - Scope changes or additions
-      </extraction>
-    </source>
-
-    <source priority="4">
-      <name>Code Analysis</name>
-      <description>Infer requirements from the implementation</description>
-      <extraction>
-        - API contracts
-        - Data flow patterns
-        - Test cases (reveal expected behavior)
-        - Documentation comments
-      </extraction>
-    </source>
-  </sources_of_requirements>
-
-  <analysis_approach>
-    <step number="1">
-      <name>Extract Explicit Requirements</name>
-      <actions>
-        - Parse linked issues for acceptance criteria
-        - Extract requirements from PR description
-        - Identify success metrics
-      </actions>
-    </step>
-
-    <step number="2">
-      <name>Understand Implementation Intent</name>
-      <actions>
-        - Analyze the code changes to understand approach
-        - Identify design decisions made
-        - Note any architectural patterns used
-      </actions>
-    </step>
-
-    <step number="3">
-      <name>Map Requirements to Implementation</name>
-      <actions>
-        - Verify each requirement has corresponding code
-        - Identify any missing functionality
-        - Note any extra functionality added
-      </actions>
-    </step>
-
-    <step number="4">
-      <name>Identify Gaps</name>
-      <actions>
-        - List unimplemented requirements
-        - Note incomplete features
-        - Identify missing tests
-      </actions>
-    </step>
-  </analysis_approach>
-
-  <common_requirement_patterns>
-    <pattern name="bug_fix">
-      <requirements>
-        - Clear description of the bug
-        - Steps to reproduce
-        - Expected vs actual behavior
-        - Affected versions/environments
-      </requirements>
-    </pattern>
-
-    <pattern name="new_feature">
-      <requirements>
-        - Feature description
-        - User stories or use cases
-        - API design (if applicable)
-        - UI/UX specifications
-        - Performance requirements
-      </requirements>
-    </pattern>
-
-    <pattern name="refactoring">
-      <requirements>
-        - Motivation for refactoring
-        - Backward compatibility needs
-        - Performance improvements expected
-        - Migration path (if breaking)
-      </requirements>
-    </pattern>
-  </common_requirement_patterns>
-</requirements_analysis_guidelines>

.roo/rules-pr-fixer-orchestrator/5_self_contained_workflow.xml

@@ -1,99 +0,0 @@
-<self_contained_workflow>
-  <overview>
-    The PR Fixer Orchestrator must be completely self-contained and able
-    to work on any PR without requiring pre-existing context files from
-    other workflows like the Issue Fixer.
-  </overview>
-
-  <independence_principles>
-    <principle>
-      <name>No External Dependencies</name>
-      <description>Never assume files from other workflows exist</description>
-      <implementation>
-        - Create own temp directory structure
-        - Gather all needed context independently
-        - Generate own analysis and plans
-      </implementation>
-    </principle>
-
-    <principle>
-      <name>Complete Context Gathering</name>
-      <description>Collect all information needed for the task</description>
-      <implementation>
-        - Fetch PR details and metadata
-        - Get linked issues if they exist
-        - Analyze codebase independently
-        - Understand requirements from available sources
-      </implementation>
-    </principle>
-
-    <principle>
-      <name>Flexible Requirements Analysis</name>
-      <description>Work with whatever information is available</description>
-      <implementation>
-        - Use linked issues when available
-        - Fall back to PR description
-        - Infer from code changes if needed
-        - Ask user for clarification when necessary
-      </implementation>
-    </principle>
-  </independence_principles>
-
-  <context_initialization>
-    <step>Create dedicated task directory</step>
-    <step>Fetch all PR-related information</step>
-    <step>Check for linked issues and fetch if present</step>
-    <step>Analyze PR changes to understand scope</step>
-    <step>Build complete context from available sources</step>
-  </context_initialization>
-
-  <handling_different_pr_types>
-    <type name="pr_with_linked_issue">
-      <description>PR that references a GitHub issue</description>
-      <approach>
-        - Fetch issue details for requirements
-        - Use issue acceptance criteria
-        - Cross-reference PR implementation with issue requirements
-      </approach>
-    </type>
-
-    <type name="standalone_pr">
-      <description>PR without linked issue</description>
-      <approach>
-        - Extract requirements from PR description
-        - Analyze code to understand intent
-        - Use PR comments for additional context
-        - Infer acceptance criteria from tests
-      </approach>
-    </type>
-
-    <type name="fork_pr">
-      <description>PR from a forked repository</description>
-      <approach>
-        - Handle remote configuration properly
-        - Ensure push targets correct repository
-        - Manage permissions appropriately
-      </approach>
-    </type>
-  </handling_different_pr_types>
-
-  <fallback_strategies>
-    <strategy name="missing_requirements">
-      <when>No clear requirements found</when>
-      <action>
-        - Analyze code changes to infer purpose
-        - Look at test changes for expected behavior
-        - Ask user for clarification if needed
-      </action>
-    </strategy>
-
-    <strategy name="unclear_scope">
-      <when>PR scope is ambiguous</when>
-      <action>
-        - Present findings to user
-        - Ask for specific guidance on what to fix
-        - Proceed with user-defined scope
-      </action>
-    </strategy>
-  </fallback_strategies>
-</self_contained_workflow>

.roo/rules-pr-fixer-orchestrator/6_pr_template_format.xml

@@ -1,361 +0,0 @@
-<pr_template_format>
-  <overview>
-    This file defines the EXACT PR message template that must be used when updating
-    pull requests. The format is specific to the Roo Code project and must be followed
-    precisely.
-  </overview>
-
-  <template>
-    <![CDATA[
-<!--
-Thank you for contributing to Roo Code!
-
-Before submitting your PR, please ensure:
-- It's linked to an approved GitHub Issue.
-- You've reviewed our [Contributing Guidelines](../CONTRIBUTING.md).
--->
-
-### Related GitHub Issue
-
-<!-- Every PR MUST be linked to an approved issue. -->
-
-Closes: #[ISSUE_NUMBER] <!-- Replace with the issue number, e.g., Closes: #123 -->
-
-### Roo Code Task Context (Optional)
-
-<!--
-If you used Roo Code to help create this PR, you can share public task links here.
-This helps reviewers understand your development process and provides additional context.
-Example: https://app.roocode.com/share/task-id
--->
-
-[TASK_CONTEXT_IF_APPLICABLE]
-
-### Description
-
-<!--
-Briefly summarize the changes in this PR and how they address the linked issue.
-The issue should cover the "what" and "why"; this section should focus on:
-- The "how": key implementation details, design choices, or trade-offs made.
-- Anything specific reviewers should pay attention to in this PR.
--->
-
-[DESCRIPTION_OF_CHANGES]
-
-### Test Procedure
-
-<!--
-Detail the steps to test your changes. This helps reviewers verify your work.
-- How did you test this specific implementation? (e.g., unit tests, manual testing steps)
-- How can reviewers reproduce your tests or verify the fix/feature?
-- Include relevant testing environment details if applicable.
--->
-
-[TEST_PROCEDURE_DETAILS]
-
-### Pre-Submission Checklist
-
-<!-- Go through this checklist before marking your PR as ready for review. -->
-
-- [x] **Issue Linked**: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
-- [x] **Scope**: My changes are focused on the linked issue (one major feature/fix per PR).
-- [x] **Self-Review**: I have performed a thorough self-review of my code.
-- [x] **Testing**: New and/or updated tests have been added to cover my changes (if applicable).
-- [x] **Documentation Impact**: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
-- [x] **Contribution Guidelines**: I have read and agree to the [Contributor Guidelines](/CONTRIBUTING.md).
-
-### Screenshots / Videos
-
-<!--
-For UI changes, please provide before-and-after screenshots or a short video of the *actual results*.
-This greatly helps in understanding the visual impact of your changes.
--->
-
-[SCREENSHOTS_OR_VIDEOS_IF_UI_CHANGES]
-
-### Documentation Updates
-
-<!--
-Does this PR necessitate updates to user-facing documentation?
-- [ ] No documentation updates are required.
-- [ ] Yes, documentation updates are required. (Please describe what needs to be updated or link to a PR in the docs repository).
--->
-
-[DOCUMENTATION_UPDATE_STATUS]
-
-### Additional Notes
-
-<!-- Add any other context, questions, or information for reviewers here. -->
-
-[ADDITIONAL_NOTES]
-
-### Get in Touch
-
-<!--
-Please provide your Discord username for reviewers or maintainers to reach you if they have questions about your PR
--->
-
-[DISCORD_USERNAME]
-    ]]>
-  </template>
-
-  <placeholders>
-    <placeholder name="[ISSUE_NUMBER]">
-      <description>The GitHub issue number this PR closes</description>
-      <source>From linked_issues.json or pr_context.json</source>
-    </placeholder>
-    
-    <placeholder name="[TASK_CONTEXT_IF_APPLICABLE]">
-      <description>Optional Roo Code task links if used</description>
-      <default>_No Roo Code task context for this PR._</default>
-    </placeholder>
-    
-    <placeholder name="[DESCRIPTION_OF_CHANGES]">
-      <description>Summary of changes and implementation details</description>
-      <content>
-        This PR addresses the review feedback and fixes identified issues for #[PR_NUMBER].
-
-        **Key Changes:**
-        - [List major changes from changes_implemented.md]
-        - [Implementation details and design choices]
-        - [Trade-offs or decisions made]
-
-        **Review Comments Addressed:**
-        [Summary of addressed review comments]
-
-        **Test Failures Fixed:**
-        [Summary of test fixes if applicable]
-
-        **Conflicts Resolved:**
-        [Summary of conflict resolutions if applicable]
-      </content>
-    </placeholder>
-    
-    <placeholder name="[TEST_PROCEDURE_DETAILS]">
-      <description>How the changes were tested</description>
-      <content>
-        **Testing performed:**
-        1. Ran all unit tests locally: `[test command used]`
-        2. Ran integration tests: `[test command used]`
-        3. Manual testing steps:
-           - [Step 1]
-           - [Step 2]
-           - [Step 3]
-
-        **To verify these changes:**
-        1. Check out this branch
-        2. Run `[specific test commands]`
-        3. [Additional verification steps]
-
-        **Test Environment:**
-        - Node.js version: [version]
-        - OS: [operating system]
-        - [Other relevant environment details]
-      </content>
-    </placeholder>
-    
-    <placeholder name="[SCREENSHOTS_OR_VIDEOS_IF_UI_CHANGES]">
-      <description>Visual evidence of UI changes</description>
-      <default>_No UI changes in this PR._</default>
-    </placeholder>
-    
-    <placeholder name="[DOCUMENTATION_UPDATE_STATUS]">
-      <description>Documentation impact assessment</description>
-      <options>
-        <option condition="no_docs_needed">- [x] No documentation updates are required.</option>
-        <option condition="docs_needed">- [x] Yes, documentation updates are required. [Describe what needs updating]</option>
-      </options>
-    </placeholder>
-    
-    <placeholder name="[ADDITIONAL_NOTES]">
-      <description>Any additional context for reviewers</description>
-      <content>
-        [Any special considerations, known issues, or questions for reviewers]
-        
-        **Files Modified:**
-        ```
-        [List of modified files from changes_implemented.md]
-        ```
-      </content>
-    </placeholder>
-    
-    <placeholder name="[DISCORD_USERNAME]">
-      <description>Contact information</description>
-      <default>Discord: @[username]</default>
-    </placeholder>
-  </placeholders>
-
-  <generation_instructions>
-    <instruction priority="1">
-      The template MUST be followed exactly - do not modify the structure or remove any sections
-    </instruction>
-    <instruction priority="2">
-      All placeholders must be replaced with actual content - no brackets should remain
-    </instruction>
-    <instruction priority="3">
-      The Pre-Submission Checklist items should all be marked as checked [x] since we're fixing an existing PR
-    </instruction>
-    <instruction priority="4">
-      Pull information from:
-      - changes_implemented.md for the description and file list
-      - validation_report.md for test results
-      - pr_context.json for issue numbers and PR details
-      - translation_summary.md for any translation updates
-    </instruction>
-    <instruction priority="5">
-      Keep the HTML comments intact - they provide guidance for reviewers
-    </instruction>
-  </generation_instructions>
-
-  <file_handling>
-    <location>.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_update_message.md</location>
-    <purpose>
-      - Used as the PR comment body when updating the PR
-      - Saved for reference and audit trail
-      - Can be edited by user before posting
-      - Should NOT be deleted even if temp files are cleaned
-    </purpose>
-    <usage>
-      Post to PR using: gh pr comment [pr_number] --repo [owner]/[repo] --body-file [path_to_file]
-    </usage>
-  </file_handling>
-
-  <example_filled_template>
-    <![CDATA[
-<!--
-Thank you for contributing to Roo Code!
-
-Before submitting your PR, please ensure:
-- It's linked to an approved GitHub Issue.
-- You've reviewed our [Contributing Guidelines](../CONTRIBUTING.md).
--->
-
-### Related GitHub Issue
-
-<!-- Every PR MUST be linked to an approved issue. -->
-
-Closes: #456
-
-### Roo Code Task Context (Optional)
-
-<!--
-If you used Roo Code to help create this PR, you can share public task links here.
-This helps reviewers understand your development process and provides additional context.
-Example: https://app.roocode.com/share/task-id
--->
-
-_No Roo Code task context for this PR._
-
-### Description
-
-<!--
-Briefly summarize the changes in this PR and how they address the linked issue.
-The issue should cover the "what" and "why"; this section should focus on:
-- The "how": key implementation details, design choices, or trade-offs made.
-- Anything specific reviewers should pay attention to in this PR.
--->
-
-This PR addresses the review feedback and fixes identified issues for #789.
-
-**Key Changes:**
-- Fixed TypeScript type errors in the API handler by adding proper type annotations
-- Improved error handling in the authentication flow to handle edge cases
-- Refactored complex functions for better testability and maintainability
-- Added missing user role management functionality
-- Resolved merge conflicts with the latest main branch
-
-**Review Comments Addressed:**
-- Added timeout handling with exponential backoff for network requests
-- Refactored large functions into smaller, testable units
-- Added comprehensive TypeScript interfaces for API responses
-- Improved error messages for better debugging
-
-**Test Failures Fixed:**
-- Updated email validation tests to match new validation rules
-- Fixed mock server responses in integration tests
-- Added missing test coverage for new functionality
-
-### Test Procedure
-
-<!--
-Detail the steps to test your changes. This helps reviewers verify your work.
-- How did you test this specific implementation? (e.g., unit tests, manual testing steps)
-- How can reviewers reproduce your tests or verify the fix/feature?
-- Include relevant testing environment details if applicable.
--->
-
-**Testing performed:**
-1. Ran all unit tests locally: `npm test`
-2. Ran integration tests: `npm run test:integration`
-3. Manual testing steps:
-   - Created new user with various role types
-   - Tested authentication flow with invalid credentials
-   - Verified timeout handling with slow network simulation
-
-**To verify these changes:**
-1. Check out this branch
-2. Run `npm install && npm test`
-3. Start the dev server with `npm run dev`
-4. Test the authentication flow at http://localhost:3000/login
-
-**Test Environment:**
-- Node.js version: 18.17.0
-- OS: Windows 11
-- Browser: Chrome 120
-
-### Pre-Submission Checklist
-
-<!-- Go through this checklist before marking your PR as ready for review. -->
-
-- [x] **Issue Linked**: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
-- [x] **Scope**: My changes are focused on the linked issue (one major feature/fix per PR).
-- [x] **Self-Review**: I have performed a thorough self-review of my code.
-- [x] **Testing**: New and/or updated tests have been added to cover my changes (if applicable).
-- [x] **Documentation Impact**: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
-- [x] **Contribution Guidelines**: I have read and agree to the [Contributor Guidelines](/CONTRIBUTING.md).
-
-### Screenshots / Videos
-
-<!--
-For UI changes, please provide before-and-after screenshots or a short video of the *actual results*.
-This greatly helps in understanding the visual impact of your changes.
--->
-
-_No UI changes in this PR._
-
-### Documentation Updates
-
-<!--
-Does this PR necessitate updates to user-facing documentation?
-- [ ] No documentation updates are required.
-- [ ] Yes, documentation updates are required. (Please describe what needs to be updated or link to a PR in the docs repository).
--->
-
-- [x] No documentation updates are required.
-
-### Additional Notes
-
-<!-- Add any other context, questions, or information for reviewers here. -->
-
-All review feedback has been addressed. The main architectural change was refactoring the authentication service to use dependency injection, which improves testability.
-
-**Files Modified:**
-```
-src/api/handler.ts - Added type annotations, improved error handling
-src/services/auth.service.ts - Refactored for dependency injection
-src/services/user.service.ts - Added role management functionality
-src/types/api.types.ts - New TypeScript interfaces
-src/__tests__/services/auth.service.test.ts - Updated tests
-src/__tests__/integration/api.test.ts - Fixed mock responses
-```
-
-### Get in Touch
-
-<!--
-Please provide your Discord username for reviewers or maintainers to reach you if they have questions about your PR
--->
-
-Discord: @contributor123
-    ]]>
-  </example_filled_template>
-</pr_template_format>

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

@@ -1,6 +1,6 @@
 <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.
+    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. All GitHub operations are performed using the GitHub CLI.
   </mode_overview>
 
   <initialization_steps>
@@ -13,9 +13,9 @@
     <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>
+        <tool>gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles,comments,reviews</tool>
+        <tool>gh pr checks [PR_NUMBER] --repo [owner]/[repo] - Check workflow status for failing tests</tool>
+        <tool>gh pr view [PR_NUMBER] --repo [owner]/[repo] --json mergeable,mergeStateStatus - Check for merge conflicts</tool>
       </tools>
     </step>
   </initialization_steps>
@@ -24,9 +24,9 @@
     <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>
+        <step>Summarize review comments and requested changes from gh pr view output.</step>
+        <step>Identify the root cause of failing tests by analyzing workflow logs with 'gh run view'.</step>
+        <step>Determine if merge conflicts exist from mergeable status.</step>
       </steps>
     </phase>
 
@@ -41,13 +41,16 @@
     <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 --force'.</step>
-        <step>Determine if the PR is from a fork by checking 'gh pr view --json isCrossRepository'.</step>
+        <step>Check out the PR branch locally using 'gh pr checkout [PR_NUMBER] --repo [owner]/[repo] --force'.</step>
+        <step>Determine if the PR is from a fork by checking 'gh pr view [PR_NUMBER] --repo [owner]/[repo] --json isCrossRepository'.</step>
         <step>Apply code changes based on review feedback using file editing tools.</step>
         <step>Fix failing tests by modifying test files or source code as needed.</step>
-        <step>For conflict resolution: Use GIT_EDITOR=true for non-interactive rebases, then resolve conflicts via file editing.</step>
+        <step>For conflict resolution: Delegate to merge-resolver mode using new_task with the PR number.</step>
         <step>If changes affect user-facing content (i18n files, UI components, announcements), delegate translation updates using the new_task tool with translate mode.</step>
-        <step>Commit changes using git commands.</step>
+        <step>Review modified files with 'git status --porcelain' to ensure no temporary files are included.</step>
+        <step>Stage files selectively using 'git add -u' (for modified tracked files) or 'git add <specific-files>' (for new files).</step>
+        <step>Verify staged files with 'git diff --cached --name-only' before committing.</step>
+        <step>Commit changes using git commands with descriptive messages.</step>
         <step>Push changes to the correct remote (origin for same-repo PRs, fork remote for cross-repo PRs) using 'git push --force-with-lease'.</step>
       </steps>
     </phase>
@@ -55,10 +58,10 @@
     <phase name="validation">
       <description>Verify that the pushed changes resolve the issues.</description>
       <steps>
-        <step>Use 'gh pr checks --watch' to monitor check status in real-time until all checks complete.</step>
-        <step>If needed, check specific workflow runs with 'gh run list --pr' for detailed CI/CD pipeline status.</step>
+        <step>Use 'gh pr checks [PR_NUMBER] --repo [owner]/[repo] --watch' to monitor check status in real-time until all checks complete.</step>
+        <step>If needed, check specific workflow runs with 'gh run list --pr [PR_NUMBER] --repo [owner]/[repo]' for detailed CI/CD pipeline status.</step>
         <step>Verify that all translation updates (if any) have been completed and committed.</step>
-        <step>Confirm PR is ready for review by checking mergeable state with 'gh pr view --json'.</step>
+        <step>Confirm PR is ready for review by checking mergeable state with 'gh pr view [PR_NUMBER] --repo [owner]/[repo] --json mergeable,mergeStateStatus'.</step>
       </steps>
     </phase>
   </main_workflow>

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

@@ -20,37 +20,46 @@
         <bad>Always push to origin without checking PR source</bad>
       </example>
     </principle>
+    <principle priority="high">
+      <name>Safe File Staging</name>
+      <description>Always review files before staging to avoid committing temporary files, build artifacts, or system files. Use selective git commands that respect .gitignore.</description>
+      <rationale>Committing unwanted files can expose sensitive data, clutter the repository, and cause CI/CD failures.</rationale>
+      <example>
+        <scenario>Staging files for commit</scenario>
+        <good>Use 'git add -u' to stage only modified tracked files, or explicitly list files to add</good>
+        <bad>Use 'git add .' which stages everything including temp files</bad>
+      </example>
+      <checklist>
+        <item>Review git status before staging</item>
+        <item>Check for temporary files (.swp, .DS_Store, *.tmp)</item>
+        <item>Exclude build artifacts (dist/, build/, *.pyc)</item>
+        <item>Avoid IDE-specific files (.idea/, .vscode/)</item>
+        <item>Verify .gitignore is properly configured</item>
+      </checklist>
+    </principle>
   </general_principles>
 
   <code_conventions>
     <convention category="merge_conflicts">
-      <rule>How to correctly escape conflict markers when using apply_diff.</rule>
+      <rule>Delegate merge conflict resolution to the merge-resolver mode.</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.
+When merge conflicts are detected, do not attempt to resolve them manually. Instead, use the new_task tool to create a task for the merge-resolver mode:
 
-**Correct Format Example:**
-
-```
-<<<<<<< SEARCH
-content before
-\<<<<<<< HEAD    <-- Note the backslash here
-content after
-=======
-replacement content
->>>>>>> REPLACE
+```xml
+<new_task>
+<mode>merge-resolver</mode>
+<message>#[PR_NUMBER]</message>
+</new_task>
 ```
 
-Without escaping, the system confuses your content with real diff markers.
+The merge-resolver mode will:
+- Checkout the PR branch
+- Perform the rebase
+- Intelligently resolve conflicts based on commit history and intent
+- Push the resolved changes
+- Return control back to pr-fixer mode
 
-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.
+This ensures consistent and intelligent conflict resolution across all PRs.
       </template>
     </convention>
   </code_conventions>

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

@@ -27,32 +27,26 @@
   <pattern name="detecting_conflicts">
     <usage>Commands to detect merge conflicts.</usage>
     <template>
-      <comment>Fetch latest main branch</comment>
-      <command tool="git">git fetch origin main</command>
-      <comment>Check if rebase would create conflicts</comment>
-      <command tool="git">git rebase --dry-run origin/main</command>
+      <comment>Check PR mergeable status</comment>
+      <command tool="gh">gh pr view <pr_number> --json mergeable,mergeStateStatus</command>
+      <comment>If mergeable is false or mergeStateStatus is CONFLICTING, delegate to merge-resolver</comment>
     </template>
   </pattern>
   
-  <pattern name="non_interactive_rebase">
-    <usage>Rebase operations using GIT_EDITOR to prevent interactive prompts.</usage>
+  <pattern name="delegating_conflict_resolution">
+    <usage>Delegate merge conflict resolution to the merge-resolver mode.</usage>
     <template>
-      <command tool="git">git checkout <pr_branch></command>
-      <command tool="git">GIT_EDITOR=true git rebase main</command>
-      <comment>If conflicts occur, resolve them manually then use 'git rebase --continue'</comment>
-      <command tool="git">git push --force-with-lease <remote> <pr_branch></command>
+      <comment>When conflicts are detected, create a new task for merge-resolver</comment>
+      <command tool="new_task"><![CDATA[
+<new_task>
+<mode>merge-resolver</mode>
+<message>#<pr_number></message>
+</new_task>
+      ]]></command>
+      <comment>Wait for merge-resolver to complete before continuing with other fixes</comment>
     </template>
   </pattern>
   
-  <pattern name="conflict_status_check">
-    <usage>Check current conflict status without interactive input.</usage>
-    <template>
-      <command tool="git">git status --porcelain</command>
-      <command tool="git">git diff --name-only --diff-filter=U</command>
-      <comment>List files with unresolved conflicts</comment>
-      <command tool="git">git ls-files --unmerged</command>
-    </template>
-  </pattern>
   <pattern name="checking_out_pr">
     <usage>Check out a pull request branch locally.</usage>
     <template>
@@ -101,10 +95,42 @@
   </pattern>
 
   <pattern name="automated_commit_operations">
-    <usage>Commit operations that work in automated environments.</usage>
+    <usage>Commit operations that work in automated environments while respecting .gitignore.</usage>
     <template>
-      <command tool="git">git add .</command>
+      <comment>Review what files have been modified</comment>
+      <command tool="git">git status --porcelain</command>
+      <comment>Add only tracked files that were modified (respects .gitignore)</comment>
+      <command tool="git">git add -u</command>
+      <comment>If you need to add specific new files, list them explicitly</comment>
+      <command tool="git">git add <specific_file_path></command>
       <command tool="git">git commit -m "<commit_message>"</command>
     </template>
   </pattern>
+  <pattern name="safe_file_staging">
+    <usage>Safely stage files for commit while avoiding temporary files and respecting .gitignore.</usage>
+    <template>
+      <comment>First, check what files are currently modified or untracked</comment>
+      <command tool="git">git status --porcelain</command>
+      <comment>Review the output to identify files that should NOT be committed:</comment>
+      <comment>- Files starting with . (hidden files like .DS_Store, .swp)</comment>
+      <comment>- Build artifacts (dist/, build/, *.pyc, *.o)</comment>
+      <comment>- IDE files (.idea/, .vscode/, *.iml)</comment>
+      <comment>- Temporary files (*.tmp, *.temp, *~)</comment>
+      
+      <comment>Option 1: Stage only modified tracked files (safest)</comment>
+      <command tool="git">git add -u</command>
+      
+      <comment>Option 2: Stage specific files by path</comment>
+      <command tool="git">git add src/file1.ts src/file2.ts</command>
+      
+      <comment>Option 3: Use pathspec to add files matching a pattern</comment>
+      <command tool="git">git add '*.ts' '*.tsx' --</command>
+      
+      <comment>Option 4: Interactive staging to review each change</comment>
+      <command tool="git">git add -p</command>
+      
+      <comment>Always verify what's staged before committing</comment>
+      <command tool="git">git diff --cached --name-only</command>
+    </template>
+  </pattern>
 </common_patterns>

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

@@ -1,7 +1,7 @@
 <tool_usage_guide>
   <tool_priorities>
     <priority level="1">
-      <tool>use_mcp_tool (server: github)</tool>
+      <tool>gh pr view</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>
@@ -23,14 +23,16 @@
  </tool_priorities>
 
   <tool_specific_guidance>
-    <tool name="use_mcp_tool (github: get_pull_request)">
+    <tool name="gh pr view">
       <best_practices>
-        <practice>Always fetch details to get the branch name, owner, repo slug, and mergeable state.</practice>
+        <practice>Always fetch details with --json to get structured data: gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles,comments,reviews,mergeable,mergeStateStatus,isCrossRepository</practice>
+        <practice>Parse the JSON output to extract branch name, owner, repo slug, and mergeable state.</practice>
       </best_practices>
     </tool>
 
-    <tool name="use_mcp_tool (github: get_pull_request_comments)">
+    <tool name="gh pr comments">
       <best_practices>
+        <practice>Use gh pr view --json comments to get all comments in structured format.</practice>
         <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>
@@ -40,14 +42,15 @@
       <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>
-        <practice>Always specify run ID explicitly to avoid interactive selection prompts.</practice>
+        <practice>Always specify run ID explicitly to avoid interactive selection prompts: gh run view [RUN_ID] --log-failed</practice>
+        <practice>Get run IDs with: gh run list --pr [PR_NUMBER] --repo [owner]/[repo]</practice>
       </best_practices>
     </tool>
 
     <tool name="gh pr checkout">
       <best_practices>
-        <practice>Use --force flag: 'gh pr checkout <pr_number> --force'</practice>
-        <practice>If gh checkout fails, use: git fetch origin pull/<pr_number>/head:<branch_name></practice>
+        <practice>Use --force flag: 'gh pr checkout [PR_NUMBER] --repo [owner]/[repo] --force'</practice>
+        <practice>If gh checkout fails, use: git fetch origin pull/[PR_NUMBER]/head:[branch_name]</practice>
       </best_practices>
     </tool>
 
@@ -58,23 +61,23 @@
         <practice>Always determine the correct remote before pushing (origin vs fork).</practice>
       </best_practices>
       <remote_handling>
-        <step>Check if PR is from a fork: 'gh pr view <pr_number> --json isCrossRepository'</step>
+        <step>Check if PR is from a fork: 'gh pr view [PR_NUMBER] --repo [owner]/[repo] --json isCrossRepository'</step>
         <step>If isCrossRepository is true, add fork remote if needed</step>
-        <step>Push to appropriate remote: 'git push --force-with-lease <remote> <branch>'</step>
+        <step>Push to appropriate remote: 'git push --force-with-lease [remote] [branch]'</step>
       </remote_handling>
       <conflict_resolution>
-        <step>Use 'GIT_EDITOR=true git rebase main' to start rebase</step>
-        <step>If conflicts occur, edit files to resolve them</step>
-        <step>Use 'git add .' and 'git rebase --continue' to proceed</step>
+        <step>Delegate to merge-resolver mode using new_task</step>
+        <step>Provide the PR number (e.g., "#123") as the message</step>
+        <step>The merge-resolver mode will handle all conflict resolution automatically</step>
       </conflict_resolution>
     </tool>
 
     <tool name="gh pr checks">
       <best_practices>
-        <practice>Use --watch flag to monitor checks in real-time: 'gh pr checks <pr_number> --watch'</practice>
-        <practice>For one-time status checks, use --json flag: 'gh pr checks <pr_number> --json state,conclusion,name'</practice>
+        <practice>Use --watch flag to monitor checks in real-time: 'gh pr checks [PR_NUMBER] --repo [owner]/[repo] --watch'</practice>
+        <practice>For one-time status checks, use --json flag: 'gh pr checks [PR_NUMBER] --repo [owner]/[repo] --json state,conclusion,name'</practice>
         <practice>The --watch flag automatically updates the display as check statuses change.</practice>
-        <practice>Use 'gh run list --pr <pr_number>' to get detailed workflow status if needed.</practice>
+        <practice>Use 'gh run list --pr [PR_NUMBER] --repo [owner]/[repo]' to get detailed workflow status if needed.</practice>
       </best_practices>
     </tool>
     
@@ -111,8 +114,43 @@ Files modified:
 - webview-ui/src/components/settings/ApiSettings.tsx: Updated button text from "Save" to "Save Configuration"
 
 Please ensure all supported languages (ca, de, es, fr, hi, id, it, ja, ko, nl, pl, pt-BR, ru, tr, vi, zh-CN, zh-TW) are updated with appropriate translations for these changes.</message>
+</new_task>
+      ]]></example_usage>
+    </tool>
+    
+    <tool name="new_task (mode: merge-resolver)">
+      <best_practices>
+        <practice>Use when PR has merge conflicts that need to be resolved.</practice>
+        <practice>Simply provide the PR number (e.g., "#123") as the message.</practice>
+        <practice>The merge-resolver mode will handle checkout, rebase, conflict resolution, and pushing.</practice>
+        <practice>Wait for merge-resolver to complete before continuing with other PR fixes.</practice>
+      </best_practices>
+      <when_to_use>
+        <trigger>When gh pr view shows mergeable: false or mergeStateStatus: CONFLICTING</trigger>
+        <trigger>When git rebase fails with conflicts</trigger>
+        <trigger>When git status shows unmerged paths</trigger>
+      </when_to_use>
+      <example_usage><![CDATA[
+<new_task>
+<mode>merge-resolver</mode>
+<message>#1234</message>
 </new_task>
       ]]></example_usage>
     </tool>
   </tool_specific_guidance>
+
+  <github_cli_reference>
+    <command_group name="pr_operations">
+      <command>gh pr view [PR_NUMBER] --repo [owner]/[repo] --json [fields]</command>
+      <command>gh pr checkout [PR_NUMBER] --repo [owner]/[repo] --force</command>
+      <command>gh pr checks [PR_NUMBER] --repo [owner]/[repo] [--watch|--json]</command>
+      <command>gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body "[text]"</command>
+    </command_group>
+
+    <command_group name="workflow_operations">
+      <command>gh run list --pr [PR_NUMBER] --repo [owner]/[repo]</command>
+      <command>gh run view [RUN_ID] --repo [owner]/[repo] --log-failed</command>
+      <command>gh workflow view [WORKFLOW_NAME] --repo [owner]/[repo]</command>
+    </command_group>
+  </github_cli_reference>
 </tool_usage_guide>

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

@@ -12,28 +12,9 @@
       <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>
+<execute_command>
+<command>gh pr view 4365 --repo RooCodeInc/Roo-Code --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles,comments,reviews,mergeable,mergeStateStatus</command>
+</execute_command>
         </tool_use>
         <expected_outcome>Get the branch name, list of review comments, and check for mergeability.</expected_outcome>
       </step>
@@ -42,7 +23,7 @@
         <description>Check CI status.</description>
         <tool_use>
 <execute_command>
-<command>gh pr checks 4365</command>
+<command>gh pr checks 4365 --repo RooCodeInc/Roo-Code</command>
 </execute_command>
         </tool_use>
         <analysis>Identify which check is failing.</analysis>
@@ -52,7 +33,17 @@
         <description>Get logs for the failing check.</description>
         <tool_use>
 <execute_command>
-<command>gh run view <run_id> --log-failed</command>
+<command>gh run list --pr 4365 --repo RooCodeInc/Roo-Code</command>
+</execute_command>
+        </tool_use>
+        <analysis>Get the run ID of the failing workflow.</analysis>
+      </step>
+
+      <step number="3a">
+        <description>View the failed logs.</description>
+        <tool_use>
+<execute_command>
+<command>gh run view [run_id] --repo RooCodeInc/Roo-Code --log-failed</command>
 </execute_command>
         </tool_use>
         <analysis>Find the specific error message causing the test to fail.</analysis>
@@ -62,7 +53,7 @@
         <description>Check out the pull request branch.</description>
         <tool_use>
           <execute_command>
-            <command>gh pr checkout 4365 --force</command>
+            <command>gh pr checkout 4365 --repo RooCodeInc/Roo-Code --force</command>
           </execute_command>
         </tool_use>
         <analysis>The PR branch is now ready for local edits.</analysis>
@@ -85,7 +76,7 @@
        <description>After pushing the changes, monitor PR checks in real-time.</description>
        <tool_use>
          <execute_command>
-           <command>gh pr checks 4365 --watch</command>
+           <command>gh pr checks 4365 --repo RooCodeInc/Roo-Code --watch</command>
          </execute_command>
        </tool_use>
        <analysis>Monitor checks continuously until all complete. The --watch flag provides real-time updates as check statuses change.</analysis>
@@ -94,7 +85,8 @@
 
     <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>
+      <takeaway>Use the GitHub CLI to get a complete picture of the PR's status.</takeaway>
+      <takeaway>The --watch flag on gh pr checks provides real-time monitoring of CI status.</takeaway>
     </key_takeaways>
   </example>
 
@@ -111,17 +103,9 @@
       <step number="1">
         <description>Get PR details and analyze changes.</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": 1234
-    }
-  </arguments>
-</use_mcp_tool>
+<execute_command>
+<command>gh pr view 1234 --repo RooCodeInc/Roo-Code --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles,comments,reviews</command>
+</execute_command>
         </tool_use>
         <expected_outcome>Identify the files changed and review feedback requiring UI text modifications.</expected_outcome>
       </step>
@@ -130,7 +114,7 @@
         <description>Check out PR and apply the requested changes.</description>
         <tool_use>
 <execute_command>
-<command>gh pr checkout 1234 --force</command>
+<command>gh pr checkout 1234 --repo RooCodeInc/Roo-Code --force</command>
 </execute_command>
         </tool_use>
         <analysis>Make the requested button text changes in the UI components.</analysis>
@@ -158,20 +142,30 @@ Ensure consistency across all language files and maintain the same context and t
       </step>
 
       <step number="4">
-        <description>Commit all changes including translations with automated git configuration.</description>
+        <description>Review and commit changes including translations.</description>
         <tool_use>
 <execute_command>
-<command>git add . && git commit -m "fix: update button text and translations as requested in review"</command>
+<command>git status --porcelain</command>
 </execute_command>
         </tool_use>
-        <analysis>All code changes and translation updates are now committed.</analysis>
+        <analysis>Review the list of modified files to ensure only intended changes are present.</analysis>
+      </step>
+      
+      <step number="4a">
+        <description>Stage only the intended files for commit.</description>
+        <tool_use>
+<execute_command>
+<command>git add -u && git commit -m "fix: update button text and translations as requested in review"</command>
+</execute_command>
+        </tool_use>
+        <analysis>Using 'git add -u' stages only modified tracked files, avoiding any temporary files.</analysis>
       </step>
 
       <step number="5">
         <description>Check if PR is from a fork and push to correct remote.</description>
         <tool_use>
 <execute_command>
-<command>gh pr view 1234 --json isCrossRepository,headRepositoryOwner,headRefName</command>
+<command>gh pr view 1234 --repo RooCodeInc/Roo-Code --json isCrossRepository,headRepositoryOwner,headRefName</command>
 </execute_command>
         </tool_use>
         <analysis>Determine if this is a cross-repository PR to know which remote to push to.</analysis>
@@ -181,7 +175,7 @@ Ensure consistency across all language files and maintain the same context and t
         <description>Push changes to the appropriate remote.</description>
         <tool_use>
 <execute_command>
-<command>git push --force-with-lease origin <branch_name></command>
+<command>git push --force-with-lease origin [branch_name]</command>
 </execute_command>
         </tool_use>
         <analysis>Push changes safely to update the pull request. Use 'fork' remote instead if PR is from a fork.</analysis>
@@ -191,7 +185,7 @@ Ensure consistency across all language files and maintain the same context and t
         <description>Monitor CI status in real-time.</description>
         <tool_use>
 <execute_command>
-<command>gh pr checks 1234 --watch</command>
+<command>gh pr checks 1234 --repo RooCodeInc/Roo-Code --watch</command>
 </execute_command>
         </tool_use>
         <analysis>Watch CI checks continuously until all tests pass. The --watch flag provides automatic updates as check statuses change.</analysis>
@@ -203,6 +197,108 @@ Ensure consistency across all language files and maintain the same context and t
       <takeaway>Use new_task with translate mode to ensure consistent translation updates.</takeaway>
       <takeaway>Include detailed context about what changed and why in translation requests.</takeaway>
       <takeaway>Verify translation completeness before considering the PR fix complete.</takeaway>
+      <takeaway>Use gh pr view --json to get structured data about PR properties.</takeaway>
+    </key_takeaways>
+  </example>
+
+  <example name="fix_pr_with_merge_conflicts">
+    <scenario>
+      A pull request has merge conflicts that need to be resolved before other fixes can be applied.
+    </scenario>
+    
+    <user_request>
+      Fix PR #5678 in RooCodeInc/Roo-Code - it has merge conflicts and failing tests.
+    </user_request>
+
+    <workflow>
+      <step number="1">
+        <description>Get PR details and check merge status.</description>
+        <tool_use>
+<execute_command>
+<command>gh pr view 5678 --repo RooCodeInc/Roo-Code --json number,title,author,state,body,url,headRefName,baseRefName,mergeable,mergeStateStatus</command>
+</execute_command>
+        </tool_use>
+        <expected_outcome>Identify that mergeable is false and mergeStateStatus is CONFLICTING.</expected_outcome>
+      </step>
+
+      <step number="2">
+        <description>Delegate merge conflict resolution to merge-resolver mode.</description>
+        <tool_use>
+<new_task>
+<mode>merge-resolver</mode>
+<message>#5678</message>
+</new_task>
+        </tool_use>
+        <expected_outcome>The merge-resolver mode will handle checkout, rebase, conflict resolution, and pushing the resolved changes.</expected_outcome>
+      </step>
+
+      <step number="3">
+        <description>After merge-resolver completes, check PR status again.</description>
+        <tool_use>
+<execute_command>
+<command>gh pr view 5678 --repo RooCodeInc/Roo-Code --json mergeable,mergeStateStatus</command>
+</execute_command>
+        </tool_use>
+        <analysis>Verify that the PR is now mergeable after conflict resolution.</analysis>
+      </step>
+
+      <step number="4">
+        <description>Check CI status for any remaining failures.</description>
+        <tool_use>
+<execute_command>
+<command>gh pr checks 5678 --repo RooCodeInc/Roo-Code</command>
+</execute_command>
+        </tool_use>
+        <analysis>Identify any tests that are still failing after the merge conflict resolution.</analysis>
+      </step>
+
+      <step number="5">
+        <description>If tests are still failing, proceed with fixing them.</description>
+        <tool_use>
+<execute_command>
+<command>gh pr checkout 5678 --repo RooCodeInc/Roo-Code --force</command>
+</execute_command>
+        </tool_use>
+        <analysis>Now that conflicts are resolved, we can focus on fixing the failing tests.</analysis>
+      </step>
+
+      <step number="6">
+        <description>Apply test fixes and push changes.</description>
+        <tool_use>
+<execute_command>
+<command>git add -u && git commit -m "fix: resolve failing tests after merge conflict resolution"</command>
+</execute_command>
+        </tool_use>
+        <analysis>Commit the test fixes separately from the merge conflict resolution.</analysis>
+      </step>
+
+      <step number="7">
+        <description>Push changes and monitor CI status.</description>
+        <tool_use>
+<execute_command>
+<command>git push --force-with-lease origin [branch_name]</command>
+</execute_command>
+        </tool_use>
+        <analysis>Push the test fixes to update the PR.</analysis>
+      </step>
+
+      <step number="8">
+        <description>Monitor CI checks in real-time.</description>
+        <tool_use>
+<execute_command>
+<command>gh pr checks 5678 --repo RooCodeInc/Roo-Code --watch</command>
+</execute_command>
+        </tool_use>
+        <analysis>Watch CI checks continuously until all tests pass.</analysis>
+      </step>
+    </workflow>
+
+    <key_takeaways>
+      <takeaway>Always check for merge conflicts before attempting other fixes.</takeaway>
+      <takeaway>Delegate merge conflict resolution to the specialized merge-resolver mode.</takeaway>
+      <takeaway>The merge-resolver mode handles the entire conflict resolution workflow including pushing.</takeaway>
+      <takeaway>After conflict resolution, continue with other PR fixes like failing tests.</takeaway>
+      <takeaway>Keep conflict resolution commits separate from other fix commits for clarity.</takeaway>
     </key_takeaways>
   </example>
 </complete_examples>

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

@@ -1,203 +0,0 @@
-<orchestrator_workflow>
-  <overview>
-    This workflow orchestrates a comprehensive pull request review process by delegating
-    specialized analysis tasks to appropriate modes while maintaining context through
-    structured report files. The orchestrator ensures critical review coverage while
-    avoiding redundant feedback.
-  </overview>
-
-  <initialization>
-    <step number="1">
-      <name>Parse PR Information and Initialize Context</name>
-      <description>
-        Extract PR information from user input (URL or PR number).
-        Create context directory and tracking files.
-        If called by another mode (Issue Fixer, PR Fixer), set calledByMode field.
-      </description>
-      <actions>
-        - Parse PR URL or number from user input
-        - Create directory: .roo/temp/pr-[PR_NUMBER]/
-        - Initialize review-context.json with PR metadata
-        - Check if called by another mode and record it
-      </actions>
-    </step>
-  </initialization>
-
-  <github_operations>
-    <step number="2">
-      <name>Fetch PR Details and Context</name>
-      <description>
-        Try using GitHub MCP tools first. If unavailable or failing, fall back to GitHub CLI.
-      </description>
-      <mcp_approach>
-        Use get_pull_request tool to fetch PR details
-      </mcp_approach>
-      <cli_fallback>
-        gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles
-      </cli_fallback>
-    </step>
-
-    <step number="3">
-      <name>Fetch Linked Issue</name>
-      <description>
-        If PR references an issue, fetch its details for context.
-      </description>
-      <mcp_approach>
-        Use get_issue tool if issue is referenced
-      </mcp_approach>
-      <cli_fallback>
-        gh issue view [issue_number] --repo [owner]/[repo] --json number,title,body,author,state
-      </cli_fallback>
-    </step>
-
-    <step number="4">
-      <name>Fetch Existing Comments and Reviews</name>
-      <description>
-        CRITICAL: Get all existing feedback to avoid redundancy.
-      </description>
-      <mcp_approach>
-        Use get_pull_request_comments and get_pull_request_reviews
-      </mcp_approach>
-      <cli_fallback>
-        gh pr review [PR_NUMBER] --repo [owner]/[repo] --json comments,reviews
-      </cli_fallback>
-      <save_to>.roo/temp/pr-[PR_NUMBER]/existing-feedback.json</save_to>
-    </step>
-
-    <step number="5">
-      <name>Check Out PR Locally</name>
-      <command>gh pr checkout [PR_NUMBER] --repo [owner]/[repo]</command>
-      <purpose>Enable local code analysis and pattern comparison</purpose>
-    </step>
-  </github_operations>
-
-  <delegated_analysis>
-    <step number="6">
-      <name>Delegate Pattern Analysis</name>
-      <description>
-        Create a subtask to analyze code patterns and organization.
-      </description>
-      <delegation>
-        <mode>code</mode>
-        <focus_areas>
-          - Identifying similar existing features/components
-          - Checking if implementations follow established patterns
-          - Finding potential code redundancy
-          - Verifying test organization
-          - Checking file/directory structure consistency
-        </focus_areas>
-        <output>.roo/temp/pr-[PR_NUMBER]/pattern-analysis.md</output>
-      </delegation>
-    </step>
-
-    <step number="7">
-      <name>Delegate Architecture Review</name>
-      <description>
-        Create a subtask for architectural analysis.
-      </description>
-      <delegation>
-        <mode>architect</mode>
-        <focus_areas>
-          - Module boundary violations
-          - Dependency management issues
-          - Separation of concerns
-          - Potential circular dependencies
-          - Overall architectural consistency
-        </focus_areas>
-        <output>.roo/temp/pr-[PR_NUMBER]/architecture-review.md</output>
-      </delegation>
-    </step>
-
-    <step number="8">
-      <name>Delegate Test Coverage Analysis</name>
-      <description>
-        If test files are modified or added, delegate test analysis.
-      </description>
-      <delegation>
-        <mode>test</mode>
-        <focus_areas>
-          - Test organization and location
-          - Test coverage adequacy
-          - Test naming conventions
-          - Mock usage patterns
-          - Edge case coverage
-        </focus_areas>
-        <output>.roo/temp/pr-[PR_NUMBER]/test-analysis.md</output>
-      </delegation>
-    </step>
-  </delegated_analysis>
-
-  <synthesis>
-    <step number="9">
-      <name>Synthesize Findings</name>
-      <description>
-        Collect all delegated analysis results and create comprehensive review.
-      </description>
-      <actions>
-        - Read all analysis files from .roo/temp/pr-[PR_NUMBER]/
-        - Identify critical issues vs suggestions
-        - Check against existing comments to avoid redundancy
-        - Prioritize findings by impact
-      </actions>
-    </step>
-
-    <step number="10">
-      <name>Create Final Review Report</name>
-      <description>
-        Generate comprehensive review report with all findings.
-      </description>
-      <output>.roo/temp/pr-[PR_NUMBER]/final-review.md</output>
-      <sections>
-        - Executive Summary
-        - Critical Issues (must fix)
-        - Pattern Inconsistencies
-        - Redundancy Findings
-        - Architecture Concerns
-        - Test Coverage Issues
-        - Minor Suggestions
-      </sections>
-    </step>
-  </synthesis>
-
-  <completion>
-    <step number="11">
-      <name>Present Review to User</name>
-      <description>
-        Show the review findings and ask for action.
-      </description>
-      <decision_points>
-        <if_called_by_mode>
-          Only present the analysis report, do not comment on PR
-        </if_called_by_mode>
-        <if_direct_review>
-          Ask user if they want to post the review as a comment
-        </if_direct_review>
-      </decision_points>
-    </step>
-
-    <step number="12">
-      <name>Post Review Comment (if approved)</name>
-      <description>
-        If user approves and not called by another mode, post review.
-      </description>
-      <mcp_approach>
-        Use add_issue_comment or create PR review
-      </mcp_approach>
-      <cli_fallback>
-        gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body-file .roo/temp/pr-[PR_NUMBER]/final-review.md
-      </cli_fallback>
-    </step>
-  </completion>
-
-  <error_handling>
-    <github_api_failures>
-      Always fall back to GitHub CLI commands
-    </github_api_failures>
-    <delegation_failures>
-      Continue with available analysis and note limitations
-    </delegation_failures>
-    <context_preservation>
-      Always save intermediate results to temp files
-    </context_preservation>
-  </error_handling>
-</orchestrator_workflow>

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

@@ -1,208 +0,0 @@
-<critical_review_guidelines>
-  <overview>
-    These guidelines ensure PR reviews are appropriately critical while remaining
-    constructive. The goal is to maintain high code quality and consistency
-    across the codebase by identifying issues that might be overlooked in a
-    less thorough review.
-  </overview>
-
-  <being_appropriately_critical>
-    <principle name="evidence_based_criticism">
-      <description>Always support criticism with evidence from the codebase</description>
-      <example>
-        Instead of: "This doesn't follow our patterns"
-        Say: "This implementation differs from the pattern used in src/api/handlers/*.ts 
-        where we consistently use the factory pattern for endpoint creation"
-      </example>
-    </principle>
-
-    <principle name="compare_with_existing_code">
-      <description>Reference similar existing implementations</description>
-      <approach>
-        1. Find 2-3 examples of similar features
-        2. Identify the common patterns they follow
-        3. Explain how the PR deviates from these patterns
-        4. Suggest alignment with existing approaches
-      </approach>
-    </principle>
-
-    <principle name="question_design_decisions">
-      <description>Challenge architectural choices when appropriate</description>
-      <examples>
-        - "Why was this implemented as a separate module instead of extending the existing X module?"
-        - "This introduces a new pattern for Y. Have we considered using the established pattern from Z?"
-        - "This creates a circular dependency with module A. Could we restructure to maintain cleaner boundaries?"
-      </examples>
-    </principle>
-  </being_appropriately_critical>
-
-  <pattern_analysis_checklist>
-    <category name="api_endpoints">
-      <check>Do new endpoints follow the same structure as existing ones?</check>
-      <check>Are error responses consistent with other endpoints?</check>
-      <check>Is authentication/authorization handled the same way?</check>
-      <check>Are request validations following established patterns?</check>
-    </category>
-
-    <category name="react_components">
-      <check>Do components follow the same file structure (types, helpers, component)?</check>
-      <check>Are props interfaces defined consistently?</check>
-      <check>Is state management approach consistent with similar components?</check>
-      <check>Are hooks used in the same patterns as elsewhere?</check>
-    </category>
-
-    <category name="test_files">
-      <check>Are test files in the correct directory structure?</check>
-      <check>Do test descriptions follow the same format?</check>
-      <check>Are mocking strategies consistent with other tests?</check>
-      <check>Is test data generation following established patterns?</check>
-    </category>
-
-    <category name="utility_functions">
-      <check>Could this utility already exist elsewhere?</check>
-      <check>Should this be added to an existing utility module?</check>
-      <check>Does the naming convention match other utilities?</check>
-      <check>Are similar transformations already implemented?</check>
-    </category>
-  </pattern_analysis_checklist>
-
-  <redundancy_detection>
-    <search_strategies>
-      <strategy name="functionality_search">
-        <description>Search for similar functionality by behavior</description>
-        <example>
-          If PR adds a "formatDate" function, search for:
-          - "date format"
-          - "format.*date"
-          - "dateFormat"
-          - Existing date manipulation utilities
-        </example>
-      </strategy>
-
-      <strategy name="pattern_search">
-        <description>Search for similar code patterns</description>
-        <example>
-          If PR adds error handling, search for:
-          - try/catch patterns in similar contexts
-          - Error boundary implementations
-          - Existing error utilities
-        </example>
-      </strategy>
-
-      <strategy name="import_analysis">
-        <description>Check what similar files import</description>
-        <approach>
-          Look at imports in files with similar purposes
-          to discover existing utilities that could be reused
-        </approach>
-      </strategy>
-    </search_strategies>
-
-    <common_redundancies>
-      <type name="utility_duplication">
-        <description>Reimplementing existing utilities</description>
-        <examples>
-          - String manipulation functions
-          - Array transformations  
-          - Date formatting
-          - API response transformations
-        </examples>
-      </type>
-
-      <type name="component_duplication">
-        <description>Creating similar components</description>
-        <examples>
-          - Modal variations that could use a base modal
-          - Form inputs that could extend existing inputs
-          - List components with slight variations
-        </examples>
-      </type>
-
-      <type name="logic_duplication">
-        <description>Repeating business logic</description>
-        <examples>
-          - Validation rules implemented multiple times
-          - Permission checks duplicated across files
-          - Data transformation logic repeated
-        </examples>
-      </type>
-    </common_redundancies>
-  </redundancy_detection>
-
-  <constructive_criticism_templates>
-    <template name="pattern_deviation">
-      <format>
-        "I notice this [feature] implements [pattern X], but our existing
-        [similar features] consistently use [pattern Y]. For example:
-        - [Link to example 1]
-        - [Link to example 2]
-        
-        Consider aligning with the established pattern to maintain consistency.
-        If there's a specific reason for the deviation, it would be helpful
-        to document it."
-      </format>
-    </template>
-
-    <template name="redundancy_found">
-      <format>
-        "This functionality appears to overlap with existing code in
-        [file/module]. Specifically, [existing function/component] already
-        handles [similar use case].
-        
-        Could we either:
-        1. Reuse the existing implementation
-        2. Extend it to cover this use case
-        3. Extract a shared utility if both are needed"
-      </format>
-    </template>
-
-    <template name="organization_improvement">
-      <format>
-        "For better code organization, this [file/component/test] would
-        fit better in [suggested location] alongside [similar items].
-        This follows our pattern where [explanation of pattern]."
-      </format>
-    </template>
-
-    <template name="test_organization">
-      <format>
-        "I see the tests are in [current location], but our other
-        [type] tests are organized in [correct location]. Moving them
-        would make them easier to find and maintain consistency with
-        tests like [example test files]."
-      </format>
-    </template>
-  </constructive_criticism_templates>
-
-  <severity_guidelines>
-    <level name="must_fix">
-      <description>Issues that should block PR approval</description>
-      <examples>
-        - Security vulnerabilities
-        - Breaking changes without migration path
-        - Significant pattern violations that would confuse future developers
-        - Major redundancy that adds maintenance burden
-      </examples>
-    </level>
-
-    <level name="should_fix">
-      <description>Important issues that need addressing</description>
-      <examples>
-        - Test files in wrong location
-        - Inconsistent error handling
-        - Missing critical test cases
-        - Code organization that violates module boundaries
-      </examples>
-    </level>
-
-    <level name="consider_fixing">
-      <description>Improvements that would benefit the codebase</description>
-      <examples>
-        - Minor pattern inconsistencies
-        - Opportunities for code reuse
-        - Additional test coverage
-        - Documentation improvements
-      </examples>
-    </level>
-  </severity_guidelines>
-</critical_review_guidelines>

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

@@ -1,238 +0,0 @@
-<delegation_patterns>
-  <overview>
-    Patterns for effectively delegating analysis tasks to specialized modes
-    while maintaining context and ensuring comprehensive review coverage.
-  </overview>
-
-  <delegation_strategies>
-    <strategy name="pattern_analysis_delegation">
-      <when_to_delegate>
-        When PR contains new features or significant code changes
-      </when_to_delegate>
-      <delegate_to>code</delegate_to>
-      <task_template>
-        Analyze the following changed files for pattern consistency:
-        [List of changed files]
-        
-        Please focus on:
-        1. Finding similar existing implementations in the codebase
-        2. Identifying established patterns for this type of feature
-        3. Checking if the new code follows these patterns
-        4. Looking for potential code redundancy
-        5. Verifying proper file organization
-        
-        Use codebase_search and search_files to find similar code.
-        Document all findings with specific examples and file references.
-        
-        Save your analysis to: .roo/temp/pr-[PR_NUMBER]/pattern-analysis.md
-        
-        Format the output as:
-        ## Pattern Analysis for PR #[PR_NUMBER]
-        ### Similar Existing Implementations
-        ### Established Patterns
-        ### Pattern Deviations
-        ### Redundancy Findings
-        ### Organization Issues
-      </task_template>
-    </strategy>
-
-    <strategy name="architecture_review_delegation">
-      <when_to_delegate>
-        When PR modifies core modules, adds new modules, or changes dependencies
-      </when_to_delegate>
-      <delegate_to>architect</delegate_to>
-      <task_template>
-        Review the architectural implications of PR #[PR_NUMBER]:
-        
-        Changed files:
-        [List of changed files]
-        
-        PR Description:
-        [PR description]
-        
-        Please analyze:
-        1. Module boundary adherence
-        2. Dependency management (new dependencies, circular dependencies)
-        3. Separation of concerns
-        4. Impact on system architecture
-        5. Consistency with architectural patterns
-        
-        Save your findings to: .roo/temp/pr-[PR_NUMBER]/architecture-review.md
-        
-        Format as:
-        ## Architecture Review for PR #[PR_NUMBER]
-        ### Module Boundaries
-        ### Dependency Analysis
-        ### Architectural Concerns
-        ### Recommendations
-      </task_template>
-    </strategy>
-
-    <strategy name="test_analysis_delegation">
-      <when_to_delegate>
-        When PR adds or modifies test files
-      </when_to_delegate>
-      <delegate_to>test</delegate_to>
-      <task_template>
-        Analyze test changes in PR #[PR_NUMBER]:
-        
-        Test files changed:
-        [List of test files]
-        
-        Please review:
-        1. Test file organization and location
-        2. Test naming conventions
-        3. Coverage of edge cases
-        4. Mock usage patterns
-        5. Consistency with existing test patterns
-        
-        Compare with similar existing tests in the codebase.
-        
-        Save analysis to: .roo/temp/pr-[PR_NUMBER]/test-analysis.md
-        
-        Format as:
-        ## Test Analysis for PR #[PR_NUMBER]
-        ### Test Organization
-        ### Coverage Assessment
-        ### Pattern Consistency
-        ### Recommendations
-      </task_template>
-    </strategy>
-
-    <strategy name="ui_review_delegation">
-      <when_to_delegate>
-        When PR modifies UI components or adds new ones
-      </when_to_delegate>
-      <delegate_to>design-engineer</delegate_to>
-      <task_template>
-        Review UI changes in PR #[PR_NUMBER]:
-        
-        UI files changed:
-        [List of UI files]
-        
-        Please analyze:
-        1. Component structure consistency
-        2. Styling approach (Tailwind usage)
-        3. Accessibility considerations
-        4. i18n implementation
-        5. Component reusability
-        
-        Save findings to: .roo/temp/pr-[PR_NUMBER]/ui-review.md
-      </task_template>
-    </strategy>
-  </delegation_strategies>
-
-  <context_preservation>
-    <principle name="use_temp_files">
-      <description>Always save delegation results to temp files</description>
-      <pattern>.roo/temp/pr-[PR_NUMBER]/[analysis-type].md</pattern>
-    </principle>
-
-    <principle name="structured_output">
-      <description>Request structured markdown output from delegates</description>
-      <benefits>
-        - Easy to parse and combine
-        - Consistent formatting
-        - Clear section headers
-      </benefits>
-    </principle>
-
-    <principle name="pass_context_forward">
-      <description>Include relevant context in delegation requests</description>
-      <include>
-        - PR number and description
-        - List of changed files
-        - Specific areas of concern
-        - Output file location
-      </include>
-    </principle>
-  </context_preservation>
-
-  <coordination_patterns>
-    <pattern name="sequential_delegation">
-      <description>Delegate tasks one at a time, using results to inform next delegation</description>
-      <example>
-        1. Pattern analysis first
-        2. If patterns violated, delegate architecture review
-        3. If tests affected, delegate test analysis
-      </example>
-    </pattern>
-
-    <pattern name="parallel_delegation">
-      <description>Delegate multiple independent analyses simultaneously</description>
-      <example>
-        - Pattern analysis (code mode)
-        - Test analysis (test mode)
-        - UI review (design-engineer mode)
-      </example>
-    </pattern>
-
-    <pattern name="conditional_delegation">
-      <description>Only delegate based on file types changed</description>
-      <conditions>
-        - If *.test.ts changed -> delegate to test mode
-        - If src/components/* changed -> delegate to design-engineer
-        - If package.json changed -> delegate to architect
-      </conditions>
-    </pattern>
-  </coordination_patterns>
-
-  <result_synthesis>
-    <step name="collect_results">
-      <action>Read all analysis files from temp directory</action>
-      <files>
-        - pattern-analysis.md
-        - architecture-review.md
-        - test-analysis.md
-        - ui-review.md
-      </files>
-    </step>
-
-    <step name="identify_themes">
-      <action>Find common issues across analyses</action>
-      <themes>
-        - Pattern violations mentioned multiple times
-        - Redundancy identified by different modes
-        - Organizational issues
-      </themes>
-    </step>
-
-    <step name="prioritize_findings">
-      <action>Categorize by severity</action>
-      <categories>
-        - Critical (blocks PR)
-        - Important (should fix)
-        - Suggestions (nice to have)
-      </categories>
-    </step>
-
-    <step name="create_unified_report">
-      <action>Combine all findings into final review</action>
-      <format>
-        ## PR Review Summary
-        ### Critical Issues
-        ### Pattern Inconsistencies
-        ### Architecture Concerns
-        ### Test Coverage
-        ### Suggestions
-      </format>
-    </step>
-  </result_synthesis>
-
-  <fallback_strategies>
-    <scenario name="delegation_fails">
-      <action>Continue with available analyses</action>
-      <note>Document which analyses couldn't be completed</note>
-    </scenario>
-
-    <scenario name="mode_unavailable">
-      <action>Perform basic analysis in orchestrator mode</action>
-      <limitations>Note limitations in final report</limitations>
-    </scenario>
-
-    <scenario name="timeout">
-      <action>Use completed analyses</action>
-      <timeout>Set reasonable time limits for delegations</timeout>
-    </scenario>
-  </fallback_strategies>
-</delegation_patterns>

.roo/rules-pr-reviewer/4_github_operations.xml

@@ -1,226 +0,0 @@
-<github_operations>
-  <overview>
-    Guidelines for handling GitHub operations with fallback strategies
-    when MCP tools are unavailable or failing.
-  </overview>
-
-  <mcp_vs_cli>
-    <principle>
-      Always try MCP tools first, fall back to GitHub CLI if they fail
-    </principle>
-    <benefits_of_mcp>
-      - Structured data responses
-      - Better error handling
-      - Integrated with the system
-    </benefits_of_mcp>
-    <benefits_of_cli>
-      - More reliable when MCP is down
-      - Direct GitHub API access
-      - Can handle complex queries
-    </benefits_of_cli>
-  </mcp_vs_cli>
-
-  <operation_patterns>
-    <operation name="fetch_pr_details">
-      <mcp_approach>
-        <tool>get_pull_request</tool>
-        <example><![CDATA[
-<use_mcp_tool>
-<server_name>github</server_name>
-<tool_name>get_pull_request</tool_name>
-<arguments>
-{
-  "owner": "RooCodeInc",
-  "repo": "Roo-Code",
-  "pullNumber": 123
-}
-</arguments>
-</use_mcp_tool>
-        ]]></example>
-      </mcp_approach>
-      <cli_fallback>
-        <command>gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles</command>
-        <parse_json>true</parse_json>
-      </cli_fallback>
-    </operation>
-
-    <operation name="fetch_pr_diff">
-      <mcp_approach>
-        <tool>get_pull_request_diff</tool>
-        <example><![CDATA[
-<use_mcp_tool>
-<server_name>github</server_name>
-<tool_name>get_pull_request_diff</tool_name>
-<arguments>
-{
-  "owner": "RooCodeInc",
-  "repo": "Roo-Code",
-  "pullNumber": 123
-}
-</arguments>
-</use_mcp_tool>
-        ]]></example>
-      </mcp_approach>
-      <cli_fallback>
-        <command>gh pr diff [PR_NUMBER] --repo [owner]/[repo]</command>
-        <save_to>.roo/temp/pr-[PR_NUMBER]/pr.diff</save_to>
-      </cli_fallback>
-    </operation>
-
-    <operation name="fetch_pr_files">
-      <mcp_approach>
-        <tool>get_pull_request_files</tool>
-      </mcp_approach>
-      <cli_fallback>
-        <command>gh pr view [PR_NUMBER] --repo [owner]/[repo] --json files --jq '.files[].path'</command>
-        <description>Lists all files changed in the PR</description>
-      </cli_fallback>
-    </operation>
-
-    <operation name="fetch_comments">
-      <mcp_approach>
-        <tool>get_pull_request_comments</tool>
-      </mcp_approach>
-      <cli_fallback>
-        <command>gh pr view [PR_NUMBER] --repo [owner]/[repo] --json comments --jq '.comments'</command>
-      </cli_fallback>
-    </operation>
-
-    <operation name="fetch_reviews">
-      <mcp_approach>
-        <tool>get_pull_request_reviews</tool>
-      </mcp_approach>
-      <cli_fallback>
-        <command>gh pr view [PR_NUMBER] --repo [owner]/[repo] --json reviews --jq '.reviews'</command>
-      </cli_fallback>
-    </operation>
-
-    <operation name="checkout_pr">
-      <cli_only>
-        <command>gh pr checkout [PR_NUMBER] --repo [owner]/[repo]</command>
-        <note>No MCP equivalent - always use CLI</note>
-      </cli_only>
-    </operation>
-
-    <operation name="post_comment">
-      <mcp_approach>
-        <tool>add_issue_comment</tool>
-        <note>PRs use same comment system as issues</note>
-      </mcp_approach>
-      <cli_fallback>
-        <command>gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body-file [file_path]</command>
-        <alternative>gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body "[comment_text]"</alternative>
-      </cli_fallback>
-    </operation>
-
-    <operation name="create_review">
-      <mcp_approach>
-        <sequence>
-          1. create_pending_pull_request_review
-          2. add_pull_request_review_comment_to_pending_review (multiple times)
-          3. submit_pending_pull_request_review
-        </sequence>
-      </mcp_approach>
-      <cli_fallback>
-        <command>gh pr review [PR_NUMBER] --repo [owner]/[repo] --comment --body-file [review_file]</command>
-      </cli_fallback>
-    </operation>
-  </operation_patterns>
-
-  <error_handling>
-    <scenario name="mcp_server_unavailable">
-      <detection>
-        Error message contains "MCP server" or "github server not found"
-      </detection>
-      <action>
-        Immediately switch to CLI commands for all operations
-      </action>
-    </scenario>
-
-    <scenario name="api_rate_limit">
-      <detection>
-        Error contains "rate limit" or status code 403
-      </detection>
-      <action>
-        1. Wait briefly (30 seconds)
-        2. Retry with CLI using --limit flag
-        3. Reduce number of API calls
-      </action>
-    </scenario>
-
-    <scenario name="authentication_failure">
-      <detection>
-        Error contains "authentication" or status code 401
-      </detection>
-      <action>
-        1. Inform user about auth issue
-        2. Suggest checking gh auth status
-        3. Continue with available data
-      </action>
-    </scenario>
-
-    <scenario name="pr_not_found">
-      <detection>
-        Error contains "not found" or status code 404
-      </detection>
-      <action>
-        1. Verify PR number and repository
-        2. Ask user to confirm details
-        3. Check if PR is from a fork
-      </action>
-    </scenario>
-  </error_handling>
-
-  <data_handling>
-    <principle name="save_everything">
-      <description>Always save API responses to temp files</description>
-      <reason>Preserve data in case of failures</reason>
-    </principle>
-
-    <principle name="parse_json_safely">
-      <description>Use jq or built-in JSON parsing</description>
-      <example>
-        gh pr view --json files --jq '.files[].path'
-      </example>
-    </principle>
-
-    <principle name="handle_large_prs">
-      <description>For PRs with many files, process in batches</description>
-      <threshold>More than 50 files</threshold>
-    </principle>
-  </data_handling>
-
-  <cli_command_reference>
-    <command_group name="pr_info">
-      <command>gh pr view [number] --json [fields]</command>
-      <fields>
-        number, title, author, state, body, url, 
-        headRefName, baseRefName, files, additions, 
-        deletions, changedFiles, comments, reviews
-      </fields>
-    </command_group>
-
-    <command_group name="pr_interaction">
-      <command>gh pr checkout [number]</command>
-      <command>gh pr diff [number]</command>
-      <command>gh pr comment [number] --body "[text]"</command>
-      <command>gh pr review [number] --comment --body "[text]"</command>
-    </command_group>
-
-    <command_group name="issue_info">
-      <command>gh issue view [number] --json [fields]</command>
-      <fields>
-        number, title, body, author, state, 
-        labels, assignees, milestone
-      </fields>
-    </command_group>
-  </cli_command_reference>
-
-  <best_practices>
-    <practice>Always specify --repo to avoid ambiguity</practice>
-    <practice>Use --json for structured data</practice>
-    <practice>Save command outputs to temp files</practice>
-    <practice>Check gh auth status before operations</practice>
-    <practice>Handle both personal repos and org repos</practice>
-  </best_practices>
-</github_operations>

.roo/rules-pr-reviewer/5_context_management.xml

@@ -1,356 +0,0 @@
-<context_management>
-  <overview>
-    Strategies for maintaining review context across delegated tasks and
-    ensuring no information is lost during the orchestration process.
-  </overview>
-
-  <context_files>
-    <file name="review-context.json">
-      <purpose>Central tracking file for the entire review process</purpose>
-      <location>.roo/temp/pr-[PR_NUMBER]/review-context.json</location>
-      <structure>
-        {
-          "prNumber": "string",
-          "repository": "string", 
-          "reviewStartTime": "ISO timestamp",
-          "calledByMode": "string or null",
-          "prMetadata": {
-            "title": "string",
-            "author": "string",
-            "state": "string",
-            "baseRefName": "string",
-            "headRefName": "string",
-            "additions": "number",
-            "deletions": "number",
-            "changedFiles": "number"
-          },
-          "linkedIssue": {
-            "number": "number",
-            "title": "string",
-            "body": "string"
-          },
-          "existingComments": [],
-          "existingReviews": [],
-          "filesChanged": [],
-          "delegatedTasks": [
-            {
-              "mode": "string",
-              "status": "pending|completed|failed",
-              "outputFile": "string",
-              "startTime": "ISO timestamp",
-              "endTime": "ISO timestamp"
-            }
-          ],
-          "findings": {
-            "critical": [],
-            "patterns": [],
-            "redundancy": [],
-            "architecture": [],
-            "tests": []
-          },
-          "reviewStatus": "initialized|analyzing|synthesizing|completed"
-        }
-      </structure>
-    </file>
-
-    <file name="pr-metadata.json">
-      <purpose>Raw PR data from GitHub</purpose>
-      <location>.roo/temp/pr-[PR_NUMBER]/pr-metadata.json</location>
-    </file>
-
-    <file name="existing-feedback.json">
-      <purpose>All existing comments and reviews</purpose>
-      <location>.roo/temp/pr-[PR_NUMBER]/existing-feedback.json</location>
-    </file>
-
-    <file name="pattern-analysis.md">
-      <purpose>Output from code mode delegation</purpose>
-      <location>.roo/temp/pr-[PR_NUMBER]/pattern-analysis.md</location>
-    </file>
-
-    <file name="architecture-review.md">
-      <purpose>Output from architect mode delegation</purpose>
-      <location>.roo/temp/pr-[PR_NUMBER]/architecture-review.md</location>
-    </file>
-
-    <file name="test-analysis.md">
-      <purpose>Output from test mode delegation</purpose>
-      <location>.roo/temp/pr-[PR_NUMBER]/test-analysis.md</location>
-    </file>
-
-    <file name="final-review.md">
-      <purpose>Synthesized review ready for posting</purpose>
-      <location>.roo/temp/pr-[PR_NUMBER]/final-review.md</location>
-    </file>
-  </context_files>
-
-  <update_patterns>
-    <pattern name="after_github_fetch">
-      <action>Update review-context.json with PR metadata</action>
-      <example><![CDATA[
-<read_file>
-<path>.roo/temp/pr-123/review-context.json</path>
-</read_file>
-
-<!-- Parse and update the JSON -->
-
-<write_to_file>
-<path>.roo/temp/pr-123/review-context.json</path>
-<content>
-{
-  ...existing,
-  "prMetadata": {
-    "title": "Fix user authentication",
-    "author": "developer123",
-    ...
-  },
-  "filesChanged": ["src/auth.ts", "tests/auth.test.ts"],
-  "reviewStatus": "analyzing"
-}
-</content>
-</write_to_file>
-      ]]></example>
-    </pattern>
-
-    <pattern name="after_delegation">
-      <action>Update delegatedTasks array with task status</action>
-      <fields>
-        - mode: Which mode was delegated to
-        - status: pending -> completed/failed
-        - outputFile: Where results were saved
-        - timestamps: Start and end times
-      </fields>
-    </pattern>
-
-    <pattern name="after_synthesis">
-      <action>Update findings object with categorized issues</action>
-      <categories>
-        - critical: Must-fix issues
-        - patterns: Pattern inconsistencies
-        - redundancy: Duplicate code findings
-        - architecture: Architectural concerns
-        - tests: Test-related issues
-      </categories>
-    </pattern>
-  </update_patterns>
-
-  <context_preservation_strategies>
-    <strategy name="atomic_updates">
-      <description>Always read-modify-write for JSON updates</description>
-      <steps>
-        1. Read current context file
-        2. Parse JSON
-        3. Update specific fields
-        4. Write entire updated JSON
-      </steps>
-    </strategy>
-
-    <strategy name="backup_critical_data">
-      <description>Save copies of important data</description>
-      <files>
-        - PR diff before analysis
-        - Existing comments before review
-        - Each delegation output
-      </files>
-    </strategy>
-
-    <strategy name="status_tracking">
-      <description>Track review progress through status field</description>
-      <states>
-        - initialized: Just started
-        - analyzing: Delegating tasks
-        - synthesizing: Combining results
-        - completed: Ready for user
-      </states>
-    </strategy>
-  </context_preservation_strategies>
-
-  <recovery_procedures>
-    <scenario name="partial_failure">
-      <description>Some delegations failed</description>
-      <action>
-        1. Mark failed tasks in context
-        2. Continue with available data
-        3. Note limitations in final review
-      </action>
-    </scenario>
-
-    <scenario name="context_corruption">
-      <description>JSON file becomes invalid</description>
-      <action>
-        1. Try to recover from backups
-        2. Reconstruct from individual files
-        3. Start fresh if necessary
-      </action>
-    </scenario>
-
-    <scenario name="interrupted_review">
-      <description>Review process interrupted</description>
-      <action>
-        1. Check reviewStatus field
-        2. Resume from last completed step
-        3. Re-run failed delegations
-      </action>
-    </scenario>
-  </recovery_procedures>
-
-  <best_practices>
-    <practice name="always_update_status">
-      Keep reviewStatus current to enable recovery
-    </practice>
-    
-    <practice name="timestamp_everything">
-      Add timestamps to all operations for debugging
-    </practice>
-    
-    <practice name="validate_json">
-      Ensure JSON is valid before writing
-    </practice>
-    
-    <practice name="use_descriptive_filenames">
-      Make it clear what each file contains
-    </practice>
-    
-    <practice name="clean_up_old_reviews">
-      Suggest cleaning .roo/temp/ periodically
-    </practice>
-  </best_practices>
-
-  <example_workflow>
-    <step number="1">
-      <action>Initialize context</action>
-      <code><![CDATA[
-<execute_command>
-<command>New-Item -ItemType Directory -Force -Path ".roo/temp/pr-123"</command>
-</execute_command>
-
-<write_to_file>
-<path>.roo/temp/pr-123/review-context.json</path>
-<content>
-{
-  "prNumber": "123",
-  "repository": "RooCodeInc/Roo-Code",
-  "reviewStartTime": "2025-01-04T18:00:00Z",
-  "calledByMode": null,
-  "prMetadata": {},
-  "linkedIssue": {},
-  "existingComments": [],
-  "existingReviews": [],
-  "filesChanged": [],
-  "delegatedTasks": [],
-  "findings": {
-    "critical": [],
-    "patterns": [],
-    "redundancy": [],
-    "architecture": [],
-    "tests": []
-  },
-  "reviewStatus": "initialized"
-}
-</content>
-</write_to_file>
-      ]]></code>
-    </step>
-
-    <step number="2">
-      <action>Update after GitHub fetch</action>
-      <code><![CDATA[
-<read_file>
-<path>.roo/temp/pr-123/review-context.json</path>
-</read_file>
-
-<!-- Update with PR data -->
-
-<write_to_file>
-<path>.roo/temp/pr-123/review-context.json</path>
-<content>
-{
-  ...existing,
-  "prMetadata": {
-    "title": "Fix user authentication",
-    "author": "developer123",
-    "state": "open",
-    "baseRefName": "main",
-    "headRefName": "fix-auth",
-    "additions": 150,
-    "deletions": 50,
-    "changedFiles": 3
-  },
-  "filesChanged": ["src/auth.ts", "tests/auth.test.ts", "docs/auth.md"],
-  "reviewStatus": "analyzing"
-}
-</content>
-</write_to_file>
-      ]]></code>
-    </step>
-
-    <step number="3">
-      <action>Track delegation</action>
-      <code><![CDATA[
-<!-- Before delegation -->
-<read_file>
-<path>.roo/temp/pr-123/review-context.json</path>
-</read_file>
-
-<!-- Update to add pending task -->
-<write_to_file>
-<path>.roo/temp/pr-123/review-context.json</path>
-<content>
-{
-  ...existing,
-  "delegatedTasks": [
-    ...existing,
-    {
-      "mode": "code",
-      "status": "pending",
-      "outputFile": "pattern-analysis.md",
-      "startTime": "2025-01-04T18:05:00Z",
-      "endTime": null
-    }
-  ]
-}
-</content>
-</write_to_file>
-
-<!-- After delegation completes -->
-<!-- Update task status to completed -->
-      ]]></code>
-    </step>
-
-    <step number="4">
-      <action>Synthesize results</action>
-      <code><![CDATA[
-<!-- Read all analysis files -->
-<read_file>
-<path>.roo/temp/pr-123/pattern-analysis.md</path>
-</read_file>
-
-<read_file>
-<path>.roo/temp/pr-123/architecture-review.md</path>
-</read_file>
-
-<read_file>
-<path>.roo/temp/pr-123/test-analysis.md</path>
-</read_file>
-
-<!-- Update findings and status -->
-<write_to_file>
-<path>.roo/temp/pr-123/review-context.json</path>
-<content>
-{
-  ...existing,
-  "findings": {
-    "critical": ["Missing error handling in auth.ts"],
-    "patterns": ["Inconsistent naming convention"],
-    "redundancy": ["Duplicate validation logic"],
-    "architecture": [],
-    "tests": ["Missing test for edge case"]
-  },
-  "reviewStatus": "completed"
-}
-</content>
-</write_to_file>
-      ]]></code>
-    </step>
-  </example_workflow>
-</context_management>