Remove roocode.com web app (#12375)

* Remove contributor and community references

* shutdown notice

* Allow empty web app test suite

.changeset/changelog-config.js

@@ -1,11 +1,9 @@
-// Half-works to simplify the format but needs 'overwrite_changeset_changelog.py' in GHA to finish formatting
-
 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

@@ -2,10 +2,10 @@
 	"$schema": "https://unpkg.com/@changesets/config@3.0.4/schema.json",
 	"changelog": "./changelog-config.js",
 	"commit": false,
-	"fixed": [],
+	"fixed": [["roo-cline"]],
 	"linked": [],
 	"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

@@ -0,0 +1,93 @@
+# git
+.git
+
+# build artifacts
+bin/
+dist/
+**/dist/
+out/
+**/out/
+src/webview-ui/
+
+# dependencies
+node_modules/
+**/node_modules/
+
+# testing
+coverage/
+**/.vscode-test/
+**/mock/
+
+# devtools
+knip.json
+.husky/
+
+# monorepo
+.turbo/
+**/.turbo/
+
+# next.js
+**/.next/
+.vercel
+
+# Ignore common development files
+node_modules
+.git
+.gitignore
+.dockerignore
+.env*
+.vscode
+.idea
+
+# Ignore build artifacts
+dist
+build
+*.log
+*.tmp
+.cache
+coverage
+
+# Ignore OS files
+.DS_Store
+Thumbs.db
+
+# Ignore test files
+__tests__
+*.test.js
+*.spec.js
+*.test.ts
+*.spec.ts
+
+# Ignore development config files
+.eslintrc*
+.prettierrc*
+
+# Ignore most directories except what we need for the build
+apps/
+evals/
+webview-ui/node_modules
+src/node_modules
+
+# Keep essential files for the build
+!README.md
+!CHANGELOG.md
+!package.json
+!pnpm-lock.yaml
+!pnpm-workspace.yaml
+!scripts/bootstrap.mjs
+!apps/web-evals/
+!apps/cli/
+!src/
+!webview-ui/
+!packages/evals/.docker/entrypoints/runner.sh
+!packages/build/
+!packages/config-eslint/
+!packages/config-typescript/
+!packages/core/
+!packages/evals/
+!packages/ipc/
+!packages/telemetry/
+!packages/types/
+!packages/vscode-shim/
+!packages/cloud/
+!locales/

.env.sample

@@ -1 +1,6 @@
 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

.eslintrc.json

@@ -1,25 +0,0 @@
-{
-	"root": true,
-	"parser": "@typescript-eslint/parser",
-	"parserOptions": {
-		"ecmaVersion": 6,
-		"sourceType": "module"
-	},
-	"plugins": ["@typescript-eslint"],
-	"rules": {
-		"@typescript-eslint/naming-convention": [
-			"warn",
-			{
-				"selector": "import",
-				"format": ["camelCase", "PascalCase"]
-			}
-		],
-		"@typescript-eslint/semi": "off",
-		"no-unused-vars": "off",
-		"@typescript-eslint/no-unused-vars": ["error", { "varsIgnorePattern": "^_", "argsIgnorePattern": "^_" }],
-		"eqeqeq": "warn",
-		"no-throw-literal": "warn",
-		"semi": "off"
-	},
-	"ignorePatterns": ["out", "dist", "**/*.d.ts", "!roo-code.d.ts"]
-}

.gitattributes

@@ -1,2 +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
+* @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,49 +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 (Optional)
-      description: |
-        Recap what went wrong in one or two lines. Use this if the bug is weird, unexpected, or needs extra context.
-
-        Example: "Expected code to run, but got an empty response and no error."
-      placeholder: Expected ___, but got ___.
+      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
-      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,76 +1,91 @@
-name: Detailed Feature Proposal
-description: Propose a specific, actionable feature or enhancement for implementation
-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 proposing a detailed feature for Roo Code!**
+        Thank you for helping improve Roo Code!
+        Please focus on the problem and the desired behavior in plain language.
 
-        This template is for submitting specific, actionable proposals that you or others intend to implement after discussion and approval. It's a key part of our [Issue-First Approach](../../CONTRIBUTING.md).
-
-        - **For general ideas or less defined suggestions**, please use [GitHub Discussions](https://github.com/RooCodeInc/Roo-Code/discussions/categories/feature-requests?discussions_q=is%3Aopen+category%3A%22Feature+Requests%22+sort%3Atop) first.
-        - **Before submitting**, please search existing [GitHub Issues](https://github.com/RooCodeInc/Roo-Code/issues) and [Discussions](https://github.com/RooCodeInc/Roo-Code/discussions) to avoid duplicates.
-
-        For guidance or to discuss your idea, join the [Roo Code Discord](https://discord.gg/roocode) and DM **Hannes Rudolph** (`hrudolph`).
-
-        A maintainer (especially @hannesrudolph) will review this proposal. **Do not start implementation until this proposal is approved and assigned.**
   - type: textarea
-    id: problem-description
+    id: problem
     attributes:
-      label: What problem does this proposed feature solve?
-      description: Clearly describe the problem, use case, or opportunity this feature addresses. Why is this change needed?
-      placeholder: e.g., "Users currently cannot..." or "It would be beneficial if..."
+      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: proposed-solution
+    id: context
     attributes:
-      label: Describe the proposed solution in detail
-      description: Provide a clear and comprehensive description of the feature or enhancement. How should it work? What are the key functionalities?
-      placeholder: Include details on user interaction, expected behavior, and potential impact.
+      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: technical-details
+    id: desired
     attributes:
-      label: Technical considerations or implementation details (optional)
-      description: If you have thoughts on how this could be implemented, or specific technical aspects to consider, please share them.
-      placeholder: e.g., "This might involve changes to X component..." or "We should consider Y library..."
+      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: alternatives-considered
+    id: constraints
     attributes:
-      label: Describe alternatives considered (if any)
-      description: What other ways could this problem be solved or this functionality be achieved? Why is your proposed solution preferred?
-      placeholder: Briefly outline any alternative approaches and why they were not chosen.
-
-  - type: textarea
-    id: additional-context
-    attributes:
-      label: Additional Context & Mockups
-      description: Add any other context, mockups, screenshots, or links that help illustrate the proposal.
+      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
     attributes:
-      label: Proposal Checklist
-      description: Please confirm the following before submitting.
+      label: Request checklist
       options:
-        - label: I have searched existing Issues and Discussions to ensure this proposal is not a duplicate.
+        - label: I've searched existing Issues and Discussions for duplicates
           required: true
-        - label: This proposal is for a specific, actionable change intended for implementation (not a general idea).
-          required: true
-        - label: I understand that this proposal requires review and approval before any development work begins.
+        - label: This describes a specific problem with clear context and impact
           required: true
 
-  - type: checkboxes
-    id: willingness-to-contribute
+  - type: textarea
+    id: roo-code-tasks
     attributes:
-      label: Are you interested in implementing this feature if approved?
-      description: (This is optional and does not affect the proposal's consideration)
-      options:
-        - label: Yes, I would like to contribute to implementing this feature.
-          required: false
+      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: You can stop here if you're just proposing the improvement.
+
+  - type: textarea
+    id: acceptance-criteria
+    attributes:
+      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]
+
+  - type: textarea
+    id: proposed-solution
+    attributes:
+      label: Proposed approach (optional)
+      description: If you have an idea, describe it briefly in plain language.
+
+  - type: textarea
+    id: risks
+    attributes:
+      label: Trade-offs / risks (optional)
+      description: Potential downsides or alternatives considered.

.github/ISSUE_TEMPLATE/marketplace.yml

@@ -0,0 +1,62 @@
+name: Marketplace Feedback
+description: Report issues or suggest improvements for marketplace items (custom modes and MCP servers)
+labels: ["marketplace"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        **Thanks for your feedback!** Please check existing issues first: https://github.com/RooCodeInc/Roo-Code/issues
+
+  - type: dropdown
+    id: feedback-type
+    attributes:
+      label: What kind of feedback?
+      options:
+        - Problem with existing marketplace item
+        - Suggestion for new custom mode
+        - Suggestion for new MCP server
+        - General marketplace issue
+    validations:
+      required: true
+
+  - type: dropdown
+    id: item-type
+    attributes:
+      label: Item Type (if applicable)
+      options:
+        - Custom Mode
+        - MCP Server
+        - Marketplace UI/Functionality
+        - Not Applicable
+    validations:
+      required: false
+
+  - type: input
+    id: item-name
+    attributes:
+      label: Item Name (if applicable)
+      placeholder: e.g., "Debug Mode", "Weather API Server", "Code Formatter"
+
+  - type: textarea
+    id: description
+    attributes:
+      label: Description
+      description: What's the issue or what would you like to see?
+      placeholder: Clear description of the problem or suggestion
+    validations:
+      required: true
+
+  - type: textarea
+    id: additional-info
+    attributes:
+      label: Additional Details (optional)
+      description: Steps to reproduce, expected behavior, screenshots, etc.
+      placeholder: Any other helpful information
+
+  - type: checkboxes
+    id: checklist
+    attributes:
+      label: Checklist
+      options:
+        - label: I've searched existing issues for duplicates
+          required: true

.github/actions/ai-release-notes/action.yml

@@ -1,83 +0,0 @@
-name: AI Release Notes
-description: Generate AI release notes using git and openai, outputs 'RELEASE_NOTES' and 'OPENAI_PROMPT'
-
-inputs:
-  OPENAI_API_KEY:
-    required: true
-    type: string
-  GHA_PAT:
-    required: true
-    type: string
-  model_name:
-    required: false
-    type: string
-    default: gpt-4o-mini
-  repo_path:
-    required: false
-    type: string
-  custom_prompt:
-    required: false
-    default: ''
-    type: string
-  git_ref:
-    required: true
-    type: string
-  head_ref:
-    required: true
-    type: string
-  base_ref:
-    required: true
-    type: string
-
-outputs:
-  RELEASE_NOTES:
-    description: "AI generated release notes"
-    value: ${{ steps.ai_release_notes.outputs.RELEASE_NOTES }}
-  OPENAI_PROMPT:
-    description: "Prompt used to generate release notes"
-    value: ${{ steps.ai_prompt.outputs.OPENAI_PROMPT }}
-
-env:
-  GITHUB_REF: ${{ inputs.git_ref }}
-  BASE_REF: ${{ inputs.base_ref }}
-  HEAD_REF: ${{ inputs.head_ref }}
-
-runs:
-  using: "composite"
-  steps:
-    - uses: actions/checkout@v4
-      with:
-        repository: ${{ inputs.repo_path }}
-        token: ${{ inputs.GHA_PAT }}
-        ref: ${{ env.GITHUB_REF }}
-        fetch-depth: 0
-
-    - name: Set Workspace
-      shell: bash
-      run: |
-        pip install tiktoken
-        pip install pytz
-
-    # Github outputs: 'OPENAI_PROMPT'
-    - name: Add Git Info to base prompt
-      id: ai_prompt
-      shell: bash
-      env:
-        BASE_REF: ${{ env.BASE_REF }}
-        HEAD_SHA: ${{ env.HEAD_SHA }}
-        PR_TITLE: ${{ github.event.pull_request.title }}
-        PR_BODY: ${{ github.event.pull_request.body }}
-        MODEL_NAME: ${{ inputs.model_name }}
-        CUSTOM_PROMPT: ${{ inputs.custom_prompt }} # Default: ''
-      run: python .github/scripts/release-notes-prompt.py
-
-    # Github outputs: 'RELEASE_NOTES'
-    - name: Generate AI release notes
-      id: ai_release_notes
-      shell: bash
-      env:
-        OPENAI_API_KEY: ${{ inputs.OPENAI_API_KEY }}
-        CUSTOM_PROMPT: ${{ steps.ai_prompt.outputs.OPENAI_PROMPT }}
-        MODEL_NAME: ${{ inputs.model_name }}
-      run: python .github/scripts/ai-release-notes.py
-

.github/actions/setup-node-pnpm/action.yml

@@ -0,0 +1,48 @@
+name: "Setup Node.js and pnpm"
+
+description: "Sets up Node.js and pnpm with caching and installs dependencies"
+
+inputs:
+    node-version:
+        description: "Node.js version to use"
+        required: false
+        default: "20.19.2"
+    pnpm-version:
+        description: "pnpm version to use"
+        required: false
+        default: "10.8.1"
+    skip-install:
+        description: "Skip dependency installation"
+        required: false
+        default: "false"
+    install-args:
+        description: "Additional arguments for pnpm install"
+        required: false
+        default: ""
+
+runs:
+    using: "composite"
+    steps:
+        - name: Install pnpm
+          uses: pnpm/action-setup@v4
+          with:
+              version: ${{ inputs.pnpm-version }}
+        - name: Get pnpm store directory
+          shell: bash
+          run: |
+              echo "STORE_PATH=$(pnpm store path --silent)" >> $GITHUB_ENV
+        - name: Setup pnpm cache
+          uses: actions/cache@v4
+          with:
+              path: ${{ env.STORE_PATH }}
+              key: ${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }}
+              restore-keys: |
+                  ${{ runner.os }}-pnpm-store-
+        - name: Setup Node.js
+          uses: actions/setup-node@v4
+          with:
+              node-version: ${{ inputs.node-version }}
+        - name: Install dependencies
+          if: ${{ inputs.skip-install != 'true' }}
+          shell: bash
+          run: pnpm install ${{ inputs.install-args }}

.github/actions/slack-notify/action.yml

@@ -0,0 +1,58 @@
+name: 'Slack Notification'
+description: 'Send Slack notification for workflow failures'
+inputs:
+  webhook-url:
+    description: 'Slack webhook URL'
+    required: true
+  channel:
+    description: 'Slack channel to notify'
+    required: true
+  workflow-name:
+    description: 'Name of the workflow'
+    required: true
+  failed-jobs:
+    description: 'JSON object containing job results'
+    required: true
+
+runs:
+  using: 'composite'
+  steps:
+    - name: Parse failed jobs
+      id: parse-jobs
+      shell: bash
+      run: |
+        echo "Parsing job results..."
+        failed_list=""
+
+        echo '${{ inputs.failed-jobs }}' | jq -r 'to_entries[] | select(.value.result == "failure") | .key' | while read job; do
+          case $job in
+            "check-translations") failed_list="${failed_list}❌ Translation check\n" ;;
+            "knip") failed_list="${failed_list}❌ Knip analysis\n" ;;
+            "compile") failed_list="${failed_list}❌ Compile & lint\n" ;;
+            "unit-test") failed_list="${failed_list}❌ Unit tests\n" ;;
+            "integration-test") failed_list="${failed_list}❌ Integration tests\n" ;;
+          esac
+        done
+
+        echo "failed_jobs<<EOF" >> $GITHUB_OUTPUT
+        echo -e "$failed_list" | sed '/^$/d' >> $GITHUB_OUTPUT
+        echo "EOF" >> $GITHUB_OUTPUT
+
+    - name: Send Slack notification
+      uses: 8398a7/action-slack@v3
+      with:
+        status: failure
+        channel: ${{ inputs.channel }}
+        text: |
+          🚨 ${{ inputs.workflow-name }} workflow failed on main branch!
+
+          Repository: ${{ github.repository }}
+          Commit: ${{ github.sha }}
+          Author: ${{ github.actor }}
+
+          Failed jobs:
+          ${{ steps.parse-jobs.outputs.failed_jobs }}
+
+          View details: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
+      env:
+        SLACK_WEBHOOK_URL: ${{ inputs.webhook-url }}

