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

@@ -1,3 +1,25 @@
 demo.gif filter=lfs diff=lfs merge=lfs -text
 assets/docs/demo.gif filter=lfs diff=lfs merge=lfs -text
 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,51 +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: steps
+    id: roo-code-tasks
     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
+      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: logs
     attributes:
-      label: 📄 Relevant Logs or Errors (Optional)
-      description: Paste API logs, terminal output, or errors here. Use triple backticks (```) for code formatting.
-      render: shell
+      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,61 +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: constraints
+    attributes:
+      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
@@ -64,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,67 +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 -->
-
-### 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,17 +1,13 @@
 name: Nightly Publish
 
 on:
-  workflow_run:
-    workflows: ["Code QA Roo Code"]
-    types:
-      - completed
+  push:
     branches: [main]
   workflow_dispatch: # Allows manual triggering.
 
 jobs:
   publish-nightly:
     runs-on: ubuntu-latest
-    if: ${{ github.event_name == 'workflow_dispatch' || github.event.workflow_run.conclusion == 'success' }}
 
     permissions:
       contents: read # No tags pushed → read is enough.
@@ -24,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,238 +1,113 @@
 <extraction_workflow>
-  <mode_overview>
-    The Docs Extractor mode performs comprehensive analysis of features and components
-    to generate multi-audience documentation. It extracts technical details, business logic,
-    user workflows, and all related information to create documentation suitable for
-    end-users, developers, administrators, and stakeholders.
-  </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>Understand Documentation Request</title>
+      <title>Identify Target</title>
       <actions>
-        <action>Parse the user's request to identify the feature or component.</action>
-        <action>Determine if the user has provided a documentation section for review or is requesting new documentation.</action>
-        <action>Default to user-friendly documentation unless technical docs are specifically requested.</action>
-        <action>Focus on practical benefits and real-world usage.</action>
-        <action>Note any specific aspects the user wants emphasized.</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 user will specify what they want documented in their initial message. The workflow branches based on whether a review is requested or new documentation is to be generated.</note>
     </step>
 
     <step number="2">
-      <title>Initial Feature Discovery</title>
+      <title>Discover Code</title>
       <actions>
-        <action>Use semantic search to find all related code</action>
-        <action>Identify entry points and main components</action>
-        <action>Map 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>Technical Implementation Analysis</title>
-      <steps>
-        <step>
-          <action>Analyze source code structure</action>
-          <details>
-            - Identify classes, functions, and modules
-            - Extract method signatures and parameters
-            - Document return types and data structures
-            - Map inheritance and composition relationships
-          </details>
-        </step>
-        <step>
-          <action>Extract API specifications</action>
-          <details>
-            - REST endpoints with methods and parameters
-            - GraphQL schemas and resolvers
-            - WebSocket events and handlers
-            - RPC interfaces and protocols
-          </details>
-        </step>
-        <step>
-          <action>Document configuration options</action>
-          <details>
-            - Environment variables
-            - Configuration files and schemas
-            - Feature flags and toggles
-            - Runtime parameters
-          </details>
-        </step>
-      </steps>
-    </phase>
-
-    <phase name="business_logic_analysis">
-      <title>Business Logic and Workflow Extraction</title>
-      <steps>
-        <step>
-          <action>Map user workflows</action>
-          <details>
-            - User journey through the feature
-            - Decision points and branching logic
-            - State transitions and lifecycle
-            - User roles and permissions
-          </details>
-        </step>
-        <step>
-          <action>Document business rules</action>
-          <details>
-            - Validation logic and constraints
-            - Calculation formulas and algorithms
-            - Business process implementations
-            - Compliance and regulatory requirements
-          </details>
-        </step>
-        <step>
-          <action>Identify use cases</action>
-          <details>
-            - Primary use cases and scenarios
-            - Edge cases and special conditions
-            - Error scenarios and recovery
-            - Performance considerations
-          </details>
-        </step>
-      </steps>
-    </phase>
-
-    <phase name="integration_analysis">
-      <title>Dependencies and Integration Analysis</title>
-      <steps>
-        <step>
-          <action>Map external dependencies</action>
-          <details>
-            - Third-party libraries and versions
-            - External services and APIs
-            - Database connections and schemas
-            - Message queues and event systems
-          </details>
-        </step>
-        <step>
-          <action>Document integration points</action>
-          <details>
-            - Incoming webhooks and callbacks
-            - Outgoing API calls
-            - Event publishers and subscribers
-            - Shared data stores and caches
-          </details>
-        </step>
-        <step>
-          <action>Analyze data flow</action>
-          <details>
-            - Input data sources and formats
-            - Data transformations and mappings
-            - Output formats and destinations
-            - Data retention and lifecycle
-          </details>
-        </step>
-      </steps>
-    </phase>
-
-    <phase name="quality_analysis">
-      <title>Quality and Testing Analysis</title>
-      <steps>
-        <step>
-          <action>Assess test coverage</action>
-          <details>
-            - Unit test coverage and quality
-            - 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 strategies
-            - Fallback mechanisms
-            - Recovery procedures
-          </details>
-        </step>
-        <step>
-          <action>Identify quality metrics</action>
-          <details>
-            - Code complexity metrics
-            - Performance benchmarks
-            - Security vulnerability assessments
-            - Maintainability indices
-          </details>
-        </step>
-      </steps>
-    </phase>
-
-    <phase name="security_analysis">
-      <title>Security and Compliance Analysis</title>
-      <steps>
-        <step>
-          <action>Document security measures</action>
-          <details>
-            - Authentication mechanisms
-            - Authorization and access control
-            - Data encryption methods
-            - Security headers and policies
-          </details>
-        </step>
-        <step>
-          <action>Identify vulnerabilities</action>
-          <details>
-            - Known security issues
-            - Potential attack vectors
-            - Mitigation strategies
-            - Security best practices
-          </details>
-        </step>
-        <step>
-          <action>Compliance requirements</action>
-          <details>
-            - Regulatory compliance (GDPR, HIPAA, etc.)
-            - Industry standards adherence
-            - Audit trail requirements
-            - Data privacy considerations
-          </details>
-        </step>
-      </steps>
-    </phase>
-  </analysis_phases>
-
-  <documentation_generation>
-    <note>This phase has two paths: Reviewing existing docs or Generating new docs. The path taken is determined in the initialization phase.</note>
-    <step number="1">
-      <title>Path 1: Review and Recommend Improvements</title>
-      <note>This path is followed if the user provided a documentation section for review.</note>
-      <actions>
-        <action>Compare the provided documentation against the analysis of the codebase.</action>
-        <action>Identify inaccuracies (technical, logical), omissions, and areas for improvement.</action>
-        <action>Categorize inaccuracies by severity (e.g., Critical, Major, Minor, Suggestion).</action>
-        <action>Formulate a structured recommendation in the chat, suitable for being copied to the docs team.</action>
-        <action>Do not write any files or make changes yourself.</action>
-        <action>The final output in the chat should ONLY be the structured recommendation, without any preceding conversational text.</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 New Documentation</title>
-      <note>This path is followed if the user requested new documentation.</note>
+
+    <step number="3">
+      <title>Extract Facts</title>
       <actions>
-        <action>Choose a documentation style (e.g., user-focused or comprehensive) from `2_documentation_patterns.xml`.</action>
-        <action>Structure the documentation with clear sections, examples, and user-friendly elements.</action>
-        <action>Create a `DOCS-TEMP-[feature].md` file with the generated content.</action>
-        <action>Use a conversational tone and practical 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>All code paths have been analyzed</criterion>
-    <criterion>Business logic is fully documented</criterion>
-    <criterion>Integration points are mapped</criterion>
-    <criterion>Security considerations are addressed</criterion>
-    <criterion>Documentation serves all target audiences</criterion>
-    <criterion>Metadata and cross-references 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,419 +0,0 @@
-<documentation_patterns>
-  <overview>
-    Standard patterns and templates for structuring extracted documentation
-    to serve end-users with clear, practical information.
-  </overview>
-
-  <output_structure>
-    <user_focused_template><![CDATA[
-# [Feature Name]
-
-[Brief, clear description of what the feature does and why it matters to users]
-
-### Key Features
-- [Feature 1 - written in user-friendly terms]
-- [Feature 2 - focus on benefits]
-- [Feature 3 - avoid technical jargon]
-
----
-
-## Why This Matters
-
-[Explain the problem this solves with a real-world example, like:]
-
-**[Before scenario]**: [Description of the old/manual way]
-- [Pain point 1]
-- [Pain point 2]
-
-**[With this feature]**: [Description of the improved experience]
-
-## How it Works
-
-[Simple explanation of the feature's operation, avoiding implementation details]
-
-[Include visual representation if helpful - suggest where diagrams would help]
-
----
-
-## Configuration
-
-[User-friendly explanation of settings]
-
-1. **[Setting Name]**:
-   - **Setting**: `[Technical name if needed]`
-   - **Description**: [What this does in plain language]
-   - **Default**: [Default value and what it means]
-
-2. **[Setting Name]**:
-   - **Setting**: `[Technical name if needed]`
-   - **Description**: [What this does in plain language]
-   - **Default**: [Default value and what it means]
-
----
-
-## Benefits
-
-- **[Benefit 1]**: [Explanation of how this helps]
-- **[Benefit 2]**: [Explanation of how this helps]
-- **[Benefit 3]**: [Explanation of how this helps]
-
-## Common Questions
-
-**"[Common user question]"**
-- [Clear, helpful answer]
-- [Additional tips if relevant]
-
-**"[Common user question]"**
-- [Clear, helpful answer]
-- [Additional tips if relevant]
-
-**"[Common user question]"**
-- [Clear, helpful answer]
-- [Additional tips if relevant]
-
-## Need Help?
-
-If you run into issues:
-1. [First troubleshooting step]
-2. [Second troubleshooting step]
-3. [Where to get help - e.g., GitHub Issues link]
-    ]]></user_focused_template>
-
-    <comprehensive_template><![CDATA[
-# [Feature Name] Documentation
-
-## Table of Contents
-1. [Overview](#overview)
-2. [Quick Start](#quick-start)
-3. [Architecture](#architecture)
-4. [API Reference](#api-reference)
-5. [Configuration](#configuration)
-6. [User Guide](#user-guide)
-7. [Developer Guide](#developer-guide)
-8. [Administrator Guide](#administrator-guide)
-9. [Security](#security)
-10. [Performance](#performance)
-11. [Troubleshooting](#troubleshooting)
-12. [FAQ](#faq)
-13. [Changelog](#changelog)
-14. [References](#references)
-
-[Rest of comprehensive template remains available for technical documentation needs]
-    ]]></comprehensive_template>
-  </output_structure>
-
-  <user_friendly_patterns>
-    <before_after_examples>
-      <template><![CDATA[
-**Previously**: When Roo needed to understand your project, you'd see multiple requests like:
-- "Can I read `src/app.js`?" → You approve
-- "Now can I read `src/utils.js`?" → You approve
-- "And can I read `src/config.json`?" → You approve
-
-**Now**: Roo asks once to read all related files together, getting the full picture immediately.
-      ]]></template>
-    </before_after_examples>
-
-    <visual_separators>
-      <use_case>Between major sections</use_case>
-      <format>---</format>
-      <purpose>Improve readability and scanning</purpose>
-    </visual_separators>
-
-    <conversational_questions>
-      <template><![CDATA[
-## Common Questions
-
-**"Why would I want to disable this feature?"**
-- You're using a less capable AI model that works better with single files
-- You want more control over which files are accessed
-- You're working with very large files that might exceed memory limits
-
-**"What happens if some files are blocked?"**
-- Roo will read the files you approve and work with those
-- Files blocked by `.rooignore` will be automatically excluded
-- You can still approve/deny individual files in the batch
-      ]]></template>
-    </conversational_questions>
-
-    <practical_examples>
-      <guideline>Show real tool output or interface elements</guideline>
-      <guideline>Use actual file paths and settings names</guideline>
-      <guideline>Include common error messages and solutions</guideline>
-    </practical_examples>
-
-    <benefit_focused_lists>
-      <template><![CDATA[
-## Benefits
-
-- **Faster Results**: Get answers in one step instead of multiple back-and-forth approvals
-- **Better Context**: Roo understands relationships between files immediately
-- **Less Interruption**: Approve once and let Roo work uninterrupted
-      ]]></template>
-    </benefit_focused_lists>
-
-    <troubleshooting_section>
-      <template><![CDATA[
-## Troubleshooting
-
-**"Roo is asking for too many files at once"**
-- Lower the concurrent file limit in settings
-- You can still approve or deny individual files in the batch dialog
-
-**"The feature isn't working as expected"**
-- Check that "Enable concurrent file reads" is turned on in settings
-- Verify your concurrent file limit is set appropriately (default: 100)
-- Some AI models may not support this feature effectively
-      ]]></template>
-    </troubleshooting_section>
-
-    <help_section>
-      <template><![CDATA[
-## Need Help?
-
-If you run into issues:
-1. Check the [FAQ section](/faq) for common solutions
-2. Report problems on [GitHub Issues](https://github.com/RooCodeInc/Roo-Code/issues)
-3. Include what you were trying to do and any error messages
-      ]]></template>
-    </help_section>
-  </user_friendly_patterns>
-
-  <audience_specific_sections>
-    <audience type="end_users">
-      <focus_areas>
-        <area>Step-by-step tutorials with screenshots</area>
-        <area>Common use case examples</area>
-        <area>Troubleshooting guides for user errors</area>
-        <area>Feature benefits and value propositions</area>
-      </focus_areas>
-      <writing_style>
-        <guideline>Use simple, non-technical language</guideline>
-        <guideline>Include visual aids and examples</guideline>
-        <guideline>Focus on outcomes rather than implementation</guideline>
-        <guideline>Provide clear action steps</guideline>
-      </writing_style>
-    </audience>
-
-    <audience type="developers">
-      <focus_areas>
-        <area>Code examples and snippets</area>
-        <area>API specifications and contracts</area>
-        <area>Integration patterns and best practices</area>
-        <area>Performance optimization techniques</area>
-      </focus_areas>
-      <writing_style>
-        <guideline>Use precise technical terminology</guideline>
-        <guideline>Include code samples in multiple languages</guideline>
-        <guideline>Document edge cases and limitations</guideline>
-        <guideline>Provide debugging and testing guidance</guideline>
-      </writing_style>
-    </audience>
-
-    <audience type="administrators">
-      <focus_areas>
-        <area>Deployment and configuration procedures</area>
-        <area>Monitoring and maintenance tasks</area>
-        <area>Security hardening guidelines</area>
-        <area>Backup and disaster recovery</area>
-      </focus_areas>
-      <writing_style>
-        <guideline>Focus on operational aspects</guideline>
-        <guideline>Include command-line examples</guideline>
-        <guideline>Document automation opportunities</guideline>
-        <guideline>Emphasize security and compliance</guideline>
-      </writing_style>
-    </audience>
-
-    <audience type="stakeholders">
-      <focus_areas>
-        <area>Business value and ROI</area>
-        <area>Feature capabilities and limitations</area>
-        <area>Competitive advantages</area>
-        <area>Risk assessment and mitigation</area>
-      </focus_areas>
-      <writing_style>
-        <guideline>Use business-oriented language</guideline>
-        <guideline>Include metrics and KPIs</guideline>
-        <guideline>Focus on strategic benefits</guideline>
-        <guideline>Provide executive summaries</guideline>
-      </writing_style>
-    </audience>
-  </audience_specific_sections>
-
-  <metadata_patterns>
-    <version_info>
-      <template><![CDATA[
-### Version Compatibility Matrix
-| Component | Min Version | Recommended | Max Version | Notes |
-|-----------|-------------|-------------|-------------|-------|
-| [Component] | [version] | [version] | [version] | [notes] |
-      ]]></template>
-    </version_info>
-
-    <deprecation_notice>
-      <template><![CDATA[
-> ⚠️ **Deprecation Notice**
-> 
-> This feature/method is deprecated as of version [X.Y.Z].
-> - **Deprecated**: [date]
-> - **Removal Target**: [version/date]
-> - **Migration Path**: [See migration guide](#migration)
-> - **Replacement**: [new feature/method]
-      ]]></template>
-    </deprecation_notice>
-
-    <security_warning>
-      <template><![CDATA[
-> 🔒 **Security Consideration**
-> 
-> [Description of security concern]
-> - **Risk Level**: [High/Medium/Low]
-> - **Affected Versions**: [versions]
-> - **Mitigation**: [steps to address]
-> - **References**: [CVE/advisory links]
-      ]]></template>
-    </security_warning>
-
-    <performance_note>
-      <template><![CDATA[
-> ⚡ **Performance Impact**
-> 
-> [Description of performance consideration]
-> - **Impact**: [metrics/benchmarks]
-> - **Optimization**: [recommended 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,410 +0,0 @@
-<analysis_techniques>
-  <overview>
-    Comprehensive techniques for analyzing code and extracting documentation-worthy
-    information from various aspects of a codebase.
-  </overview>
-
-  <code_analysis_techniques>
-    <technique name="entry_point_analysis">
-      <description>
-        Identify and analyze main entry points to understand feature flow
-      </description>
-      <steps>
-        <step>Search for main functions, controllers, or route handlers</step>
-        <step>Trace execution flow from entry to exit</step>
-        <step>Map decision branches and conditionals</step>
-        <step>Document input validation and preprocessing</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 implementations
-      </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 parameters
-            - Query parameters
-            - Request body schema
-            - 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 types
-            - Resolvers
-            - Input types
-            - Return types
-            - Field arguments
-          </extraction>
-        </pattern>
-      </patterns>
-    </technique>
-
-    <technique name="dependency_mapping">
-      <description>
-        Map all dependencies and integration points
-      </description>
-      <analysis_points>
-        <point>Import statements and require calls</point>
-        <point>Package.json dependencies</point>
-        <point>External API calls</point>
-        <point>Database connections</point>
-        <point>Message queue integrations</point>
-        <point>File system 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>
-            - interface definitions
-            - type aliases
-            - class declarations
-            - enum definitions
-          </patterns>
-        </source>
-        <source type="database">
-          <patterns>
-            - Schema definitions
-            - Migration files
-            - Model definitions (ORM)
-            - SQL CREATE statements
-          </patterns>
-        </source>
-        <source type="validation">
-          <patterns>
-            - JSON Schema
-            - Joi/Yup schemas
-            - Validation decorators
-            - Custom validators
-          </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 and logic
-      </description>
-      <indicators>
-        <indicator>Complex conditional statements</indicator>
-        <indicator>Calculation functions</indicator>
-        <indicator>Validation rules</indicator>
-        <indicator>State machines</indicator>
-        <indicator>Business-specific constants</indicator>
-        <indicator>Domain-specific algorithms</indicator>
-      </indicators>
-      <documentation_focus>
-        <focus>Why the logic exists (business requirement)</focus>
-        <focus>When the logic applies (conditions)</focus>
-        <focus>What the logic does (transformation)</focus>
-        <focus>Edge cases and exceptions</focus>
-        <focus>Business impact of changes</focus>
-      </documentation_focus>
-    </technique>
-
-    <technique name="error_handling_analysis">
-      <description>
-        Document error handling strategies and recovery mechanisms
-      </description>
-      <analysis_areas>
-        <area>Try-catch blocks and error boundaries</area>
-        <area>Custom error classes and types</area>
-        <area>Error codes and messages</area>
-        <area>Logging strategies</area>
-        <area>Fallback mechanisms</area>
-        <area>Retry logic</area>
-        <area>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 potential vulnerabilities
-      </description>
-      <security_checks>
-        <check category="authentication">
-          <patterns>
-            - JWT implementation
-            - Session management
-            - OAuth flows
-            - API key handling
-          </patterns>
-        </check>
-        <check category="authorization">
-          <patterns>
-            - Role-based access control
-            - Permission checks
-            - Resource ownership validation
-            - Access control lists
-          </patterns>
-        </check>
-        <check category="data_protection">
-          <patterns>
-            - Encryption usage
-            - Hashing algorithms
-            - Sensitive data handling
-            - PII protection
-          </patterns>
-        </check>
-        <check category="input_validation">
-          <patterns>
-            - Input sanitization
-            - SQL injection prevention
-            - XSS protection
-            - CSRF tokens
-          </patterns>
-        </check>
-      </security_checks>
-    </technique>
-
-    <technique name="performance_analysis">
-      <description>
-        Identify performance characteristics and optimization opportunities
-      </description>
-      <analysis_points>
-        <point>Database query patterns (N+1 queries)</point>
-        <point>Caching strategies</point>
-        <point>Async/await 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 complexity of algorithms</metric>
-        <metric>Space complexity</metric>
-        <metric>Database query counts</metric>
-        <metric>API response times</metric>
-        <metric>Memory usage patterns</metric>
-        <metric>Concurrent request handling</metric>
-      </metrics_to_document>
-    </technique>
-
-    <technique name="test_coverage_analysis">
-      <description>
-        Analyze test coverage and quality
-      </description>
-      <test_types>
-        <type name="unit_tests">
-          <location>__tests__, *.test.ts, *.spec.ts</location>
-          <analysis>Function-level coverage</analysis>
-        </type>
-        <type name="integration_tests">
-          <location>integration/, e2e/</location>
-          <analysis>Feature workflow coverage</analysis>
-        </type>
-        <type name="api_tests">
-          <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 all configuration options and their impacts
-      </description>
-      <configuration_sources>
-        <source>Environment variables (.env files)</source>
-        <source>Configuration files (config.json, settings.yml)</source>
-        <source>Command-line arguments</source>
-        <source>Feature flags</source>
-        <source>Build-time constants</source>
-      </configuration_sources>
-      <documentation_requirements>
-        <requirement>Default values</requirement>
-        <requirement>Valid value ranges</requirement>
-        <requirement>Impact on behavior</requirement>
-        <requirement>Dependencies between configs</requirement>
-        <requirement>Security implications</requirement>
-      </documentation_requirements>
-    </technique>
-  </code_analysis_techniques>
-
-  <workflow_analysis>
-    <technique name="user_journey_mapping">
-      <description>
-        Map complete user workflows through the feature
-      </description>
-      <steps>
-        <step>Identify user entry points (UI, API, CLI)</step>
-        <step>Trace user actions through the system</step>
-        <step>Document decision points and branches</step>
-        <step>Map data transformations at each step</step>
-        <step>Identify exit points and outcomes</step>
-      </steps>
-      <deliverables>
-        <deliverable>User flow diagrams</deliverable>
-        <deliverable>Step-by-step procedures</deliverable>
-        <deliverable>Decision trees</deliverable>
-        <deliverable>State transition diagrams</deliverable>
-      </deliverables>
-    </technique>
-
-    <technique name="integration_flow_analysis">
-      <description>
-        Document how the feature integrates with other systems
-      </description>
-      <integration_types>
-        <type>Synchronous API calls</type>
-        <type>Asynchronous messaging</type>
-        <type>Event-driven interactions</type>
-        <type>Batch processing</type>
-        <type>Real-time streaming</type>
-      </integration_types>
-      <documentation_focus>
-        <focus>Integration protocols and formats</focus>
-        <focus>Authentication mechanisms</focus>
-        <focus>Error handling and retries</focus>
-        <focus>Data transformation requirements</focus>
-        <focus>SLA and performance expectations</focus>
-      </documentation_focus>
-    </technique>
-  </workflow_analysis>
-
-  <metadata_extraction>
-    <technique name="version_compatibility">
-      <sources>
-        <source>Package.json engines field</source>
-        <source>README compatibility sections</source>
-        <source>Migration guides</source>
-        <source>Breaking change documentation</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 annotations</indicator>
-        <indicator>TODO: deprecate comments</indicator>
-        <indicator>Legacy code markers</indicator>
-        <indicator>Migration warnings</indicator>
-      </indicators>
-      <documentation_requirements>
-        <requirement>Deprecation date</requirement>
-        <requirement>Removal timeline</requirement>
-        <requirement>Migration path</requirement>
-        <requirement>Alternative solutions</requirement>
-      </documentation_requirements>
-    </technique>
-  </metadata_extraction>
-
-  <quality_indicators>
-    <indicator name="documentation_completeness">
-      <checks>
-        <check>All public APIs documented</check>
-        <check>Examples provided for complex features</check>
-        <check>Error scenarios covered</check>
-        <check>Configuration options explained</check>
-        <check>Security considerations addressed</check>
-      </checks>
-    </indicator>
-
-    <indicator name="code_quality_metrics">
-      <metrics>
-        <metric>Cyclomatic complexity</metric>
-        <metric>Code duplication</metric>
-        <metric>Test coverage percentage</metric>
-        <metric>Documentation coverage</metric>
-        <metric>Technical debt indicators</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,398 +0,0 @@
-<tool_usage_guide>
-  <overview>
-    Specific guidance on using tools effectively for comprehensive documentation extraction,
-    with emphasis on gathering complete information across all aspects of a feature.
-  </overview>
-
-  <tool_sequence>
-    <priority level="1">
-      <tool>codebase_search</tool>
-      <purpose>Initial discovery of feature-related code</purpose>
-      <usage_patterns>
-        <pattern>
-          <scenario>Finding feature entry points</scenario>
-          <example><![CDATA[
-<codebase_search>
-<query>authentication login user session JWT token</query>
-</codebase_search>
-          ]]></example>
-        </pattern>
-        <pattern>
-          <scenario>Locating business logic</scenario>
-          <example><![CDATA[
-<codebase_search>
-<query>calculate pricing discount tax invoice billing</query>
-</codebase_search>
-          ]]></example>
-        </pattern>
-        <pattern>
-          <scenario>Finding 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>Understanding code structure and organization</purpose>
-      <best_practices>
-        <practice>Use on directories containing core feature logic</practice>
-        <practice>Analyze both implementation and test directories</practice>
-        <practice>Look for patterns in naming conventions</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>Deep analysis of specific implementations</purpose>
-      <strategy>
-        <step>Read main feature files first</step>
-        <step>Follow imports to understand dependencies</step>
-        <step>Read test files to understand expected behavior</step>
-        <step>Examine configuration 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>Finding specific patterns and implementations</purpose>
-      <use_cases>
-        <use_case>
-          <description>Find all 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 patterns</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 configuration 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 the final documentation file when generating new documentation from scratch.</purpose>
-      <note>This tool is NOT used when reviewing a user-provided document section. In that scenario, feedback is provided directly in the chat.</note>
-      <file_naming>DOCS-TEMP-[feature-name].md</file_naming>
-      <best_practices>
-        <practice>Use descriptive feature names in filename</practice>
-        <practice>Include table of contents with anchors</practice>
-        <practice>Use consistent markdown formatting</practice>
-        <practice>Include code examples with syntax highlighting</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 requirements when multiple interpretations exist</purpose>
-      <when_to_use>
-        <scenario>Multiple features with similar names exist</scenario>
-        <scenario>Documentation depth needs clarification</scenario>
-        <scenario>Target audience priorities need definition</scenario>
-      </when_to_use>
-      <examples>
-        <example><![CDATA[
-<ask_followup_question>
-<question>Which aspects of the authentication system should I focus on?</question>
-<follow_up>
-<suggest>Complete authentication flow including JWT tokens, session management, and OAuth integration</suggest>
-<suggest>Only the JWT token implementation and validation</suggest>
-<suggest>OAuth2 integration with external providers</suggest>
-<suggest>Password reset and account recovery workflows</suggest>
-</follow_up>
-</ask_followup_question>
-        ]]></example>
-        <example><![CDATA[
-<ask_followup_question>
-<question>What level of technical detail should the documentation include?</question>
-<follow_up>
-<suggest>High-level overview suitable for all audiences</suggest>
-<suggest>Detailed technical implementation for developers</suggest>
-<suggest>API reference with code examples</suggest>
-<suggest>Complete coverage for all audience types</suggest>
-</follow_up>
-</ask_followup_question>
-        ]]></example>
-      </examples>
-    </tool>
-  </documentation_generation_tools>
-
-  <analysis_strategies>
-    <strategy name="comprehensive_file_discovery">
-      <description>
-        Systematic approach to finding 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 core functionality</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>Locate configuration 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 understand all dependencies
-      </description>
-      <process>
-        <step>Read main feature file</step>
-        <step>Extract all imports</step>
-        <step>Read each imported file</step>
-        <step>Recursively analyze their 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 complete API documentation from code
-      </description>
-      <extraction_points>
-        <point>Route definitions</point>
-        <point>Request/response schemas</point>
-        <point>Authentication requirements</point>
-        <point>Rate limiting rules</point>
-        <point>Error responses</point>
-      </extraction_points>
-      <tools_sequence>
-        <sequence>
-          <step>Find all route files</step>
-          <step>Extract route definitions</step>
-          <step>Find associated 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 understand expected behavior
-      </description>
-      <benefits>
-        <benefit>Tests show real usage examples</benefit>
-        <benefit>Test descriptions explain functionality</benefit>
-        <benefit>Edge cases are often tested</benefit>
-        <benefit>Expected outputs are documented</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="structured_sections">
-      <description>Organize output for easy navigation</description>
-      <structure>
-        - Clear hierarchy with numbered sections
-        - Consistent heading levels
-        - Table of contents with links
-        - Cross-references between sections
-      </structure>
-    </guideline>
-
-    <guideline name="code_examples">
-      <description>Include relevant code examples</description>
-      <best_practices>
-        - Use syntax highlighting
-        - Show both request and response
-        - Include error cases
-        - Provide language-specific examples
-      </best_practices>
-    </guideline>
-
-    <guideline name="visual_aids">
-      <description>Suggest where diagrams would help</description>
-      <diagram_types>
-        - Architecture diagrams
-        - Sequence diagrams
-        - Data flow diagrams
-        - State machines
-      </diagram_types>
-    </guideline>
-
-    <guideline name="metadata_inclusion">
-      <description>Always include important metadata</description>
-      <required_metadata>
-        - Version compatibility
-        - Last updated date
-        - Feature status (stable/beta/deprecated)
-        - Performance characteristics
-        - Security considerations
-      </required_metadata>
-    </guideline>
-  </output_optimization>
-</tool_usage_guide>

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

@@ -1,943 +0,0 @@
-<complete_extraction_examples>
-  <overview>
-    Complete examples demonstrating the full documentation extraction workflow
-    for different types of features and components.
-  </overview>
-
-  <example name="authentication_system_extraction">
-    <scenario>
-      Extract comprehensive documentation for a JWT-based authentication system
-      including login, logout, token refresh, and role-based access control.
-    </scenario>
-
-    <workflow>
-      <step number="1">
-        <description>Initial feature discovery</description>
-        <tool_use><![CDATA[
-<codebase_search>
-<query>authentication JWT login logout token refresh auth middleware</query>
-</codebase_search>
-        ]]></tool_use>
-        <expected_findings>
-          - Auth controller files
-          - JWT service implementations
-          - Middleware functions
-          - User model with auth fields
-          - Auth route definitions
-        </expected_findings>
-      </step>
-
-      <step number="2">
-        <description>Analyze authentication structure</description>
-        <tool_use><![CDATA[
-<list_code_definition_names>
-<path>src/auth</path>
-</list_code_definition_names>
-        ]]></tool_use>
-        <analysis>
-          - Identify main classes and functions
-          - Map authentication flow
-          - Find token generation/validation logic
-        </analysis>
-      </step>
-
-      <step number="3">
-        <description>Read core implementation 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>Document 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 measures</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 documentation</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>Start with semantic search to find all related files</takeaway>
-      <takeaway>Read multiple files together for context</takeaway>
-      <takeaway>Extract API documentation from route definitions</takeaway>
-      <takeaway>Use tests to understand expected behavior</takeaway>
-      <takeaway>Document security measures comprehensively</takeaway>
-      <takeaway>Include troubleshooting based on common errors</takeaway>
-    </key_takeaways>
-  </example>
-
-  <example name="database_schema_extraction">
-    <scenario>
-      Extract documentation for database models, relationships, migrations,
-      and data access patterns.
-    </scenario>
-
-    <workflow>
-      <step number="1">
-        <description>Find database-related 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 model definitions</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,323 +0,0 @@
-<communication_guidelines>
-  <overview>
-    Guidelines for communicating with users and formatting documentation output
-    during the extraction process.
-  </overview>
-
-  <user_interaction>
-    <initial_understanding>
-      <principle>Users will specify what they want documented in their initial message</principle>
-      <principle>Start working immediately based on their request</principle>
-      <principle>Only ask for clarification if genuinely ambiguous</principle>
-    </initial_understanding>
-
-    <clarification_only_when_needed>
-      <when_to_ask>
-        <scenario>Multiple features with identical names found</scenario>
-        <scenario>Request is genuinely ambiguous (rare)</scenario>
-        <scenario>User explicitly asks for options</scenario>
-      </when_to_ask>
-      
-      <question_example><![CDATA[
-<ask_followup_question>
-<question>I found multiple authentication systems. Which one should I document?</question>
-<follow_up>
-<suggest>JWT-based authentication system (src/auth/jwt/*)</suggest>
-<suggest>OAuth2 integration (src/auth/oauth/*)</suggest>
-<suggest>Basic authentication middleware (src/middleware/basic-auth.ts)</suggest>
-<suggest>All authentication features comprehensively</suggest>
-</follow_up>
-</ask_followup_question>
-      ]]></question_example>
-    </clarification_only_when_needed>
-
-    <progress_updates>
-      <when_to_update>
-        <trigger>Starting major analysis phase</trigger>
-        <trigger>Completed significant extraction</trigger>
-        <trigger>Found unexpected complexity</trigger>
-        <trigger>Discovered related features</trigger>
-      </when_to_update>
-      
-      <update_format>
-        <template>
-          Analyzing [component/feature]...
-          - Found [X] files related to [feature]
-          - Identified [Y] API endpoints
-          - Discovered [Z] configuration options
-        </template>
-      </update_format>
-    </progress_updates>
-
-    <findings_communication>
-      <important_discoveries>
-        <discovery type="security_issue">
-          Alert user to potential security concerns found during analysis
-        </discovery>
-        <discovery type="deprecated_code">
-          Note deprecated features that need migration documentation
-        </discovery>
-        <discovery type="missing_documentation">
-          Highlight areas where code lacks inline documentation
-        </discovery>
-        <discovery type="complex_dependencies">
-          Warn about intricate dependency chains affecting the feature
-        </discovery>
-      </important_discoveries>
-      <review_findings>
-       <template><![CDATA[
-I have reviewed the documentation section provided. Here are my recommendations for improvement:
-
-**Overall Assessment**: [Brief summary of the document's quality]
-
-**Recommendations for Improvement**:
-
-*   **Critical Inaccuracies**:
-   *   [Inaccuracy 1]: The documentation states [X], but the code implements [Y].
-   *   [Inaccuracy 2]: ...
-
-*   **Major Omissions**:
-   *   The documentation is missing information about [Missing Feature/Concept].
-   *   ...
-
-*   **Suggestions for Clarity**:
-   *   The section on [Topic] could be clarified by [Suggestion].
-   *   ...
-
-This feedback can be copied and pasted for your documentation team.
-       ]]></template>
-      </review_findings>
-    </findings_communication>
-  </user_interaction>
-
-  <output_formatting>
-    <markdown_standards>
-      <heading_hierarchy>
-        <rule>Use # for main title only</rule>
-        <rule>Use ## for major sections</rule>
-        <rule>Use ### for subsections</rule>
-        <rule>Use #### sparingly for minor subsections</rule>
-        <rule>Never skip heading levels</rule>
-      </heading_hierarchy>
-
-      <code_blocks>
-        <rule>Always specify language for syntax highlighting</rule>
-        <rule>Use appropriate language identifiers (typescript, javascript, json, yaml, bash)</rule>
-        <rule>Include file paths as comments when 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 configurations</rule>
-        <rule>Include headers with proper alignment</rule>
-        <rule>Keep cell content concise</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 bullet points for unordered lists</rule>
-        <rule>Use numbers for sequential steps</rule>
-        <rule>Nest lists with proper indentation</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</rule>
-        <rule>Test all internal links</rule>
-      </internal_links>
-
-      <external_links>
-        <format>[Link text](https://example.com)</format>
-        <rule>Use HTTPS when available</rule>
-        <rule>Link to official documentation</rule>
-      </external_links>
-
-      <file_references>
-        <format>`path/to/file.ts`</format>
-        <rule>Use relative paths from project root</rule>
-        <rule>Use backticks for inline file references</rule>
-      </file_references>
-    </cross_references>
-
-    <special_sections>
-      <alerts>
-        <type name="warning">
-          <format>> ⚠️ **Warning**: [message]</format>
-          <use_for>Security concerns, breaking changes, deprecations</use_for>
-        </type>
-        <type name="note">
-          <format>> 📝 **Note**: [message]</format>
-          <use_for>Important information, clarifications</use_for>
-        </type>
-        <type name="tip">
-          <format>> 💡 **Tip**: [message]</format>
-          <use_for>Best practices, optimization suggestions</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_principles>
-      <principle>Be conversational and approachable</principle>
-      <principle>Use active voice and "you" to address the reader</principle>
-      <principle>Lead with benefits, not features</principle>
-      <principle>Use concrete examples and scenarios</principle>
-      <principle>Keep paragraphs short and scannable</principle>
-      <principle>Avoid unnecessary technical details</principle>
-    </general_principles>
-
-    <user_focused_tone>
-      <guideline>Write as if explaining to a colleague who isn't technical</guideline>
-      <guideline>Use analogies and comparisons to familiar concepts</guideline>
-      <guideline>Focus on "what" and "why" before "how"</guideline>
-      <guideline>Include practical examples users can relate to</guideline>
-      <guideline>Address common concerns and questions directly</guideline>
-    </user_focused_tone>
-
-    <audience_specific_tone>
-      <audience type="default_user">
-        <tone>Friendly, helpful, encouraging</tone>
-        <vocabulary>Plain language, minimal jargon</vocabulary>
-        <examples>Real-world scenarios, before/after comparisons</examples>
-        <structure>Problem → Solution → Benefits → How to use</structure>
-      </audience>
-
-      <audience type="developers">
-        <tone>Technical when needed, but still approachable</tone>
-        <vocabulary>Use standard programming terminology</vocabulary>
-        <examples>Include code snippets and implementation details</examples>
-      </audience>
-
-      <audience type="end_users">
-        <tone>Friendly, instructional, step-by-step</tone>
-        <vocabulary>Avoid technical jargon, explain concepts simply</vocabulary>
-        <examples>Use screenshots and real-world scenarios</examples>
-      </audience>
-
-      <audience type="administrators">
-        <tone>Professional, operational focus</tone>
-        <vocabulary>Use IT/DevOps terminology</vocabulary>
-        <examples>Include command-line examples and configurations</examples>
-      </audience>
-
-      <audience type="stakeholders">
-        <tone>Business-oriented, value-focused</tone>
-        <vocabulary>Use business terminology, avoid implementation details</vocabulary>
-        <examples>Include metrics, ROI, and business benefits</examples>
-      </audience>
-    </audience_specific_tone>
-  </documentation_tone>
-
-  <completion_message>
-    <structure>
-      <element>Summary of what was documented</element>
-      <element>Key findings or insights</element>
-      <element>File location and name</element>
-      <element>Suggestions for next steps (if applicable)</element>
-    </structure>
-
-    <example><![CDATA[
-I've completed the comprehensive documentation extraction for the authentication system.
-
-**Documentation Generated**: `DOCS-TEMP-authentication-system.md`
-
-**Key Findings**:
-- The system uses JWT tokens with refresh token rotation
-- Found 5 main API endpoints for authentication
-- Identified 12 configuration options
-- Documented security measures including bcrypt hashing and rate limiting
-- Included troubleshooting for 3 common issues
-
-**Coverage**:
-- ✅ Technical implementation details
-- ✅ API reference with examples
-- ✅ Configuration guide
-- ✅ Security considerations
-- ✅ User and developer guides
-- ✅ Troubleshooting section
-
-The documentation is structured for multiple audiences and includes all requested metadata, version information, and cross-references.
-    ]]></example>
-    <example_review><![CDATA[
-I have completed the review of the provided documentation section.
-
-**Action Taken**:
-- Analyzed the provided text against the current codebase for accuracy.
-- Identified several areas for improvement and outlined them as a recommendation.
-
-**Next Steps**:
-- The detailed feedback has been provided in the chat. You can copy and paste it to your documentation team. No files were created.
-    ]]></example_review>
-  </completion_message>
-
-  <error_handling>
-    <common_scenarios>
-      <scenario type="feature_not_found">
-        <response>
-          I couldn't find a feature matching "[feature name]". Here are some similar features I found:
-          - [List similar features]
-          Would you like me to document one of these instead?
-        </response>
-      </scenario>
-
-      <scenario type="insufficient_code_documentation">
-        <response>
-          The code for [feature] has limited inline documentation. I'll extract what I can from:
-          - Code structure and naming
-          - Test files
-          - Related documentation
-          - Usage patterns
-        </response>
-      </scenario>
-
-      <scenario type="complex_feature">
-        <response>
-          This feature is quite complex with [X] components. Would you like me to:
-          - Document everything comprehensively (may result in a large document)
-          - Focus on the core functionality
-          - Split into multiple documentation files
-        </response>
-      </scenario>
-    </common_scenarios>
-  </error_handling>
-
-  <quality_checks>
-    <before_completion>
-      <check>All sections have content (no placeholders)</check>
-      <check>Code examples are syntactically correct</check>
-      <check>Links and cross-references work</check>
-      <check>Tables are properly formatted</check>
-      <check>Version information is included</check>
-      <check>File naming follows convention</check>
-    </before_completion>
-  </quality_checks>
-</communication_guidelines>

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

@@ -1,254 +0,0 @@
-<user_friendly_examples>
-  <overview>
-    Examples and patterns for creating documentation that prioritizes user experience
-    and practical understanding over technical completeness.
-  </overview>
-
-  <writing_principles>
-    <principle name="lead_with_benefits">
-      <bad>The concurrent file read feature uses parallel processing to read multiple files.</bad>
-      <good>Read multiple files at once, saving time and reducing interruptions.</good>
-    </principle>
-
-    <principle name="use_scenarios">
-      <bad>This feature improves efficiency.</bad>
-      <good>Instead of approving 10 file reads one by one, approve them all at once and get your answer faster.</good>
-    </principle>
-
-    <principle name="avoid_implementation_details">
-      <bad>The feature uses a thread pool with configurable concurrency limits to process file I/O operations.</bad>
-      <good>Roo can read up to 100 files at once (you can change this limit in settings).</good>
-    </principle>
-
-    <principle name="conversational_tone">
-      <bad>Users must configure the concurrent file read limit parameter.</bad>
-      <good>You can adjust how many files Roo reads at once in the settings.</good>
-    </principle>
-  </writing_principles>
-
-  <structure_examples>
-    <example name="feature_introduction">
-      <template><![CDATA[
-# [Feature Name]
-
-[One-sentence description of what it does for the user]
-
-### Key Features
-- [Benefit 1 - what users can do]
-- [Benefit 2 - what problem it solves]  
-- [Benefit 3 - how it makes life easier]
-
----
-      ]]></template>
-    </example>
-
-    <example name="why_it_matters">
-      <template><![CDATA[
-## Why This Matters
-
-**Without [feature]**: [Description of the painful old way]
-- [Specific pain point]
-- [Another pain point]
-- [Time/effort wasted]
-
-**With [feature]**: [Description of the better experience]
-      ]]></template>
-    </example>
-
-    <example name="configuration_section">
-      <template><![CDATA[
-## Configuration
-
-You can customize this feature in Roo's settings:
-
-1. **[Human-friendly setting name]**
-   - What it does: [Plain language explanation]
-   - Default: [Default value] (this works well for most users)
-   - When to change: [Specific scenarios when users might want to adjust this]
-
-2. **[Another setting]**
-   - What it does: [Plain language explanation]
-   - Default: [Default value]
-   - Try changing this if: [Specific use case]
-      ]]></template>
-    </example>
-
-    <example name="common_questions">
-      <template><![CDATA[
-## Common Questions
-
-**"[Actual question users ask]"**
-[Direct, helpful answer]
-[Optional: Additional tip or context]
-
-**"[Another real question]"**
-[Answer that addresses the concern]
-[Optional: Link to more info]
-
-**"[Technical question simplified]"**
-[Non-technical explanation]
-[Optional: "For developers:" with technical details]
-      ]]></template>
-    </example>
-
-    <example name="troubleshooting">
-      <template><![CDATA[
-## Troubleshooting
-
-### [Problem symptom users would recognize]
-**What's happening**: [Brief explanation]
-**Quick fix**: [Immediate solution]
-**If that doesn't work**: [Alternative solution]
-
-### [Another common issue]
-**You might see this when**: [Scenario]
-**Solution**: 
-1. [First step]
-2. [Second step]
-3. [If needed, third step]
-      ]]></template>
-    </example>
-
-    <example name="help_section">
-      <template><![CDATA[
-## Need Help?
-
-Still having issues? Here's how to get help:
-
-1. **Check our FAQ**: [Link to FAQ] - answers to common questions
-2. **Report a bug**: [GitHub Issues link] - we typically respond within 24 hours
-3. **Join the community**: [Discord/Forum link] - get help from other users
-
-When reporting an issue, please include:
-- What you were trying to do
-- What happened instead
-- Any error messages you saw
-      ]]></template>
-    </example>
-  </structure_examples>
-
-  <tone_examples>
-    <friendly_explanations>
-      <example context="explaining a limit">
-        <technical>The system imposes a hard limit of 100 concurrent operations.</technical>
-        <friendly>Roo can handle up to 100 files at once - more than enough for most projects!</friendly>
-      </example>
-
-      <example context="describing an error">
-        <technical>Error: Maximum concurrency threshold exceeded.</technical>
-        <friendly>Oops! That's too many files at once. Try lowering the file limit in settings.</friendly>
-      </example>
-
-      <example context="explaining a benefit">
-        <technical>Reduces API call overhead through request batching.</technical>
-        <friendly>Get answers faster by reading all the files Roo needs in one go.</friendly>
-      </example>
-    </friendly_explanations>
-
-    <visual_elements>
-      <use_emojis_sparingly>
-        <when>Error messages: ⚠️</when>
-        <when>Tips: 💡</when>
-        <when>Important notes: 📝</when>
-        <when>Security: 🔒</when>
-      </use_emojis_sparingly>
-
-      <use_formatting>
-        <bold>For emphasis on key points</bold>
-        <code>For settings names, file paths, or commands</code>
-        <blockquotes>For important callouts or warnings</blockquotes>
-      </use_formatting>
-    </visual_elements>
-  </tone_examples>
-
-  <real_world_example>
-    <title>Concurrent File Reads Documentation</title>
-    <content><![CDATA[
-# Concurrent File Reads
-
-The Concurrent File Reads feature allows Roo to read multiple files from your workspace in a single step. This significantly improves efficiency when working on tasks that require context from several files.
-
-### Key Features
-- Read up to 100 files in a single request
-- Enabled by default for a faster, more streamlined workflow
-- Configurable to match your preferences and system capabilities
-
----
-
-## Why This Matters
-
-**Previously**: When Roo needed to understand your project, you'd see multiple requests like:
-- "Can I read `src/app.js`?" → You approve
-- "Now can I read `src/utils.js`?" → You approve
-- "And can I read `src/config.json`?" → You approve
-
-**With concurrent file reads**: Roo asks once to read all related files together, getting the full picture immediately and providing better assistance faster.
-
-## How it Works
-
-When you ask Roo to perform a task that involves multiple files, it will automatically identify the relevant files and read them together. This is especially useful for:
-
-- Understanding components split across multiple files
-- Refactoring code with dependencies
-- Answering questions that require broad project context
-
-The [`read_file`](/advanced-usage/available-tools/read-file) tool automatically accepts multiple files in a single request.
-
----
-
-## Configuration
-
-You can customize this feature in Roo's settings:
-
-1. **Enable/Disable Concurrent File Reads**
-   - What it does: Controls whether Roo can read multiple files at once
-   - Default: Enabled (recommended for most users)
-   - When to disable: If using a less capable AI model or wanting more control
-
-2. **Concurrent File Reads Limit**
-   - What it does: Sets the maximum number of files Roo can read at once
-   - Default: 100 files
-   - When to adjust: Lower if you have memory constraints, raise for very large projects
-
----
-
-## Benefits
-
-- **Faster Results**: Get comprehensive answers without multiple approval steps
-- **Better Context**: Roo understands file relationships immediately
-- **Less Interruption**: Approve once and continue working while Roo analyzes
-
-## Common Questions
-
-**"Roo is asking for too many files at once"**
-- Lower the concurrent file limit in settings
-- You can still approve or deny individual files in the batch dialog
-
-**"Some files were denied but others approved"**
-- This is normal - Roo works with the files you approve
-- Files might be blocked by your `.rooignore` settings
-
-**"Will this use more memory?"**
-- Yes, but the impact is usually minimal
-- If you notice slowdowns, try reducing the file limit
-
-## Need Help?
-
-If you run into issues:
-1. Check the [FAQ section](/faq) for common solutions
-2. Report problems on [GitHub Issues](https://github.com/RooCodeInc/Roo-Code/issues)
-3. Include what you were trying to do and any error messages
-    ]]></content>
-  </real_world_example>
-
-  <checklist>
-    <item>Does it start with benefits, not features?</item>
-    <item>Are technical terms explained or avoided?</item>
-    <item>Does it use "you" to address the reader?</item>
-    <item>Are there practical examples or scenarios?</item>
-    <item>Is the tone conversational and friendly?</item>
-    <item>Are sections short and scannable?</item>
-    <item>Does it answer common user questions?</item>
-    <item>Is help easily 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/1_Workflow.xml

@@ -1,62 +1,41 @@
 <workflow>
   <step number="1">
-    <name>Determine Workflow Type and Retrieve Context</name>
+    <name>Retrieve Issue Context</name>
     <instructions>
-      First, determine what type of work is needed. The user will provide either:
-      - An issue number/URL (e.g., "#123" or GitHub issue URL) - for new implementation
-      - A PR number/URL (e.g., "#456" or GitHub PR URL) - for addressing review feedback
-      - A description of changes needed for an existing PR
+      The user should provide a full GitHub issue URL (e.g., "https://github.com/owner/repo/issues/123") for implementation.
       
-      For Issue-based workflow:
-      Extract the issue number and retrieve it:
+      Parse the URL to extract:
+      - Owner (organization or username)
+      - Repository name
+      - Issue number
       
-      <use_mcp_tool>
-      <server_name>github</server_name>
-      <tool_name>get_issue</tool_name>
-      <arguments>
-      {
-        "owner": "RooCodeInc",
-        "repo": "Roo-Code",
-        "issue_number": [extracted number]
-      }
-      </arguments>
-      </use_mcp_tool>
+      For example, from https://github.com/RooCodeInc/Roo-Code/issues/123:
+      - Owner: RooCodeInc
+      - Repo: Roo-Code
+      - Issue: 123
       
-      For PR Review workflow:
-      Extract the PR number and retrieve it:
+      Then retrieve the issue:
       
-      <use_mcp_tool>
-      <server_name>github</server_name>
-      <tool_name>get_pull_request</tool_name>
-      <arguments>
-      {
-        "owner": "RooCodeInc",
-        "repo": "Roo-Code",
-        "pull_number": [extracted number]
-      }
-      </arguments>
-      </use_mcp_tool>
+      <execute_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>
       
-      Then get PR review comments:
+      If the command fails with an authentication error (e.g., "gh: Not authenticated" or "HTTP 401"), ask the 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>
       
-      <use_mcp_tool>
-      <server_name>github</server_name>
-      <tool_name>get_pull_request_reviews</tool_name>
-      <arguments>
-      {
-        "owner": "RooCodeInc",
-        "repo": "Roo-Code",
-        "pull_number": [extracted number]
-      }
-      </arguments>
-      </use_mcp_tool>
+      Analyze the issue to determine:
+      1. All requirements and acceptance criteria
+      2. Technical details mentioned
+      3. Any linked issues or discussions
       
-      Analyze the context to determine:
-      1. Type of work (new issue implementation vs PR feedback)
-      2. All requirements and acceptance criteria
-      3. Specific changes requested (for PR reviews)
-      4. Technical details mentioned
-      5. Any linked issues or discussions
+      Note: For PR review feedback, users should use the dedicated pr-fixer mode instead.
     </instructions>
   </step>
 
@@ -69,23 +48,20 @@
       - Community suggestions
       - Any decisions or changes to requirements
       
-      <use_mcp_tool>
-      <server_name>github</server_name>
-      <tool_name>get_issue_comments</tool_name>
-      <arguments>
-      {
-        "owner": "RooCodeInc",
-        "repo": "Roo-Code",
-        "issue_number": [issue number]
-      }
-      </arguments>
-      </use_mcp_tool>
+      <execute_command>
+      <command>gh api repos/[owner]/[repo]/issues/[issue-number]/comments --paginate --jq '.[].body'</command>
+      </execute_command>
       
       Also check for:
       1. Related issues mentioned in the body or comments
       2. Linked pull requests
       3. Referenced discussions
       
+      If related PRs are mentioned, view them:
+      <execute_command>
+      <command>gh pr view [pr-number] --repo [owner]/[repo]</command>
+      </execute_command>
+      
       Document all requirements and constraints found.
     </instructions>
   </step>
@@ -109,16 +85,9 @@
       - Identify patterns to follow
       - Find related components and utilities
       
-      For PR Reviews:
-      - Search for files mentioned in review comments
-      - Find related files that use similar patterns
-      - Locate test files for modified functionality
-      - Identify files that import/depend on changed code
-      
       Example searches based on issue type:
       - Bug: Search for error messages, function names, component names
       - Feature: Search for similar functionality, API endpoints, UI components
-      - PR Review: Search for patterns mentioned in feedback
       
       CRITICAL: Always read multiple related files together to understand:
       - Current code patterns and conventions
@@ -133,10 +102,15 @@
       - read_file to examine specific implementations (read multiple files at once)
       - search_files for specific patterns or error messages
       
-      Also use GitHub tools:
-      - list_commits to see recent changes to affected files
-      - get_commit to understand specific changes
-      - list_pull_requests to find related PRs
+      Also use GitHub CLI to check recent changes:
+      <execute_command>
+      <command>gh api repos/[owner]/[repo]/commits?path=[file-path]&per_page=10 --jq '.[].sha + " " + .[].commit.message'</command>
+      </execute_command>
+      
+      Search for related PRs:
+      <execute_command>
+      <command>gh pr list --repo [owner]/[repo] --search "[relevant search terms]" --limit 10</command>
+      </execute_command>
       
       Document:
       - All files that need modification
@@ -217,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
@@ -252,11 +225,70 @@
       - [ ] No linting errors
       
       If any criteria fail, return to implementation step.
-    </instructions>
-  </step>
-
-  <step number="7">
-    <name>Run Tests and Checks</name>
+     </instructions>
+   </step>
+ 
+   <step number="7">
+     <name>Check for Translation Requirements</name>
+     <instructions>
+       After implementing changes, analyze if any translations are required:
+       
+       Translation is needed if the implementation includes:
+       1. New user-facing text strings in UI components
+       2. New error messages or user notifications
+       3. Updated documentation files that need localization
+       4. New command descriptions or tooltips
+       5. Changes to announcement files or release notes
+       6. New configuration options with user-visible descriptions
+       
+       Check for these patterns:
+       - Hard-coded strings in React components (.tsx/.jsx files)
+       - New entries needed in i18n JSON files
+       - Updated markdown documentation files
+       - New VSCode command contributions
+       - Changes to user-facing configuration schemas
+       
+       If translations are required:
+       
+       <new_task>
+       <mode>translate</mode>
+       <message>Translation needed for issue #[issue-number] implementation.
+ 
+       The following changes require translation into all supported languages:
+ 
+       **Files with new/updated user-facing content:**
+       - [List specific files and what content needs translation]
+       - [Include context about where the strings appear]
+       - [Note any special formatting or constraints]
+ 
+       **Translation scope:**
+       - [Specify if it's new strings, updated strings, or both]
+       - [List specific JSON keys that need attention]
+       - [Note any markdown files that need localization]
+ 
+       **Context for translators:**
+       - [Explain the feature/fix being implemented]
+       - [Provide context about how the text is used]
+       - [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.
+       
+       If no translations are required, continue to the next step.
+     </instructions>
+   </step>
+ 
+   <step number="8">
+     <name>Run Tests and Checks</name>
     <instructions>
       Run comprehensive tests to ensure quality:
       
@@ -289,7 +321,7 @@
     </instructions>
   </step>
 
-  <step number="8">
+  <step number="9">
     <name>Prepare Summary</name>
     <instructions>
       Create a comprehensive summary of the implementation:
@@ -341,7 +373,7 @@
     </instructions>
   </step>
 
-  <step number="9">
+  <step number="10">
     <name>Prepare for Pull Request</name>
     <instructions>
       If user wants to create a pull request, prepare everything needed:
@@ -412,13 +444,13 @@
 
       **Branch:** [branch-name]
       **Title:** [PR title]
-      **Target:** RooCodeInc/Roo-Code (main branch)
+      **Target:** [owner]/[repo] (main branch)
 
       Here's the PR description:
 
       [Show prepared PR description]
 
-      Would you like me to create this pull request to RooCodeInc/Roo-Code?</question>
+      Would you like me to create this pull request to [owner]/[repo]?</question>
       <follow_up>
       <suggest>Yes, create the pull request</suggest>
       <suggest>Let me review the PR description first</suggest>
@@ -429,49 +461,31 @@
     </instructions>
   </step>
 
-  <step number="10">
+  <step number="11">
     <name>Create Pull Request</name>
     <instructions>
-      Once user approves, create the pull request using GitHub MCP:
+      Once user approves, create the pull request using GitHub CLI:
       
-      <use_mcp_tool>
-      <server_name>github</server_name>
-      <tool_name>create_pull_request</tool_name>
-      <arguments>
-      {
-        "owner": "RooCodeInc",
-        "repo": "Roo-Code",
-        "title": "[Type]: [Brief description] (#[issue-number])",
-        "head": "[user-fork-owner]:[branch-name]",
-        "base": "main",
-        "body": "[Complete PR description from step 9]",
-        "draft": false,
-        "maintainer_can_modify": true
-      }
-      </arguments>
-      </use_mcp_tool>
+      If the user doesn't have push access to [owner]/[repo], fork the repository:
+      <execute_command>
+      <command>gh repo fork [owner]/[repo] --clone</command>
+      </execute_command>
       
-      Note: The "head" parameter format depends on where the branch exists:
-      - If user has push access: "branch-name"
-      - If working from a fork: "username:branch-name"
+      Create the pull request:
+      <execute_command>
+      <command>gh pr create --repo [owner]/[repo] --base main --title "[Type]: [Brief description] (#[issue-number])" --body "[Complete PR description from step 10]" --maintainer-can-modify</command>
+      </execute_command>
+      
+      The gh CLI will automatically handle the fork workflow if needed.
       
       After PR creation:
-      1. Capture the PR number and URL from the response
+      1. Capture the PR number and URL from the command output
       2. Link the PR to the issue by commenting on the issue
       3. Inform the user of the successful creation
       
-      <use_mcp_tool>
-      <server_name>github</server_name>
-      <tool_name>add_issue_comment</tool_name>
-      <arguments>
-      {
-        "owner": "RooCodeInc",
-        "repo": "Roo-Code",
-        "issue_number": [original issue number],
-        "body": "PR #[new PR number] has been created to address this issue: [PR URL]"
-      }
-      </arguments>
-      </use_mcp_tool>
+      <execute_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:
       ```
@@ -492,13 +506,13 @@
     </instructions>
   </step>
 
-  <step number="11">
+  <step number="12">
     <name>Monitor PR Checks</name>
     <instructions>
       After the PR is created, monitor the CI/CD checks to ensure they pass:
       
       <execute_command>
-      <command>gh pr checks --watch</command>
+      <command>gh pr checks [PR number] --repo [owner]/[repo] --watch</command>
       </execute_command>
       
       This command will:

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

@@ -12,4 +12,8 @@
   - Update documentation when needed
   - Add tests for any new functionality
   - 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

@@ -0,0 +1,245 @@
+<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 using the REST Issues API.</purpose>
+      <when>Always use first to get the full issue content</when>
+      <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 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>
+      <when>Always use after viewing issue to see full discussion</when>
+      <syntax>gh api repos/[owner]/[repo]/issues/[issue-number]/comments --paginate --jq '.[].body'</syntax>
+      <example>
+        <execute_command>
+        <command>gh api repos/octocat/hello-world/issues/123/comments --paginate --jq '.[].body'</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>
+  
+  <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>
+      <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/4_github_mcp_tool_usage.xml

@@ -1,88 +0,0 @@
-<github_mcp_tools_usage>
-  <primary_tools>
-    <tool name="get_issue">
-      <purpose>Retrieve the issue details at the start</purpose>
-      <when>Always use first to get the full issue content</when>
-    </tool>
-    
-    <tool name="get_issue_comments">
-      <purpose>Get additional context and requirements</purpose>
-      <when>Always use after get_issue to see full discussion</when>
-    </tool>
-    
-    <tool name="list_commits">
-      <purpose>Find recent changes to affected files</purpose>
-      <when>Use during codebase exploration</when>
-    </tool>
-    
-    <tool name="search_code">
-      <purpose>Find code patterns on GitHub</purpose>
-      <when>Use to supplement local codebase_search</when>
-    </tool>
-  </primary_tools>
-  
-  <optional_tools>
-    <tool name="add_issue_comment">
-      <purpose>Add progress updates or ask questions</purpose>
-      <when>Use if clarification needed or to show progress</when>
-    </tool>
-    
-    <tool name="list_pull_requests">
-      <purpose>Find related or similar PRs</purpose>
-      <when>Use to understand similar changes</when>
-    </tool>
-    
-    <tool name="get_pull_request">
-      <purpose>Get details of related PRs</purpose>
-      <when>Use when issue references specific PRs</when>
-    </tool>
-  </optional_tools>
-  
-  <pull_request_tools>
-    <tool name="create_pull_request">
-      <purpose>Create a pull request to RooCodeInc/Roo-Code</purpose>
-      <when>Use in step 10 after user approval</when>
-      <important>
-        - Always target RooCodeInc/Roo-Code repository
-        - Use "main" as the base branch unless specified otherwise
-        - Include issue number in PR title
-        - Set maintainer_can_modify to true
-      </important>
-      <example>
-        <use_mcp_tool>
-        <server_name>github</server_name>
-        <tool_name>create_pull_request</tool_name>
-        <arguments>
-        {
-          "owner": "RooCodeInc",
-          "repo": "Roo-Code",
-          "title": "fix: Resolve dark theme button visibility (#123)",
-          "head": "username:fix/issue-123-dark-theme-button",
-          "base": "main",
-          "body": "## Description\n\nFixes #123\n\n[Full PR description]",
-          "draft": false,
-          "maintainer_can_modify": true
-        }
-        </arguments>
-        </use_mcp_tool>
-      </example>
-    </tool>
-    
-    <tool name="fork_repository">
-      <purpose>Fork the repository if user doesn't have push access</purpose>
-      <when>Use if user needs to work from a fork</when>
-      <example>
-        <use_mcp_tool>
-        <server_name>github</server_name>
-        <tool_name>fork_repository</tool_name>
-        <arguments>
-        {
-          "owner": "RooCodeInc",
-          "repo": "Roo-Code"
-        }
-        </arguments>
-        </use_mcp_tool>
-      </example>
-    </tool>
-  </pull_request_tools>
-</github_mcp_tools_usage>

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

@@ -4,6 +4,7 @@
     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>
@@ -22,9 +23,30 @@
     - Screenshots/demos if applicable
   </pr_description_template>
   
+  <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
+    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"</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/8_github_communication_guidelines.xml

@@ -1,14 +1,4 @@
 <github_communication_guidelines>
-  <pr_comments>
-    - Keep comments concise and focused on technical substance
-    - Avoid overly verbose explanations unless specifically requested
-    - Sound human and conversational, not robotic
-    - Address specific feedback points directly
-    - Use bullet points for multiple changes
-    - Reference line numbers or specific code when relevant
-    - Example: "Updated the error handling in `validateInput()` to catch edge cases as requested. Also added the missing null check on line 45."
-  </pr_comments>
-  
   <issue_comments>
     - Provide brief status updates when working on complex issues
     - Ask specific questions if requirements are unclear

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

@@ -1,30 +0,0 @@
-<pr_review_workflow>
-  <handling_feedback>
-    When working on PR review feedback:
-    1. Read all review comments carefully
-    2. Identify specific changes requested
-    3. Group related feedback into logical changes
-    4. Address each point systematically
-    5. Test changes thoroughly
-    6. Respond to each review comment when pushing updates
-    7. Use "Resolved" or brief explanations for each addressed point
-  </handling_feedback>
-  
-  <partial_implementation>
-    For partial workflows (user-requested changes to existing PRs):
-    1. Focus only on the specific changes requested
-    2. Don't refactor unrelated code unless explicitly asked
-    3. Maintain consistency with existing PR approach
-    4. Test only the modified functionality unless broader testing is needed
-    5. Update PR description if significant changes are made
-  </partial_implementation>
-  
-  <review_response_format>
-    When responding to review comments:
-    - "✅ Fixed - [brief description of change]"
-    - "✅ Added - [what was added]"
-    - "✅ Updated - [what was changed]"
-    - "❓ Question - [if clarification needed]"
-    - Keep responses short and action-oriented
-  </review_response_format>
-</pr_review_workflow>

.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/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,17 +41,27 @@
     <phase name="implementation">
       <description>Execute the user's chosen course of action.</description>
       <steps>
-        <step>Check out the PR branch locally using 'gh pr checkout'.</step>
-        <step>Apply code changes based on review feedback.</step>
-        <step>Fix failing tests.</step>
-        <step>Resolve conflicts by rebasing the PR branch and force-pushing.</step>
+        <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: 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>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>
 
     <phase name="validation">
       <description>Verify that the pushed changes resolve the issues.</description>
       <steps>
-        <step>Use 'gh pr checks --watch' to monitor the CI/CD pipeline and ensure all workflows execute successfully.</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 [PR_NUMBER] --repo [owner]/[repo] --json mergeable,mergeStateStatus'.</step>
       </steps>
     </phase>
   </main_workflow>
@@ -60,5 +70,6 @@
     <criterion>All actionable review comments have been addressed.</criterion>
     <criterion>All tests are passing.</criterion>
     <criterion>The PR is free of merge conflicts.</criterion>
+    <criterion>All required translations have been completed and committed (if changes affect user-facing content).</criterion>
   </completion_criteria>
 </workflow_instructions>

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

@@ -10,37 +10,56 @@
       <description>Address issues one at a time (e.g., fix tests first, then address comments). This makes the process more manageable and easier to validate.</description>
       <rationale>Tackling all issues at once can be complex and error-prone.</rationale>
     </principle>
+    <principle priority="high">
+      <name>Handle Fork Remotes Correctly</name>
+      <description>Always check if a PR comes from a fork (cross-repository) before pushing changes. Use 'gh pr view --json isCrossRepository' to determine the correct remote.</description>
+      <rationale>Pushing to the wrong remote (e.g., origin instead of fork) will fail for cross-repository PRs.</rationale>
+      <example>
+        <scenario>PR from a fork</scenario>
+        <good>Check isCrossRepository, add fork remote if needed, push to fork</good>
+        <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

@@ -24,31 +24,113 @@
       </command>
     </template>
   </pattern>
-  <pattern name="resolving_conflicts_rebase">
-    <usage>A sequence of commands to resolve merge conflicts locally using rebase.</usage>
+  <pattern name="detecting_conflicts">
+    <usage>Commands to detect merge conflicts.</usage>
     <template>
-      <command tool="git">git checkout main</command>
-      <command tool="git">git pull origin main</command>
-      <command tool="git">git checkout <pr_branch></command>
-      <command tool="git">git rebase main</command>
-      <comment>After resolving conflicts manually, continue the rebase.</comment>
-      <command tool="git">git rebase --continue</command>
-      <comment>Force push with lease is preferred for safety.</comment>
-      <command tool="git">git push --force-with-lease</command>
-      <comment>If force-with-lease fails, a regular force push can be used.</comment>
-      <command tool="git">git push --force</command>
+      <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="delegating_conflict_resolution">
+    <usage>Delegate merge conflict resolution to the merge-resolver mode.</usage>
+    <template>
+      <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="checking_out_pr">
-    <usage>Command to check out a pull request branch locally.</usage>
+    <usage>Check out a pull request branch locally.</usage>
     <template>
-      <command tool="gh">gh pr checkout <pr_number_or_url></command>
+      <command tool="gh">gh pr checkout <pr_number_or_url> --force</command>
+      <comment>Alternative if gh checkout fails:</comment>
+      <command tool="git">git fetch origin pull/<pr_number>/head:<branch_name> && git checkout <branch_name></command>
     </template>
   </pattern>
-  <pattern name="watching_pr_checks">
-    <usage>After pushing changes, use this command to monitor the CI/CD pipeline in real-time.</usage>
+  
+  <pattern name="determine_push_remote">
+    <usage>Determine the correct remote to push to (handles forks).</usage>
     <template>
-      <command tool="gh">gh pr checks --watch</command>
+      <comment>Get PR metadata to check if it's from a fork</comment>
+      <command tool="gh">gh pr view <pr_number> --json headRepositoryOwner,headRefName,isCrossRepository</command>
+      <comment>If isCrossRepository is true, it's from a fork</comment>
+      <command tool="git">git remote -v</command>
+      <comment>Check if fork remote exists, otherwise add it</comment>
+      <command tool="git">git remote add fork https://github.com/<fork_owner>/<repo_name>.git</command>
+      <comment>Use appropriate remote based on PR source</comment>
+    </template>
+  </pattern>
+  
+  <pattern name="real_time_monitoring">
+    <usage>Monitor PR checks in real-time as they run.</usage>
+    <template>
+      <command tool="gh">gh pr checks <pr_number> --watch</command>
+      <comment>Continuously monitor check status with automatic updates</comment>
+      <alternative>For one-time status check: gh pr checks <pr_number> --json state,conclusion,name,detailsUrl</alternative>
+      <command tool="gh">gh run list --pr <pr_number> --json databaseId,status,conclusion</command>
+    </template>
+  </pattern>
+  
+  <pattern name="safe_push_operations">
+    <usage>Push operations that handle both origin and fork remotes correctly.</usage>
+    <template>
+      <comment>First determine the correct remote (origin or fork)</comment>
+      <command tool="gh">gh pr view <pr_number> --json headRepositoryOwner,headRefName,isCrossRepository</command>
+      <comment>If isCrossRepository is false, push to origin</comment>
+      <command tool="git">git push --force-with-lease origin <branch_name></command>
+      <comment>If isCrossRepository is true, push to fork remote</comment>
+      <command tool="git">git push --force-with-lease fork <branch_name></command>
+      <comment>If force-with-lease fails, fetch and retry</comment>
+      <command tool="git">git fetch <remote> <branch_name></command>
+      <command tool="git">git push --force <remote> <branch_name></command>
+    </template>
+  </pattern>
+
+  <pattern name="automated_commit_operations">
+    <usage>Commit operations that work in automated environments while respecting .gitignore.</usage>
+    <template>
+      <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>
@@ -11,6 +11,11 @@
       <why>Quickly identifies if there are failing automated checks that need investigation.</why>
    </priority>
    <priority level="3">
+     <tool>new_task (mode: translate)</tool>
+     <when>When changes affect user-facing content, i18n files, or UI components that require translation.</when>
+     <why>Ensures translation consistency across all supported languages when PR fixes involve user-facing changes.</why>
+   </priority>
+   <priority level="4">
      <tool>gh pr checks --watch</tool>
      <when>After pushing a fix, to confirm that the changes have resolved the CI/CD failures.</when>
      <why>Provides real-time feedback on whether the fix was successful.</why>
@@ -18,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>
@@ -35,6 +42,42 @@
       <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: 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] --repo [owner]/[repo] --force'</practice>