.github/pull_request_template.md

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

@@ -1,123 +0,0 @@
-"""
-AI-powered release notes generator that creates concise and informative release notes from git changes.
-
-This script uses OpenAI's API to analyze git changes (summary, diff, and commit log) and generate
-well-formatted release notes in markdown. It focuses on important changes and their impact,
-particularly highlighting new types and schemas while avoiding repetitive information.
-
-Environment Variables Required:
-    OPENAI_API_KEY: OpenAI API key for authentication
-    CHANGE_SUMMARY: Summary of changes made (optional if CUSTOM_PROMPT provided)
-    CHANGE_DIFF: Git diff of changes (optional if CUSTOM_PROMPT provided)
-    CHANGE_LOG: Git commit log (optional if CUSTOM_PROMPT provided)
-    GITHUB_OUTPUT: Path to GitHub output file
-    CUSTOM_PROMPT: Custom prompt to override default (optional)
-"""
-
-import os
-import requests  # type: ignore
-import json
-import tiktoken # type: ignore
-
-OPENAI_API_KEY = os.environ["OPENAI_API_KEY"]
-CHANGE_SUMMARY = os.environ.get('CHANGE_SUMMARY', '')
-CHANGE_DIFF = os.environ.get('CHANGE_DIFF', '')
-CHANGE_LOG = os.environ.get('CHANGE_LOG', '')
-GITHUB_OUTPUT = os.getenv("GITHUB_OUTPUT")
-OPEN_AI_BASE_URL = "https://api.openai.com/v1"
-OPEN_API_HEADERS = {"Authorization": f"Bearer {OPENAI_API_KEY}", "Content-Type": "application/json"}
-CUSTOM_PROMPT = os.environ.get('CUSTOM_PROMPT', '')
-MODEL_NAME = os.environ.get('MODEL_NAME', 'gpt-3.5-turbo-16k')
-
-def num_tokens_from_string(string: str, model_name: str) -> int:
-    """
-    Calculate the number of tokens in a text string for a specific model.
-    
-    Args:
-        string: The input text to count tokens for
-        model_name: Name of the OpenAI model to use for token counting
-    
-    Returns:
-        int: Number of tokens in the input string
-    """
-    encoding = tiktoken.encoding_for_model(model_name)
-    num_tokens = len(encoding.encode(string))
-    return num_tokens
-
-def truncate_to_token_limit(text, max_tokens, model_name):
-    """
-    Truncate text to fit within a maximum token limit for a specific model.
-    
-    Args:
-        text: The input text to truncate
-        max_tokens: Maximum number of tokens allowed
-        model_name: Name of the OpenAI model to use for tokenization
-    
-    Returns:
-        str: Truncated text that fits within the token limit
-    """
-    encoding = tiktoken.encoding_for_model(model_name)
-    encoded = encoding.encode(text)
-    truncated = encoded[:max_tokens]
-    return encoding.decode(truncated)
-
-def generate_release_notes(model_name):
-    """
-    Generate release notes using OpenAI's API based on git changes.
-    
-    Uses the GPT-3.5-turbo model to analyze change summary, commit log, and code diff
-    to generate concise and informative release notes in markdown format. The notes
-    focus on important changes and their impact, with sections for new types/schemas
-    and other updates.
-    
-    Returns:
-        str: Generated release notes in markdown format
-    
-    Raises:
-        requests.exceptions.RequestException: If the OpenAI API request fails
-    """
-    max_tokens = 14000  # Reserve some tokens for the response
-
-    # Truncate inputs if necessary to fit within token limits
-    change_summary = '' if CUSTOM_PROMPT else truncate_to_token_limit(CHANGE_SUMMARY, 1000, model_name)
-    change_log = '' if CUSTOM_PROMPT else truncate_to_token_limit(CHANGE_LOG, 2000, model_name)
-    change_diff = '' if CUSTOM_PROMPT else truncate_to_token_limit(CHANGE_DIFF, max_tokens - num_tokens_from_string(change_summary, model_name) - num_tokens_from_string(change_log, model_name) - 1000, model_name)
-
-    url = f"{OPEN_AI_BASE_URL}/chat/completions"
-
-    # Construct prompt for OpenAI API
-    openai_prompt = CUSTOM_PROMPT if CUSTOM_PROMPT else f"""Based on the following summary of changes, commit log and code diff, please generate concise and informative release notes:
-    Summary of changes:
-    {change_summary}
-    Commit log:
-    {change_log}
-    Code Diff:
-    {json.dumps(change_diff)}
-    """
-
-    data = {
-        "model": model_name,
-        "messages": [{"role": "user", "content": openai_prompt}],
-        "temperature": 0.7,
-        "max_tokens": 1000,
-    }
-
-    print("----------------------------------------------------------------------------------------------------------")
-    print("POST request to OpenAI")
-    print("----------------------------------------------------------------------------------------------------------")
-    ai_response = requests.post(url, headers=OPEN_API_HEADERS, json=data)
-    print(f"Status Code: {str(ai_response.status_code)}")
-    print(f"Response: {ai_response.text}")
-    ai_response.raise_for_status()
-
-    return ai_response.json()["choices"][0]["message"]["content"]
-
-release_notes = generate_release_notes(MODEL_NAME)
-print("----------------------------------------------------------------------------------------------------------")
-print("OpenAI generated release notes")
-print("----------------------------------------------------------------------------------------------------------")
-print(release_notes)
-
-# Write the release notes to GITHUB_OUTPUT
-with open(GITHUB_OUTPUT, "a") as outputs_file:
-    outputs_file.write(f"RELEASE_NOTES<<EOF\n{release_notes}\nEOF")

.github/scripts/get_prev_version_refs.py

@@ -1,52 +0,0 @@
-import os
-import re
-import subprocess
-
-def run_git_command(command):
-    result = subprocess.getoutput(command)
-    print(f"Git Command: {command}")
-    print(f"Git Output: {result}")
-    return result
-
-def parse_merge_commit(line):
-    # Parse merge commit messages like:
-    # "355dc82 Merge pull request #71 from RooCodeInc/better-error-handling"
-    pattern = r"([a-f0-9]+)\s+Merge pull request #(\d+) from (.+)"
-    match = re.match(pattern, line)
-    if match:
-        sha, pr_number, branch = match.groups()
-        return {
-            'sha': sha,
-            'pr_number': pr_number,
-            'branch': branch
-        }
-    return None
-
-def get_version_refs():
-    # Get the merge commits with full message
-    command = 'git log --merges --pretty=oneline -n 3'
-    result = run_git_command(command)
-    
-    if result:
-        commits = result.split('\n')
-        if len(commits) >= 3:
-            # Parse HEAD~1 (PR to generate notes for)
-            head_info = parse_merge_commit(commits[1])
-            # Parse HEAD~2 (previous PR to compare against)
-            base_info = parse_merge_commit(commits[2])
-            
-            if head_info and base_info:
-                # Set output for GitHub Actions
-                with open(os.environ['GITHUB_OUTPUT'], 'a') as gha_outputs:
-                    gha_outputs.write(f"head_ref={head_info['sha']}\n")
-                    gha_outputs.write(f"base_ref={base_info['sha']}")
-                
-                print(f"Head ref (PR #{head_info['pr_number']}): {head_info['sha']}")
-                print(f"Base ref (PR #{base_info['pr_number']}): {base_info['sha']}")
-                return head_info, base_info
-    
-    print("Could not find or parse sufficient merge history")
-    return None, None
-
-if __name__ == "__main__":
-    head_info, base_info = get_version_refs()

.github/scripts/overwrite_changeset_changelog.py

@@ -1,62 +0,0 @@
-"""
-This script updates a specific version's release notes section in CHANGELOG.md with new content
-or reformats existing content.
-
-The script:
-1. Takes a version number, changelog path, and optionally new content as input from environment variables
-2. Finds the section in the changelog for the specified version
-3. Either:
-   a) Replaces the content with new content if provided, or
-   b) Reformats existing content by:
-      - Removing the first two lines of the changeset format
-      - Ensuring version numbers are wrapped in square brackets
-4. Writes the updated changelog back to the file
-
-Environment Variables:
-    CHANGELOG_PATH: Path to the changelog file (defaults to 'CHANGELOG.md')
-    VERSION: The version number to update/format
-    PREV_VERSION: The previous version number (used to locate section boundaries)
-    NEW_CONTENT: Optional new content to insert for this version
-"""
-
-#!/usr/bin/env python3
-
-import os
-
-CHANGELOG_PATH = os.environ.get("CHANGELOG_PATH", "CHANGELOG.md")
-VERSION = os.environ['VERSION']
-PREV_VERSION = os.environ.get("PREV_VERSION", "")
-NEW_CONTENT = os.environ.get("NEW_CONTENT", "")
-
-def overwrite_changelog_section(changelog_text: str, new_content: str):
-    # Find the section for the specified version
-    version_pattern = f"## {VERSION}\n"
-    prev_version_pattern = f"## [{PREV_VERSION}]\n"
-    print(f"latest version: {VERSION}")
-    print(f"prev_version: {PREV_VERSION}")
-
-    notes_start_index = changelog_text.find(version_pattern) + len(version_pattern)
-    notes_end_index = changelog_text.find(prev_version_pattern, notes_start_index) if PREV_VERSION and prev_version_pattern in changelog_text else len(changelog_text)
-
-    if new_content:
-        return changelog_text[:notes_start_index] + f"{new_content}\n" + changelog_text[notes_end_index:]
-    else:
-        changeset_lines = changelog_text[notes_start_index:notes_end_index].split("\n")
-        # Remove the first two lines from the regular changeset format, ex: \n### Patch Changes
-        parsed_lines = "\n".join(changeset_lines[2:]) 
-        updated_changelog = changelog_text[:notes_start_index] + parsed_lines + changelog_text[notes_end_index:]
-        updated_changelog = updated_changelog.replace(f"## {VERSION}", f"## [{VERSION}]")
-        return updated_changelog
-
-with open(CHANGELOG_PATH, 'r') as f:
-    changelog_content = f.read()
-
-new_changelog = overwrite_changelog_section(changelog_content, NEW_CONTENT)
-print("----------------------------------------------------------------------------------")
-print(new_changelog)
-print("----------------------------------------------------------------------------------")
-# Write back to CHANGELOG.md
-with open(CHANGELOG_PATH, 'w') as f:
-    f.write(new_changelog)
-
-print(f"{CHANGELOG_PATH} updated successfully!")

.github/scripts/parse_changeset_changelog.py

@@ -1,64 +0,0 @@
-"""
-This script extracts the release notes section for a specific version from CHANGELOG.md.
-
-The script:
-1. Takes a version number and changelog path as input from environment variables
-2. Finds the section in the changelog for the specified version
-3. Extracts the content between the current version header and the next version header
-   (or end of file if it's the latest version)
-4. Outputs the extracted release notes to GITHUB_OUTPUT for use in creating GitHub releases
-
-Environment Variables:
-    GITHUB_OUTPUT: Path to GitHub Actions output file
-    CHANGELOG_PATH: Path to the changelog file (defaults to 'CHANGELOG.md')
-    VERSION: The version number to extract notes for
-"""
-
-#!/usr/bin/env python3
-
-import sys
-import os
-import subprocess
-
-GITHUB_OUTPUT = os.getenv("GITHUB_OUTPUT")
-CHANGELOG_PATH = os.environ.get("CHANGELOG_PATH", "CHANGELOG.md")
-VERSION = os.environ['VERSION']
-
-def parse_changelog_section(content: str):
-    """Parse a specific version section from the changelog content.
-    
-    Args:
-        content: The full changelog content as a string
-        
-    Returns:
-        The formatted content for this version, or None if version not found
-        
-    Example:
-        >>> content = "## 1.2.0\\nChanges\\n## 1.1.0\\nOld changes"
-        >>> parse_changelog_section(content)
-        'Changes\\n'
-    """
-    # Find the section for the specified version
-    version_pattern = f"## {VERSION}\n"
-    print(f"latest version: {VERSION}")
-    notes_start_index = content.find(version_pattern) + len(version_pattern)
-    prev_version = subprocess.getoutput("git show origin/main:package.json | grep '\"version\":' | cut -d'\"' -f4")
-    print(f"prev_version: {prev_version}")
-    prev_version_pattern = f"## {prev_version}\n"
-    notes_end_index = content.find(prev_version_pattern, notes_start_index) if prev_version_pattern in content else len(content)
-
-    return content[notes_start_index:notes_end_index]
-
-with open(CHANGELOG_PATH, 'r') as f:
-    content = f.read()
-
-formatted_content = parse_changelog_section(content)
-if not formatted_content:
-    print(f"Version {VERSION} not found in changelog", file=sys.stderr)
-    sys.exit(1)
-
-print(formatted_content)
-
-# Write the extracted release notes to GITHUB_OUTPUT
-with open(GITHUB_OUTPUT, "a") as gha_output:
-    gha_output.write(f"release-notes<<EOF\n{formatted_content}\nEOF")

.github/scripts/release-notes-prompt.py

@@ -1,125 +0,0 @@
-import os
-import subprocess
-import json
-import re
-import tiktoken # type: ignore
-from datetime import datetime;
-from pytz import timezone
-
-GITHUB_OUTPUT = os.getenv("GITHUB_OUTPUT")
-BASE_REF = os.getenv("BASE_REF", "main")
-HEAD_SHA = os.environ["HEAD_SHA"]
-PR_TITLE = os.environ["PR_TITLE"]
-PR_BODY = os.environ["PR_BODY"]
-EXISTING_NOTES = os.environ.get("EXISTING_NOTES", "null")
-MODEL_NAME = os.environ.get('MODEL_NAME', 'gpt-3.5-turbo-16k')
-CUSTOM_PROMPT = os.environ.get('CUSTOM_PROMPT', '')
-
-def extract_description_section(pr_body):
-    # Find content between ## Description and the next ## or end of text
-    description_match = re.search(r'## Description\s*\n(.*?)(?=\n##|$)', pr_body, re.DOTALL)
-    if description_match:
-        content = description_match.group(1).strip()
-        # Remove the comment line if it exists
-        comment_pattern = r'\[comment\]:.+?\n'
-        content = re.sub(comment_pattern, '', content)
-        return content.strip()
-    return ""
-
-def extract_ellipsis_important(pr_body):
-    # Find content between <!-- ELLIPSIS_HIDDEN --> and <!-- ELLIPSIS_HIDDEN --> that contains [!IMPORTANT]
-    ellipsis_match = re.search(r'<!--\s*ELLIPSIS_HIDDEN\s*-->(.*?)<!--\s*ELLIPSIS_HIDDEN\s*-->', pr_body, re.DOTALL)
-    if ellipsis_match:
-        content = ellipsis_match.group(1).strip()
-        important_match = re.search(r'\[!IMPORTANT\](.*?)(?=\[!|$)', content, re.DOTALL)
-        if important_match:
-            important_text = important_match.group(1).strip()
-            important_text = re.sub(r'^-+\s*', '', important_text)
-            return important_text.strip()
-    return ""
-
-def extract_coderabbit_summary(pr_body):
-    # Find content between ## Summary by CodeRabbit and the next ## or end of text
-    summary_match = re.search(r'## Summary by CodeRabbit\s*\n(.*?)(?=\n##|$)', pr_body, re.DOTALL)
-    return summary_match.group(1).strip() if summary_match else ""
-
-def num_tokens_from_string(string: str, model_name: str) -> int:
-    """
-    Calculate the number of tokens in a text string for a specific model.
-    
-    Args:
-        string: The input text to count tokens for
-        model_name: Name of the OpenAI model to use for token counting
-    
-    Returns:
-        int: Number of tokens in the input string
-    """
-    encoding = tiktoken.encoding_for_model(model_name)
-    num_tokens = len(encoding.encode(string))
-    return num_tokens
-
-def truncate_to_token_limit(text, max_tokens, model_name):
-    """
-    Truncate text to fit within a maximum token limit for a specific model.
-    
-    Args:
-        text: The input text to truncate
-        max_tokens: Maximum number of tokens allowed
-        model_name: Name of the OpenAI model to use for tokenization
-    
-    Returns:
-        str: Truncated text that fits within the token limit
-    """
-    encoding = tiktoken.encoding_for_model(model_name)
-    encoded = encoding.encode(text)
-    truncated = encoded[:max_tokens]
-    return encoding.decode(truncated)
-
-# Extract sections and combine into PR_OVERVIEW
-description = extract_description_section(PR_BODY)
-important = extract_ellipsis_important(PR_BODY)
-summary = extract_coderabbit_summary(PR_BODY)
-
-PR_OVERVIEW = "\n\n".join(filter(None, [description, important, summary]))
-
-# Get git information
-base_sha = subprocess.getoutput(f"git rev-parse origin/{BASE_REF}") if BASE_REF == 'main' else BASE_REF
-diff_overview = subprocess.getoutput(f"git diff {base_sha}..{HEAD_SHA} --name-status | awk '{{print $2}}' | sort | uniq -c | awk '{{print $2 \": \" $1 \" files changed\"}}'")
-git_log = subprocess.getoutput(f"git log {base_sha}..{HEAD_SHA} --pretty=format:'%h - %s (%an)' --reverse | head -n 50")
-git_diff = subprocess.getoutput(f"git diff {base_sha}..{HEAD_SHA} --minimal --abbrev --ignore-cr-at-eol --ignore-space-at-eol --ignore-space-change --ignore-all-space --ignore-blank-lines --unified=0 --diff-filter=ACDMRT")
-
-max_tokens = 14000  # Reserve some tokens for the response
-changes_summary = truncate_to_token_limit(diff_overview, 1000, MODEL_NAME)
-git_logs = truncate_to_token_limit(git_log, 2000, MODEL_NAME)
-changes_diff = truncate_to_token_limit(git_diff, max_tokens - num_tokens_from_string(changes_summary, MODEL_NAME) - num_tokens_from_string(git_logs, MODEL_NAME) - 1000, MODEL_NAME)
-
-# Get today's existing changelog if any
-existing_changelog = EXISTING_NOTES if EXISTING_NOTES != "null" else None
-existing_changelog_text = f"\nAdditional context:\n{existing_changelog}" if existing_changelog else ""
-TODAY = datetime.now(timezone('US/Eastern')).isoformat(sep=' ', timespec='seconds')
-
-BASE_PROMPT = CUSTOM_PROMPT if CUSTOM_PROMPT else f"""Based on the following 'PR Information', please generate concise and informative release notes to be read by developers.
-Format the release notes with markdown, and always use this structure: a descriptive and very short title (no more than 8 words) with heading level 2, a paragraph with a summary of changes (no header), and if applicable, sections for '🚀 New Features & Improvements', '🐛 Bugs Fixed' and '🔧 Other Updates', with heading level 3, skip respectively the sections if not applicable. 
-Finally include the following markdown comment with the PR merged date: <!-- PR_DATE: {TODAY} -->.
-Avoid being repetitive and focus on the most important changes and their impact, discard any mention of version bumps/updates, changeset files, environment variables or syntax updates.
-PR Information:"""
-
-OPENAI_PROMPT = f"""{BASE_PROMPT}
-Git log summary:
-{changes_summary}
-Commit Messages:
-{git_logs}
-PR Title:
-{PR_TITLE}
-PR Overview:
-{PR_OVERVIEW}{existing_changelog_text}
-Code Diff:
-{json.dumps(changes_diff)}"""
-
-print("OpenAI Prompt")
-print("----------------------------------------------------------------")
-print(OPENAI_PROMPT)
-
-# Write the prompt to GITHUB_OUTPUT
-with open(GITHUB_OUTPUT, "a") as outputs_file:
-    outputs_file.write(f"OPENAI_PROMPT<<EOF\n{OPENAI_PROMPT}\nEOF")