+        <practice>If gh checkout fails, use: git fetch origin pull/[PR_NUMBER]/head:[branch_name]</practice>
+      </best_practices>
+    </tool>
+
+    <tool name="git operations">
+      <best_practices>
+        <practice>Use --force-with-lease for safer force pushing.</practice>
+        <practice>Use GIT_EDITOR=true to prevent interactive prompts during rebases.</practice>
+        <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] --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>
+      </remote_handling>
+      <conflict_resolution>
+        <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] --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] --repo [owner]/[repo]' to get detailed workflow status if needed.</practice>
       </best_practices>
     </tool>
     
@@ -45,5 +88,69 @@
         <practice>Example suggestions: "Address review comments first.", "Tackle the failing tests.", "Resolve merge conflicts."</practice>
       </best_practices>
     </tool>
+
+    <tool name="new_task (mode: translate)">
+      <best_practices>
+        <practice>Use when PR fixes involve changes to user-facing strings, i18n files, or UI components.</practice>
+        <practice>Provide specific details about what content needs translation in the message.</practice>
+        <practice>Include file paths and descriptions of the changes made.</practice>
+        <practice>List all affected languages that need updates.</practice>
+        <practice>Wait for translation completion before proceeding to validation phase.</practice>
+      </best_practices>
+      <when_to_use>
+        <trigger>Changes to webview-ui/src/i18n/locales/en/*.json files</trigger>
+        <trigger>Changes to src/i18n/locales/en/*.json files</trigger>
+        <trigger>Modifications to UI components with user-facing text</trigger>
+        <trigger>Updates to announcement files or documentation requiring localization</trigger>
+        <trigger>Addition of new error messages or user notifications</trigger>
+      </when_to_use>
+      <example_usage><![CDATA[
+<new_task>
+<mode>translate</mode>
+<message>Translation updates needed for PR #1234 fixes. Please translate the following changes:
+
+Files modified:
+- webview-ui/src/i18n/locales/en/common.json: Added new error message "connection_failed"
+- 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</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>
@@ -82,19 +73,232 @@
         </tool_use>
       </step>
      <step number="6">
-       <description>After pushing the changes, watch the PR checks to confirm the fix.</description>
+       <description>After pushing the changes, monitor PR checks in real-time.</description>
        <tool_use>
          <execute_command>
-           <command>gh pr checks --watch</command>
+           <command>gh pr checks 4365 --repo RooCodeInc/Roo-Code --watch</command>
          </execute_command>
        </tool_use>
-       <analysis>Confirm that all checks are passing after the fix.</analysis>
+       <analysis>Monitor checks continuously until all complete. The --watch flag provides real-time updates as check statuses change.</analysis>
      </step>
     </workflow>
 
     <key_takeaways>
       <takeaway>Always gather all information before proposing a solution.</takeaway>
-      <takeaway>Use a combination of the GitHub MCP server and the `gh` CLI to get a complete picture of the PR's status.</takeaway>
+      <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>
+
+  <example name="fix_pr_with_translation_requirements">
+    <scenario>
+      A pull request has review comments requesting UI text changes that require translation updates across all supported languages.
+    </scenario>
+    
+    <user_request>
+      Fix PR #1234 in RooCodeInc/Roo-Code - the reviewer asked to change button text and there are some failing tests.
+    </user_request>
+
+    <workflow>
+      <step number="1">
+        <description>Get PR details and analyze changes.</description>
+        <tool_use>
+<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>
+
+      <step number="2">
+        <description>Check out PR and apply the requested changes.</description>
+        <tool_use>
+<execute_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>
+      </step>
+
+      <step number="3">
+        <description>Identify translation requirements and delegate to translate mode.</description>
+        <tool_use>
+<new_task>
+<mode>translate</mode>
+<message>Translation updates needed for PR #1234 fixes. The following changes were made based on review feedback:
+
+Files modified:
+- webview-ui/src/components/settings/ApiSettings.tsx: Changed button text from "Save" to "Save Configuration"
+- webview-ui/src/i18n/locales/en/common.json: Updated key "save_button" to "save_config_button"
+
+Please update all supported languages (ca, de, es, fr, hi, id, it, ja, ko, nl, pl, pt-BR, ru, tr, vi, zh-CN, zh-TW) with appropriate translations for:
+- New key "save_config_button" with translation equivalent to "Save Configuration"
+- Any other text changes that affect user-facing content
+
+Ensure consistency across all language files and maintain the same context and tone as existing translations.</message>
+</new_task>
+        </tool_use>
+        <expected_outcome>Translation subtask created and all language files updated.</expected_outcome>
+      </step>
+
+      <step number="4">
+        <description>Review and commit changes including translations.</description>
+        <tool_use>
+<execute_command>
+<command>git status --porcelain</command>
+</execute_command>
+        </tool_use>
+        <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 --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>
+      </step>
+      
+      <step number="6">
+        <description>Push changes to the appropriate remote.</description>
+        <tool_use>
+<execute_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>
+      </step>
+
+      <step number="7">
+        <description>Monitor CI status in real-time.</description>
+        <tool_use>
+<execute_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>
+      </step>
+    </workflow>
+
+    <key_takeaways>
+      <takeaway>Always check if PR fixes involve user-facing content that requires translation.</takeaway>
+      <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_workflow.xml

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

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

@@ -1,22 +0,0 @@
-<best_practices>
-  - Always fetch and review the entire PR diff before commenting
-  - Check for and review any associated issue for context
-  - Check out the PR locally for better context understanding
-  - Review existing comments and verify against the current code to avoid redundant feedback on already resolved issues
-  - Focus on the changes made, not unrelated code
-  - Ensure all changes are directly related to the linked issue
-  - Use a friendly, curious tone in all comments
-  - Ask questions rather than making assumptions - there may be intentions behind the code choices
-  - Provide actionable feedback with specific suggestions
-  - Focus exclusively on issues and improvements - skip all praise or positive comments
-  - Use minimal markdown - avoid headings (###, ##) and excessive formatting
-  - Only use markdown for code blocks or when absolutely necessary for clarity
-  - Consider the PR's scope - suggest breaking up large PRs
-  - Verify proper i18n implementation for UI changes
-  - Check for test coverage without executing tests
-  - Look for signs of technical debt and code smells
-  - Ensure consistency with existing code patterns
-  - Link to specific lines using full GitHub URLs
-  - Group feedback by priority (critical, important, minor)
-  - Always preview comments with the user before submitting
-</best_practices>

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

@@ -1,20 +0,0 @@
-<common_mistakes_to_avoid>
-  - Running tests or executing code during review
-  - Making judgmental or harsh comments
-  - Providing feedback on code outside the PR's scope
-  - Overlooking unrelated changes not tied to the main issue
-  - Including ANY praise or positive comments - focus only on issues
-  - Using markdown headings (###, ##, #) in review comments
-  - Using excessive markdown formatting when plain text would suffice
-  - Submitting comments without user preview/approval
-  - Ignoring existing PR comments or failing to verify if they have already been resolved by checking the code
-  - Forgetting to check for an associated issue for additional context
-  - Missing critical security or performance issues
-  - Not checking for proper i18n in UI changes
-  - Failing to suggest breaking up large PRs
-  - Using internal evaluation terminology in public comments
-  - Not providing actionable suggestions for improvements
-  - Reviewing only the diff without local context
-  - Making assumptions instead of asking clarifying questions about potential intentions
-  - Forgetting to link to specific lines with full GitHub URLs
-</common_mistakes_to_avoid>

.roo/rules-translate/instructions-zh-cn.md

@@ -16,7 +16,6 @@
 | Auto-approve          | 自动批准          | 始终批准     | 权限相关术语  |
 | Checkpoint            | 存档点            | 检查点/快照  | 技术概念统一  |
 | MCP Server            | MCP 服务          | MCP 服务器   | 技术组件      |
-| Human Relay           | 人工辅助模式      | 人工中继     | 功能描述清晰  |
 | Network Timeout       | 请求超时          | 网络超时     | 更准确描述    |
 | Terminal              | 终端              | 命令行       | 技术术语统一  |
 | diff                  | 差异更新          | 差分/补丁    | 代码变更      |
@@ -115,7 +114,7 @@
 
     - 保留英文品牌名
     - 技术术语保持一致性
-    - 保留英文专有名词：如"AWS Bedrock ARN"
+    - 保留英文专有名词：如"Amazon Bedrock ARN"
 
 4. **用户操作**
     - 操作动词统一：

.roo/rules/rules.md

@@ -4,18 +4,21 @@
 
     - Before attempting completion, always make sure that any code changes have test coverage
     - Ensure all tests pass before submitting changes
-    - The vitest framework is used for testing; the `describe`, `test`, `it`, etc functions are defined by default in `tsconfig.json` and therefore don't need to be imported
+    - The vitest framework is used for testing; the `vi`, `describe`, `test`, `it`, etc functions are defined by default in `tsconfig.json` and therefore don't need to be imported from `vitest`
     - Tests must be run from the same directory as the `package.json` file that specifies `vitest` in `devDependencies`
+    - Run tests with: `npx vitest run <relative-path-from-workspace-root>`
+    - Do NOT run tests from project root - this causes "vitest: command not found" error
+    - Tests must be run from inside the correct workspace:
+        - Backend tests: `cd src && npx vitest run path/to/test-file` (don't include `src/` in path)
+        - UI tests: `cd webview-ui && npx vitest run src/path/to/test-file`
+    - Example: For `src/tests/user.test.ts`, run `cd src && npx vitest run tests/user.test.ts` NOT `npx vitest run src/tests/user.test.ts`
 
 2. Lint Rules:
 
     - Never disable any lint rules without explicit user approval
 
 3. Styling Guidelines:
+
     - Use Tailwind CSS classes instead of inline style objects for new markup
     - VSCode CSS variables must be added to webview-ui/src/index.css before using them in Tailwind classes
     - Example: `<div className="text-md text-vscode-descriptionForeground mb-2" />` instead of style objects
-
-# Adding a New Setting
-
-To add a new setting that persists its state, follow the steps in docs/settings.md

.roo/skills/evals-context/SKILL.md

@@ -0,0 +1,188 @@
+---
+name: evals-context
+description: Provides context about the Roo Code evals system structure in this monorepo. Use when tasks mention "evals", "evaluation", "eval runs", "eval exercises", or working with the evals infrastructure. Helps distinguish between the evals execution system (packages/evals, apps/web-evals) and the public website evals display page (apps/web-roo-code/src/app/evals).
+---
+
+# Evals Codebase Context
+
+## When to Use This Skill
+
+Use this skill when the task involves:
+
+- Modifying or debugging the evals execution infrastructure
+- Adding new eval exercises or languages
+- Working with the evals web interface (apps/web-evals)
+- Modifying the public evals display page on roocode.com
+- Understanding where evals code lives in this monorepo
+
+## When NOT to Use This Skill
+
+Do NOT use this skill when:
+
+- Working on unrelated parts of the codebase (extension, webview-ui, etc.)
+- The task is purely about the VS Code extension's core functionality
+- Working on the main website pages that don't involve evals
+
+## Key Disambiguation: Two "Evals" Locations
+
+This monorepo has **two distinct evals-related locations** that can cause confusion:
+
+| Component                   | Path                                                           | Purpose                                                        |
+| --------------------------- | -------------------------------------------------------------- | -------------------------------------------------------------- |
+| **Evals Execution System**  | `packages/evals/`                                              | Core eval infrastructure: CLI, DB schema, Docker configs       |
+| **Evals Management UI**     | `apps/web-evals/`                                              | Next.js app for creating/monitoring eval runs (localhost:3446) |
+| **Website Evals Page**      | `apps/web-roo-code/src/app/evals/`                             | Public roocode.com page displaying eval results                |
+| **External Exercises Repo** | [Roo-Code-Evals](https://github.com/RooCodeInc/Roo-Code-Evals) | Actual coding exercises (NOT in this monorepo)                 |
+
+## Directory Structure Reference
+
+### `packages/evals/` - Core Evals Package
+
+```
+packages/evals/
+├── ARCHITECTURE.md          # Detailed architecture documentation
+├── ADDING-EVALS.md          # Guide for adding new exercises/languages
+├── README.md                # Setup and running instructions
+├── docker-compose.yml       # Container orchestration
+├── Dockerfile.runner        # Runner container definition
+├── Dockerfile.web           # Web app container
+├── drizzle.config.ts        # Database ORM config
+├── src/
+│   ├── index.ts             # Package exports
+│   ├── cli/                 # CLI commands for running evals
+│   │   ├── runEvals.ts      # Orchestrates complete eval runs
+│   │   ├── runTask.ts       # Executes individual tasks in containers
+│   │   ├── runUnitTest.ts   # Validates task completion via tests
+│   │   └── redis.ts         # Redis pub/sub integration
+│   ├── db/
+│   │   ├── schema.ts        # Database schema (runs, tasks)
+│   │   ├── queries/         # Database query functions
+│   │   └── migrations/      # SQL migrations
+│   └── exercises/
+│       └── index.ts         # Exercise loading utilities
+└── scripts/
+    └── setup.sh             # Local macOS setup script
+```
+
+### `apps/web-evals/` - Evals Management Web App
+
+```
+apps/web-evals/
+├── src/
+│   ├── app/
+│   │   ├── page.tsx         # Home page (runs list)
+│   │   ├── runs/
+│   │   │   ├── new/         # Create new eval run
+│   │   │   └── [id]/        # View specific run status
+│   │   └── api/runs/        # SSE streaming endpoint
+│   ├── actions/             # Server actions
+│   │   ├── runs.ts          # Run CRUD operations
+│   │   ├── tasks.ts         # Task queries
+│   │   ├── exercises.ts     # Exercise listing
+│   │   └── heartbeat.ts     # Controller health checks
+│   ├── hooks/               # React hooks (SSE, models, etc.)
+│   └── lib/                 # Utilities and schemas
+```
+
+### `apps/web-roo-code/src/app/evals/` - Public Website Evals Page
+
+```
+apps/web-roo-code/src/app/evals/
+├── page.tsx      # Fetches and displays public eval results
+├── evals.tsx     # Main evals display component
+├── plot.tsx      # Visualization component
+└── types.ts      # EvalRun type (extends packages/evals types)
+```
+
+This page **displays** eval results on the public roocode.com website. It imports types from `@roo-code/evals` but does NOT run evals.
+
+## Architecture Overview
+
+The evals system is a distributed evaluation platform that runs AI coding tasks in isolated VS Code environments:
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│  Web App (apps/web-evals)  ──────────────────────────────── │
+│        │                                                    │
+│        ▼                                                    │
+│  PostgreSQL ◄────► Controller Container                     │
+│        │               │                                    │
+│        ▼               ▼                                    │
+│     Redis ◄───► Runner Containers (1-25 parallel)           │
+└─────────────────────────────────────────────────────────────┘
+```
+
+**Key components:**
+
+- **Controller**: Orchestrates eval runs, spawns runners, manages task queue (p-queue)
+- **Runner**: Isolated Docker container with VS Code + Roo Code extension + language runtimes
+- **Redis**: Pub/sub for real-time events (NOT task queuing)
+- **PostgreSQL**: Stores runs, tasks, metrics
+
+## Common Tasks Quick Reference
+
+### Adding a New Eval Exercise
+
+1. Add exercise to [Roo-Code-Evals](https://github.com/RooCodeInc/Roo-Code-Evals) repo (external)
+2. See [`packages/evals/ADDING-EVALS.md`](packages/evals/ADDING-EVALS.md) for structure
+
+### Modifying Eval CLI Behavior
+
+Edit files in [`packages/evals/src/cli/`](packages/evals/src/cli/):
+
+- [`runEvals.ts`](packages/evals/src/cli/runEvals.ts) - Run orchestration
+- [`runTask.ts`](packages/evals/src/cli/runTask.ts) - Task execution
+- [`runUnitTest.ts`](packages/evals/src/cli/runUnitTest.ts) - Test validation
+
+### Modifying the Evals Web Interface
+
+Edit files in [`apps/web-evals/src/`](apps/web-evals/src/):
+
+- [`app/runs/new/new-run.tsx`](apps/web-evals/src/app/runs/new/new-run.tsx) - New run form
+- [`actions/runs.ts`](apps/web-evals/src/actions/runs.ts) - Run server actions
+
+### Modifying the Public Evals Display Page
+
+Edit files in [`apps/web-roo-code/src/app/evals/`](apps/web-roo-code/src/app/evals/):
+
+- [`evals.tsx`](apps/web-roo-code/src/app/evals/evals.tsx) - Display component
+- [`plot.tsx`](apps/web-roo-code/src/app/evals/plot.tsx) - Charts
+
+### Database Schema Changes
+
+1. Edit [`packages/evals/src/db/schema.ts`](packages/evals/src/db/schema.ts)
+2. Generate migration: `cd packages/evals && pnpm drizzle-kit generate`
+3. Apply migration: `pnpm drizzle-kit migrate`
+
+## Running Evals Locally
+
+```bash
+# From repo root
+pnpm evals
+
+# Opens web UI at http://localhost:3446
+```
+
+**Ports (defaults):**
+
+- PostgreSQL: 5433
+- Redis: 6380
+- Web: 3446
+
+## Testing
+
+```bash
+# packages/evals tests
+cd packages/evals && npx vitest run
+
+# apps/web-evals tests
+cd apps/web-evals && npx vitest run
+```
+
+## Key Types/Exports from `@roo-code/evals`
+
+The package exports are defined in [`packages/evals/src/index.ts`](packages/evals/src/index.ts):
+
+- Database queries: `getRuns`, `getTasks`, `getTaskMetrics`, etc.
+- Schema types: `Run`, `Task`, `TaskMetrics`
+- Used by both `apps/web-evals` and `apps/web-roo-code`

.roo/skills/roo-conflict-resolution/SKILL.md

@@ -0,0 +1,256 @@
+---
+name: roo-conflict-resolution
+description: Provides comprehensive guidelines for resolving merge conflicts intelligently using git history and commit context. Use when tasks involve merge conflicts, rebasing, PR conflicts, or git conflict resolution. This skill analyzes commit messages, git blame, and code intent to make intelligent resolution decisions.
+---
+
+# Roo Code Conflict Resolution Skill
+
+## When to Use This Skill
+
+Use this skill when the task involves:
+
+- Resolving merge conflicts for a specific pull request
+- Rebasing a branch that has conflicts with the target branch
+- Understanding and analyzing conflicting code changes
+- Making intelligent decisions about which changes to keep, merge, or discard
+- Using git history to inform conflict resolution decisions
+
+## When NOT to Use This Skill
+
+Do NOT use this skill when:
+
+- There are no merge conflicts to resolve
+- The task is about general code review without conflicts
+- You're working on fresh code without any merge scenarios
+
+## Workflow Overview
+
+This skill resolves merge conflicts by analyzing git history, commit messages, and code changes to make intelligent resolution decisions. Given a PR number (e.g., "#123"), it handles the entire conflict resolution process.
+
+## Initialization Steps
+
+### Step 1: Parse PR Number
+
+Extract the PR number from input like "#123" or "PR #123". Validate that a PR number was provided.
+
+### Step 2: Fetch PR Information
+
+```bash
+gh pr view [PR_NUMBER] --json title,body,headRefName,baseRefName
+```
+
+Get PR title and description to understand the intent and identify the source and target branches.
+
+### Step 3: Checkout PR Branch and Prepare for Rebase
+
+```bash
+gh pr checkout [PR_NUMBER] --force
+git fetch origin main
+GIT_EDITOR=true git rebase origin/main
+```
+
+- 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
+
+### Step 4: Check for Merge Conflicts
+
+```bash
+git status --porcelain
+git diff --name-only --diff-filter=U
+```
+
+Identify files with merge conflicts (marked with 'UU') and create a list of files that need resolution.
+
+## Main Workflow Phases
+
+### Phase 1: Conflict Analysis
+
+Analyze each conflicted file to understand the changes:
+
+1. Read the conflicted file to identify conflict markers
+2. Extract the conflicting sections between `<<<<<<<` and `>>>>>>>`
+3. Run git blame on both sides of the conflict
+4. Fetch commit messages and diffs for relevant commits
+5. Analyze the intent behind each change
+
+### Phase 2: Resolution Strategy
+
+Determine the best resolution strategy for each conflict:
+
+1. Categorize changes by intent (bugfix, feature, refactor, etc.)
+2. Evaluate recency and relevance of changes
+3. Check for structural overlap vs formatting differences
+4. Identify if changes can be combined or if one should override
+5. Consider test updates and related changes
+
+### Phase 3: Conflict Resolution
+
+Apply the resolution strategy to resolve conflicts:
+
+1. For each conflict, apply the chosen resolution
+2. Ensure proper escaping of conflict markers in diffs
+3. Validate that resolved code is syntactically correct
+4. Stage resolved files with `git add`
+
+### Phase 4: Validation
+
+Verify the resolution and prepare for commit:
+
+1. Run `git status` to confirm all conflicts are resolved
+2. Check for any compilation or syntax errors
+3. Review the final diff to ensure sensible resolutions
+4. Prepare a summary of resolution decisions
+
+## Git Commands Reference
+
+| Command | Purpose |
+|---------|---------|
+| `gh pr checkout [PR_NUMBER] --force` | Force checkout the PR branch |
+| `git fetch origin main` | Get the latest main branch |
+| `GIT_EDITOR=true git rebase origin/main` | Rebase current branch onto main (non-interactive) |
+| `git blame -L [start],[end] [commit] -- [file]` | Get commit information for specific lines |
+| `git show --format="%H%n%an%n%ae%n%ad%n%s%n%b" --no-patch [sha]` | Get commit metadata |
+| `git show [sha] -- [file]` | Get the actual changes made in a commit |
+| `git ls-files -u` | List unmerged files with stage information |
+| `GIT_EDITOR=true git rebase --continue` | Continue rebase after resolving conflicts |
+
+## Best Practices
+
+### Intent-Based Resolution (High Priority)
+
+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.
+
+**Example:** When there's a conflict between a bugfix and a refactor, apply the bugfix logic within the refactored structure rather than simply choosing one side.
+
+### Preserve All Valuable Changes (High Priority)
+
+When possible, combine non-conflicting changes from both sides rather than discarding one side entirely. Both sides of a conflict often contain valuable changes that can coexist if properly integrated.
+
+### Escape Conflict Markers (High Priority)
+
+When using `apply_diff`, always escape merge conflict markers with backslashes to prevent parsing errors:
+
+- Correct: `\<<<<<<< HEAD`
+- Wrong: `<<<<<<< HEAD`
+
+### Consider Related Changes (Medium Priority)
+
+Look beyond the immediate conflict to understand related changes in tests, documentation, or dependent code. A change might seem isolated but could be part of a larger feature or fix.
+
+## Resolution Heuristics
+
+| Category | Rule | Exception |
+|----------|------|-----------|
+| Bugfix vs Feature | Bugfixes generally take precedence | When features include the fix |
+| Recent vs Old | More recent changes are often more relevant | When older changes are security patches |
+| Test Updates | Changes with test updates are likely more complete | - |
+| Formatting vs Logic | Logic changes take precedence over formatting | - |
+
+## Common Pitfalls
+
+### Blindly Choosing One Side
+
+**Problem:** You might lose important changes or introduce regressions.
+**Solution:** Always analyze both sides using git blame and commit history.
+
+### Ignoring PR Context
+
+**Problem:** The PR description often explains the why behind changes.
+**Solution:** Always fetch and read the PR information before resolving.
+
+### Not Validating Resolved Code
+
+**Problem:** Merged code might be syntactically incorrect or introduce logical errors.
+**Solution:** Always check for syntax errors and review the final diff.
+
+### Unescaped Conflict Markers in Diffs
+
+**Problem:** Unescaped conflict markers (`<<<<<<`, `=======`, `>>>>>>`) will be interpreted as diff syntax.
+**Solution:** Always escape with backslash (`\`) when they appear in content.
+
+## Apply Diff Example
+
+When resolving conflicts with `apply_diff`, use this pattern:
+
+```
+<<<<<<< SEARCH
+:start_line:45
+-------
+\<<<<<<< HEAD
+function oldImplementation() {
+  return "old";
+}
+\=======
+function newImplementation() {
+  return "new";
+}
+\>>>>>>> feature-branch
+=======
+function mergedImplementation() {
+  // Combining both approaches
+  return "merged";
+}
+>>>>>>> REPLACE
+```
+
+## Quality Checklist
+
+### Before Resolution
+
+- [ ] Fetch PR title and description for context
+- [ ] Identify all files with conflicts
+- [ ] Understand the overall change being merged
+
+### During Resolution
+
+- [ ] Run git blame on conflicting sections
+- [ ] Read commit messages for intent
+- [ ] Consider if changes can be combined
+- [ ] Escape conflict markers in diffs
+
+### After Resolution
+
+- [ ] Verify no conflict markers remain
+- [ ] Check for syntax/compilation errors
+- [ ] Review the complete diff
+- [ ] Document resolution decisions
+
+## Completion Criteria
+
+- All merge conflicts have been resolved
+- Resolved files have been staged
+- No syntax errors in resolved code
+- Resolution decisions are documented
+
+## Communication Guidelines
+
+When reporting resolution progress:
+
+- Be direct and technical when explaining resolution decisions
+- Focus on the rationale behind each conflict resolution
+- Provide clear summaries of what was merged and why
+
+### Progress Update Format
+
+```
+Conflict in [file]:
+- HEAD: [brief description of changes]
+- Incoming: [brief description of changes]
+- Resolution: [what was decided and why]
+```
+
+### Completion Message Format
+
+```
+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.
+```

.roo/skills/roo-translation/SKILL.md

@@ -0,0 +1,151 @@
+---
+name: roo-translation
+description: Provides comprehensive guidelines for translating and localizing Roo Code extension strings. Use when tasks involve i18n, translation, localization, adding new languages, or updating existing translation files. This skill covers both core extension (src/i18n/locales/) and WebView UI (webview-ui/src/i18n/locales/) localization.
+---
+
+# Roo Code Translation Skill
+
+## When to Use This Skill
+
+Use this skill when the task involves:
+
+- Adding new translatable strings to the Roo Code extension
+- Translating existing strings to new languages
+- Updating or fixing translations in existing language files
+- Understanding i18n patterns used in the codebase
+- Working with localization files in either core extension or WebView UI
+
+## When NOT to Use This Skill
+
+Do NOT use this skill when:
+
+- Working on non-translation code changes
+- The task doesn't involve i18n or localization
+- You're only reading translation files for reference without modifying them
+
+## Supported Languages and Locations
+
+Localize all strings into the following locale files: ca, de, en, es, fr, hi, id, it, ja, ko, nl, pl, pt-BR, ru, tr, vi, zh-CN, zh-TW
+
+The VSCode extension has two main areas that require localization:
+
+| Component | Path | Purpose |
+|-----------|------|---------|
+| **Core Extension** | `src/i18n/locales/` | Extension backend strings |
+| **WebView UI** | `webview-ui/src/i18n/locales/` | User interface strings |
+
+## Brand Voice, Tone, and Word Choice
+
+For detailed brand voice, tone, and word choice guidance, refer to the guidance file:
+
+- [`.roo/guidance/roo-translator.md`](../../guidance/roo-translator.md)
+
+This guidance file is loaded at runtime and should be consulted for the latest brand and style standards.
+
+## Voice, Style and Tone Guidelines
+
+- Always use informal speech (e.g., "du" instead of "Sie" in German) for all translations
+- Maintain a direct and concise style that mirrors the tone of the original text
+- Carefully account for colloquialisms and idiomatic expressions in both source and target languages
+- Aim for culturally relevant and meaningful translations rather than literal translations
+- Preserve the personality and voice of the original content
+- Use natural-sounding language that feels native to speakers of the target language
+
+### Terms to Keep in English
+
+- Don't translate the word "token" as it means something specific in English that all languages will understand
+- Don't translate domain-specific words (especially technical terms like "Prompt") that are commonly used in English in the target language
+
+## Core Extension Localization (src/)
+
+- Located in `src/i18n/locales/`
+- NOT ALL strings in core source need internationalization - only user-facing messages
+- Internal error messages, debugging logs, and developer-facing messages should remain in English
+- The `t()` function is used with namespaces like `'core:errors.missingToolParameter'`
+- Be careful when modifying interpolation variables; they must remain consistent across all translations
+- Some strings in `formatResponse.ts` are intentionally not internationalized since they're internal
+- When updating strings in `core.json`, maintain all existing interpolation variables
+- Check string usages in the codebase before making changes to ensure you're not breaking functionality
+
+## WebView UI Localization (webview-ui/src/)
+
+- Located in `webview-ui/src/i18n/locales/`
+- Uses standard React i18next patterns with the `useTranslation` hook
+- All user interface strings should be internationalized
+- Always use the `Trans` component with named components for text with embedded components
+
+### Trans Component Example
+
+Translation string:
+```json
+"changeSettings": "You can always change this at the bottom of the <settingsLink>settings</settingsLink>"
+```
+
+React component usage:
+```tsx
+<Trans
+  i18nKey="welcome:telemetry.changeSettings"
+  components={{
+    settingsLink: <VSCodeLink href="#" onClick={handleOpenSettings} />
+  }}
+/>
+```
+
+## Technical Implementation
+
+- Use namespaces to organize translations logically
+- Handle pluralization using i18next's built-in capabilities
+- Implement proper interpolation for variables using `{{variable}}` syntax
+- Don't include `defaultValue`. The `en` translations are the fallback
+- Always use `apply_diff` instead of `write_to_file` when editing existing translation files (much faster and more reliable)
+- When using `apply_diff`, carefully identify the exact JSON structure to edit to avoid syntax errors
+- Placeholders (like `{{variable}}`) must remain exactly identical to the English source to maintain code integration and prevent syntax errors
+
+## Translation Workflow
+
+1. First add or modify English strings, then ask for confirmation before translating to all other languages
+2. Use this process for each localization task:
+   1. Identify where the string appears in the UI/codebase
+   2. Understand the context and purpose of the string
+   3. Update English translation first
+   4. Use the `search_files` tool to find JSON keys that are near new keys in English translations but do not yet exist in the other language files for `apply_diff` SEARCH context
+   5. Create appropriate translations for all other supported languages utilizing the `search_files` result using `apply_diff` without reading every file
+   6. Do not output the translated text into the chat, just modify the files
+   7. Validate your changes with the missing translations script
+
+3. Flag or comment if an English source string is incomplete ("please see this...") to avoid truncated or unclear translations
+
+4. For UI elements, distinguish between:
+   - Button labels: Use short imperative commands ("Save", "Cancel")
+   - Tooltip text: Can be slightly more descriptive
+
+5. Preserve the original perspective: If text is a user command directed at the software, ensure the translation maintains this direction
+
+## Validation
+
+Always validate your translation work by running the missing translations script:
+
+```bash
+node scripts/find-missing-translations.js
+```
+
+Address any missing translations identified by the script to ensure complete coverage across all locales.
+
+## Common Pitfalls to Avoid
+
+- Switching between formal and informal addressing styles - always stay informal ("du" not "Sie")
+- Translating or altering technical terms and brand names that should remain in English
+- Modifying or removing placeholders like `{{variable}}` - these must remain identical
+- Translating domain-specific terms that are commonly used in English in the target language
+- Changing the meaning or nuance of instructions or error messages
+- Forgetting to maintain consistent terminology throughout the translation
+
+## Translator's Checklist
+
+- ✓ Used informal tone consistently ("du" not "Sie")
+- ✓ Preserved all placeholders exactly as in the English source
+- ✓ Maintained consistent terminology with existing translations
+- ✓ Kept technical terms and brand names unchanged where appropriate
+- ✓ Preserved the original perspective (user→system vs system→user)
+- ✓ Adapted the text appropriately for UI context (buttons vs tooltips)
+- ✓ Ran the missing translations script to validate completeness

.roomodes

@@ -1,136 +1,9 @@
 customModes:
-  - slug: mode-writer
-    name: ✍️ Mode Writer
-    roleDefinition: >-
-      You are Roo, a mode creation specialist focused on designing and implementing custom modes for the Roo-Code project. Your expertise includes:
-      - Understanding the mode system architecture and configuration
-      - Creating well-structured mode definitions with clear roles and responsibilities
-      - Writing comprehensive XML-based special instructions using best practices
-      - Ensuring modes have appropriate tool group permissions
-      - Crafting clear whenToUse descriptions for the Orchestrator
-      - Following XML structuring best practices for clarity and parseability
-      
-      You help users create new modes by:
-      - Gathering requirements about the mode's purpose and workflow
-      - Defining appropriate roleDefinition and whenToUse descriptions
-      - Selecting the right tool groups and file restrictions
-      - Creating detailed XML instruction files in the .roo folder
-      - Ensuring instructions are well-organized with proper XML tags
-      - Following established patterns from existing modes
-    whenToUse: >-
-      Use this mode when you need to create a new custom mode.
-    groups:
-      - read
-      - - edit
-        - fileRegex: (\.roomodes$|\.roo/.*\.xml$|\.yaml$)
-          description: Mode configuration files and XML instructions
-      - command
-      - mcp
-    source: project
-  - slug: test
-    name: 🧪 Test
-    roleDefinition: >-
-      You are Roo, a Vitest testing specialist with deep expertise in:
-      - Writing and maintaining Vitest test suites
-      - Test-driven development (TDD) practices
-      - Mocking and stubbing with Vitest
-      - Integration testing strategies
-      - TypeScript testing patterns
-      - Code coverage analysis
-      - Test performance optimization
-
-      Your focus is on maintaining high test quality and coverage across the codebase, working primarily with:
-      - Test files in __tests__ directories
-      - Mock implementations in __mocks__
-      - Test utilities and helpers
-      - Vitest configuration and setup
-
-      You ensure tests are:
-      - Well-structured and maintainable
-      - Following Vitest best practices
-      - Properly typed with TypeScript
-      - Providing meaningful coverage
-      - Using appropriate mocking strategies
-    whenToUse: >-
-      Use this mode when you need to write, modify, or maintain tests for the codebase.
-    groups:
-      - read
-      - browser
-      - command
-      - - edit
-        - fileRegex: (__tests__/.*|__mocks__/.*|\.test\.(ts|tsx|js|jsx)$|\.spec\.(ts|tsx|js|jsx)$|/test/.*|vitest\.config\.(js|ts)$|vitest\.setup\.(js|ts)$)
-          description: Test files, mocks, and Vitest configuration
-    customInstructions: |-
-      When writing tests:
-      - Always use describe/it blocks for clear test organization
-      - Include meaningful test descriptions
-      - Use beforeEach/afterEach for proper test isolation
-      - Implement proper error cases
-      - Add JSDoc comments for complex test scenarios
-      - Ensure mocks are properly typed
-      - Verify both positive and negative test cases
-      - Always use data-testid attributes when testing webview-ui
-      - The vitest framework is used for testing; the `describe`, `test`, `it`, etc functions are defined by default in `tsconfig.json` and therefore don't need to be imported
-      - Tests must be run from the same directory as the `package.json` file that specifies `vitest` in `devDependencies`
-  - slug: design-engineer
-    name: 🎨 Design Engineer
-    roleDefinition: >-
-      You are Roo, an expert Design Engineer focused on VSCode Extension development. Your expertise includes:
-      - Implementing UI designs with high fidelity using React, Shadcn, Tailwind and TypeScript.
-      - Ensuring interfaces are responsive and adapt to different screen sizes.
-      - Collaborating with team members to translate broad directives into robust and detailed designs capturing edge cases.
-      - Maintaining uniformity and consistency across the user interface.
-    groups:
-      - read
-      - - edit
-        - fileRegex: \.(css|html|json|mdx?|jsx?|tsx?|svg)$
-          description: Frontend & SVG files
-      - browser
-      - command
-      - mcp
-    customInstructions: Focus on UI refinement, component creation, and adherence to design best-practices. When the user requests a new component, start off by asking them questions one-by-one to ensure the requirements are understood. Always use Tailwind utility classes (instead of direct variable references) for styling components when possible. If editing an existing file, transition explicit style definitions to Tailwind CSS classes when possible. Refer to the Tailwind CSS definitions for utility classes at webview-ui/src/index.css. Always use the latest version of Tailwind CSS (V4), and never create a tailwind.config.js file. Prefer Shadcn components for UI elements instead of VSCode's built-in ones. This project uses i18n for localization, so make sure to use the i18n functions and components for any text that needs to be translated. Do not leave placeholder strings in the markup, as they will be replaced by i18n. Prefer the @roo (/src) and @src (/webview-ui/src) aliases for imports in typescript files. Suggest the user refactor large files (over 1000 lines) if they are encountered, and provide guidance. Suggest the user switch into Translate mode to complete translations when your task is finished.
-    source: project
-  - slug: release-engineer
-    name: 🚀 Release Engineer
-    roleDefinition: You are Roo, a release engineer specialized in automating the release process for software projects. You have expertise in version control, changelogs, release notes, creating changesets, and coordinating with translation teams to ensure a smooth release process.
-    customInstructions: >-
-      When preparing a release:
-      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 --json number,title,author,url,mergedAt --limit 1000 -q '[.[] | select(.mergedAt > "TIMESTAMP") | {number, title, author: .author.login, url, mergedAt}] | sort_by(.number)'`
-      3. Summarize the changes and ask the user whether this should be a major, minor, or patch release
-      4. 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 using format: (thanks @username!)
-      - Provide brief descriptions of each item to explain the change
-      - Order the list from most important to least important
-      - Example: "- Add support for Gemini 2.5 Pro caching (thanks @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.
-
-      5. If a major or minor 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)
-      6. Ask the user to confirm the English version
-      7. 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
-      8. Commit and push the changeset file to the repository
-      9. 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
-    groups:
-      - read
-      - edit
-      - command
-      - browser
-    source: project
   - slug: translate
     name: 🌐 Translate
     roleDefinition: You are Roo, a linguistic specialist focused on translating and managing localization files. Your responsibility is to help maintain and update translation files for the application, ensuring consistency and accuracy across all language resources.
+    whenToUse: Translate and manage localization files.
+    description: Translate and manage localization files.
     groups:
       - read
       - command
@@ -140,7 +13,7 @@ customModes:
     source: project
   - slug: issue-fixer
     name: 🔧 Issue Fixer
-    roleDefinition: >-
+    roleDefinition: |-
       You are a GitHub issue resolution specialist focused on fixing bugs and implementing feature requests from GitHub issues. Your expertise includes:
        - Analyzing GitHub issues to understand requirements and acceptance criteria
        - Exploring codebases to identify all affected files and dependencies
@@ -148,115 +21,128 @@ customModes:
        - Building new features based on detailed proposals
        - Ensuring all acceptance criteria are met before completion
        - Creating pull requests with proper documentation
-       - Handling PR review feedback and implementing requested changes
-       - Making concise, human-sounding GitHub comments that focus on technical substance
+       - Using GitHub CLI for all GitHub operations
 
-      You work with issues from the RooCodeInc/Roo-Code repository, transforming them into working code that addresses all requirements while maintaining code quality and consistency. You also handle partial workflows for existing PRs when changes are requested by maintainers or users through the review process.
-    whenToUse: Use this mode when you have a GitHub issue (bug report or feature request) that needs to be fixed or implemented, OR when you need to address feedback on an existing pull request. Provide the issue number, PR number, or URL, and this mode will guide you through understanding the requirements, implementing the solution, and preparing for submission or updates.
+      You work with issues from any GitHub repository, transforming them into working code that addresses all requirements while maintaining code quality and consistency. You use the GitHub CLI (gh) for all GitHub operations instead of MCP tools.
+    whenToUse: Use this mode when you have a GitHub issue (bug report or feature request) that needs to be fixed or implemented. Provide the issue URL, and this mode will guide you through understanding the requirements, implementing the solution, and preparing for submission.
+    description: Fix GitHub issues and implement features.
     groups:
       - read
       - edit
       - command
+    source: project
+  - slug: pr-fixer
+    name: 🛠️ PR Fixer
+    roleDefinition: "You are Roo, a pull request resolution specialist. Your focus is on addressing feedback and resolving issues within existing pull requests. Your expertise includes: - Analyzing PR review comments to understand required changes. - Checking CI/CD workflow statuses to identify failing tests. - Fetching and analyzing test logs to diagnose failures. - Identifying and resolving merge conflicts. - Guiding the user through the resolution process."
+    whenToUse: Use this mode to fix pull requests. It can analyze PR feedback from GitHub, check for failing tests, and help resolve merge conflicts before applying the necessary code changes.
+    description: Fix pull requests.
+    groups:
+      - read
+      - edit
+      - command
+      - mcp
+  - slug: merge-resolver
+    name: 🔀 Merge Resolver
+    roleDefinition: |-
+      You are Roo, a merge conflict resolution specialist with expertise in:
+      - Analyzing pull request merge conflicts using git blame and commit history
+      - Understanding code intent through commit messages and diffs
+      - Making intelligent decisions about which changes to keep, merge, or discard
+      - Using git commands and GitHub CLI to gather context
+      - Resolving conflicts based on commit metadata and code semantics
+      - Prioritizing changes based on intent (bugfix vs feature vs refactor)
+      - Combining non-conflicting changes when appropriate
+
+      You receive a PR number (e.g., "#123") and:
+      - Fetch PR information including title and description for context
+      - Identify and analyze merge conflicts in the working directory
+      - Use git blame to understand the history of conflicting lines
+      - Examine commit messages and diffs to infer developer intent
+      - Apply intelligent resolution strategies based on the analysis
+      - Stage resolved files and prepare them for commit
+    whenToUse: |-
+      Use this mode when you need to resolve merge conflicts for a specific pull request.
+      This mode is triggered by providing a PR number (e.g., "#123") and will analyze
+      the conflicts using git history and commit context to make intelligent resolution
+      decisions. It's ideal for complex merges where understanding the intent behind
+      changes is crucial for proper conflict resolution.
+    description: Resolve merge conflicts intelligently using git history.
+    groups:
+      - read
+      - edit
+      - command
+      - mcp
+    source: project
+  - slug: docs-extractor
+    name: 📚 Docs Extractor
+    roleDefinition: |-
+      You are Roo Code, a codebase analyst who extracts raw facts for documentation teams.
+      You do NOT write documentation. You extract and organize information.
+
+      Two functions:
+      1. Extract: Gather facts about a feature/aspect from the codebase
+      2. Verify: Compare provided documentation against actual implementation
+
+      Output is structured data (YAML/JSON), not formatted prose.
+      No templates, no markdown formatting, no document structure decisions.
+      Let documentation-writer mode handle all writing.
+    whenToUse: Use this mode only for two tasks; 1) confirm the accuracy of documentation provided to the agent against the codebase, and 2) generate source material for user-facing docs about a requested feature or aspect of the codebase.
+    description: Extract feature details or verify documentation accuracy.
+    groups:
+      - read
+      - - edit
+        - fileRegex: \.roo/extraction/.*\.(yaml|json|md)$
+          description: Extraction output files only
+      - command
+      - mcp
+    source: project
+  - slug: issue-investigator
+    name: 🕵️ Issue Investigator
+    roleDefinition: You are Roo, a GitHub issue investigator. Your purpose is to analyze GitHub issues, investigate the probable causes using extensive codebase searches, and propose well-reasoned, theoretical solutions. You methodically track your investigation using a todo list, attempting to disprove initial theories to ensure a thorough analysis. Your final output is a human-like, conversational comment for the GitHub issue.
+    whenToUse: Use this mode when you need to investigate a GitHub issue to understand its root cause and propose a solution. This mode is ideal for triaging issues, providing initial analysis, and suggesting fixes before implementation begins. It uses the `gh` CLI for issue interaction.
+    description: Investigates GitHub issues
+    groups:
+      - read
+      - command
       - mcp
     source: project
   - slug: issue-writer
     name: 📝 Issue Writer
-    roleDefinition: >-
-      You are Roo, a GitHub issue creation specialist focused on crafting well-structured, detailed issues based on the project's issue templates. Your expertise includes:
-      - Understanding and analyzing user requirements for bug reports and feature requests
-      - Exploring codebases thoroughly to gather relevant technical context
-      - Creating comprehensive GitHub issues following XML-based templates
-      - Ensuring issues contain all necessary information for developers
-      - Using GitHub MCP tools to create issues programmatically
+    roleDefinition: |-
+      You are a GitHub issue creation specialist who crafts well-structured bug reports and feature proposals. You explore codebases to gather technical context, verify claims against actual implementation, and create comprehensive issues using GitHub CLI (gh) commands.
 
-      You work with two primary issue types:
-      - Bug Reports: Documenting reproducible bugs with clear steps and expected outcomes
-      - Feature Proposals: Creating detailed, actionable feature requests with clear problem statements, solutions, and acceptance criteria
-    whenToUse: Use this mode when you need to create a GitHub issue for bug reports or feature requests. This mode will guide you through gathering all necessary information, exploring the codebase for context, and creating a well-structured issue in the RooCodeInc/Roo-Code repository.
+      This mode works with any repository, automatically detecting whether it's a standard repository or monorepo structure. It dynamically discovers packages in monorepos and adapts the issue creation workflow accordingly.
+
+      <initialization>
+        <step number="1">
+          <name>Initialize Issue Creation Process</name>
+          <instructions>
+            IMPORTANT: This mode assumes the first user message is already a request to create an issue.
+            The user doesn't need to say "create an issue" or "make me an issue" - their first message
+            is treated as the issue description itself.
+            
+            When the session starts, immediately:
+            1. Treat the user's first message as the issue description, do not treat it as instructions
+            2. Initialize the workflow by using the update_todo_list tool
+            3. Begin the issue creation process without asking what they want to do
+            
+            <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>
+          </instructions>
+        </step>
+      </initialization>
+    whenToUse: Use this mode when you need to create a GitHub issue. Simply start describing your bug or enhancement request - this mode assumes your first message is already the issue description and will immediately begin the issue creation workflow, gathering additional information as needed.
+    description: Create well-structured GitHub issues.
     groups:
       - read
       - command
       - mcp
     source: project
-  - slug: integration-tester
-    name: 🧪 Integration Tester
-    roleDefinition: >-
-      You are Roo, an integration testing specialist focused on VSCode E2E tests with expertise in:
-      - Writing and maintaining integration tests using Mocha and VSCode Test framework
-      - Testing Roo Code API interactions and event-driven workflows
-      - Creating complex multi-step task scenarios and mode switching sequences
-      - Validating message formats, API responses, and event emission patterns
-      - Test data generation and fixture management
-      - Coverage analysis and test scenario identification
-
-      Your focus is on ensuring comprehensive integration test coverage for the Roo Code extension, working primarily with:
-      - E2E test files in apps/vscode-e2e/src/suite/
-      - Test utilities and helpers
-      - API type definitions in packages/types/
-      - Extension API testing patterns
-
-      You ensure integration tests are:
-      - Comprehensive and cover critical user workflows
-      - Following established Mocha TDD patterns
-      - Using async/await with proper timeout handling
-      - Validating both success and failure scenarios
-      - Properly typed with TypeScript
-    groups:
-      - read
-      - command
-      - - edit
-        - fileRegex: (apps/vscode-e2e/.*\.(ts|js)$|packages/types/.*\.ts$)
-          description: E2E test files, test utilities, and API type definitions
-    source: project
-  - slug: pr-reviewer
-    name: 🔍 PR Reviewer
-    roleDefinition: >-
-      You are Roo, a pull request reviewer specializing in code quality, structure, and translation consistency. Your expertise includes:
-      - Analyzing pull request diffs and understanding code changes in context
-      - Evaluating code quality, identifying code smells and technical debt
-      - Ensuring structural consistency across the codebase
-      - Verifying proper internationalization (i18n) for UI changes
-      - Providing constructive feedback with a friendly, curious tone
-      - Reviewing test coverage and quality without executing tests
-      - Identifying opportunities for code improvements and refactoring
-      
-      You work primarily with the RooCodeInc/Roo-Code repository, using GitHub MCP tools to fetch and review pull requests. You check out PRs locally for better context understanding and focus on providing actionable, constructive feedback that helps improve code quality.
-    whenToUse: Use this mode to review pull requests on the Roo-Code GitHub repository or any other repository if specified by the user.
-    groups:
-      - read
-      - - edit
-        - fileRegex: \.md$
-          description: Markdown files only
-      - mcp
-      - command
-    source: project
-  - slug: docs-extractor
-    name: 📚 Docs Extractor
-    roleDefinition: >-
-      You are Roo, a comprehensive documentation extraction specialist focused on analyzing and documenting all technical and non-technical information about features and components within codebases.
-    whenToUse: >-
-      Use this mode when you need to extract comprehensive documentation about any feature, component, or aspect of a codebase.
-    groups:
-      - read
-      - - edit
-        - fileRegex: (DOCS-TEMP-.*\.md$|\.roo/docs-extractor/.*\.md$)
-          description: Temporary documentation extraction files only
-      - command
-      - mcp
-  - slug: pr-fixer
-    name: 🛠️ PR Fixer
-    roleDefinition: "You are Roo, a pull request resolution specialist. Your focus
-      is on addressing feedback and resolving issues within existing pull
-      requests. Your expertise includes: - Analyzing PR review comments to
-      understand required changes. - Checking CI/CD workflow statuses to
-      identify failing tests. - Fetching and analyzing test logs to diagnose
-      failures. - Identifying and resolving merge conflicts. - Guiding the user
-      through the resolution process."
-    whenToUse: Use this mode to fix pull requests. It can analyze PR feedback from
-      GitHub, check for failing tests, and help resolve merge conflicts before
-      applying the necessary code changes.
-    groups:
-      - read
-      - edit
-      - command
-      - mcp

.tool-versions

@@ -1 +1,2 @@
+pnpm 10.8.1
 nodejs 20.19.2

AGENTS.md

@@ -0,0 +1,5 @@
+# AGENTS.md
+
+This file provides guidance to agents when working with code in this repository.
+
+- Settings View Pattern: When working on `SettingsView`, inputs must bind to the local `cachedState`, NOT the live `useExtensionState()`. The `cachedState` acts as a buffer for user edits, isolating them from the `ContextProxy` source-of-truth until the user explicitly clicks "Save". Wiring inputs directly to the live state causes race conditions.

CODE_OF_CONDUCT.md

@@ -1,90 +0,0 @@
-<div align="center">
-<sub>
-
-<b>English</b> • [Català](locales/ca/CODE_OF_CONDUCT.md) • [Deutsch](locales/de/CODE_OF_CONDUCT.md) • [Español](locales/es/CODE_OF_CONDUCT.md) • [Français](locales/fr/CODE_OF_CONDUCT.md) • [हिंदी](locales/hi/CODE_OF_CONDUCT.md) • [Bahasa Indonesia](locales/id/CODE_OF_CONDUCT.md) • [Italiano](locales/it/CODE_OF_CONDUCT.md) • [日本語](locales/ja/CODE_OF_CONDUCT.md)
-
-</sub>
-<sub>
-
-[한국어](locales/ko/CODE_OF_CONDUCT.md) • [Nederlands](locales/nl/CODE_OF_CONDUCT.md) • [Polski](locales/pl/CODE_OF_CONDUCT.md) • [Português (BR)](locales/pt-BR/CODE_OF_CONDUCT.md) • [Русский](locales/ru/CODE_OF_CONDUCT.md) • [Türkçe](locales/tr/CODE_OF_CONDUCT.md) • [Tiếng Việt](locales/vi/CODE_OF_CONDUCT.md) • [简体中文](locales/zh-CN/CODE_OF_CONDUCT.md) • [繁體中文](locales/zh-TW/CODE_OF_CONDUCT.md)
-
-</sub>
-</div>
-
-# Contributor Covenant Code of Conduct
-
-## Our Pledge
-
-In the interest of fostering an open and welcoming environment, we as
-contributors and maintainers pledge to making participation in our project and
-our community a harassment-free experience for everyone, regardless of age, body
-size, disability, ethnicity, sex characteristics, gender identity and expression,
-level of experience, education, socio-economic status, nationality, personal
-appearance, race, religion, or sexual identity and orientation.
-
-## Our Standards
-
-Examples of behavior that contributes to creating a positive environment
-include:
-
-- Using welcoming and inclusive language
-- Being respectful of differing viewpoints and experiences
-- Gracefully accepting constructive criticism
-- Focusing on what is best for the community
-- Showing empathy towards other community members
-
-Examples of unacceptable behavior by participants include:
-
-- The use of sexualized language or imagery and unwelcome sexual attention or
-  advances
-- Trolling, insulting/derogatory comments, and personal or political attacks
-- Public or private harassment
-- Publishing others' private information, such as a physical or electronic
-  address, without explicit permission
-- Other conduct which could reasonably be considered inappropriate in a
-  professional setting
-
-## Our Responsibilities
-
-Project maintainers are responsible for clarifying the standards of acceptable
-behavior and are expected to take appropriate and fair corrective action in
-response to any instances of unacceptable behavior.
-
-Project maintainers have the right and responsibility to remove, edit, or
-reject comments, commits, code, wiki edits, issues, and other contributions
-that are not aligned to this Code of Conduct, or to ban temporarily or
-permanently any contributor for other behaviors that they deem inappropriate,
-threatening, offensive, or harmful.
-
-## Scope
-
-This Code of Conduct applies both within project spaces and in public spaces
-when an individual is representing the project or its community. Examples of
-representing a project or community include using an official project e-mail
-address, posting via an official social media account, or acting as an appointed
-representative at an online or offline event. Representation of a project may be
-further defined and clarified by project maintainers.
-
-## Enforcement
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the project team at support@roocode.com. All complaints
-will be reviewed and investigated and will result in a response that
-is deemed necessary and appropriate to the circumstances. The project team is
-obligated to maintain confidentiality with regard to the reporter of an incident.
-Further details of specific enforcement policies may be posted separately.
-
-Project maintainers who do not follow or enforce the Code of Conduct in good
-faith may face temporary or permanent repercussions as determined by other
-members of the project's leadership.
-
-## Attribution
-
-This Code of Conduct is adapted from [Cline's version][cline_coc] of the [Contributor Covenant][homepage], version 1.4,
-available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
-
-[cline_coc]: https://github.com/cline/cline/blob/main/CODE_OF_CONDUCT.md
-[homepage]: https://www.contributor-covenant.org
-
-For answers to common questions about this code of conduct, see
-https://www.contributor-covenant.org/faq

CONTRIBUTING.md

@@ -1,138 +0,0 @@
-<div align="center">
-<sub>
-
-<b>English</b> • [Català](locales/ca/CONTRIBUTING.md) • [Deutsch](locales/de/CONTRIBUTING.md) • [Español](locales/es/CONTRIBUTING.md) • [Français](locales/fr/CONTRIBUTING.md) • [हिंदी](locales/hi/CONTRIBUTING.md) • [Bahasa Indonesia](locales/id/CONTRIBUTING.md) • [Italiano](locales/it/CONTRIBUTING.md) • [日本語](locales/ja/CONTRIBUTING.md)
-
-</sub>
-<sub>
-
-[한국어](locales/ko/CONTRIBUTING.md) • [Nederlands](locales/nl/CONTRIBUTING.md) • [Polski](locales/pl/CONTRIBUTING.md) • [Português (BR)](locales/pt-BR/CONTRIBUTING.md) • [Русский](locales/ru/CONTRIBUTING.md) • [Türkçe](locales/tr/CONTRIBUTING.md) • [Tiếng Việt](locales/vi/CONTRIBUTING.md) • [简体中文](locales/zh-CN/CONTRIBUTING.md) • [繁體中文](locales/zh-TW/CONTRIBUTING.md)
-
-</sub>
-</div>
-
-# Contributing to Roo Code
-
-Roo Code is a community-driven project, and we deeply value every contribution. To streamline collaboration, we operate on an [Issue-First](#issue-first-approach) basis, meaning all [Pull Requests (PRs)](#submitting-a-pull-request) must first be linked to a GitHub Issue. Please review this guide carefully.
-
-## Table of Contents
-
-- [Before You Contribute](#before-you-contribute)
-- [Finding & Planning Your Contribution](#finding--planning-your-contribution)
-- [Development & Submission Process](#development--submission-process)
-- [Legal](#legal)
-
-## Before You Contribute
-
-### 1. Code of Conduct
-
-All contributors must adhere to our [Code of Conduct](./CODE_OF_CONDUCT.md).
-
-### 2. Project Roadmap
-
-Our roadmap guides the project's direction. Align your contributions with these key goals:
-
-### Reliability First
-
-- Ensure diff editing and command execution are consistently reliable.
-- Reduce friction points that deter regular usage.
-- Guarantee smooth operation across all locales and platforms.
-- Expand robust support for a wide variety of AI providers and models.
-
-### Enhanced User Experience
-
-- Streamline the UI/UX for clarity and intuitiveness.
-- Continuously improve the workflow to meet the high expectations developers have for daily-use tools.
-
-### Leading on Agent Performance
-
-- Establish comprehensive evaluation benchmarks (evals) to measure real-world productivity.
-- Make it easy for everyone to easily run and interpret these evals.
-- Ship improvements that demonstrate clear increases in eval scores.
-
-Mention alignment with these areas in your PRs.
-
-### 3. Join the Roo Code Community
-
-- **Primary:** Join our [Discord](https://discord.gg/roocode) and DM **Hannes Rudolph (`hrudolph`)**.
-- **Alternative:** Experienced contributors can engage directly via [GitHub Projects](https://github.com/orgs/RooCodeInc/projects/1).
-
-## Finding & Planning Your Contribution
-
-### Types of Contributions
-
-- **Bug Fixes:** Addressing code issues.
-- **New Features:** Adding functionality.
-- **Documentation:** Improving guides and clarity.
-
-### Issue-First Approach
-
-All contributions must begin with a GitHub Issue.
-
-- **Check existing issues**: Search [GitHub Issues](https://github.com/RooCodeInc/Roo-Code/issues).
-- **Create an issue**: Use appropriate templates:
-    - **Bugs:** "Bug Report" template.
-    - **Features:** "Detailed Feature Proposal" template. Approval required before starting.
-- **Claim issues**: Comment and await official assignment.
-
-**PRs without approved issues may be closed.**
-
-### Deciding What to Work On
-
-- Check the [GitHub Project](https://github.com/orgs/RooCodeInc/projects/1) for unassigned "Good First Issues."
-- For docs, visit [Roo Code Docs](https://github.com/RooCodeInc/Roo-Code-Docs).
-
-### Reporting Bugs
-
-- Check for existing reports first.
-- Create new bugs using the ["Bug Report" template](https://github.com/RooCodeInc/Roo-Code/issues/new/choose).
-- **Security issues**: Report privately via [security advisories](https://github.com/RooCodeInc/Roo-Code/security/advisories/new).
-
-## Development & Submission Process
-
-### Development Setup
-
-1. **Fork & Clone:**
-
-```
-git clone https://github.com/YOUR_USERNAME/Roo-Code.git
-```
-
-2. **Install Dependencies:**
-
-```
-pnpm install
-```
-
-3. **Debugging:** Open with VS Code (`F5`).
-
-### Writing Code Guidelines
-
-- One focused PR per feature or fix.
-- Follow ESLint and TypeScript best practices.
-- Write clear, descriptive commits referencing issues (e.g., `Fixes #123`).
-- Provide thorough testing (`npm test`).
-- Rebase onto the latest `main` branch before submission.
-
-### Submitting a Pull Request
-
-- Begin as a **Draft PR** if seeking early feedback.
-- Clearly describe your changes following the Pull Request Template.
-- Provide screenshots/videos for UI changes.
-- Indicate if documentation updates are necessary.
-
-### Pull Request Policy
-
-- Must reference pre-approved, assigned issues.
-- PRs without adherence to the policy may be closed.
-- PRs should pass CI tests, align with the roadmap, and have clear documentation.
-
-### Review Process
-
-- **Daily Triage:** Quick checks by maintainers.
-- **Weekly In-depth Review:** Comprehensive assessment.
-- **Iterate promptly** based on feedback.
-
-## Legal
-
-By contributing, you agree your contributions will be licensed under the Apache 2.0 License, consistent with Roo Code's licensing.

PRIVACY.md

@@ -1,28 +1,27 @@
 # Roo Code Privacy Policy
 
-**Last Updated: June 10th, 2025**
+**Last Updated: September 11th, 2025**
 
 Roo Code respects your privacy and is committed to transparency about how we handle your data. Below is a simple breakdown of where key pieces of data go—and, importantly, where they don’t.
 
 ### **Where Your Data Goes (And Where It Doesn’t)**
 
-- **Code & Files**: Roo Code accesses files on your local machine when needed for AI-assisted features. When you send commands to Roo Code, relevant files may be transmitted to your chosen AI model provider (e.g., OpenAI, Anthropic, OpenRouter) to generate responses. We do not have access to this data, but AI providers may store it per their privacy policies.
+- **Code & Files**: Roo Code accesses files on your local machine when needed for AI-assisted features. When you send commands to Roo Code, relevant files may be transmitted to your chosen AI model provider (e.g., OpenAI, Anthropic, OpenRouter) to generate responses. AI providers may store data per their privacy policies.
 - **Commands**: Any commands executed through Roo Code happen on your local environment. However, when you use AI-powered features, the relevant code and context from your commands may be transmitted to your chosen AI model provider (e.g., OpenAI, Anthropic, OpenRouter) to generate responses. We do not have access to or store this data, but AI providers may process it per their privacy policies.
 - **Prompts & AI Requests**: When you use AI-powered features, your prompts and relevant project context are sent to your chosen AI model provider (e.g., OpenAI, Anthropic, OpenRouter) to generate responses. We do not store or process this data. These AI providers have their own privacy policies and may store data per their terms of service.
 - **API Keys & Credentials**: If you enter an API key (e.g., to connect an AI model), it is stored locally on your device and never sent to us or any third party, except the provider you have chosen.
-- **Telemetry (Usage Data)**: We only collect feature usage and error data if you explicitly opt-in. This telemetry is powered by PostHog and helps us understand feature usage to improve Roo Code. This includes your VS Code machine ID and feature usage patterns and exception reports. We do **not** collect personally identifiable information, your code, or AI prompts.
-- **Marketplace Requests**: When you browse or search the Marketplace for Model Configuration Profiles (MCPs) or Custom Modes, Roo Code makes a secure API call to Roo Code’s backend servers to retrieve listing information. These requests send only the query parameters (e.g., extension version, search term) necessary to fulfill the request and do not include your code, prompts, or personally identifiable information.
+- **Telemetry (Usage Data)**: We collect anonymous feature usage and error data to help us improve Roo Code. This telemetry is powered by PostHog and includes your VS Code machine ID, feature usage patterns, and exception reports. This telemetry does **not** collect personally identifiable information, your code, or AI prompts. You can opt out of this telemetry at any time through the settings.
 
 ### **How We Use Your Data (If Collected)**
 
-- If you opt-in to telemetry, we use it to understand feature usage and improve Roo Code.
+- We use telemetry to understand feature usage and improve Roo Code.
 - We do **not** sell or share your data.
 - We do **not** train any models on your data.
 
 ### **Your Choices & Control**
 
 - You can run models locally to prevent data being sent to third-parties.
-- By default, telemetry collection is off and if you turn it on, you can opt out of telemetry at any time.
+- Telemetry collection is enabled by default to help us improve Roo Code, but you can opt out at any time through the settings.
 - You can delete Roo Code to stop all data collection.
 
 ### **Security & Updates**

README.md

@@ -1,222 +1,77 @@
-<div align="center">
-<sub>
+<p align="center">
+  <a href="https://marketplace.visualstudio.com/items?itemName=RooVeterinaryInc.roo-cline"><img src="https://img.shields.io/badge/VS_Code_Marketplace-007ACC?style=flat&logo=visualstudiocode&logoColor=white" alt="VS Code Marketplace"></a>  
+</p>
 
-<b>English</b> • [Català](locales/ca/README.md) • [Deutsch](locales/de/README.md) • [Español](locales/es/README.md) • [Français](locales/fr/README.md) • [हिंदी](locales/hi/README.md) • [Bahasa Indonesia](locales/id/README.md) • [Italiano](locales/it/README.md) • [日本語](locales/ja/README.md)
+# Roo Code
 
-</sub>
-<sub>
+> Your AI-Powered Dev Team, Right in Your Editor
 
-[한국어](locales/ko/README.md) • [Nederlands](locales/nl/README.md) • [Polski](locales/pl/README.md) • [Português (BR)](locales/pt-BR/README.md) • [Русский](locales/ru/README.md) • [Türkçe](locales/tr/README.md) • [Tiếng Việt](locales/vi/README.md) • [简体中文](locales/zh-CN/README.md) • [繁體中文](locales/zh-TW/README.md)
+<details>
+  <summary>🌐 Available languages</summary>
 
-</sub>
-</div>
-<br>
-<div align="center">
-  <h1>Roo Code (prev. Roo Cline)</h1>
-  <p align="center">
-  <img src="https://media.githubusercontent.com/media/RooCodeInc/Roo-Code/main/src/assets/docs/demo.gif" width="100%" />
-  </p>
-  <p>Connect with developers, contribute ideas, and stay ahead with the latest AI-powered coding tools.</p>
-  
-  <a href="https://discord.gg/roocode" target="_blank"><img src="https://img.shields.io/badge/Join%20Discord-5865F2?style=for-the-badge&logo=discord&logoColor=white" alt="Join Discord"></a>
-  <a href="https://www.reddit.com/r/RooCode/" target="_blank"><img src="https://img.shields.io/badge/Join%20Reddit-FF4500?style=for-the-badge&logo=reddit&logoColor=white" alt="Join Reddit"></a>
-  
-</div>
-<br>
-<br>
-
-<div align="center">
-
-<a href="https://marketplace.visualstudio.com/items?itemName=RooVeterinaryInc.roo-cline" target="_blank"><img src="https://img.shields.io/badge/Download%20on%20VS%20Marketplace-blue?style=for-the-badge&logo=visualstudiocode&logoColor=white" alt="Download on VS Marketplace"></a>
-<a href="https://github.com/RooCodeInc/Roo-Code/discussions/categories/feature-requests?discussions_q=is%3Aopen+category%3A%22Feature+Requests%22+sort%3Atop" target="_blank"><img src="https://img.shields.io/badge/Feature%20Requests-yellow?style=for-the-badge" alt="Feature Requests"></a>
-<a href="https://marketplace.visualstudio.com/items?itemName=RooVeterinaryInc.roo-cline&ssr=false#review-details" target="_blank"><img src="https://img.shields.io/badge/Rate%20%26%20Review-green?style=for-the-badge" alt="Rate & Review"></a>
-<a href="https://docs.roocode.com" target="_blank"><img src="https://img.shields.io/badge/Documentation-6B46C1?style=for-the-badge&logo=readthedocs&logoColor=white" alt="Documentation"></a>
-
-</div>
-
-**Roo Code** is an AI-powered **autonomous coding agent** that lives in your editor. It can:
-
-- Communicate in natural language
-- Read and write files directly in your workspace
-- Run terminal commands
-- Automate browser actions
-- Integrate with any OpenAI-compatible or custom API/model
-- Adapt its “personality” and capabilities through **Custom Modes**
-
-Whether you’re seeking a flexible coding partner, a system architect, or specialized roles like a QA engineer or product manager, Roo Code can help you build software more efficiently.
-
-Check out the [CHANGELOG](CHANGELOG.md) for detailed updates and fixes.
+- [English](README.md)
+- [Català](locales/ca/README.md)
+- [Deutsch](locales/de/README.md)
+- [Español](locales/es/README.md)
+- [Français](locales/fr/README.md)
+- [हिंदी](locales/hi/README.md)
+- [Bahasa Indonesia](locales/id/README.md)
+- [Italiano](locales/it/README.md)
+- [日本語](locales/ja/README.md)
+- [한국어](locales/ko/README.md)
+- [Nederlands](locales/nl/README.md)
+- [Polski](locales/pl/README.md)
+- [Português (BR)](locales/pt-BR/README.md)
+- [Русский](locales/ru/README.md)
+- [Türkçe](locales/tr/README.md)
+- [Tiếng Việt](locales/vi/README.md)
+- [简体中文](locales/zh-CN/README.md)
+- [繁體中文](locales/zh-TW/README.md)
+- ...
+    </details>
 
 ---
 
-## 🎉 Roo Code 3.21 Released
+## What Can Roo Code Do For YOU?
 
-Roo Code 3.21 brings major new features and improvements based on your feedback!
+- Generate Code from natural language descriptions and specs
+- Adapt with Modes: Code, Architect, Ask, Debug, and Custom Modes
+- Refactor & Debug existing code
+- Write & Update documentation
+- Answer Questions about your codebase
+- Automate repetitive tasks
+- Utilize MCP Servers
 
-- **Roo Marketplace Launch** - The marketplace is now live! The marketplace is now live! Discover and install modes and MCPs easier than ever before.
-- **Gemini 2.5 Models** - Added support for new Gemini 2.5 Pro, Flash, and Flash Lite models.
-- **Excel File Support & More** - Added Excel (.xlsx) file support and numerous bug fixes and improvements!
+## Modes
 
----
+Roo Code adapts to how you work:
 
-## What Can Roo Code Do?
+- Code Mode: everyday coding, edits, and file ops
+- Architect Mode: plan systems, specs, and migrations
+- Ask Mode: fast answers, explanations, and docs
+- Debug Mode: trace issues, add logs, isolate root causes
+- Custom Modes: build specialized modes for your team or workflow
 
-- 🚀 **Generate Code** from natural language descriptions
-- 🔧 **Refactor & Debug** existing code
-- 📝 **Write & Update** documentation
-- 🤔 **Answer Questions** about your codebase
-- 🔄 **Automate** repetitive tasks
-- 🏗️ **Create** new files and projects
-
-## Quick Start
-
-1. [Install Roo Code](https://docs.roocode.com/getting-started/installing)
-2. [Connect Your AI Provider](https://docs.roocode.com/getting-started/connecting-api-provider)
-3. [Try Your First Task](https://docs.roocode.com/getting-started/your-first-task)
-
-## Key Features
-
-### Multiple Modes
-
-Roo Code adapts to your needs with specialized [modes](https://docs.roocode.com/basic-usage/using-modes):
-
-- **Code Mode:** For general-purpose coding tasks
-- **Architect Mode:** For planning and technical leadership
-- **Ask Mode:** For answering questions and providing information
-- **Debug Mode:** For systematic problem diagnosis
-- **[Custom Modes](https://docs.roocode.com/advanced-usage/custom-modes):** Create unlimited specialized personas for security auditing, performance optimization, documentation, or any other task
-
-### Smart Tools
-
-Roo Code comes with powerful [tools](https://docs.roocode.com/basic-usage/how-tools-work) that can:
-
-- Read and write files in your project
-- Execute commands in your VS Code terminal
-- Control a web browser
-- Use external tools via [MCP (Model Context Protocol)](https://docs.roocode.com/advanced-usage/mcp)
-
-MCP extends Roo Code's capabilities by allowing you to add unlimited custom tools. Integrate with external APIs, connect to databases, or create specialized development tools - MCP provides the framework to expand Roo Code's functionality to meet your specific needs.
-
-### Customization
-
-Make Roo Code work your way with:
-
-- [Custom Instructions](https://docs.roocode.com/advanced-usage/custom-instructions) for personalized behavior
-- [Custom Modes](https://docs.roocode.com/advanced-usage/custom-modes) for specialized tasks
-- [Local Models](https://docs.roocode.com/advanced-usage/local-models) for offline use
-- [Auto-Approval Settings](https://docs.roocode.com/advanced-usage/auto-approving-actions) for faster workflows
+Learn more: [Using Modes](https://roocodeinc.github.io/Roo-Code/basic-usage/using-modes) • [Custom Modes](https://roocodeinc.github.io/Roo-Code/advanced-usage/custom-modes)
 
 ## Resources
 
-### Documentation
-
-- [Basic Usage Guide](https://docs.roocode.com/basic-usage/the-chat-interface)
-- [Advanced Features](https://docs.roocode.com/advanced-usage/auto-approving-actions)
-- [Frequently Asked Questions](https://docs.roocode.com/faq)
-
-### Community
-
-- **Discord:** [Join our Discord server](https://discord.gg/roocode) for real-time help and discussions
-- **Reddit:** [Visit our subreddit](https://www.reddit.com/r/RooCode) to share experiences and tips
-- **GitHub:** Report [issues](https://github.com/RooCodeInc/Roo-Code/issues) or request [features](https://github.com/RooCodeInc/Roo-Code/discussions/categories/feature-requests?discussions_q=is%3Aopen+category%3A%22Feature+Requests%22+sort%3Atop)
-
----
-
-## Local Setup & Development
-
-1. **Clone** the repo:
-
-```sh
-git clone https://github.com/RooCodeInc/Roo-Code.git
-```
-
-2. **Install dependencies**:
-
-```sh
-pnpm install
-```
-
-3. **Run the extension**:
-
-Press `F5` (or **Run** → **Start Debugging**) in VSCode to open a new window with Roo Code running.
-
-Changes to the webview will appear immediately. Changes to the core extension will require a restart of the extension host.
-
-Alternatively you can build a .vsix and install it directly in VSCode:
-
-```sh
-pnpm vsix
-```
-
-A `.vsix` file will appear in the `bin/` directory which can be installed with:
-
-```sh
-code --install-extension bin/roo-cline-<version>.vsix
-```
-
-We use [changesets](https://github.com/changesets/changesets) for versioning and publishing. Check our `CHANGELOG.md` for release notes.
+- **[Documentation](https://roocodeinc.github.io/Roo-Code/):** The official guide to installing, configuring, and mastering Roo Code.
+- **[GitHub Issues](https://github.com/RooCodeInc/Roo-Code/issues):** Report bugs and track development.
 
 ---
 
 ## Disclaimer
 
+The Roo Code Extension was shut down on May 15th.
+
+- If you're looking for an alternative, check out [ZooCode](https://github.com/Zoo-Code-Org/Zoo-Code/) (a fork started by the Roo Code community) and [Cline](https://cline.bot/) (from where Roo Code originated).
+- If you were a paying user and have billing questions, please write [billing@roocode.com](mailto:billing@roocode.com).
+
 **Please note** that Roo Code, Inc does **not** make any representations or warranties regarding any code, models, or other tools provided or made available in connection with Roo Code, any associated third-party tools, or any resulting outputs. You assume **all risks** associated with the use of any such tools or outputs; such tools are provided on an **"AS IS"** and **"AS AVAILABLE"** basis. Such risks may include, without limitation, intellectual property infringement, cyber vulnerabilities or attacks, bias, inaccuracies, errors, defects, viruses, downtime, property loss or damage, and/or personal injury. You are solely responsible for your use of any such tools or outputs (including, without limitation, the legality, appropriateness, and results thereof).
 
 ---
 
-## Contributing
-
-We love community contributions! Get started by reading our [CONTRIBUTING.md](CONTRIBUTING.md).
-
----
-
-## Contributors
-
-Thanks to all our contributors who have helped make Roo Code better!
-
-<!-- START CONTRIBUTORS SECTION - AUTO-GENERATED, DO NOT EDIT MANUALLY -->
-
-|                     <a href="https://github.com/mrubens"><img src="https://avatars.githubusercontent.com/u/2600?v=4" width="100" height="100" alt="mrubens"/><br /><sub><b>mrubens</b></sub></a>                      |         <a href="https://github.com/saoudrizwan"><img src="https://avatars.githubusercontent.com/u/7799382?v=4" width="100" height="100" alt="saoudrizwan"/><br /><sub><b>saoudrizwan</b></sub></a>         |                <a href="https://github.com/cte"><img src="https://avatars.githubusercontent.com/u/16332?v=4" width="100" height="100" alt="cte"/><br /><sub><b>cte</b></sub></a>                 |               <a href="https://github.com/samhvw8"><img src="https://avatars.githubusercontent.com/u/12538214?v=4" width="100" height="100" alt="samhvw8"/><br /><sub><b>samhvw8</b></sub></a>               |          <a href="https://github.com/daniel-lxs"><img src="https://avatars.githubusercontent.com/u/57051444?v=4" width="100" height="100" alt="daniel-lxs"/><br /><sub><b>daniel-lxs</b></sub></a>          |            <a href="https://github.com/hannesrudolph"><img src="https://avatars.githubusercontent.com/u/49103247?v=4" width="100" height="100" alt="hannesrudolph"/><br /><sub><b>hannesrudolph</b></sub></a>            |
-| :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |
-|                     <a href="https://github.com/KJ7LNW"><img src="https://avatars.githubusercontent.com/u/93454819?v=4" width="100" height="100" alt="KJ7LNW"/><br /><sub><b>KJ7LNW</b></sub></a>                     |              <a href="https://github.com/a8trejo"><img src="https://avatars.githubusercontent.com/u/62401433?v=4" width="100" height="100" alt="a8trejo"/><br /><sub><b>a8trejo</b></sub></a>               |    <a href="https://github.com/ColemanRoo"><img src="https://avatars.githubusercontent.com/u/117104599?v=4" width="100" height="100" alt="ColemanRoo"/><br /><sub><b>ColemanRoo</b></sub></a>    |         <a href="https://github.com/canrobins13"><img src="https://avatars.githubusercontent.com/u/20544372?v=4" width="100" height="100" alt="canrobins13"/><br /><sub><b>canrobins13</b></sub></a>         |             <a href="https://github.com/stea9499"><img src="https://avatars.githubusercontent.com/u/4163795?v=4" width="100" height="100" alt="stea9499"/><br /><sub><b>stea9499</b></sub></a>              |              <a href="https://github.com/joemanley201"><img src="https://avatars.githubusercontent.com/u/8299960?v=4" width="100" height="100" alt="joemanley201"/><br /><sub><b>joemanley201</b></sub></a>              |
-|                <a href="https://github.com/System233"><img src="https://avatars.githubusercontent.com/u/20336040?v=4" width="100" height="100" alt="System233"/><br /><sub><b>System233</b></sub></a>                 |             <a href="https://github.com/jquanton"><img src="https://avatars.githubusercontent.com/u/88576563?v=4" width="100" height="100" alt="jquanton"/><br /><sub><b>jquanton</b></sub></a>             |    <a href="https://github.com/nissa-seru"><img src="https://avatars.githubusercontent.com/u/119150866?v=4" width="100" height="100" alt="nissa-seru"/><br /><sub><b>nissa-seru</b></sub></a>    |                        <a href="https://github.com/jr"><img src="https://avatars.githubusercontent.com/u/5629?v=4" width="100" height="100" alt="jr"/><br /><sub><b>jr</b></sub></a>                         |                <a href="https://github.com/NyxJae"><img src="https://avatars.githubusercontent.com/u/52313587?v=4" width="100" height="100" alt="NyxJae"/><br /><sub><b>NyxJae</b></sub></a>                |                   <a href="https://github.com/MuriloFP"><img src="https://avatars.githubusercontent.com/u/50873657?v=4" width="100" height="100" alt="MuriloFP"/><br /><sub><b>MuriloFP</b></sub></a>                    |
-|                  <a href="https://github.com/elianiva"><img src="https://avatars.githubusercontent.com/u/51877647?v=4" width="100" height="100" alt="elianiva"/><br /><sub><b>elianiva</b></sub></a>                  |                  <a href="https://github.com/d-oit"><img src="https://avatars.githubusercontent.com/u/6849456?v=4" width="100" height="100" alt="d-oit"/><br /><sub><b>d-oit</b></sub></a>                  |       <a href="https://github.com/punkpeye"><img src="https://avatars.githubusercontent.com/u/108313943?v=4" width="100" height="100" alt="punkpeye"/><br /><sub><b>punkpeye</b></sub></a>       |           <a href="https://github.com/wkordalski"><img src="https://avatars.githubusercontent.com/u/3035587?v=4" width="100" height="100" alt="wkordalski"/><br /><sub><b>wkordalski</b></sub></a>           |            <a href="https://github.com/xyOz-dev"><img src="https://avatars.githubusercontent.com/u/195602624?v=4" width="100" height="100" alt="xyOz-dev"/><br /><sub><b>xyOz-dev</b></sub></a>             |                 <a href="https://github.com/sachasayan"><img src="https://avatars.githubusercontent.com/u/1666034?v=4" width="100" height="100" alt="sachasayan"/><br /><sub><b>sachasayan</b></sub></a>                 |
-| <a href="https://github.com/Smartsheet-JB-Brown"><img src="https://avatars.githubusercontent.com/u/171734120?v=4" width="100" height="100" alt="Smartsheet-JB-Brown"/><br /><sub><b>Smartsheet-JB-Brown</b></sub></a> |       <a href="https://github.com/monotykamary"><img src="https://avatars.githubusercontent.com/u/1130103?v=4" width="100" height="100" alt="monotykamary"/><br /><sub><b>monotykamary</b></sub></a>        |         <a href="https://github.com/cannuri"><img src="https://avatars.githubusercontent.com/u/91494156?v=4" width="100" height="100" alt="cannuri"/><br /><sub><b>cannuri</b></sub></a>         |            <a href="https://github.com/feifei325"><img src="https://avatars.githubusercontent.com/u/46489071?v=4" width="100" height="100" alt="feifei325"/><br /><sub><b>feifei325</b></sub></a>            |      <a href="https://github.com/zhangtony239"><img src="https://avatars.githubusercontent.com/u/157202938?v=4" width="100" height="100" alt="zhangtony239"/><br /><sub><b>zhangtony239</b></sub></a>       |                        <a href="https://github.com/qdaxb"><img src="https://avatars.githubusercontent.com/u/4157870?v=4" width="100" height="100" alt="qdaxb"/><br /><sub><b>qdaxb</b></sub></a>                         |
-|             <a href="https://github.com/shariqriazz"><img src="https://avatars.githubusercontent.com/u/196900129?v=4" width="100" height="100" alt="shariqriazz"/><br /><sub><b>shariqriazz</b></sub></a>             |     <a href="https://github.com/pugazhendhi-m"><img src="https://avatars.githubusercontent.com/u/132246623?v=4" width="100" height="100" alt="pugazhendhi-m"/><br /><sub><b>pugazhendhi-m</b></sub></a>     |        <a href="https://github.com/dtrugman"><img src="https://avatars.githubusercontent.com/u/2451669?v=4" width="100" height="100" alt="dtrugman"/><br /><sub><b>dtrugman</b></sub></a>        |           <a href="https://github.com/lloydchang"><img src="https://avatars.githubusercontent.com/u/1329685?v=4" width="100" height="100" alt="lloydchang"/><br /><sub><b>lloydchang</b></sub></a>           | <a href="https://github.com/vigneshsubbiah16"><img src="https://avatars.githubusercontent.com/u/51325334?v=4" width="100" height="100" alt="vigneshsubbiah16"/><br /><sub><b>vigneshsubbiah16</b></sub></a> |                     <a href="https://github.com/Szpadel"><img src="https://avatars.githubusercontent.com/u/1857251?v=4" width="100" height="100" alt="Szpadel"/><br /><sub><b>Szpadel</b></sub></a>                      |
-|                <a href="https://github.com/lupuletic"><img src="https://avatars.githubusercontent.com/u/105351510?v=4" width="100" height="100" alt="lupuletic"/><br /><sub><b>lupuletic</b></sub></a>                |                <a href="https://github.com/kiwina"><img src="https://avatars.githubusercontent.com/u/1071364?v=4" width="100" height="100" alt="kiwina"/><br /><sub><b>kiwina</b></sub></a>                 |       <a href="https://github.com/Premshay"><img src="https://avatars.githubusercontent.com/u/28099628?v=4" width="100" height="100" alt="Premshay"/><br /><sub><b>Premshay</b></sub></a>        |               <a href="https://github.com/psv2522"><img src="https://avatars.githubusercontent.com/u/87223770?v=4" width="100" height="100" alt="psv2522"/><br /><sub><b>psv2522</b></sub></a>               |        <a href="https://github.com/olweraltuve"><img src="https://avatars.githubusercontent.com/u/39308405?v=4" width="100" height="100" alt="olweraltuve"/><br /><sub><b>olweraltuve</b></sub></a>         |       <a href="https://github.com/diarmidmackenzie"><img src="https://avatars.githubusercontent.com/u/16045703?v=4" width="100" height="100" alt="diarmidmackenzie"/><br /><sub><b>diarmidmackenzie</b></sub></a>        |
-|             <a href="https://github.com/chrarnoldus"><img src="https://avatars.githubusercontent.com/u/12196001?v=4" width="100" height="100" alt="chrarnoldus"/><br /><sub><b>chrarnoldus</b></sub></a>              |    <a href="https://github.com/PeterDaveHello"><img src="https://avatars.githubusercontent.com/u/3691490?v=4" width="100" height="100" alt="PeterDaveHello"/><br /><sub><b>PeterDaveHello</b></sub></a>     |           <a href="https://github.com/aheizi"><img src="https://avatars.githubusercontent.com/u/8243770?v=4" width="100" height="100" alt="aheizi"/><br /><sub><b>aheizi</b></sub></a>           |        <a href="https://github.com/afshawnlotfi"><img src="https://avatars.githubusercontent.com/u/6283745?v=4" width="100" height="100" alt="afshawnlotfi"/><br /><sub><b>afshawnlotfi</b></sub></a>        |           <a href="https://github.com/RaySinner"><img src="https://avatars.githubusercontent.com/u/118297374?v=4" width="100" height="100" alt="RaySinner"/><br /><sub><b>RaySinner</b></sub></a>           |         <a href="https://github.com/nbihan-mediware"><img src="https://avatars.githubusercontent.com/u/42357253?v=4" width="100" height="100" alt="nbihan-mediware"/><br /><sub><b>nbihan-mediware</b></sub></a>         |
-|                  <a href="https://github.com/ChuKhaLi"><img src="https://avatars.githubusercontent.com/u/15166543?v=4" width="100" height="100" alt="ChuKhaLi"/><br /><sub><b>ChuKhaLi</b></sub></a>                  |             <a href="https://github.com/hassoncs"><img src="https://avatars.githubusercontent.com/u/5104925?v=4" width="100" height="100" alt="hassoncs"/><br /><sub><b>hassoncs</b></sub></a>              |        <a href="https://github.com/emshvac"><img src="https://avatars.githubusercontent.com/u/121588911?v=4" width="100" height="100" alt="emshvac"/><br /><sub><b>emshvac</b></sub></a>         |            <a href="https://github.com/kyle-apex"><img src="https://avatars.githubusercontent.com/u/20145331?v=4" width="100" height="100" alt="kyle-apex"/><br /><sub><b>kyle-apex</b></sub></a>            |      <a href="https://github.com/noritaka1166"><img src="https://avatars.githubusercontent.com/u/189505037?v=4" width="100" height="100" alt="noritaka1166"/><br /><sub><b>noritaka1166</b></sub></a>       |                       <a href="https://github.com/pdecat"><img src="https://avatars.githubusercontent.com/u/318490?v=4" width="100" height="100" alt="pdecat"/><br /><sub><b>pdecat</b></sub></a>                        |
-|           <a href="https://github.com/SannidhyaSah"><img src="https://avatars.githubusercontent.com/u/186946675?v=4" width="100" height="100" alt="SannidhyaSah"/><br /><sub><b>SannidhyaSah</b></sub></a>            |      <a href="https://github.com/StevenTCramer"><img src="https://avatars.githubusercontent.com/u/357219?v=4" width="100" height="100" alt="StevenTCramer"/><br /><sub><b>StevenTCramer</b></sub></a>       |      <a href="https://github.com/Lunchb0ne"><img src="https://avatars.githubusercontent.com/u/22198661?v=4" width="100" height="100" alt="Lunchb0ne"/><br /><sub><b>Lunchb0ne</b></sub></a>      |           <a href="https://github.com/SmartManoj"><img src="https://avatars.githubusercontent.com/u/7231077?v=4" width="100" height="100" alt="SmartManoj"/><br /><sub><b>SmartManoj</b></sub></a>           |             <a href="https://github.com/vagadiya"><img src="https://avatars.githubusercontent.com/u/32499123?v=4" width="100" height="100" alt="vagadiya"/><br /><sub><b>vagadiya</b></sub></a>             |             <a href="https://github.com/slytechnical"><img src="https://avatars.githubusercontent.com/u/139649758?v=4" width="100" height="100" alt="slytechnical"/><br /><sub><b>slytechnical</b></sub></a>             |
-|                    <a href="https://github.com/dleffel"><img src="https://avatars.githubusercontent.com/u/7119958?v=4" width="100" height="100" alt="dleffel"/><br /><sub><b>dleffel</b></sub></a>                    |     <a href="https://github.com/arthurauffray"><img src="https://avatars.githubusercontent.com/u/51604173?v=4" width="100" height="100" alt="arthurauffray"/><br /><sub><b>arthurauffray</b></sub></a>      |         <a href="https://github.com/upamune"><img src="https://avatars.githubusercontent.com/u/8219560?v=4" width="100" height="100" alt="upamune"/><br /><sub><b>upamune</b></sub></a>          |               <a href="https://github.com/NamesMT"><img src="https://avatars.githubusercontent.com/u/23612546?v=4" width="100" height="100" alt="NamesMT"/><br /><sub><b>NamesMT</b></sub></a>               |      <a href="https://github.com/taylorwilsdon"><img src="https://avatars.githubusercontent.com/u/6508528?v=4" width="100" height="100" alt="taylorwilsdon"/><br /><sub><b>taylorwilsdon</b></sub></a>      |                       <a href="https://github.com/sammcj"><img src="https://avatars.githubusercontent.com/u/862951?v=4" width="100" height="100" alt="sammcj"/><br /><sub><b>sammcj</b></sub></a>                        |
-|                     <a href="https://github.com/Ruakij"><img src="https://avatars.githubusercontent.com/u/54639830?v=4" width="100" height="100" alt="Ruakij"/><br /><sub><b>Ruakij</b></sub></a>                     |                <a href="https://github.com/p12tic"><img src="https://avatars.githubusercontent.com/u/1056711?v=4" width="100" height="100" alt="p12tic"/><br /><sub><b>p12tic</b></sub></a>                 |          <a href="https://github.com/gtaylor"><img src="https://avatars.githubusercontent.com/u/75556?v=4" width="100" height="100" alt="gtaylor"/><br /><sub><b>gtaylor</b></sub></a>           |            <a href="https://github.com/aitoroses"><img src="https://avatars.githubusercontent.com/u/1699368?v=4" width="100" height="100" alt="aitoroses"/><br /><sub><b>aitoroses</b></sub></a>             |            <a href="https://github.com/benzntech"><img src="https://avatars.githubusercontent.com/u/4044180?v=4" width="100" height="100" alt="benzntech"/><br /><sub><b>benzntech</b></sub></a>            |            <a href="https://github.com/mr-ryan-james"><img src="https://avatars.githubusercontent.com/u/9344431?v=4" width="100" height="100" alt="mr-ryan-james"/><br /><sub><b>mr-ryan-james</b></sub></a>             |
-|                    <a href="https://github.com/heyseth"><img src="https://avatars.githubusercontent.com/u/8293842?v=4" width="100" height="100" alt="heyseth"/><br /><sub><b>heyseth</b></sub></a>                    |            <a href="https://github.com/taisukeoe"><img src="https://avatars.githubusercontent.com/u/1506707?v=4" width="100" height="100" alt="taisukeoe"/><br /><sub><b>taisukeoe</b></sub></a>            |             <a href="https://github.com/avtc"><img src="https://avatars.githubusercontent.com/u/10050240?v=4" width="100" height="100" alt="avtc"/><br /><sub><b>avtc</b></sub></a>              |          <a href="https://github.com/dlab-anton"><img src="https://avatars.githubusercontent.com/u/20571486?v=4" width="100" height="100" alt="dlab-anton"/><br /><sub><b>dlab-anton</b></sub></a>           |                 <a href="https://github.com/eonghk"><img src="https://avatars.githubusercontent.com/u/139964?v=4" width="100" height="100" alt="eonghk"/><br /><sub><b>eonghk</b></sub></a>                 |                     <a href="https://github.com/kcwhite"><img src="https://avatars.githubusercontent.com/u/3812801?v=4" width="100" height="100" alt="kcwhite"/><br /><sub><b>kcwhite</b></sub></a>                      |
-|                  <a href="https://github.com/ronyblum"><img src="https://avatars.githubusercontent.com/u/20314054?v=4" width="100" height="100" alt="ronyblum"/><br /><sub><b>ronyblum</b></sub></a>                  |           <a href="https://github.com/teddyOOXX"><img src="https://avatars.githubusercontent.com/u/121077180?v=4" width="100" height="100" alt="teddyOOXX"/><br /><sub><b>teddyOOXX</b></sub></a>           |   <a href="https://github.com/vincentsong"><img src="https://avatars.githubusercontent.com/u/2343574?v=4" width="100" height="100" alt="vincentsong"/><br /><sub><b>vincentsong</b></sub></a>    |               <a href="https://github.com/yongjer"><img src="https://avatars.githubusercontent.com/u/54315206?v=4" width="100" height="100" alt="yongjer"/><br /><sub><b>yongjer</b></sub></a>               |           <a href="https://github.com/zeozeozeo"><img src="https://avatars.githubusercontent.com/u/108888572?v=4" width="100" height="100" alt="zeozeozeo"/><br /><sub><b>zeozeozeo</b></sub></a>           |                       <a href="https://github.com/ashktn"><img src="https://avatars.githubusercontent.com/u/6723913?v=4" width="100" height="100" alt="ashktn"/><br /><sub><b>ashktn</b></sub></a>                       |
-|                    <a href="https://github.com/franekp"><img src="https://avatars.githubusercontent.com/u/9804230?v=4" width="100" height="100" alt="franekp"/><br /><sub><b>franekp</b></sub></a>                    |             <a href="https://github.com/yt3trees"><img src="https://avatars.githubusercontent.com/u/57471763?v=4" width="100" height="100" alt="yt3trees"/><br /><sub><b>yt3trees</b></sub></a>             |    <a href="https://github.com/axkirillov"><img src="https://avatars.githubusercontent.com/u/32141102?v=4" width="100" height="100" alt="axkirillov"/><br /><sub><b>axkirillov</b></sub></a>     |          <a href="https://github.com/anton-otee"><img src="https://avatars.githubusercontent.com/u/149477749?v=4" width="100" height="100" alt="anton-otee"/><br /><sub><b>anton-otee</b></sub></a>          |             <a href="https://github.com/bramburn"><img src="https://avatars.githubusercontent.com/u/11090413?v=4" width="100" height="100" alt="bramburn"/><br /><sub><b>bramburn</b></sub></a>             |                 <a href="https://github.com/olearycrew"><img src="https://avatars.githubusercontent.com/u/6044920?v=4" width="100" height="100" alt="olearycrew"/><br /><sub><b>olearycrew</b></sub></a>                 |
-|             <a href="https://github.com/brunobergher"><img src="https://avatars.githubusercontent.com/u/328388?v=4" width="100" height="100" alt="brunobergher"/><br /><sub><b>brunobergher</b></sub></a>             |             <a href="https://github.com/snoyiatk"><img src="https://avatars.githubusercontent.com/u/3056569?v=4" width="100" height="100" alt="snoyiatk"/><br /><sub><b>snoyiatk</b></sub></a>              | <a href="https://github.com/GitlyHallows"><img src="https://avatars.githubusercontent.com/u/136527758?v=4" width="100" height="100" alt="GitlyHallows"/><br /><sub><b>GitlyHallows</b></sub></a> |                <a href="https://github.com/jcbdev"><img src="https://avatars.githubusercontent.com/u/17152092?v=4" width="100" height="100" alt="jcbdev"/><br /><sub><b>jcbdev</b></sub></a>                 |    <a href="https://github.com/Chenjiayuan195"><img src="https://avatars.githubusercontent.com/u/30591313?v=4" width="100" height="100" alt="Chenjiayuan195"/><br /><sub><b>Chenjiayuan195</b></sub></a>    |                   <a href="https://github.com/julionav"><img src="https://avatars.githubusercontent.com/u/45607850?v=4" width="100" height="100" alt="julionav"/><br /><sub><b>julionav</b></sub></a>                    |
-|               <a href="https://github.com/SplittyDev"><img src="https://avatars.githubusercontent.com/u/4216049?v=4" width="100" height="100" alt="SplittyDev"/><br /><sub><b>SplittyDev</b></sub></a>                |                      <a href="https://github.com/mdp"><img src="https://avatars.githubusercontent.com/u/2868?v=4" width="100" height="100" alt="mdp"/><br /><sub><b>mdp</b></sub></a>                       |           <a href="https://github.com/napter"><img src="https://avatars.githubusercontent.com/u/6260841?v=4" width="100" height="100" alt="napter"/><br /><sub><b>napter</b></sub></a>           |                     <a href="https://github.com/ross"><img src="https://avatars.githubusercontent.com/u/12789?v=4" width="100" height="100" alt="ross"/><br /><sub><b>ross</b></sub></a>                     |             <a href="https://github.com/philfung"><img src="https://avatars.githubusercontent.com/u/1054593?v=4" width="100" height="100" alt="philfung"/><br /><sub><b>philfung</b></sub></a>              |                    <a href="https://github.com/dairui1"><img src="https://avatars.githubusercontent.com/u/183250644?v=4" width="100" height="100" alt="dairui1"/><br /><sub><b>dairui1</b></sub></a>                     |
-|                    <a href="https://github.com/dqroid"><img src="https://avatars.githubusercontent.com/u/192424994?v=4" width="100" height="100" alt="dqroid"/><br /><sub><b>dqroid</b></sub></a>                     |            <a href="https://github.com/forestyoo"><img src="https://avatars.githubusercontent.com/u/2929056?v=4" width="100" height="100" alt="forestyoo"/><br /><sub><b>forestyoo</b></sub></a>            |    <a href="https://github.com/GOODBOY008"><img src="https://avatars.githubusercontent.com/u/13617900?v=4" width="100" height="100" alt="GOODBOY008"/><br /><sub><b>GOODBOY008</b></sub></a>     |               <a href="https://github.com/hatsu38"><img src="https://avatars.githubusercontent.com/u/16137809?v=4" width="100" height="100" alt="hatsu38"/><br /><sub><b>hatsu38</b></sub></a>               |              <a href="https://github.com/hongzio"><img src="https://avatars.githubusercontent.com/u/11085613?v=4" width="100" height="100" alt="hongzio"/><br /><sub><b>hongzio</b></sub></a>               |                      <a href="https://github.com/im47cn"><img src="https://avatars.githubusercontent.com/u/67424112?v=4" width="100" height="100" alt="im47cn"/><br /><sub><b>im47cn</b></sub></a>                       |
-|                  <a href="https://github.com/shoopapa"><img src="https://avatars.githubusercontent.com/u/45986634?v=4" width="100" height="100" alt="shoopapa"/><br /><sub><b>shoopapa</b></sub></a>                  |               <a href="https://github.com/jwcraig"><img src="https://avatars.githubusercontent.com/u/241358?v=4" width="100" height="100" alt="jwcraig"/><br /><sub><b>jwcraig</b></sub></a>                |    <a href="https://github.com/nevermorec"><img src="https://avatars.githubusercontent.com/u/22953064?v=4" width="100" height="100" alt="nevermorec"/><br /><sub><b>nevermorec</b></sub></a>     |               <a href="https://github.com/bannzai"><img src="https://avatars.githubusercontent.com/u/10897361?v=4" width="100" height="100" alt="bannzai"/><br /><sub><b>bannzai</b></sub></a>               |                   <a href="https://github.com/axmo"><img src="https://avatars.githubusercontent.com/u/2386344?v=4" width="100" height="100" alt="axmo"/><br /><sub><b>axmo</b></sub></a>                    |                    <a href="https://github.com/asychin"><img src="https://avatars.githubusercontent.com/u/178776568?v=4" width="100" height="100" alt="asychin"/><br /><sub><b>asychin</b></sub></a>                     |
-|                  <a href="https://github.com/amittell"><img src="https://avatars.githubusercontent.com/u/1388680?v=4" width="100" height="100" alt="amittell"/><br /><sub><b>amittell</b></sub></a>                   | <a href="https://github.com/Yoshino-Yukitaro"><img src="https://avatars.githubusercontent.com/u/67864326?v=4" width="100" height="100" alt="Yoshino-Yukitaro"/><br /><sub><b>Yoshino-Yukitaro</b></sub></a> |    <a href="https://github.com/Yikai-Liao"><img src="https://avatars.githubusercontent.com/u/110762732?v=4" width="100" height="100" alt="Yikai-Liao"/><br /><sub><b>Yikai-Liao</b></sub></a>    |                   <a href="https://github.com/zxdvd"><img src="https://avatars.githubusercontent.com/u/107175?v=4" width="100" height="100" alt="zxdvd"/><br /><sub><b>zxdvd</b></sub></a>                   |           <a href="https://github.com/vladstudio"><img src="https://avatars.githubusercontent.com/u/914320?v=4" width="100" height="100" alt="vladstudio"/><br /><sub><b>vladstudio</b></sub></a>           |                   <a href="https://github.com/tmsjngx0"><img src="https://avatars.githubusercontent.com/u/40481136?v=4" width="100" height="100" alt="tmsjngx0"/><br /><sub><b>tmsjngx0</b></sub></a>                    |
-|       <a href="https://github.com/Githubguy132010"><img src="https://avatars.githubusercontent.com/u/145768128?v=4" width="100" height="100" alt="Githubguy132010"/><br /><sub><b>Githubguy132010</b></sub></a>       |                  <a href="https://github.com/tgfjt"><img src="https://avatars.githubusercontent.com/u/2628239?v=4" width="100" height="100" alt="tgfjt"/><br /><sub><b>tgfjt</b></sub></a>                  | <a href="https://github.com/maekawataiki"><img src="https://avatars.githubusercontent.com/u/26317009?v=4" width="100" height="100" alt="maekawataiki"/><br /><sub><b>maekawataiki</b></sub></a>  |      <a href="https://github.com/PretzelVector"><img src="https://avatars.githubusercontent.com/u/95664360?v=4" width="100" height="100" alt="PretzelVector"/><br /><sub><b>PretzelVector</b></sub></a>      |             <a href="https://github.com/zetaloop"><img src="https://avatars.githubusercontent.com/u/36418285?v=4" width="100" height="100" alt="zetaloop"/><br /><sub><b>zetaloop</b></sub></a>             |                     <a href="https://github.com/cdlliuy"><img src="https://avatars.githubusercontent.com/u/17263036?v=4" width="100" height="100" alt="cdlliuy"/><br /><sub><b>cdlliuy</b></sub></a>                     |
-|               <a href="https://github.com/user202729"><img src="https://avatars.githubusercontent.com/u/25191436?v=4" width="100" height="100" alt="user202729"/><br /><sub><b>user202729</b></sub></a>               |       <a href="https://github.com/student20880"><img src="https://avatars.githubusercontent.com/u/74263488?v=4" width="100" height="100" alt="student20880"/><br /><sub><b>student20880</b></sub></a>       | <a href="https://github.com/shohei-ihaya"><img src="https://avatars.githubusercontent.com/u/25131938?v=4" width="100" height="100" alt="shohei-ihaya"/><br /><sub><b>shohei-ihaya</b></sub></a>  |                 <a href="https://github.com/shaybc"><img src="https://avatars.githubusercontent.com/u/8535905?v=4" width="100" height="100" alt="shaybc"/><br /><sub><b>shaybc</b></sub></a>                 |             <a href="https://github.com/seedlord"><img src="https://avatars.githubusercontent.com/u/20932878?v=4" width="100" height="100" alt="seedlord"/><br /><sub><b>seedlord</b></sub></a>             |             <a href="https://github.com/samir-nimbly"><img src="https://avatars.githubusercontent.com/u/112695483?v=4" width="100" height="100" alt="samir-nimbly"/><br /><sub><b>samir-nimbly</b></sub></a>             |
-|           <a href="https://github.com/robertheadley"><img src="https://avatars.githubusercontent.com/u/1780455?v=4" width="100" height="100" alt="robertheadley"/><br /><sub><b>robertheadley</b></sub></a>           |       <a href="https://github.com/refactorthis"><img src="https://avatars.githubusercontent.com/u/3012240?v=4" width="100" height="100" alt="refactorthis"/><br /><sub><b>refactorthis</b></sub></a>        |  <a href="https://github.com/qingyuan1109"><img src="https://avatars.githubusercontent.com/u/841732?v=4" width="100" height="100" alt="qingyuan1109"/><br /><sub><b>qingyuan1109</b></sub></a>   |               <a href="https://github.com/pokutuna"><img src="https://avatars.githubusercontent.com/u/57545?v=4" width="100" height="100" alt="pokutuna"/><br /><sub><b>pokutuna</b></sub></a>               |          <a href="https://github.com/philipnext"><img src="https://avatars.githubusercontent.com/u/81944499?v=4" width="100" height="100" alt="philipnext"/><br /><sub><b>philipnext</b></sub></a>          |               <a href="https://github.com/village-way"><img src="https://avatars.githubusercontent.com/u/11625846?v=4" width="100" height="100" alt="village-way"/><br /><sub><b>village-way</b></sub></a>               |
-|                  <a href="https://github.com/oprstchn"><img src="https://avatars.githubusercontent.com/u/16177972?v=4" width="100" height="100" alt="oprstchn"/><br /><sub><b>oprstchn</b></sub></a>                  |               <a href="https://github.com/nobu007"><img src="https://avatars.githubusercontent.com/u/8529529?v=4" width="100" height="100" alt="nobu007"/><br /><sub><b>nobu007</b></sub></a>               |       <a href="https://github.com/mosleyit"><img src="https://avatars.githubusercontent.com/u/189396442?v=4" width="100" height="100" alt="mosleyit"/><br /><sub><b>mosleyit</b></sub></a>       |         <a href="https://github.com/moqimoqidea"><img src="https://avatars.githubusercontent.com/u/39821951?v=4" width="100" height="100" alt="moqimoqidea"/><br /><sub><b>moqimoqidea</b></sub></a>         |               <a href="https://github.com/mlopezr"><img src="https://avatars.githubusercontent.com/u/8202027?v=4" width="100" height="100" alt="mlopezr"/><br /><sub><b>mlopezr</b></sub></a>               |                        <a href="https://github.com/mecab"><img src="https://avatars.githubusercontent.com/u/1580772?v=4" width="100" height="100" alt="mecab"/><br /><sub><b>mecab</b></sub></a>                         |
-|                        <a href="https://github.com/olup"><img src="https://avatars.githubusercontent.com/u/13785588?v=4" width="100" height="100" alt="olup"/><br /><sub><b>olup</b></sub></a>                        |         <a href="https://github.com/lightrabbit"><img src="https://avatars.githubusercontent.com/u/1521765?v=4" width="100" height="100" alt="lightrabbit"/><br /><sub><b>lightrabbit</b></sub></a>         |            <a href="https://github.com/kohii"><img src="https://avatars.githubusercontent.com/u/6891780?v=4" width="100" height="100" alt="kohii"/><br /><sub><b>kohii</b></sub></a>             |             <a href="https://github.com/kinandan"><img src="https://avatars.githubusercontent.com/u/186135699?v=4" width="100" height="100" alt="kinandan"/><br /><sub><b>kinandan</b></sub></a>             |               <a href="https://github.com/linegel"><img src="https://avatars.githubusercontent.com/u/1746296?v=4" width="100" height="100" alt="linegel"/><br /><sub><b>linegel</b></sub></a>               | <a href="https://github.com/edwin-truthsearch-io"><img src="https://avatars.githubusercontent.com/u/211044285?v=4" width="100" height="100" alt="edwin-truthsearch-io"/><br /><sub><b>edwin-truthsearch-io</b></sub></a> |
-|           <a href="https://github.com/EamonNerbonne"><img src="https://avatars.githubusercontent.com/u/803518?v=4" width="100" height="100" alt="EamonNerbonne"/><br /><sub><b>EamonNerbonne</b></sub></a>            |            <a href="https://github.com/dbasclpy"><img src="https://avatars.githubusercontent.com/u/139889137?v=4" width="100" height="100" alt="dbasclpy"/><br /><sub><b>dbasclpy</b></sub></a>             |      <a href="https://github.com/dflatline"><img src="https://avatars.githubusercontent.com/u/60121893?v=4" width="100" height="100" alt="dflatline"/><br /><sub><b>dflatline</b></sub></a>      |               <a href="https://github.com/Deon588"><img src="https://avatars.githubusercontent.com/u/12716437?v=4" width="100" height="100" alt="Deon588"/><br /><sub><b>Deon588</b></sub></a>               |                  <a href="https://github.com/dleen"><img src="https://avatars.githubusercontent.com/u/1297964?v=4" width="100" height="100" alt="dleen"/><br /><sub><b>dleen</b></sub></a>                  |                   <a href="https://github.com/devxpain"><img src="https://avatars.githubusercontent.com/u/170700110?v=4" width="100" height="100" alt="devxpain"/><br /><sub><b>devxpain</b></sub></a>                   |
-|                     <a href="https://github.com/CW-B-W"><img src="https://avatars.githubusercontent.com/u/76680670?v=4" width="100" height="100" alt="CW-B-W"/><br /><sub><b>CW-B-W</b></sub></a>                     |            <a href="https://github.com/chadgauth"><img src="https://avatars.githubusercontent.com/u/2413356?v=4" width="100" height="100" alt="chadgauth"/><br /><sub><b>chadgauth</b></sub></a>            |   <a href="https://github.com/thecolorblue"><img src="https://avatars.githubusercontent.com/u/13137?v=4" width="100" height="100" alt="thecolorblue"/><br /><sub><b>thecolorblue</b></sub></a>   |           <a href="https://github.com/bogdan0083"><img src="https://avatars.githubusercontent.com/u/7077307?v=4" width="100" height="100" alt="bogdan0083"/><br /><sub><b>bogdan0083</b></sub></a>           |             <a href="https://github.com/benashby"><img src="https://avatars.githubusercontent.com/u/1023089?v=4" width="100" height="100" alt="benashby"/><br /><sub><b>benashby</b></sub></a>              |                     <a href="https://github.com/Atlogit"><img src="https://avatars.githubusercontent.com/u/86947554?v=4" width="100" height="100" alt="Atlogit"/><br /><sub><b>Atlogit</b></sub></a>                     |
-|                <a href="https://github.com/atlasgong"><img src="https://avatars.githubusercontent.com/u/68199735?v=4" width="100" height="100" alt="atlasgong"/><br /><sub><b>atlasgong</b></sub></a>                 |   <a href="https://github.com/andreastempsch"><img src="https://avatars.githubusercontent.com/u/117991125?v=4" width="100" height="100" alt="andreastempsch"/><br /><sub><b>andreastempsch</b></sub></a>    |         <a href="https://github.com/alasano"><img src="https://avatars.githubusercontent.com/u/14372930?v=4" width="100" height="100" alt="alasano"/><br /><sub><b>alasano</b></sub></a>         |          <a href="https://github.com/QuinsZouls"><img src="https://avatars.githubusercontent.com/u/40646096?v=4" width="100" height="100" alt="QuinsZouls"/><br /><sub><b>QuinsZouls</b></sub></a>           |    <a href="https://github.com/HadesArchitect"><img src="https://avatars.githubusercontent.com/u/1742301?v=4" width="100" height="100" alt="HadesArchitect"/><br /><sub><b>HadesArchitect</b></sub></a>     |                       <a href="https://github.com/alarno"><img src="https://avatars.githubusercontent.com/u/4355547?v=4" width="100" height="100" alt="alarno"/><br /><sub><b>alarno</b></sub></a>                       |
-|                   <a href="https://github.com/nexon33"><img src="https://avatars.githubusercontent.com/u/47557266?v=4" width="100" height="100" alt="nexon33"/><br /><sub><b>nexon33</b></sub></a>                    |          <a href="https://github.com/adilhafeez"><img src="https://avatars.githubusercontent.com/u/13196462?v=4" width="100" height="100" alt="adilhafeez"/><br /><sub><b>adilhafeez</b></sub></a>          |   <a href="https://github.com/adamwlarson"><img src="https://avatars.githubusercontent.com/u/1392315?v=4" width="100" height="100" alt="adamwlarson"/><br /><sub><b>adamwlarson</b></sub></a>    |              <a href="https://github.com/adamhill"><img src="https://avatars.githubusercontent.com/u/188638?v=4" width="100" height="100" alt="adamhill"/><br /><sub><b>adamhill</b></sub></a>               |               <a href="https://github.com/AMHesch"><img src="https://avatars.githubusercontent.com/u/4777192?v=4" width="100" height="100" alt="AMHesch"/><br /><sub><b>AMHesch</b></sub></a>               |       <a href="https://github.com/AlexandruSmirnov"><img src="https://avatars.githubusercontent.com/u/210187997?v=4" width="100" height="100" alt="AlexandruSmirnov"/><br /><sub><b>AlexandruSmirnov</b></sub></a>       |
-|             <a href="https://github.com/samsilveira"><img src="https://avatars.githubusercontent.com/u/109295696?v=4" width="100" height="100" alt="samsilveira"/><br /><sub><b>samsilveira</b></sub></a>             |               <a href="https://github.com/01Rian"><img src="https://avatars.githubusercontent.com/u/109045233?v=4" width="100" height="100" alt="01Rian"/><br /><sub><b>01Rian</b></sub></a>                |                <a href="https://github.com/RSO"><img src="https://avatars.githubusercontent.com/u/139663?v=4" width="100" height="100" alt="RSO"/><br /><sub><b>RSO</b></sub></a>                | <a href="https://github.com/SECKainersdorfer"><img src="https://avatars.githubusercontent.com/u/155164204?v=4" width="100" height="100" alt="SECKainersdorfer"/><br /><sub><b>SECKainersdorfer</b></sub></a> |                  <a href="https://github.com/R-omk"><img src="https://avatars.githubusercontent.com/u/1633879?v=4" width="100" height="100" alt="R-omk"/><br /><sub><b>R-omk</b></sub></a>                  |                        <a href="https://github.com/Sarke"><img src="https://avatars.githubusercontent.com/u/2719310?v=4" width="100" height="100" alt="Sarke"/><br /><sub><b>Sarke</b></sub></a>                         |
-|             <a href="https://github.com/OlegOAndreev"><img src="https://avatars.githubusercontent.com/u/149705?v=4" width="100" height="100" alt="OlegOAndreev"/><br /><sub><b>OlegOAndreev</b></sub></a>             |                <a href="https://github.com/kvokka"><img src="https://avatars.githubusercontent.com/u/15954013?v=4" width="100" height="100" alt="kvokka"/><br /><sub><b>kvokka</b></sub></a>                |          <a href="https://github.com/ecmasx"><img src="https://avatars.githubusercontent.com/u/135958728?v=4" width="100" height="100" alt="ecmasx"/><br /><sub><b>ecmasx</b></sub></a>          |                 <a href="https://github.com/mollux"><img src="https://avatars.githubusercontent.com/u/3983285?v=4" width="100" height="100" alt="mollux"/><br /><sub><b>mollux</b></sub></a>                 |       <a href="https://github.com/marvijo-code"><img src="https://avatars.githubusercontent.com/u/82562019?v=4" width="100" height="100" alt="marvijo-code"/><br /><sub><b>marvijo-code</b></sub></a>       |                 <a href="https://github.com/markijbema"><img src="https://avatars.githubusercontent.com/u/624143?v=4" width="100" height="100" alt="markijbema"/><br /><sub><b>markijbema</b></sub></a>                  |
-|           <a href="https://github.com/mamertofabian"><img src="https://avatars.githubusercontent.com/u/7698436?v=4" width="100" height="100" alt="mamertofabian"/><br /><sub><b>mamertofabian</b></sub></a>           | <a href="https://github.com/monkeyDluffy6017"><img src="https://avatars.githubusercontent.com/u/9354193?v=4" width="100" height="100" alt="monkeyDluffy6017"/><br /><sub><b>monkeyDluffy6017</b></sub></a>  | <a href="https://github.com/libertyteeth"><img src="https://avatars.githubusercontent.com/u/32841567?v=4" width="100" height="100" alt="libertyteeth"/><br /><sub><b>libertyteeth</b></sub></a>  |                 <a href="https://github.com/shtse8"><img src="https://avatars.githubusercontent.com/u/8020099?v=4" width="100" height="100" alt="shtse8"/><br /><sub><b>shtse8</b></sub></a>                 |           <a href="https://github.com/Rexarrior"><img src="https://avatars.githubusercontent.com/u/25753287?v=4" width="100" height="100" alt="Rexarrior"/><br /><sub><b>Rexarrior</b></sub></a>            |               <a href="https://github.com/KanTakahiro"><img src="https://avatars.githubusercontent.com/u/64513424?v=4" width="100" height="100" alt="KanTakahiro"/><br /><sub><b>KanTakahiro</b></sub></a>               |
-|                         <a href="https://github.com/ksze"><img src="https://avatars.githubusercontent.com/u/381556?v=4" width="100" height="100" alt="ksze"/><br /><sub><b>ksze</b></sub></a>                         |                <a href="https://github.com/Jdo300"><img src="https://avatars.githubusercontent.com/u/67338327?v=4" width="100" height="100" alt="Jdo300"/><br /><sub><b>Jdo300</b></sub></a>                |           <a href="https://github.com/hesara"><img src="https://avatars.githubusercontent.com/u/1335918?v=4" width="100" height="100" alt="hesara"/><br /><sub><b>hesara</b></sub></a>           |            <a href="https://github.com/DeXtroTip"><img src="https://avatars.githubusercontent.com/u/21011087?v=4" width="100" height="100" alt="DeXtroTip"/><br /><sub><b>DeXtroTip</b></sub></a>            |                  <a href="https://github.com/pfitz"><img src="https://avatars.githubusercontent.com/u/3062911?v=4" width="100" height="100" alt="pfitz"/><br /><sub><b>pfitz</b></sub></a>                  |         <a href="https://github.com/celestial-vault"><img src="https://avatars.githubusercontent.com/u/58194240?v=4" width="100" height="100" alt="celestial-vault"/><br /><sub><b>celestial-vault</b></sub></a>         |
-
-<!-- END CONTRIBUTORS SECTION -->
-
 ## License
 
-[Apache 2.0 © 2025 Roo Code, Inc.](./LICENSE)
-
----
-
-**Enjoy Roo Code!** Whether you keep it on a short leash or let it roam autonomously, we can’t wait to see what you build. If you have questions or feature ideas, drop by our [Reddit community](https://www.reddit.com/r/RooCode/) or [Discord](https://discord.gg/roocode). Happy coding!
+[Apache 2.0 © 2026 Roo Code, Inc.](./LICENSE)

apps/cli/CHANGELOG.md

@@ -0,0 +1,391 @@
+# Changelog
+
+All notable changes to the `@roo-code/cli` package will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [0.1.17] - 2026-03-04
+
+### Added
+
+- **Custom Session ID Support**: New `--create-with-session-id` flag allows specifying a custom UUID session ID when creating tasks. Session IDs are now validated as UUIDs for both create and resume operations, as well as for `start.taskId` in stdin-stream mode.
+
+### Tests
+
+- Added integration coverage for create+resume loading the correct session.
+
+## [0.1.16] - 2026-03-04
+
+### Added
+
+- **Custom Shell Selection**: New `--terminal-shell` flag to specify which shell to use for inline command execution. The shell path is validated at the CLI layer and passed through the standard settings mechanism.
+
+### Tests
+
+- Added integration coverage for stdin stream routing and race invariants.
+
+## [0.1.15] - 2026-03-03
+
+### Fixed
+
+- **Follow-up Routing for Completion Asks**: Fixed routing of follow-up messages when the agent asks for clarification (ask_followup_question) in stdin-stream mode. Messages sent after a completion ask are now correctly delivered to the agent instead of being queued.
+
+## [0.1.14] - 2026-03-03
+
+### Fixed
+
+- **Command Output Streaming**: Ensure full command output is streamed before the done event is emitted, preventing truncated output in stdin-stream mode.
+
+## [0.1.13] - 2026-03-02
+
+### Added
+
+- **Skills as Slash Commands**: Skills are now exposed as slash commands, so you can invoke skill workflows directly from command-style input.
+- **Skill Fallback Execution**: When a slash command does not match a command file but matches a skill slug, the CLI can resolve and execute that skill path.
+
+### Changed
+
+- **Slash Command Resolution Priority**: Command precedence is preserved, with skill fallback only used when no matching slash command is found.
+
+### Tests
+
+- Added and updated tests for slash command + skill fallback behavior, including command precedence and duplicate skill-slug handling.
+
+## [0.1.12] - 2026-03-02
+
+### Fixed
+
+- **Command Timeout Handling**: CLI runtime now correctly ignores model-provided background timeouts for commands, ensuring command lifetime is governed solely by the `--timeout` setting.
+
+## [0.1.11] - 2026-03-02
+
+### Added
+
+- **Image Support in Stdin Stream**: The `start` and `message` commands in stdin-stream mode now support an optional `images` field (array of base64 data URIs) to attach images to prompts.
+
+### Fixed
+
+- **Upgrade Version Detection**: Fixed version detection in the `upgrade` command to correctly identify when updates are available.
+
+## [0.1.10] - 2026-03-02
+
+### Added
+
+- **Command Exit Code in Events**: The `tool_result` event for command executions now includes an `exitCode` field, allowing CLI consumers to programmatically distinguish between successful and failed command executions without parsing output text.
+
+## [0.1.9] - 2026-03-02
+
+### Fixed
+
+- **Stdin Stream Cancel Race**: Fixed a race condition during startup cancellation in stdin-stream mode that could cause unexpected behavior when canceling tasks immediately after starting them.
+
+### Tests
+
+- **Integration Test Suite**: Added comprehensive integration test suite for stdin-stream protocol covering cancel, followup, multi-message queue, and shutdown scenarios.
+
+## [0.1.8] - 2026-03-02
+
+### Changed
+
+- **Command Execution Timeout**: Increased timeout for command execution to improve reliability for long-running operations.
+
+### Fixed
+
+- **Stdin Stream Queue Handling**: Fixed stdin stream queued messages and command output streaming to ensure messages are properly processed.
+
+## [0.1.7] - 2026-03-01
+
+### Fixed
+
+- **Stdin Stream Control Flow**: Gracefully handle control-flow errors in stdin-stream mode to prevent unexpected crashes during cancellation and shutdown sequences.
+
+### Changed
+
+- **Type Definitions**: Refactored and simplified JSON event type definitions for better type safety.
+
+## [0.1.6] - 2026-02-27
+
+### Added
+
+- **Consecutive Mistake Limit**: New `--mistake-limit` flag to configure the maximum number of consecutive mistakes before the agent pauses for intervention.
+
+### Changed
+
+- **Workspace-Scoped Sessions**: The `list sessions` command and `--resume` flag now only show and resume sessions from the current workspace directory.
+
+### Fixed
+
+- **Task Configuration Forwarding**: Task configuration (custom modes, disabled tools, etc.) passed via the stdin-prompt-stream protocol is now correctly forwarded to the extension host instead of being silently dropped.
+- **Stream Error Recovery**: Improved recovery from streaming errors to prevent task interruption.
+
+## [0.1.5] - 2026-02-26
+
+### Added
+
+- **Session History**: New `list sessions` subcommand to view recent CLI sessions with task IDs, timestamps, and initial prompts.
+- **Session Resume**: New `--resume <taskId>` flag to continue a previous session from where it left off.
+- **Upgrade Command**: New `upgrade` command to check for and install the latest CLI version.
+
+## [0.1.4] - 2026-02-26
+
+### Fixed
+
+- **Exception Handling**: Improved recovery from unhandled exceptions in the CLI to prevent unexpected crashes.
+
+## [0.1.3] - 2026-02-25
+
+### Fixed
+
+- **Task Resumption**: Fixed an issue where resuming a previously suspended task could fail due to state initialization timing in the extension host.
+
+## [0.1.2] - 2026-02-25
+
+### Changed
+
+- **Streaming Deltas**: Tool use ask messages (command, tool, mcp) are now streamed as structured deltas instead of full snapshots in json-event-emitter for improved efficiency.
+- **Task ID Propagation**: Task ID is now generated upfront and propagated through runTask/createTask so currentTaskId is available in extension state immediately.
+- **Custom Tools**: Enabled customTools experiment in extension host.
+
+### Fixed
+
+- **Cancel Recovery**: Wait for resumable state after cancel before processing follow-up messages to prevent race conditions in stdin-stream.
+- **Custom Tool Schema**: Provide valid empty JSON Schema for custom tools without parameters to fix strict-mode API validation.
+- **Path Handling**: Skip paths outside cwd in RooProtectedController to avoid RangeError.
+- **Retry Handling**: Silently handle abort during exponential backoff retry countdown.
+- Fixed spelling/grammar and casing inconsistencies.
+
+### Added
+
+- **Telemetry Control**: Added `ROO_CODE_DISABLE_TELEMETRY=1` environment variable to disable cloud telemetry.
+
+## [0.1.1] - 2026-02-24
+
+### Added
+
+- **Roo Model Warmup**: When configured with the Roo provider, the CLI now proactively fetches and warms the model list during activation so that model information is available before the first prompt is sent. The warmup has a 10s timeout and failures are logged only in debug mode.
+- **Unbound Provider**: Added Unbound as an available provider option.
+
+## [0.1.0] - 2026-02-19
+
+### Added
+
+- **NDJSON Stdin Protocol**: Overhauled the stdin prompt stream from raw text lines to a structured NDJSON command protocol (`start`/`message`/`cancel`/`ping`/`shutdown`) with requestId correlation, ack/done/error lifecycle events, and queue telemetry. See [`stdin-stream.ts`](src/ui/stdin-stream.ts) for implementation.
+- **List Subcommands**: New `list` subcommands (`commands`, `modes`, `models`) for programmatic discovery of available CLI capabilities.
+- **Shared Utilities**: Added `isRecord` guard utility for improved type safety.
+
+### Changed
+
+- **Modularized Architecture**: Extracted stdin stream logic from `run.ts` into dedicated [`stdin-stream.ts`](src/ui/stdin-stream.ts) module for better code organization and maintainability.
+
+### Fixed
+
+- Fixed a bug in `Task.ts` affecting CLI operation.
+
+## [0.0.55] - 2026-02-17
+
+### Fixed
+
+- **Stdin Stream Mode**: Fixed issue where new tasks were incorrectly being created in stdin-prompt-stream mode. The mode now properly reuses the existing task for subsequent prompts instead of creating new tasks.
+
+## [0.0.54] - 2026-02-15
+
+### Added
+
+- **Stdin Stream Mode**: New `stdin-prompt-stream` mode that reads prompts from stdin, allowing batch processing and piping multiple tasks. Each line of stdin is processed as a separate prompt with streaming JSON output. See [`stdin-prompt-stream.ts`](src/ui/stdin-prompt-stream.ts) for implementation.
+
+### Fixed
+
+- Fixed JSON emitter state not being cleared between tasks in stdin-prompt-stream mode
+- Fixed inconsistent user role for prompt echo partials in stream-json mode
+
+## [0.0.53] - 2026-02-12
+
+### Changed
+
+- **Auto-Approve by Default**: The CLI now auto-approves all actions (tools, commands, browser, MCP) by default. Followup questions auto-select the first suggestion after a 60-second timeout.
+- **New `--require-approval` Flag**: Replaced `-y`/`--yes`/`--dangerously-skip-permissions` flags with a new `-a, --require-approval` flag for users who want manual approval prompts before actions execute.
+
+### Fixed
+
+- Spamming the escape key to cancel a running task no longer crashes the cli.
+
+## [0.0.52] - 2026-02-09
+
+### Added
+
+- **Linux Support**: Added support for `linux-arm64`.
+
+## [0.0.51] - 2026-02-06
+
+### Changed
+
+- **Default Model Update**: Changed the default model from Opus 4.5 to Opus 4.6 for improved performance and capabilities
+
+## [0.0.50] - 2026-02-05
+
+### Added
+
+- **Linux Support**: The CLI now supports Linux platforms in addition to macOS
+- **Roo Provider API Key Support**: Allow `--api-key` flag and `ROO_API_KEY` environment variable for the roo provider instead of requiring cloud auth token
+- **Exit on Error**: New `--exit-on-error` flag to exit immediately on API request errors instead of retrying, useful for CI/CD pipelines
+
+### Changed
+
+- **Improved Dev Experience**: Dev scripts now use `tsx` for running directly from source without building first
+- **Path Resolution Fixes**: Fixed path resolution in [`version.ts`](src/lib/utils/version.ts), [`extension.ts`](src/lib/utils/extension.ts), and [`extension-host.ts`](src/agent/extension-host.ts) to work from both source and bundled locations
+- **Debug Logging**: Debug log file (`~/.roo/cli-debug.log`) is now disabled by default unless `--debug` flag is passed
+- Updated README with complete environment variable table and dev workflow documentation
+
+### Fixed
+
+- Corrected example in install script
+
+### Removed
+
+- Dropped macOS 13 support
+
+## [0.0.49] - 2026-01-18
+
+### Added
+
+- **Output Format Options**: New `--output-format` flag to control CLI output format for scripting and automation:
+    - `text` (default) - Human-readable interactive output
+    - `json` - Single JSON object with all events and final result at task completion
+    - `stream-json` - NDJSON (newline-delimited JSON) for real-time streaming of events
+    - See [`json-events.ts`](src/types/json-events.ts) for the complete event schema
+    - New [`JsonEventEmitter`](src/agent/json-event-emitter.ts) for structured output generation
+
+## [0.0.48] - 2026-01-17
+
+### Changed
+
+- Simplified authentication callback flow by using HTTP redirects instead of POST requests with CORS headers for improved browser compatibility
+
+## [0.0.47] - 2026-01-17
+
+### Added
+
+- **Workspace flag**: New `-w, --workspace <path>` option to specify a custom workspace directory instead of using the current working directory
+- **Oneshot mode**: New `--oneshot` flag to exit upon task completion, useful for scripting and automation (can also be saved in settings via [`CliSettings.oneshot`](src/types/types.ts))
+
+### Changed
+
+- Skip onboarding flow when a provider is explicitly specified via `--provider` flag or saved in settings
+- Unified permission flags: Combined approval-skipping flags into a single option for Claude Code-like CLI compatibility
+- Improved Roo Code Router authentication flow and error messaging
+
+### Fixed
+
+- Removed unnecessary timeout that could cause issues with long-running tasks
+- Fixed authentication token validation for Roo Code Router provider
+
+## [0.0.45] - 2026-01-08
+
+### Changed
+
+- **Major Refactor**: Extracted ~1400 lines from [`App.tsx`](src/ui/App.tsx) into reusable hooks and utilities for better maintainability:
+
+    - [`useExtensionHost`](src/ui/hooks/useExtensionHost.ts) - Extension host connection and lifecycle management
+    - [`useMessageHandlers`](src/ui/hooks/useMessageHandlers.ts) - Message processing and state updates
+    - [`useTaskSubmit`](src/ui/hooks/useTaskSubmit.ts) - Task submission logic
+    - [`useGlobalInput`](src/ui/hooks/useGlobalInput.ts) - Global keyboard shortcut handling
+    - [`useFollowupCountdown`](src/ui/hooks/useFollowupCountdown.ts) - Auto-approval countdown logic
+    - [`useFocusManagement`](src/ui/hooks/useFocusManagement.ts) - Input focus state management
+    - [`usePickerHandlers`](src/ui/hooks/usePickerHandlers.ts) - Picker component event handling
+    - [`uiStateStore`](src/ui/stores/uiStateStore.ts) - UI-specific state (showExitHint, countdown, etc.)
+    - Tool data utilities ([`extractToolData`](src/ui/utils/toolDataUtils.ts), `formatToolOutput`, etc.)
+    - [`HorizontalLine`](src/ui/components/HorizontalLine.tsx) component
+
+- **Performance Optimizations**:
+
+    - Added RAF-style scroll throttling to reduce state updates
+    - Stabilized `useExtensionHost` hook return values with `useCallback`/`useMemo`
+    - Added streaming message debouncing to batch rapid partial updates
+    - Added shallow array equality checks to prevent unnecessary re-renders
+
+- Simplified [`ModeTool`](src/ui/components/tools/ModeTool.tsx) layout to horizontal with mode suffix
+- Simplified logging by removing verbose debug output and adding first/last partial message logging pattern
+- Updated Nerd Font icon codepoints in [`Icon`](src/ui/components/Icon.tsx) component
+
+### Added
+
+- `#` shortcut in help trigger for quick access to task history autocomplete
+
+### Fixed
+
+- Fixed a crash in message handling
+- Added protected file warning in tool approval prompts
+- Enabled `alwaysAllowWriteProtected` for non-interactive mode
+
+### Removed
+
+- Removed unused `renderLogger.ts` utility file
+
+### Tests
+
+- Updated extension-host tests to expect `[Tool Request]` format
+- Updated Icon tests to expect single-char Nerd Font icons
+
+## [0.0.44] - 2026-01-08
+
+### Added
+
+- **Tool Renderer Components**: Specialized renderers for displaying tool outputs with optimized formatting for each tool type. Each renderer provides a focused view of its data structure.
+
+    - [`FileReadTool`](src/ui/components/tools/FileReadTool.tsx) - Display file read operations with syntax highlighting
+    - [`FileWriteTool`](src/ui/components/tools/FileWriteTool.tsx) - Show file write/edit operations with diff views
+    - [`SearchTool`](src/ui/components/tools/SearchTool.tsx) - Render search results with context
+    - [`CommandTool`](src/ui/components/tools/CommandTool.tsx) - Display command execution with output
+    - [`BrowserTool`](src/ui/components/tools/BrowserTool.tsx) - Show browser automation actions
+    - [`ModeTool`](src/ui/components/tools/ModeTool.tsx) - Display mode switching operations
+    - [`CompletionTool`](src/ui/components/tools/CompletionTool.tsx) - Show task completion status
+    - [`GenericTool`](src/ui/components/tools/GenericTool.tsx) - Fallback renderer for other tools
+
+- **History Trigger**: New `#` trigger for task history autocomplete with fuzzy search support. Type `#` at the start of a line to browse and resume previous tasks.
+
+    - [`HistoryTrigger.tsx`](src/ui/components/autocomplete/triggers/HistoryTrigger.tsx) - Trigger implementation with fuzzy filtering
+    - Shows task status, mode, and relative timestamps
+    - Supports keyboard navigation for quick task selection
+
+- **Release Confirmation Prompt**: The release script now prompts for confirmation before creating a release.
+
+### Fixed
+
+- Task history picker selection and navigation issues
+- Mode switcher keyboard handling bug
+
+### Changed
+
+- Reorganized test files into `__tests__` directories for better project structure
+- Refactored utility modules into dedicated `utils/` directory
+
+## [0.0.43] - 2026-01-07
+
+### Added
+
+- **Toast Notification System**: New toast notifications for user feedback with support for info, success, warning, and error types. Toasts auto-dismiss after a configurable duration and are managed via Zustand store.
+
+    - New [`ToastDisplay`](src/ui/components/ToastDisplay.tsx) component for rendering toast messages
+    - New [`useToast`](src/ui/hooks/useToast.ts) hook for managing toast state and displaying notifications
+
+- **Global Input Sequences Registry**: Centralized system for handling keyboard shortcuts at the application level, preventing conflicts with input components.
+
+    - New [`globalInputSequences.ts`](src/ui/utils/globalInputSequences.ts) utility module
+    - Support for Kitty keyboard protocol (CSI u encoding) for better terminal compatibility
+    - Built-in sequences for `Ctrl+C` (exit) and `Ctrl+M` (mode cycling)
+
+- **Local Tarball Installation**: The install script now supports installing from a local tarball via the `ROO_LOCAL_TARBALL` environment variable, useful for offline installation or testing pre-release builds.
+
+### Changed
+
+- **MultilineTextInput**: Updated to respect global input sequences, preventing the component from consuming shortcuts meant for application-level handling.
+
+### Tests
+
+- Added comprehensive tests for the toast notification system
+- Added tests for global input sequence matching
+
+## [0.0.42] - 2025-01-07
+
+The cli is alive!

apps/cli/README.md

@@ -0,0 +1,240 @@
+# @roo-code/cli
+
+Command Line Interface for Roo Code - Run the Roo Code agent from the terminal without VSCode.
+
+## Overview
+
+This CLI uses the `@roo-code/vscode-shim` package to provide a VSCode API compatibility layer, allowing the main Roo Code extension to run in a Node.js environment.
+
+## Installation
+
+### Quick Install (Recommended)
+
+Install the Roo Code CLI with a single command:
+
+```bash
+curl -fsSL https://raw.githubusercontent.com/RooCodeInc/Roo-Code/main/apps/cli/install.sh | sh
+```
+
+**Requirements:**
+
+- Node.js 20 or higher
+- macOS Apple Silicon (M1/M2/M3/M4) or Linux x64
+
+**Custom installation directory:**
+
+```bash
+ROO_INSTALL_DIR=/opt/roo-code ROO_BIN_DIR=/usr/local/bin curl -fsSL ... | sh
+```
+
+**Install a specific version:**
+
+```bash
+ROO_VERSION=0.1.0 curl -fsSL https://raw.githubusercontent.com/RooCodeInc/Roo-Code/main/apps/cli/install.sh | sh
+```
+
+### Updating
+
+Re-run the install script to update to the latest version:
+
+```bash
+curl -fsSL https://raw.githubusercontent.com/RooCodeInc/Roo-Code/main/apps/cli/install.sh | sh
+```
+
+Or run:
+
+```bash
+roo upgrade
+```
+
+### Uninstalling
+
+```bash
+rm -rf ~/.roo/cli ~/.local/bin/roo
+```
+
+## Usage
+
+### Interactive Mode (Default)
+
+By default, the CLI auto-approves actions and runs in interactive TUI mode:
+
+```bash
+export OPENROUTER_API_KEY=sk-or-v1-...
+
+roo "What is this project?" -w ~/Documents/my-project
+```
+
+You can also run without a prompt and enter it interactively in TUI mode:
+
+```bash
+roo -w ~/Documents/my-project
+```
+
+In interactive mode:
+
+- Tool executions are auto-approved
+- Commands are auto-approved
+- Followup questions show suggestions with a 60-second timeout, then auto-select the first suggestion
+- Browser and MCP actions are auto-approved
+
+### Approval-Required Mode (`--require-approval`)
+
+If you want manual approval prompts, enable approval-required mode:
+
+```bash
+roo "Refactor the utils.ts file" --require-approval -w ~/Documents/my-project
+```
+
+In approval-required mode:
+
+- Tool, command, browser, and MCP actions prompt for yes/no approval
+- Followup questions wait for manual input (no auto-timeout)
+
+### Print Mode (`--print`)
+
+Use `--print` for non-interactive execution and machine-readable output:
+
+```bash
+# Prompt is required
+roo --print "Summarize this repository"
+
+# Create a new task with a specific session ID (UUID)
+roo --print --create-with-session-id 018f7fc8-7c96-7f7c-98aa-2ec4ff7f6d87 "Summarize this repository"
+```
+
+### Stdin Stream Mode (`--stdin-prompt-stream`)
+
+For programmatic control (one process, multiple prompts), use `--stdin-prompt-stream` with `--print`.
+Send NDJSON commands via stdin:
+
+```bash
+printf '{"command":"start","requestId":"1","prompt":"1+1=?"}\n' | roo --print --stdin-prompt-stream --output-format stream-json
+
+# Optional: provide taskId per start command
+printf '{"command":"start","requestId":"1","taskId":"018f7fc8-7c96-7f7c-98aa-2ec4ff7f6d87","prompt":"1+1=?"}\n' | roo --print --stdin-prompt-stream --output-format stream-json
+```
+
+## Options
+
+| Option                                  | Description                                                                             | Default                     |
+| --------------------------------------- | --------------------------------------------------------------------------------------- | --------------------------- |
+| `[prompt]`                              | Your prompt (positional argument, optional)                                             | None                        |
+| `--prompt-file <path>`                  | Read prompt from a file instead of command line argument                                | None                        |
+| `--create-with-session-id <session-id>` | Create a new task using the provided session ID (UUID)                                  | None                        |
+| `-w, --workspace <path>`                | Workspace path to operate in                                                            | Current directory           |
+| `-p, --print`                           | Print response and exit (non-interactive mode)                                          | `false`                     |
+| `--stdin-prompt-stream`                 | Read NDJSON control commands from stdin (requires `--print`)                            | `false`                     |
+| `-e, --extension <path>`                | Path to the extension bundle directory                                                  | Auto-detected               |
+| `-d, --debug`                           | Enable debug output (includes detailed debug information, prompts, paths, etc)          | `false`                     |
+| `-a, --require-approval`                | Require manual approval before actions execute                                          | `false`                     |
+| `-k, --api-key <key>`                   | API key for the LLM provider                                                            | From env var                |
+| `--provider <provider>`                 | API provider (anthropic, openai, openrouter, etc.)                                      | `openrouter`                |
+| `-m, --model <model>`                   | Model to use                                                                            | `anthropic/claude-opus-4.6` |
+| `--mode <mode>`                         | Mode to start in (code, architect, ask, debug, etc.)                                    | `code`                      |
+| `--terminal-shell <path>`               | Absolute shell path for inline terminal command execution                               | Auto-detected shell         |
+| `-r, --reasoning-effort <effort>`       | Reasoning effort level (unspecified, disabled, none, minimal, low, medium, high, xhigh) | `medium`                    |
+| `--consecutive-mistake-limit <n>`       | Consecutive error/repetition limit before guidance prompt (`0` disables the limit)      | `10`                        |
+| `--ephemeral`                           | Run without persisting state (uses temporary storage)                                   | `false`                     |
+| `--oneshot`                             | Exit upon task completion                                                               | `false`                     |
+| `--output-format <format>`              | Output format with `--print`: `text`, `json`, or `stream-json`                          | `text`                      |
+
+## Environment Variables
+
+The CLI will look for API keys in environment variables if not provided via `--api-key`:
+
+| Provider          | Environment Variable        |
+| ----------------- | --------------------------- |
+| anthropic         | `ANTHROPIC_API_KEY`         |
+| openai-native     | `OPENAI_API_KEY`            |
+| openrouter        | `OPENROUTER_API_KEY`        |
+| gemini            | `GOOGLE_API_KEY`            |
+| vercel-ai-gateway | `VERCEL_AI_GATEWAY_API_KEY` |
+
+## Architecture
+
+```
+┌─────────────────┐
+│   CLI Entry     │
+│   (index.ts)    │
+└────────┬────────┘
+         │
+         ▼
+┌─────────────────┐
+│  ExtensionHost  │
+│  (extension-    │
+│   host.ts)      │
+└────────┬────────┘
+         │
+    ┌────┴────┐
+    │         │
+    ▼         ▼
+┌───────┐  ┌──────────┐
+│vscode │  │Extension │
+│-shim  │  │ Bundle   │
+└───────┘  └──────────┘
+```
+
+## How It Works
+
+1. **CLI Entry Point** (`index.ts`): Parses command line arguments and initializes the ExtensionHost
+
+2. **ExtensionHost** (`extension-host.ts`):
+
+    - Creates a VSCode API mock using `@roo-code/vscode-shim`
+    - Intercepts `require('vscode')` to return the mock
+    - Loads and activates the extension bundle
+    - Manages bidirectional message flow
+
+3. **Message Flow**:
+    - CLI → Extension: `emit("webviewMessage", {...})`
+    - Extension → CLI: `emit("extensionWebviewMessage", {...})`
+
+## Development
+
+```bash
+# Run directly from source (no build required)
+pnpm dev --provider openrouter --api-key $OPENROUTER_API_KEY --print "Hello"
+
+# Run tests
+pnpm test
+
+# Type checking
+pnpm check-types
+
+# Linting
+pnpm lint
+```
+
+## Releasing
+
+Official releases are created via the GitHub Actions workflow at `.github/workflows/cli-release.yml`.
+
+To trigger a release:
+
+1. Go to **Actions** → **CLI Release**
+2. Click **Run workflow**
+3. Optionally specify a version (defaults to `package.json` version)
+4. Click **Run workflow**
+
+The workflow will:
+
+1. Build the CLI on all platforms (macOS Apple Silicon, Linux x64)
+2. Create platform-specific tarballs with bundled ripgrep
+3. Verify each tarball
+4. Create a GitHub release with all tarballs attached
+
+### Local Builds
+
+For local development and testing, use the build script:
+
+```bash
+# Build tarball for your current platform
+./apps/cli/scripts/build.sh
+
+# Build and install locally
+./apps/cli/scripts/build.sh --install
+
+# Fast build (skip verification)
+./apps/cli/scripts/build.sh --skip-verify
+```