.github/workflows/build-vsix.yml

@@ -1,45 +0,0 @@
-name: Build VSIX
-
-on:
-  pull_request:
-    types: [labeled]
-    branches: [ main ]
-
-jobs:
-  build:
-    runs-on: ubuntu-latest
-    if: github.event.label.name == 'build'
-
-    steps:
-    - name: Checkout code
-      uses: actions/checkout@v4
-
-    - name: Set up Node.js
-      uses: actions/setup-node@v4
-      with:
-        node-version-file: 'package.json'
-        cache: 'npm'
-
-    - name: Install dependencies
-      run: npm ci
-
-    - name: Install all dependencies
-      run: npm run install:all
-
-    - name: Build Extension
-      run: npm run build
-
-    - name: Upload VSIX artifact
-      uses: actions/upload-artifact@v4
-      with:
-        name: extension-vsix
-        path: bin/*.vsix
-
-    - name: Comment PR with artifact link
-      if: github.event_name == 'pull_request'
-      uses: peter-evans/create-or-update-comment@v4
-      with:
-        issue-number: ${{ github.event.pull_request.number }}
-        body: |
-          Build successful! 🚀
-          You can download the VSIX extension [here](${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}).

.github/workflows/changeset-release.yml

@@ -9,7 +9,6 @@ on:
 env:
   REPO_PATH: ${{ github.repository }}
   GIT_REF: ${{ github.event_name == 'pull_request' && github.event.pull_request.head.sha || 'main' }}
-  NODE_VERSION: 20.18.1
 
 jobs:
   # Job 1: Create version bump PR when changesets are merged to main
@@ -30,15 +29,8 @@ jobs:
         with:
           fetch-depth: 0
           ref: ${{ env.GIT_REF }}
-
-      - name: Setup Node.js
-        uses: actions/setup-node@v4
-        with:
-          node-version: ${{ env.NODE_VERSION }}
-          cache: 'npm'
-            
-      - name: Install Dependencies
-        run: npm run install:all
+      - name: Setup Node.js and pnpm
+        uses: ./.github/actions/setup-node-pnpm
 
       # Check if there are any new changesets to process
       - name: Check for changesets
@@ -56,7 +48,7 @@ jobs:
         with:
           commit: "changeset version bump"
           title: "Changeset version bump"
-          version: npm run version-packages # This performs the changeset version bump
+          version: pnpm changeset:version # This performs the changeset version bump
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 
@@ -96,25 +88,6 @@ jobs:
           fetch-depth: 0
           ref: ${{ steps.checkout-ref.outputs.git_ref }}
 
-      # Get current and previous versions to edit changelog entry
-      - name: Get version
-        id: get_version
-        run: |
-          VERSION=$(git show HEAD:package.json | jq -r '.version')
-          echo "version=$VERSION" >> $GITHUB_OUTPUT
-          PREV_VERSION=$(git show origin/main:package.json | jq -r '.version')
-          echo "prev_version=$PREV_VERSION" >> $GITHUB_OUTPUT
-          echo "version=$VERSION"
-          echo "prev_version=$PREV_VERSION"
-
-      # Update CHANGELOG.md with proper format
-      - name: Update Changelog Format
-        if: ${{ !contains(github.event.pull_request.labels.*.name, 'changelog-ready') }}
-        env:
-          VERSION: ${{ steps.get_version.outputs.version }}
-          PREV_VERSION: ${{ steps.get_version.outputs.prev_version }}
-        run: python .github/scripts/overwrite_changeset_changelog.py
-
       # Commit and push changelog updates
       - name: Push Changelog updates
         if: ${{ !contains(github.event.pull_request.labels.*.name, 'changelog-ready') }}

.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

@@ -1,146 +1,60 @@
 name: Code QA Roo Code
 
 on:
-  workflow_dispatch:
-  push:
-    branches: [main]
-  pull_request:
-    types: [opened, reopened, ready_for_review, synchronize]
-    branches: [main]
-
-env:
-  NODE_VERSION: 20.18.1
+    workflow_dispatch:
+    push:
+        branches: [main]
+    pull_request:
+        types: [opened, reopened, ready_for_review, synchronize]
+        branches: [main]
 
 jobs:
-  compile:
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout code
-        uses: actions/checkout@v4
-      - name: Setup Node.js
-        uses: actions/setup-node@v4
-        with:
-          node-version: ${{ env.NODE_VERSION }}
-          cache: 'npm'
-      - name: Install dependencies
-        run: npm run install:all
-      - name: Compile
-        run: npm run compile
-      - name: Check types
-        run: npm run check-types
-      - name: Lint
-        run: npm run lint
+    check-translations:
+        runs-on: ubuntu-latest
+        steps:
+            - name: Checkout code
+              uses: actions/checkout@v4
+            - name: Setup Node.js and pnpm
+              uses: ./.github/actions/setup-node-pnpm
+            - name: Verify all translations are complete
+              run: node scripts/find-missing-translations.js
 
-  check-translations:
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout code
-        uses: actions/checkout@v4
-      - name: Setup Node.js
-        uses: actions/setup-node@v4
-        with:
-          node-version: '18'
-          cache: 'npm'
-      - name: Install dependencies
-        run: npm run install:all
-      - name: Verify all translations are complete
-        run: node scripts/find-missing-translations.js
+    knip:
+        runs-on: ubuntu-latest
+        steps:
+            - name: Checkout code
+              uses: actions/checkout@v4
+            - name: Setup Node.js and pnpm
+              uses: ./.github/actions/setup-node-pnpm
+            - name: Run knip checks
+              run: pnpm knip
 
-  knip:
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout code
-        uses: actions/checkout@v4
-      - name: Setup Node.js
-        uses: actions/setup-node@v4
-        with:
-          node-version: '18'
-          cache: 'npm'
-      - name: Install dependencies
-        run: npm run install:all
-      - name: Run knip checks
-        run: npm run knip
+    compile:
+        runs-on: ubuntu-latest
+        steps:
+            - name: Checkout code
+              uses: actions/checkout@v4
+            - name: Setup Node.js and pnpm
+              uses: ./.github/actions/setup-node-pnpm
+            - name: Lint
+              run: pnpm lint
+            - name: Check types
+              run: pnpm check-types
 
-  test-extension:
-    runs-on: ${{ matrix.os }}
-    strategy:
-      matrix:
-        os: [ubuntu-latest, windows-latest]
-    steps:
-      - name: Checkout code
-        uses: actions/checkout@v4
-      - name: Setup Node.js
-        uses: actions/setup-node@v4
-        with:
-          node-version: ${{ env.NODE_VERSION }}
-          cache: 'npm'
-      - name: Install dependencies
-        run: npm run install:all
-      - name: Compile (to build and copy WASM files)
-        run: npm run compile
-      - name: Run jest unit tests
-        run: npx jest --silent
-      - name: Run vitest unit tests
-        run: npx vitest run --silent
-
-  test-webview:
-    runs-on: ${{ matrix.os }}
-    strategy:
-      matrix:
-        os: [ubuntu-latest, windows-latest]
-    steps:
-      - name: Checkout code
-        uses: actions/checkout@v4
-      - name: Setup Node.js
-        uses: actions/setup-node@v4
-        with:
-          node-version: '18'
-          cache: 'npm'
-      - name: Install dependencies
-        run: npm run install:all
-      - name: Run unit tests
-        working-directory: webview-ui
-        run: npx jest --silent
-
-  unit-test:
-    needs: [test-extension, test-webview]
-    runs-on: ubuntu-latest
-    steps:
-      - name: NO-OP
-        run: echo "All unit tests passed."
-
-  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
-        uses: actions/setup-node@v4
-        with:
-          node-version: ${{ env.NODE_VERSION }}
-          cache: 'npm'
-      - name: Install dependencies
-        run: npm run install:all
-      - name: Create .env.local file
-        working-directory: e2e
-        run: echo "OPENROUTER_API_KEY=${{ secrets.OPENROUTER_API_KEY }}" > .env.local
-      - name: Run integration tests
-        working-directory: e2e
-        run: xvfb-run -a npm run ci
+    unit-test:
+        name: platform-unit-test (${{ matrix.name }})
+        runs-on: ${{ matrix.os }}
+        strategy:
+            matrix:
+                include:
+                    - os: ubuntu-latest
+                      name: ubuntu-latest
+                    - os: windows-latest
+                      name: windows-latest
+        steps:
+            - name: Checkout code
+              uses: actions/checkout@v4
+            - name: Setup Node.js and pnpm
+              uses: ./.github/actions/setup-node-pnpm
+            - name: Run unit tests
+              run: pnpm test

.github/workflows/codeql.yml

@@ -1,15 +1,4 @@
-# For most projects, this workflow file will not need changing; you simply need
-# to commit it to your repository.
-#
-# You may wish to alter this file to override the set of languages analyzed,
-# or to provide custom queries or build logic.
-#
-# ******** NOTE ********
-# We have attempted to detect the languages in your repository. Please check
-# the `language` matrix defined below to confirm you have the correct set of
-# supported CodeQL languages.
-#
-name: "CodeQL Advanced"
+name: CodeQL Advanced
 
 on:
   push:

.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/marketplace-publish.yml

@@ -1,4 +1,5 @@
 name: Publish Extension
+
 on:
   pull_request:
     types: [closed]
@@ -6,7 +7,6 @@ on:
 
 env:
   GIT_REF: ${{ github.event_name == 'pull_request' && github.event.pull_request.head.sha || 'main' }}
-  NODE_VERSION: 20.18.1
 
 jobs:
   publish-extension:
@@ -19,50 +19,57 @@ jobs:
         contains(github.event.pull_request.title, 'Changeset version bump') ) ||
         github.event_name == 'workflow_dispatch'
     steps:
-      - uses: actions/checkout@v4
+      - name: Checkout code
+        uses: actions/checkout@v4
         with:
           ref: ${{ env.GIT_REF }}
-      - uses: actions/setup-node@v4
-        with:
-          node-version: ${{ env.NODE_VERSION }}
-      - run: |
+      - name: Setup Node.js and pnpm
+        uses: ./.github/actions/setup-node-pnpm
+      - name: Configure Git
+        run: |
           git config user.name "github-actions[bot]"
           git config user.email "github-actions[bot]@users.noreply.github.com"
-      - name: Install Dependencies
-        run: npm run install:all
       - name: Create .env file
         run: echo "POSTHOG_API_KEY=${{ secrets.POSTHOG_API_KEY }}" >> .env
       - name: Package Extension
         run: |
-          current_package_version=$(node -p "require('./package.json').version")
-          npm run vsix
-          package=$(unzip -l bin/roo-cline-${current_package_version}.vsix)
-          echo "$package" | grep -q "extension/package.json" || exit 1
-          echo "$package" | grep -q "extension/package.nls.json" || exit 1
-          echo "$package" | grep -q "extension/dist/extension.js" || exit 1
-          echo "$package" | grep -q "extension/webview-ui/audio/celebration.wav" || exit 1
-          echo "$package" | grep -q "extension/webview-ui/build/assets/index.js" || exit 1
-          echo "$package" | grep -q "extension/node_modules/@vscode/codicons/dist/codicon.ttf" || exit 1
-          echo "$package" | grep -q ".env" || exit 1
+          current_package_version=$(node -p "require('./src/package.json').version")
+          pnpm vsix
+
+          # Save VSIX contents to a temporary file to avoid broken pipe issues.
+          unzip -l bin/roo-cline-${current_package_version}.vsix > /tmp/roo-code-vsix-contents.txt
+
+          # Check for required files.
+          grep -q "extension/package.json" /tmp/roo-code-vsix-contents.txt || exit 1
+          grep -q "extension/package.nls.json" /tmp/roo-code-vsix-contents.txt || exit 1
+          grep -q "extension/dist/extension.js" /tmp/roo-code-vsix-contents.txt || exit 1
+          grep -q "extension/webview-ui/audio/celebration.wav" /tmp/roo-code-vsix-contents.txt || exit 1
+          grep -q "extension/webview-ui/build/assets/index.js" /tmp/roo-code-vsix-contents.txt || exit 1
+          grep -q "extension/assets/codicons/codicon.ttf" /tmp/roo-code-vsix-contents.txt || exit 1
+          grep -q "extension/assets/vscode-material-icons/icons/3d.svg" /tmp/roo-code-vsix-contents.txt || exit 1
+          grep -q ".env" /tmp/roo-code-vsix-contents.txt || exit 1
+          
+          # Clean up temporary file.
+          rm /tmp/roo-code-vsix-contents.txt
       - name: Create and Push Git Tag
         run: |
-          current_package_version=$(node -p "require('./package.json').version")
+          current_package_version=$(node -p "require('./src/package.json').version")
           git tag -a "v${current_package_version}" -m "Release v${current_package_version}"
-          git push origin "v${current_package_version}"
+          git push origin "v${current_package_version}" --no-verify
           echo "Successfully created and pushed git tag v${current_package_version}"
       - name: Publish Extension
         env:
           VSCE_PAT: ${{ secrets.VSCE_PAT }}
           OVSX_PAT: ${{ secrets.OVSX_PAT }}
         run: |
-          current_package_version=$(node -p "require('./package.json').version")
-          npm run publish:marketplace
+          current_package_version=$(node -p "require('./src/package.json').version")
+          pnpm --filter roo-cline publish:marketplace
           echo "Successfully published version $current_package_version to VS Code Marketplace"
       - name: Create GitHub Release
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         run: |
-          current_package_version=$(node -p "require('./package.json').version")
+          current_package_version=$(node -p "require('./src/package.json').version")
 
           # Extract changelog for current version
           echo "Extracting changelog for version ${current_package_version}"

.github/workflows/nightly-publish.yml

@@ -0,0 +1,52 @@
+name: Nightly Publish
+
+on:
+  push:
+    branches: [main]
+  workflow_dispatch: # Allows manual triggering.
+
+jobs:
+  publish-nightly:
+    runs-on: ubuntu-latest
+
+    permissions:
+      contents: read # No tags pushed → read is enough.
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      - name: Setup Node.js and pnpm
+        uses: ./.github/actions/setup-node-pnpm
+        with:
+          install-args: '--frozen-lockfile'
+      - name: Forge numeric Nightly version
+        id: version
+        env:
+          RUN_NUMBER: ${{ github.run_number }}
+        run: echo "number=$(( 5500 + ${RUN_NUMBER} ))" >> $GITHUB_OUTPUT
+      - name: Patch package.json version
+        env:
+          VERSION_NUMBER: ${{ steps.version.outputs.number }}
+        run: |
+          node <<'EOF'
+            const fs = require('fs');
+            const path = require('path');
+            const pkgPath = path.join(__dirname, 'apps', 'vscode-nightly', 'package.nightly.json');
+            const pkg = JSON.parse(fs.readFileSync(pkgPath,'utf8'));
+            const [maj, min] = pkg.version.split('.');
+            pkg.version = `${maj}.${min}.${process.env.VERSION_NUMBER}`;
+            fs.writeFileSync(pkgPath, JSON.stringify(pkg, null, 2));
+            console.log(`🔖 Nightly version set to ${pkg.version}`);
+          EOF
+      - name: Build VSIX
+        run: pnpm vsix:nightly # Produces bin/roo-code-nightly-0.0.[count].vsix
+      - name: Publish to VS Code Marketplace
+        env:
+          VSCE_PAT: ${{ secrets.VSCE_PAT }}
+        run: npx vsce publish --packagePath "bin/$(/bin/ls bin | head -n1)"
+      - name: Publish to Open VSX Registry
+        env:
+          OVSX_PAT: ${{ secrets.OVSX_PAT }}
+        run: npx ovsx publish "bin/$(ls bin | head -n1)"

.github/workflows/update-contributors.yml

@@ -1,56 +0,0 @@
-name: Update Contributors
-
-on:
-  push:
-    branches:
-      - main
-  workflow_dispatch:  # Allows manual triggering
-
-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
-        uses: actions/setup-node@v4
-        with:
-          node-version: '18'
-          cache: 'npm'
-          
-      - name: Disable Husky
-        run: |
-          echo "HUSKY=0" >> $GITHUB_ENV
-          git config --global core.hooksPath /dev/null
-          
-      - name: Install dependencies
-        run: npm ci
-        
-      - name: Update contributors and format
-        run: |
-          npm run 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@v5
-        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

.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
@@ -30,16 +32,26 @@ docs/_site/
 .env.*
 !.env.*.sample
 
-
-#Local lint config
-.eslintrc.local.json
-
-#Logging
+# Logging
 logs
+*.log
 
 # Vite development
 .vite-port
 
+# Turborepo
+.turbo
+
 # IntelliJ and Qodo plugin folders
 .idea/
 .qodo/
+.vercel
+.roo/mcp.json
+
+# Qdrant
+qdrant_storage/
+
+# Architect plans
+plans/
+
+roo-cli-*.tar.gz*

.husky/pre-commit

@@ -5,19 +5,23 @@ if [ "$branch" = "main" ]; then
   exit 1
 fi
 
-# Detect if running on Windows and use npx.cmd, otherwise use npx
+# Detect if running on Windows and use pnpm.cmd, otherwise use pnpm.
+if [ "$OS" = "Windows_NT" ]; then
+  pnpm_cmd="pnpm.cmd"
+else
+  if command -v pnpm >/dev/null 2>&1; then
+    pnpm_cmd="pnpm"
+  else
+    pnpm_cmd="npx pnpm"
+  fi
+fi
+
+# Detect if running on Windows and use npx.cmd, otherwise use npx.
 if [ "$OS" = "Windows_NT" ]; then
   npx_cmd="npx.cmd"
 else
   npx_cmd="npx"
 fi
 
-npm run generate-types
-
-if [ -n "$(git diff --name-only src/exports/roo-code.d.ts)" ]; then
-  echo "Error: There are unstaged changes to roo-code.d.ts after running 'npm run generate-types'."
-  echo "Please review and stage the changes before committing."
-  exit 1
-fi
-
-"$npx_cmd" lint-staged
+$npx_cmd lint-staged
+$pnpm_cmd lint

.husky/pre-push

@@ -5,21 +5,38 @@ if [ "$branch" = "main" ]; then
   exit 1
 fi
 
-# Detect if running on Windows and use npm.cmd, otherwise use npm
+# Detect if running on Windows and use pnpm.cmd, otherwise use pnpm.
 if [ "$OS" = "Windows_NT" ]; then
-  npm_cmd="npm.cmd"
+  pnpm_cmd="pnpm.cmd"
 else
-  npm_cmd="npm"
+  if command -v pnpm >/dev/null 2>&1; then
+    pnpm_cmd="pnpm"
+  else
+    pnpm_cmd="npx pnpm"
+  fi
 fi
 
-"$npm_cmd" run compile
+$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"
 
-if [ "$NEW_CHANGESETS" == "0" ]; then
+if [ "$NEW_CHANGESETS" = "0" ]; then
   echo "-------------------------------------------------------------------------------------"
-  echo "Changes detected. Please run 'npm run changeset' to create a changeset if applicable."
+  echo "Changes detected. Please run 'pnpm changeset' to create a changeset if applicable."
   echo "-------------------------------------------------------------------------------------"
 fi

.npmrc

@@ -1 +0,0 @@
-registry=https://registry.npmjs.org/

.nvmrc

@@ -1 +1 @@
-v20.18.1
+v20.19.2

.prettierignore

@@ -1,5 +0,0 @@
-dist/
-node_modules
-webview-ui/build/
-CHANGELOG.md
-package-lock.json

.prettierrc.json

@@ -3,5 +3,6 @@
 	"useTabs": true,
 	"printWidth": 120,
 	"semi": false,
-	"bracketSameLine": true
+	"bracketSameLine": true,
+	"ignore": ["node_modules", "dist", "build", "out", ".next", ".venv", "pnpm-lock.yaml"]
 }

.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-code/use-safeWriteJson.md

@@ -0,0 +1,6 @@
+# JSON File Writing Must Be Atomic
+
+- You MUST use `safeWriteJson(filePath: string, data: any): Promise<void>` from `src/utils/safeWriteJson.ts` instead of `JSON.stringify` with file-write operations
+- `safeWriteJson` will create parent directories if necessary, so do not call `mkdir` prior to `safeWriteJson`
+- `safeWriteJson` prevents data corruption via atomic writes with locking and streams the write to minimize memory footprint
+- Test files are exempt from this rule

.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

@@ -0,0 +1,113 @@
+<extraction_workflow>
+  <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>
+
+  <process>
+    <step number="1">
+      <title>Identify Target</title>
+      <actions>
+        <action>Parse the user's request to identify the feature/aspect</action>
+        <action>Clarify scope if ambiguous (ask one question max)</action>
+      </actions>
+    </step>
+
+    <step number="2">
+      <title>Discover Code</title>
+      <actions>
+        <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="3">
+      <title>Extract Facts</title>
+      <actions>
+        <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>
+
+    <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_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_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-issue-fixer/1_Workflow.xml

@@ -0,0 +1,566 @@
+<workflow>
+  <step number="1">
+    <name>Retrieve Issue Context</name>
+    <instructions>
+      The user should provide a full GitHub issue URL (e.g., "https://github.com/owner/repo/issues/123") for implementation.
+      
+      Parse the URL to extract:
+      - Owner (organization or username)
+      - Repository name
+      - Issue number
+      
+      For example, from https://github.com/RooCodeInc/Roo-Code/issues/123:
+      - Owner: RooCodeInc
+      - Repo: Roo-Code
+      - Issue: 123
+      
+      Then retrieve the issue:
+      
+      <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>
+      
+      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>
+      
+      Analyze the issue to determine:
+      1. All requirements and acceptance criteria
+      2. Technical details mentioned
+      3. Any linked issues or discussions
+      
+      Note: For PR review feedback, users should use the dedicated pr-fixer mode instead.
+    </instructions>
+  </step>
+
+  <step number="2">
+    <name>Review Issue Comments and Related Context</name>
+    <instructions>
+      Get all comments on the issue to understand:
+      - Additional context or clarifications
+      - Maintainer feedback
+      - Community suggestions
+      - Any decisions or changes to requirements
+      
+      <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>
+
+  <step number="3">
+    <name>Explore Codebase and Related Files</name>
+    <instructions>
+      Use codebase_search FIRST to understand the codebase structure and find ALL related files:
+      
+      For Bug Fixes:
+      - Search for the broken functionality
+      - Find error handling and logging
+      - Locate related test files
+      - Identify dependencies and imports
+      - Find similar patterns in the codebase
+      
+      For Features:
+      - Search for similar existing features
+      - Find integration points
+      - Locate configuration files
+      - Identify patterns to follow
+      - Find related components and utilities
+      
+      Example searches based on issue type:
+      - Bug: Search for error messages, function names, component names
+      - Feature: Search for similar functionality, API endpoints, UI components
+      
+      CRITICAL: Always read multiple related files together to understand:
+      - Current code patterns and conventions
+      - How similar functionality is implemented
+      - Testing patterns used in the project
+      - Import/export patterns
+      - Error handling approaches
+      - Configuration and setup patterns
+      
+      Then use other tools:
+      - list_code_definition_names to understand file structure
+      - read_file to examine specific implementations (read multiple files at once)
+      - search_files for specific patterns or error messages
+      
+      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
+      - Current implementation details and patterns
+      - Code conventions to follow (naming, structure, etc.)
+      - Test file locations and patterns
+      - Related files that might be affected
+    </instructions>
+  </step>
+
+  <step number="4">
+    <name>Create Implementation Plan</name>
+    <instructions>
+      Based on the issue analysis, create a detailed implementation plan:
+      
+      For Bug Fixes:
+      1. Reproduce the bug locally (if possible)
+      2. Identify root cause
+      3. Plan the fix approach. The plan should be focused on resolving the issue with a high-quality, targeted fix, while avoiding unrelated changes.
+      4. Identify files to modify.
+      5. Plan test cases to prevent regression.
+      
+      For Feature Implementation:
+      1. Break down the feature into components
+      2. Identify all files that need changes
+      3. Plan the implementation approach
+      4. Consider edge cases and error handling
+      5. Plan test coverage
+      
+      Present the plan to the user:
+      
+      <ask_followup_question>
+      <question>I've analyzed issue #[number]: "[title]"
+
+      Here's my implementation plan to resolve the issue:
+
+      [Detailed plan with steps and affected files]
+
+      This plan focuses on providing a quality fix for the reported problem without introducing unrelated changes.
+
+      Would you like me to proceed with this implementation?</question>
+      <follow_up>
+      <suggest>Yes, proceed with the implementation</suggest>
+      <suggest>Let me review the issue first</suggest>
+      <suggest>Modify the approach for: [specific aspect]</suggest>
+      <suggest>Focus only on: [specific part]</suggest>
+      </follow_up>
+      </ask_followup_question>
+    </instructions>
+  </step>
+
+  <step number="5">
+    <name>Implement the Solution</name>
+    <instructions>
+      Implement the fix or feature following the plan:
+      
+      General Guidelines:
+      1. Follow existing code patterns and style
+      2. Add appropriate error handling
+      3. Include necessary comments
+      4. Update related documentation
+      5. Ensure backward compatibility (if applicable)
+      
+      For Bug Fixes:
+      1. Implement the planned fix, focusing on quality and precision.
+      2. The scope of the fix should be as narrow as possible to address the issue. Avoid making changes to code that is not directly related to the fix. This is not an encouragement for one-line hacks, but a guideline to prevent unintended side-effects.
+      3. Add regression tests.
+      4. Verify the fix resolves the issue.
+      5. Check for side effects.
+      
+      For Features:
+      1. Implement incrementally
+      2. Test each component as you build
+      3. Follow the acceptance criteria exactly
+      4. Add comprehensive tests
+      5. Update documentation
+      
+      Use appropriate tools:
+      - apply_diff for targeted changes
+      - write_to_file for new files
+      
+      After each significant change, run relevant tests:
+      - execute_command to run test suites
+      - Check for linting errors
+      - Verify functionality works as expected
+    </instructions>
+  </step>
+
+  <step number="6">
+    <name>Verify Acceptance Criteria</name>
+    <instructions>
+      Systematically verify all acceptance criteria from the issue:
+      
+      For Bug Fixes:
+      1. Confirm the bug no longer reproduces
+      2. Follow the exact reproduction steps
+      3. Verify expected behavior now occurs
+      4. Check no new bugs introduced
+      5. Run all related tests
+      
+      For Features:
+      1. Test each acceptance criterion
+      2. Verify all Given/When/Then scenarios
+      3. Test edge cases
+      4. Verify UI changes (if applicable)
+      5. Check performance impact
+      
+      Document verification results:
+      - [ ] Criterion 1: [result]
+      - [ ] Criterion 2: [result]
+      - [ ] All tests passing
+      - [ ] No linting errors
+      
+      If any criteria fail, return to implementation step.
+     </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:
+      
+      1. Run unit tests for modified files:
+         ```
+         npm test [test file paths]
+         ```
+      
+      2. Run integration tests if applicable:
+         ```
+         npm run test:integration
+         ```
+      
+      3. Check for linting errors:
+         ```
+         npm run lint
+         ```
+      
+      4. Run type checking:
+         ```
+         npm run type-check
+         ```
+      
+      5. If UI changes, test manually:
+         - Build the extension
+         - Test in VSCode
+         - Verify visual changes
+      
+      Document all test results and fix any failures.
+    </instructions>
+  </step>
+
+  <step number="9">
+    <name>Prepare Summary</name>
+    <instructions>
+      Create a comprehensive summary of the implementation:
+      
+      ## Summary of Changes
+      
+      **Issue:** #[number] - [title]
+      **Type:** [Bug Fix/Feature Implementation]
+      
+      ### What was done:
+      - [List key changes]
+      - [Files modified]
+      - [Tests added]
+      
+      ### How it addresses the issue:
+      [Explain how each requirement is met]
+      
+      ### Testing performed:
+      - [List all tests run]
+      - [Manual testing done]
+      - [Verification of acceptance criteria]
+      
+      ### Files changed:
+      - `path/to/file1.ts` - [brief description]
+      - `path/to/file2.ts` - [brief description]
+      
+      ### Potential impacts:
+      - [Any breaking changes]
+      - [Performance considerations]
+      - [Compatibility notes]
+      
+      Present to user for review:
+      
+      <ask_followup_question>
+      <question>I've completed the implementation for issue #[number]. Here's what was done:
+
+      [Insert summary]
+
+      All acceptance criteria have been met and tests are passing.
+
+      Would you like me to prepare a pull request, or would you like to review the changes first?</question>
+      <follow_up>
+      <suggest>Create a pull request with these changes</suggest>
+      <suggest>Show me the key changes in detail</suggest>
+      <suggest>Run additional tests for: [specific area]</suggest>
+      <suggest>Make additional changes to: [specific file]</suggest>
+      </follow_up>
+      </ask_followup_question>
+    </instructions>
+  </step>
+
+  <step number="10">
+    <name>Prepare for Pull Request</name>
+    <instructions>
+      If user wants to create a pull request, prepare everything needed:
+      
+      1. Create appropriate branch name:
+         - Bug fix: `fix/issue-[number]-[brief-description]`
+         - Feature: `feat/issue-[number]-[brief-description]`
+      
+      2. Ensure all changes are committed:
+         ```bash
+         git status
+         git add [modified files]
+         git commit -m "fix: [description] (#[issue-number])"
+         ```
+      
+      3. Push to a fork or branch (depending on user's access):
+         ```bash
+         git push origin [branch-name]
+         ```
+      
+      4. Prepare comprehensive PR description:
+         ```markdown
+         ## Description
+         
+         Fixes #[issue number]
+         
+         [Detailed description of what was changed and why]
+         
+         ## Changes Made
+         
+         - [Specific change 1 with file references]
+         - [Specific change 2 with technical details]
+         - [Any refactoring or cleanup done]
+         
+         ## Testing
+         
+         - [x] All existing tests pass
+         - [x] Added tests for [specific functionality]
+         - [x] Manual testing completed:
+           - [Specific manual test 1]
+           - [Specific manual test 2]
+         
+         ## Verification of Acceptance Criteria
+         
+         [For each criterion from the issue, show it's met]
+         - [x] Criterion 1: [How it's verified]
+         - [x] Criterion 2: [How it's verified]
+         
+         ## Checklist
+         
+         - [x] Code follows project style guidelines
+         - [x] Self-review completed
+         - [x] Comments added for complex logic
+         - [x] Documentation updated (if needed)
+         - [x] No breaking changes (or documented if any)
+         - [x] Accessibility checked (for UI changes)
+         
+         ## Screenshots/Demo (if applicable)
+         
+         [Add before/after screenshots for UI changes]
+         [Add terminal output for CLI changes]
+         ```
+      
+      5. Ask user for final approval:
+      
+      <ask_followup_question>
+      <question>I've prepared everything for the pull request:
+
+      **Branch:** [branch-name]
+      **Title:** [PR title]
+      **Target:** [owner]/[repo] (main branch)
+
+      Here's the PR description:
+
+      [Show prepared PR description]
+
+      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>
+      <suggest>Change the PR title to: [let me specify]</suggest>
+      <suggest>Add more details about: [specific aspect]</suggest>
+      </follow_up>
+      </ask_followup_question>
+    </instructions>
+  </step>
+
+  <step number="11">
+    <name>Create Pull Request</name>
+    <instructions>
+      Once user approves, create the pull request using GitHub CLI:
+      
+      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>
+      
+      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 command output
+      2. Link the PR to the issue by commenting on the issue
+      3. Inform the user of the successful creation
+      
+      <execute_command>
+      <command>gh issue comment [original issue number] --repo [owner]/[repo] --body "PR #[new PR number] has been created to address this issue"</command>
+      </execute_command>
+      
+      Final message to user:
+      ```
+      ✅ Pull Request Created Successfully!
+      
+      PR #[number]: [title]
+      URL: [PR URL]
+      
+      The PR has been created and linked to issue #[issue number].
+      
+      Next steps:
+      1. The PR will be reviewed by maintainers
+      2. Address any feedback in the PR comments
+      3. Once approved, it will be merged
+      
+      You can track the PR status at: [PR URL]
+      ```
+    </instructions>
+  </step>
+
+  <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 [PR number] --repo [owner]/[repo] --watch</command>
+      </execute_command>
+      
+      This command will:
+      1. Display all CI/CD checks configured for the repository
+      2. Show the status of each check in real-time
+      3. Update automatically as checks complete
+      4. Exit when all checks have finished running
+      
+      Monitor the output and note:
+      - Which checks are running (e.g., tests, linting, build)
+      - Any checks that fail and their error messages
+      - The overall status of the PR checks
+      
+      If any checks fail:
+      1. Analyze the failure logs
+      2. Identify what needs to be fixed
+      3. Ask the user if they want you to address the failures
+      
+      <ask_followup_question>
+      <question>The PR checks have completed. Here's the status:
+
+      [Show check results - passing/failing]
+
+      [If all pass]: All checks have passed successfully! The PR is ready for review.
+
+      [If any fail]: Some checks have failed:
+      - [Failed check 1]: [Brief error description]
+      - [Failed check 2]: [Brief error description]
+
+      Would you like me to fix these issues?</question>
+      <follow_up>
+      <suggest>Yes, please fix the failing checks</suggest>
+      <suggest>Show me the detailed error logs</suggest>
+      <suggest>I'll handle the failures manually</suggest>
+      <suggest>The PR is fine as-is, these failures are expected</suggest>
+      </follow_up>
+      </ask_followup_question>
+      
+      If user wants fixes:
+      1. Create a plan to address each failure
+      2. Make necessary code changes
+      3. Commit and push the fixes
+      4. Monitor checks again to ensure they pass
+      
+      Important notes:
+      - The --watch flag will keep the command running until all checks complete
+      - This step helps ensure the PR meets all quality standards before review
+      - Early detection of CI/CD failures saves reviewer time
+    </instructions>
+  </step>
+</workflow>

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

@@ -0,0 +1,19 @@
+<best_practices>
+  - Always read the entire issue and all comments before starting
+  - Follow the project's coding standards and patterns
+  - Focus exclusively on addressing the issue's requirements.
+  - Make minimal, high-quality changes for bug fixes. The goal is a narrow, targeted fix, not a one-line hack.
+  - Test thoroughly - both automated and manual testing
+  - Document complex logic with comments
+  - Keep commits focused and well-described
+  - Reference the issue number in commits
+  - Verify all acceptance criteria are met
+  - Consider performance and security implications
+  - Update documentation when needed
+  - Add tests for any new functionality
+  - Check for accessibility issues (for UI changes)
+  - 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/3_common_patterns.xml

@@ -0,0 +1,21 @@
+<common_patterns>
+  <bug_fix_pattern>
+    1. Reproduce the issue
+    2. Identify root cause
+    3. Implement minimal fix
+    4. Add regression test
+    5. Verify fix works
+    6. Check for side effects
+  </bug_fix_pattern>
+  
+  <feature_implementation_pattern>
+    1. Understand all requirements
+    2. Design the solution
+    3. Implement incrementally
+    4. Test each component
+    5. Integrate components
+    6. Verify acceptance criteria
+    7. Add comprehensive tests
+    8. Update documentation
+  </feature_implementation_pattern>
+</common_patterns>

.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/5_pull_request_workflow.xml

@@ -0,0 +1,52 @@
+<pull_request_workflow>
+  <preparation>
+    1. Ensure all changes are committed with proper message format
+    2. Push to appropriate branch (fork or direct)
+    3. Prepare comprehensive PR description
+    4. Get user approval before creating PR
+    5. Extract owner and repo from the provided GitHub URL
+  </preparation>
+  
+  <pr_title_format>
+    - Bug fixes: "fix: [description] (#[issue-number])"
+    - Features: "feat: [description] (#[issue-number])"
+    - Follow conventional commit format
+  </pr_title_format>
+  
+  <pr_description_template>
+    Must include:
+    - Link to issue (Fixes #[number])
+    - Detailed description of changes
+    - Testing performed
+    - Verification of acceptance criteria
+    - Checklist items
+    - 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:
+       <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/6_testing_guidelines.xml

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

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

@@ -0,0 +1,8 @@
+<communication_style>
+  - Be clear about what you're doing at each step
+  - Explain technical decisions and trade-offs
+  - Ask for clarification if requirements are ambiguous
+  - Provide regular progress updates for complex issues
+  - Summarize changes clearly for non-technical stakeholders
+  - Use issue numbers and links for reference
+</communication_style>

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

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

.roo/rules-issue-fixer/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

@@ -0,0 +1,391 @@
+<workflow>
+  <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>
+
+  <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>
+
+  <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>
+
+  <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="2">
+      <name>Detect Current Repository Information</name>
+      <instructions>
+        Verify we're in a Git repository and capture the GitHub remote for safe submission.
+
+        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>
+
+        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>
+
+        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>
+
+        If no origin remote exists, stop:
+        <attempt_completion>
+        <result>
+        No GitHub 'origin' remote found. Configure a GitHub remote and retry.
+        </result>
+        </attempt_completion>
+
+        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/3_best_practices.xml

@@ -0,0 +1,147 @@
+<best_practices>
+  <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 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

@@ -0,0 +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" 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>
+
+  <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-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-pr-fixer/1_workflow.xml

@@ -0,0 +1,75 @@
+<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. All GitHub operations are performed using the GitHub CLI.
+  </mode_overview>
+
+  <initialization_steps>
+    <step number="1">
+      <action>Understand the user's request</action>
+      <details>
+        Parse the user's input to identify the pull request URL or number. Extract the repository owner and name.
+      </details>
+    </step>
+    <step number="2">
+      <action>Gather PR context</action>
+      <tools>
+        <tool>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>
+
+  <main_workflow>
+    <phase name="analysis">
+      <description>Analyze the gathered information to identify the core problems.</description>
+      <steps>
+        <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>
+
+    <phase name="synthesis">
+      <description>Synthesize the findings and present them to the user.</description>
+      <steps>
+        <step>Present a summary of the issues found (reviews, failing tests, conflicts).</step>
+        <step>Use ask_followup_question to ask the user how they want to proceed with fixing the issues.</step>
+      </steps>
+    </phase>
+
+    <phase name="implementation">
+      <description>Execute the user's chosen course of action.</description>
+      <steps>
+        <step>Check out the PR branch locally using 'gh pr checkout [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 [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>
+
+  <completion_criteria>
+    <criterion>All actionable review comments have been addressed.</criterion>
+    <criterion>All tests are passing.</criterion>
+    <criterion>The PR is free of merge conflicts.</criterion>
+    <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

@@ -0,0 +1,75 @@
+<best_practices>
+  <general_principles>
+    <principle priority="high">
+      <name>Context is Key</name>
+      <description>Always gather full context before attempting a fix. This includes reading all relevant PR comments, checking CI/CD logs, and understanding the surrounding code.</description>
+      <rationale>Without full context, fixes may be incomplete or introduce new issues.</rationale>
+    </principle>
+    <principle priority="medium">
+      <name>Incremental Fixes</name>
+      <description>Address issues one at a time (e.g., fix tests first, then address comments). This makes the process more manageable and easier to validate.</description>
+      <rationale>Tackling all issues at once can be complex and error-prone.</rationale>
+    </principle>
+    <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>Delegate merge conflict resolution to the merge-resolver mode.</rule>
+      <template>
+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:
+
+```xml
+<new_task>
+<mode>merge-resolver</mode>
+<message>#[PR_NUMBER]</message>
+</new_task>
+```
+
+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
+
+This ensures consistent and intelligent conflict resolution across all PRs.
+      </template>
+    </convention>
+  </code_conventions>
+
+  <quality_checklist>
+    <category name="before_completion">
+      <item>Have all review comments been addressed?</item>
+      <item>Are all CI/CD checks passing?</item>
+      <item>Is the PR free of merge conflicts?</item>
+      <item>Have the changes been tested locally?</item>
+    </category>
+  </quality_checklist>
+</best_practices>

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

@@ -0,0 +1,136 @@
+<common_patterns>
+  <pattern name="checking_pr_status">
+    <usage>A set of commands to quickly assess the state of a Pull Request.</usage>
+    <template>
+      <command tool="gh">
+        gh pr status --json number,title,state,conflict,reviewDecision,headRefName,headRepositoryOwner
+      </command>
+      <command tool="gh">
+        gh pr checks
+      </command>
+      <command tool="gh">
+        gh pr view --comments
+      </command>
+    </template>
+  </pattern>
+  <pattern name="analyzing_failing_tests">
+    <usage>Commands to investigate why a specific test is failing.</usage>
+    <template>
+      <command tool="gh">
+        gh run list --workflow=<workflow_id> --branch=<branch_name> --json databaseId,name,status,conclusion
+      </command>
+      <command tool="gh">
+        gh run view --log-failed <run_id>
+      </command>
+    </template>
+  </pattern>
+  <pattern name="detecting_conflicts">
+    <usage>Commands to detect merge conflicts.</usage>
+    <template>
+      <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>Check out a pull request branch locally.</usage>
+    <template>
+      <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="determine_push_remote">
+    <usage>Determine the correct remote to push to (handles forks).</usage>
+    <template>
+      <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

@@ -0,0 +1,156 @@
+<tool_usage_guide>
+  <tool_priorities>
+    <priority level="1">
+      <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>
+    <priority level="2">
+      <tool>gh pr checks</tool>
+      <when>After getting comments, to check the technical status.</when>
+      <why>Quickly identifies if there are failing automated checks that need investigation.</why>
+   </priority>
+   <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>
+   </priority>
+ </tool_priorities>
+
+  <tool_specific_guidance>
+    <tool name="gh pr view">
+      <best_practices>
+        <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="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>
+    </tool>
+
+    <tool name="gh run view --log-failed">
+      <best_practices>
+        <practice>Use this command to get the exact error messages from failing tests.</practice>
+        <practice>Search the log for keywords like 'error', 'failed', or 'exception' to quickly find the root cause.</practice>
+        <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>
+    
+    <tool name="ask_followup_question">
+      <best_practices>
+        <practice>After analyzing all the problems (reviews, tests, conflicts), present a summary to the user.</practice>
+        <practice>Provide clear, actionable next steps as suggestions.</practice>
+        <practice>Example suggestions: "Address review comments first.", "Tackle the failing tests.", "Resolve merge conflicts."</practice>
+      </best_practices>
+    </tool>
+
+    <tool 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

@@ -0,0 +1,304 @@
+<complete_examples>
+  <example name="fix_failing_tests_and_address_comments">
+    <scenario>
+      A pull request has a failing CI check and a review comment asking for a change.
+    </scenario>
+    
+    <user_request>
+      Fix PR #4365 in RooCodeInc/Roo-Code.
+    </user_request>
+
+    <workflow>
+      <step number="1">
+        <description>Get PR details and review comments.</description>
+        <tool_use>
+<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>
+
+      <step number="2">
+        <description>Check CI status.</description>
+        <tool_use>
+<execute_command>
+<command>gh pr checks 4365 --repo RooCodeInc/Roo-Code</command>
+</execute_command>
+        </tool_use>
+        <analysis>Identify which check is failing.</analysis>
+      </step>
+
+      <step number="3">
+        <description>Get logs for the failing check.</description>
+        <tool_use>
+<execute_command>
+<command>gh run 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>
+      </step>
+      
+      <step number="4">
+        <description>Check out the pull request branch.</description>
+        <tool_use>
+          <execute_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>
+      </step>
+
+      <step number="5">
+        <description>Summarize findings and ask the user for the next action.</description>
+        <tool_use>
+<ask_followup_question>
+<question>I've checked out the branch. I've found a failing test related to 'XYZ' and a review comment asking to rename a variable. How should we proceed?</question>
+<follow_up>
+<suggest>First, apply the change requested in the review comment.</suggest>
+<suggest>Let's start by fixing the failing test.</suggest>
+<suggest>Show me the code for the failing test and the file with the requested change.</suggest>
+</follow_up>
+</ask_followup_question>
+        </tool_use>
+      </step>
+     <step number="6">
+       <description>After pushing the changes, monitor PR checks in real-time.</description>
+       <tool_use>
+         <execute_command>
+           <command>gh pr checks 4365 --repo RooCodeInc/Roo-Code --watch</command>
+         </execute_command>
+       </tool_use>
+       <analysis>Monitor checks continuously until all complete. The --watch flag provides real-time updates as check statuses change.</analysis>
+     </step>
+    </workflow>
+
+    <key_takeaways>
+      <takeaway>Always gather all information before proposing a solution.</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-translate/001-general-rules.md

@@ -1,6 +1,6 @@
 # 1. SUPPORTED LANGUAGES AND LOCATION
 
-- Localize all strings into the following locale files: ca, de, en, es, fr, hi, it, ja, ko, nl, pl, pt-BR, ru, tr, vi, zh-CN, zh-TW
+- 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:
     - Core Extension: src/i18n/locales/ (extension backend)
     - WebView UI: webview-ui/src/i18n/locales/ (user interface)
@@ -64,8 +64,10 @@
     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. Create appropriate translations for all other supported languages
-    5. Validate your changes with the missing translations script
+    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
 - Flag or comment if an English source string is incomplete ("please see this...") to avoid truncated or unclear translations
 - For UI elements, distinguish between:
     - Button labels: Use short imperative commands ("Save", "Cancel")

.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,16 +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 `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,182 +1,9 @@
 customModes:
-  - slug: test
-    name: 🧪 Test
-    roleDefinition: >-
-      You are Roo, a Jest testing specialist with deep expertise in:
-
-      - Writing and maintaining Jest test suites
-
-      - Test-driven development (TDD) practices
-
-      - Mocking and stubbing with Jest
-
-      - 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
-
-      - Jest configuration and setup
-
-
-      You ensure tests are:
-
-      - Well-structured and maintainable
-
-      - Following Jest best practices
-
-      - Properly typed with TypeScript
-
-      - Providing meaningful coverage
-
-      - Using appropriate mocking strategies
-    groups:
-      - read
-      - browser
-      - command
-      - - edit
-        - fileRegex: (__tests__/.*|__mocks__/.*|\.test\.(ts|tsx|js|jsx)$|/test/.*|jest\.config\.(js|ts)$)
-          description: Test files, mocks, and Jest 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
-  - 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 100 | jq '[.[] |
-      select(.mergedAt > "TIMESTAMP") | {number, title, author: .author.login,
-      url, mergedAt}]'`
-
-      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!)"
-
-
-      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.
+    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
@@ -184,3 +11,138 @@ customModes:
         - fileRegex: (.*\.(md|ts|tsx|js|jsx)$|.*\.json$)
           description: Source code, translation files, and documentation
     source: project
+  - slug: issue-fixer
+    name: 🔧 Issue Fixer
+    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
+       - Implementing fixes for bug reports with comprehensive testing
+       - Building new features based on detailed proposals
+       - Ensuring all acceptance criteria are met before completion
+       - Creating pull requests with proper documentation
+       - Using GitHub CLI for all GitHub operations
+
+      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 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.
+
+      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

.tool-versions

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

.vscode/extensions.json

@@ -6,6 +6,7 @@
 		"esbenp.prettier-vscode",
 		"csstools.postcss",
 		"bradlc.vscode-tailwindcss",
-		"connor4312.esbuild-problem-matchers"
+		"connor4312.esbuild-problem-matchers",
+		"yoavbls.pretty-ts-errors"
 	]
 }

.vscode/launch.json

@@ -10,9 +10,9 @@
 			"type": "extensionHost",
 			"request": "launch",
 			"runtimeExecutable": "${execPath}",
-			"args": ["--extensionDevelopmentPath=${workspaceFolder}"],
+			"args": ["--extensionDevelopmentPath=${workspaceFolder}/src"],
 			"sourceMaps": true,
-			"outFiles": ["${workspaceFolder}/dist/**/*.js"],
+			"outFiles": ["${workspaceFolder}/src/dist/**/*.js"],
 			"preLaunchTask": "${defaultBuildTask}",
 			"env": {
 				"NODE_ENV": "development",

.vscode/settings.json

@@ -9,5 +9,6 @@
 		"dist": true // set this to false to include "dist" folder in search results
 	},
 	// Turn off tsc task auto detection since we have the necessary tasks as npm scripts
-	"typescript.tsc.autoDetect": "off"
+	"typescript.tsc.autoDetect": "off",
+	"vitest.disableWorkspaceWarning": true
 }

.vscode/tasks.json

@@ -5,7 +5,7 @@
 	"tasks": [
 		{
 			"label": "watch",
-			"dependsOn": ["npm: dev", "npm: watch:tsc", "npm: watch:esbuild"],
+			"dependsOn": ["watch:webview", "watch:bundle", "watch:tsc"],
 			"presentation": {
 				"reveal": "never"
 			},
@@ -15,9 +15,9 @@
 			}
 		},
 		{
-			"label": "npm: dev",
-			"type": "npm",
-			"script": "dev",
+			"label": "watch:webview",
+			"type": "shell",
+			"command": "pnpm --filter @roo-code/vscode-webview dev",
 			"group": "build",
 			"problemMatcher": {
 				"owner": "vite",
@@ -32,14 +32,14 @@
 			},
 			"isBackground": true,
 			"presentation": {
-				"group": "webview-ui",
+				"group": "watch",
 				"reveal": "always"
 			}
 		},
 		{
-			"label": "npm: watch:esbuild",
-			"type": "npm",
-			"script": "watch:esbuild",
+			"label": "watch:bundle",
+			"type": "shell",
+			"command": "npx turbo watch:bundle",
 			"group": "build",
 			"problemMatcher": {
 				"owner": "esbuild",
@@ -48,8 +48,8 @@
 				},
 				"background": {
 					"activeOnStart": true,
-					"beginsPattern": "\\[watch\\] build started",
-					"endsPattern": "\\[watch\\] build finished"
+					"beginsPattern": "esbuild-problem-matcher#onStart",
+					"endsPattern": "esbuild-problem-matcher#onEnd"
 				}
 			},
 			"isBackground": true,
@@ -59,9 +59,9 @@
 			}
 		},
 		{
-			"label": "npm: watch:tsc",
-			"type": "npm",
-			"script": "watch:tsc",
+			"label": "watch:tsc",
+			"type": "shell",
+			"command": "npx turbo watch:tsc",
 			"group": "build",
 			"problemMatcher": "$tsc-watch",
 			"isBackground": true,

.vscodeignore

@@ -1,74 +0,0 @@
-# Default
-.changeset/**
-.github/**
-.husky/**
-.vscode/**
-coverage/**
-node_modules/**
-src/**
-scripts/**
-.gitignore
-esbuild.js
-jest.*
-**/tsconfig.json
-**/.eslintrc.json
-.prettierignore
-**/*.map
-**/*.ts
-**/.gitignore
-
-# Custom
-.env.sample
-.git-blame-ignore-revs
-.gitconfig
-.gitattributes
-.tool-versions
-.vite-port
-.nvmrc
-.clinerules*
-.roomodes
-.rooignore
-.roo/**
-benchmark/**
-docs/**
-e2e/**
-evals/**
-locales/**
-out/**
-ellipsis.yaml
-knip.json
-
-# Ignore all webview-ui files except the build directory.
-# https://github.com/microsoft/vscode-webview-ui-toolkit-samples/blob/main/frameworks/hello-world-react-cra/.vscodeignore
-webview-ui/src/**
-webview-ui/public/**
-webview-ui/scripts/**
-webview-ui/index.html
-webview-ui/README.md
-webview-ui/package.json
-webview-ui/package-lock.json
-webview-ui/node_modules/**
-
-# Include codicons
-!node_modules/@vscode/codicons/dist/codicon.css
-!node_modules/@vscode/codicons/dist/codicon.ttf
-
-# Include material icons
-!node_modules/vscode-material-icons/generated/**
-
-# Include default themes JSON files used in getTheme
-!src/integrations/theme/default-themes/**
-
-# Ignore doc assets
-assets/docs/**
-
-# Include icons and images
-!assets/icons/**
-!assets/images/**
-
-# Include .env file for telemetry
-!.env
-
-# Ignore IntelliJ and Qodo plugin folders
-.idea/**
-.qodo/**

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,81 +0,0 @@
-**English** • [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) • [Italiano](locales/it/CODE_OF_CONDUCT.md) • [Nederlands](locales/nl/CODE_OF_CONDUCT.md) • [Русский](locales/ru/CODE_OF_CONDUCT.md)
-
-[日本語](locales/ja/CODE_OF_CONDUCT.md) • [한국어](locales/ko/CODE_OF_CONDUCT.md) • [Polski](locales/pl/CODE_OF_CONDUCT.md) • [Português (BR)](locales/pt-BR/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)
-
-# 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,129 +0,0 @@
-**English** • [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) • [Italiano](locales/it/CONTRIBUTING.md) • [Nederlands](locales/nl/CONTRIBUTING.md) • [Русский](locales/ru/CONTRIBUTING.md)
-
-[日本語](locales/ja/CONTRIBUTING.md) • [한국어](locales/ko/CONTRIBUTING.md) • [Polski](locales/pl/CONTRIBUTING.md) • [Português (BR)](locales/pt-BR/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)
-
-# 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:**
-
-```
-npm run install:all
-```
-
-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,27 +1,27 @@
 # Roo Code Privacy Policy
 
-**Last Updated: March 7th, 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.
+- **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>
 
-English • [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) • [Italiano](locales/it/README.md) • [Nederlands](locales/nl/README.md) • [Русский](locales/ru/README.md)
+# Roo Code
 
-</sub>
-<sub>
+> Your AI-Powered Dev Team, Right in Your Editor
 
-[日本語](locales/ja/README.md) • [한국어](locales/ko/README.md) • [Polski](locales/pl/README.md) • [Português (BR)](locales/pt-BR/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/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.18 Released
+## What Can Roo Code Do For YOU?
 
-Roo Code 3.18 brings powerful 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
 
-- **Gemini 2.5 Flash Preview Models** - Access the latest Gemini Flash models for faster and more efficient responses.
-- **Intelligent Context Condensing Button** - New button in task header lets you intelligently condense content with visual feedback.
-- **YAML Support for Mode Definitions** - Create and customize modes more easily with YAML support.
+## 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
-npm run install:all
-```
-
-3. **Start the webview (Vite/React app with HMR)**:
-
-```sh
-npm run dev
-```
-
-4. **Debug**:
-   Press `F5` (or **Run** → **Start Debugging**) in VSCode to open a new session with Roo Code loaded.
-
-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
-npm run build
-```
-
-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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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> |               <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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/ksze"><img src="https://avatars.githubusercontent.com/u/381556?v=4" width="100" height="100" alt="ksze"/><br /><sub><b>ksze</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)

SECURITY.md

@@ -0,0 +1,17 @@
+# Security Policy
+
+## Supported Versions
+
+We actively patch only the most recent minor release of Roo Code. Older versions receive fixes at our discretion.
+
+## Reporting a Vulnerability
+
+Email security@roocode.com with:
+
+- A short summary of the issue
+- Steps to reproduce or a proof of concept
+- Any logs, stack traces, or screenshots that might help us understand the problem
+
+We acknowledge reports within 48 hours and aim to release a fix or mitigation within 30 days. While we work on a resolution, please keep the details private.
+
+Thank you for helping us keep Roo Code users safe.

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!