.changeset/changelog-config.js

@@ -1,9 +1,11 @@
+// Half-works to simplify the format but needs 'overwrite_changeset_changelog.py' in GHA to finish formatting
+
 const getReleaseLine = async (changeset) => {
-	const lines = changeset.summary
+	const [firstLine] = changeset.summary
 		.split("\n")
 		.map((l) => l.trim())
 		.filter(Boolean)
-	return lines.map((line) => (line.startsWith("- ") ? line : `- ${line}`)).join("\n")
+	return `- ${firstLine}`
 }
 
 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": [["roo-cline"]],
+	"fixed": [],
 	"linked": [],
 	"access": "restricted",
 	"baseBranch": "main",
 	"updateInternalDependencies": "patch",
-	"ignore": ["@roo-code/cli"]
+	"ignore": []
 }

.changeset/v3.54.0.md

@@ -1,15 +0,0 @@
----
-"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)

.clinerules

@@ -0,0 +1,15 @@
+# Code Quality Rules
+
+1. Test Coverage:
+   - Before attempting completion, always make sure that any code changes have test coverage
+   - Ensure all tests pass before submitting changes
+
+2. Lint Rules:
+   - Never disable any lint rules without explicit user approval
+   - If a lint rule needs to be disabled, ask the user first and explain why
+   - Prefer fixing the underlying issue over disabling the lint rule
+   - Document any approved lint rule disabling with a comment explaining the reason
+
+# Adding a New Setting
+
+To add a new setting that persists its state, follow the steps in cline_docs/settings.md

.dockerignore

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

@@ -0,0 +1,24 @@
+{
+	"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",
+		"eqeqeq": "warn",
+		"no-throw-literal": "warn",
+		"semi": "off",
+		"react-hooks/exhaustive-deps": "off"
+	},
+	"ignorePatterns": ["out", "dist", "**/*.d.ts"]
+}

.git-blame-ignore-revs

@@ -1,3 +1,3 @@
-# Ran Prettier on all files - https://github.com/RooCodeInc/Roo-Code/pull/404
+# Ran Prettier on all files - https://github.com/RooVetGit/Roo-Code/pull/404
 60a0a824b96a0b326af4d8871b6903f4ddcfe114
 579bdd9dbf6d2d569e5e7adb5ff6292b1e42ea34

.gitattributes

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

.github/CODEOWNERS

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

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -1,119 +1,68 @@
 name: Bug Report
-description: Report a broken behavior in plain language with a minimal reproduction
+description: File a bug report
 labels: ["bug"]
-title: "[BUG] "
 body:
-  - type: markdown
-    attributes:
-      value: |
-        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
-    attributes:
-      label: App Version
-      description: What version of Roo Code are you using? (e.g., v3.3.1)
-    validations:
-      required: true
-
-  - type: dropdown
-    id: provider
-    attributes:
-      label: API Provider (optional)
-      options:
-        - Anthropic
-        - Amazon Bedrock
-        - Chutes AI
-        - DeepSeek
-        - Featherless AI
-        - Fireworks AI
-        - Google Gemini
-        - Google Vertex AI
-        - Groq
-        - LiteLLM
-        - LM Studio
-        - Mistral AI
-        - Ollama
-        - OpenAI
-        - OpenAI Compatible
-        - OpenRouter
-        - Requesty
-        - SambaNova
-        - Unbound
-        - VS Code Language Model API
-        - xAI (Grok)
-        - Not Applicable / Other
-
-  - type: input
-    id: model
-    attributes:
-      label: Model Used (optional)
-      description: Exact model name (e.g., Claude 3.7 Sonnet). Use N/A if irrelevant.
-
-  - type: textarea
-    id: roo-code-tasks
-    attributes:
-      label: Roo Code Task Links (optional)
-      description: If you have any publicly shared Roo Code task links that demonstrate the issue, paste them here.
-      placeholder: Paste your Roo Code share links here, one per line
-
-  - type: textarea
-    id: logs
-    attributes:
-      label: Relevant logs or errors (optional)
-      description: Paste relevant output or errors. Use triple backticks (```) for formatting.
-      render: shell
+    - type: input
+      id: version
+      attributes:
+          label: Which version of the app are you using?
+          description: Please specify the app version you're using (e.g. v3.3.1)
+      validations:
+          required: true
+    - type: dropdown
+      id: provider
+      attributes:
+          label: Which API Provider are you using?
+          multiple: false
+          options:
+              - OpenRouter
+              - Anthropic
+              - Google Gemini
+              - DeepSeek
+              - OpenAI
+              - OpenAI Compatible
+              - GCP Vertex AI
+              - AWS Bedrock
+              - Glama
+              - VS Code LM API
+              - LM Studio
+              - Ollama
+      validations:
+          required: true
+    - type: input
+      id: model
+      attributes:
+          label: Which Model are you using?
+          description: Please specify the model you're using (e.g. Claude 3.5 Sonnet)
+      validations:
+          required: true
+    - type: textarea
+      id: what-happened
+      attributes:
+          label: What happened?
+          description: Also tell us, what did you expect to happen?
+          placeholder: Tell us what you see!
+      validations:
+          required: true
+    - type: textarea
+      id: steps
+      attributes:
+          label: Steps to reproduce
+          description: How do you trigger this bug? Please walk us through it step by step.
+          value: |
+              1.
+              2.
+              3.
+      validations:
+          required: true
+    - type: textarea
+      id: logs
+      attributes:
+          label: Relevant API REQUEST output
+          description: Please copy and paste any relevant output. This will be automatically formatted into code, so no need for backticks.
+          render: shell
+    - type: textarea
+      id: additional-context
+      attributes:
+          label: Additional context
+          description: Add any other context about the problem here, such as screenshots or related issues.

.github/ISSUE_TEMPLATE/config.yml

@@ -1,5 +1,8 @@
 blank_issues_enabled: false
 contact_links:
+    - name: Feature Request
+      url: https://github.com/RooVetGit/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,91 +0,0 @@
-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 helping improve Roo Code!
-        Please focus on the problem and the desired behavior in plain language.
-
-  - type: textarea
-    id: problem
-    attributes:
-      label: Problem (one or two sentences)
-      description: What problem are users facing?
-      placeholder: e.g., "Users often click Copy Run by mistake and duplicate runs unintentionally."
-    validations:
-      required: true
-
-  - type: textarea
-    id: context
-    attributes:
-      label: Context (who is affected and when)
-      description: Who encounters this and in what situation?
-      placeholder: e.g., "Happens when browsing the Runs list; most visible for new users."
-    validations:
-      required: true
-
-  - type: textarea
-    id: desired
-    attributes:
-      label: Desired behavior (conceptual, not technical)
-      description: Describe what should happen in simple terms.
-      placeholder: e.g., "Ask for confirmation before copying a run."
-    validations:
-      required: true
-
-  - type: textarea
-    id: constraints
-    attributes:
-      label: Constraints / preferences (optional)
-      description: Any considerations like performance, accessibility, or UX expectations.
-      placeholder: e.g., "Keep it quick and unobtrusive; keyboard accessible."
-
-  - type: checkboxes
-    id: checklist
-    attributes:
-      label: Request checklist
-      options:
-        - label: I've searched existing Issues and Discussions for duplicates
-          required: true
-        - label: This describes a specific problem with clear context and impact
-          required: true
-
-  - type: textarea
-    id: roo-code-tasks
-    attributes:
-      label: Roo Code Task Links (optional)
-      description: If you explored this with Roo Code, share public task links for context.
-      placeholder: Paste your Roo Code share links here, one per line
-
-  - type: markdown
-    attributes:
-      value: |
-        ---
-        Optional: 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

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

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

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

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

@@ -0,0 +1,37 @@
+<!-- **Note:** Consider creating PRs as a DRAFT. For early feedback and self-review. -->
+
+## Description
+
+## Type of change
+
+<!-- Please ignore options that are not relevant -->
+
+- [ ] Bug fix (non-breaking change which fixes an issue)
+- [ ] New feature
+- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
+- [ ] This change requires a documentation update
+
+## How Has This Been Tested?
+
+<!-- Please describe the tests that you ran to verify your changes -->
+
+## Checklist:
+
+<!-- Go over all the following points, and put an `x` in all the boxes that apply -->
+
+- [ ] My code follows the patterns of this project
+- [ ] I have performed a self-review of my own code
+- [ ] I have commented my code, particularly in hard-to-understand areas
+- [ ] I have made corresponding changes to the documentation
+
+## Additional context
+
+<!-- Add any other context or screenshots about the pull request here -->
+
+## Related Issues
+
+<!-- List any related issues here. Use the GitHub issue linking syntax: #issue-number -->
+
+## Reviewers
+
+<!-- @mention specific team members or individuals who should review this PR -->

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

@@ -0,0 +1,123 @@
+"""
+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

@@ -0,0 +1,52 @@
+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 RooVetGit/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

@@ -0,0 +1,62 @@
+"""
+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

@@ -0,0 +1,64 @@
+"""
+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

@@ -0,0 +1,125 @@
+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/changeset-release.yml

@@ -29,8 +29,15 @@ jobs:
         with:
           fetch-depth: 0
           ref: ${{ env.GIT_REF }}
-      - name: Setup Node.js and pnpm
-        uses: ./.github/actions/setup-node-pnpm
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: 20
+          cache: 'npm'
+            
+      - name: Install Dependencies
+        run: npm run install:all
 
       # Check if there are any new changesets to process
       - name: Check for changesets
@@ -48,9 +55,9 @@ jobs:
         with:
           commit: "changeset version bump"
           title: "Changeset version bump"
-          version: pnpm changeset:version # This performs the changeset version bump
+          version: npm run version-packages # This performs the changeset version bump
         env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          GITHUB_TOKEN: ${{ secrets.CROSS_REPO_ACCESS_TOKEN }}
 
   # Job 2: Process version bump PR created by R00-B0T
   changeset-pr-edit-approve:
@@ -84,10 +91,29 @@ jobs:
       - name: Checkout Repo
         uses: actions/checkout@v4
         with:
-          token: ${{ secrets.GITHUB_TOKEN }}
+          token: ${{ secrets.CROSS_REPO_ACCESS_TOKEN }}
           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') }}
@@ -129,4 +155,4 @@ jobs:
         if: false # Needs enablePullRequestAutoMerge in repo settings to work contains(github.event.pull_request.labels.*.name, 'changelog-ready')
         run: gh pr merge --auto --merge ${{ github.event.pull_request.number }}
         env:
-          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          GH_TOKEN: ${{ secrets.CROSS_REPO_ACCESS_TOKEN }}

.github/workflows/cli-release.yml

@@ -1,394 +0,0 @@
-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,60 +1,68 @@
 name: Code QA Roo Code
 
 on:
-    workflow_dispatch:
-    push:
-        branches: [main]
-    pull_request:
-        types: [opened, reopened, ready_for_review, synchronize]
-        branches: [main]
+  workflow_dispatch:
+  push:
+    branches: [main]
+  pull_request:
+    types: [opened, reopened, ready_for_review, synchronize]
+    branches: [main]
 
 jobs:
-    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
+  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: '18'
+          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
 
-    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
+  unit-test:
+    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 unit tests
+        run: npm test
 
-    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
-
-    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
+  integration-test:
+    strategy:
+      matrix:
+        os: [ubuntu-latest] # macos-latest, windows-latest
+    runs-on: ${{ matrix.os }}
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: '18'
+          cache: 'npm'
+      - name: Create env.integration file
+        run: echo "OPENROUTER_API_KEY=${{ secrets.OPENROUTER_API_KEY }}" > .env.integration
+      - name: Check env.integration file
+        run: cat .env.integration
+      - name: Install dependencies
+        run: npm run install:all
+      - run: xvfb-run -a npm run test:integration
+        if: runner.os == 'Linux'
+      - run: npm run test:integration
+        if: runner.os != 'Linux'

.github/workflows/codeql.yml

@@ -1,4 +1,15 @@
-name: CodeQL Advanced
+# 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"
 
 on:
   push:

.github/workflows/docs-pages.yml

@@ -1,55 +0,0 @@
-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,5 +1,4 @@
 name: Publish Extension
-
 on:
   pull_request:
     types: [closed]
@@ -11,82 +10,35 @@ env:
 jobs:
   publish-extension:
     runs-on: ubuntu-latest
-    permissions:
-      contents: write # Required for pushing tags.
     if: >
         ( github.event_name == 'pull_request' &&
         github.event.pull_request.base.ref == 'main' &&
         contains(github.event.pull_request.title, 'Changeset version bump') ) ||
         github.event_name == 'workflow_dispatch'
     steps:
-      - name: Checkout code
-        uses: actions/checkout@v4
+      - uses: actions/checkout@v4
         with:
           ref: ${{ env.GIT_REF }}
-      - 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: Create .env file
-        run: echo "POSTHOG_API_KEY=${{ secrets.POSTHOG_API_KEY }}" >> .env
-      - name: Package Extension
-        run: |
-          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
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 18
+      - run: |
+          git config user.name github-actions
+          git config user.email github-actions@github.com
+      - name: Install Dependencies
         run: |
-          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}" --no-verify
-          echo "Successfully created and pushed git tag v${current_package_version}"
-      - name: Publish Extension
+          npm install -g vsce ovsx
+          npm install
+          cd webview-ui
+          npm install
+          cd ..
+      - name: Package and Publish Extension
         env:
           VSCE_PAT: ${{ secrets.VSCE_PAT }}
           OVSX_PAT: ${{ secrets.OVSX_PAT }}
         run: |
-          current_package_version=$(node -p "require('./src/package.json').version")
-          pnpm --filter roo-cline publish:marketplace
+          current_package_version=$(node -p "require('./package.json').version")
+          npm run 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('./src/package.json').version")
 
-          # Extract changelog for current version
-          echo "Extracting changelog for version ${current_package_version}"
-          changelog_content=$(sed -n "/## \\[${current_package_version}\\]/,/## \\[/p" CHANGELOG.md | sed '$d')
-
-          # If changelog extraction failed, use a default message
-          if [ -z "$changelog_content" ]; then
-            echo "Warning: No changelog section found for version ${current_package_version}"
-            changelog_content="Release v${current_package_version}"
-          else
-            echo "Found changelog section for version ${current_package_version}"
-          fi
-
-          # Create release with changelog content
-          gh release create "v${current_package_version}" \
-            --title "Release v${current_package_version}" \
-            --notes "$changelog_content" \
-            --target ${{ env.GIT_REF }} \
-            bin/roo-cline-${current_package_version}.vsix
-          echo "Successfully created GitHub Release v${current_package_version}"

.github/workflows/nightly-publish.yml

@@ -1,52 +0,0 @@
-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/pages.yml

@@ -0,0 +1,44 @@
+name: Deploy Jekyll site to Pages
+
+on:
+  push:
+    branches: ["main"]
+  workflow_dispatch:
+
+permissions:
+  contents: read
+  pages: write
+  id-token: write
+
+concurrency:
+  group: "pages"
+  cancel-in-progress: false
+
+jobs:
+  # Build job
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+      - name: Setup Pages
+        uses: actions/configure-pages@v5
+      - name: Build with Jekyll
+        uses: actions/jekyll-build-pages@v1
+        with:
+          source: ./docs/
+          destination: ./_site
+      - name: Upload artifact
+        uses: actions/upload-pages-artifact@v3
+
+  # Deployment job
+  deploy:
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    runs-on: ubuntu-latest
+    needs: build
+    steps:
+      - name: Deploy to GitHub Pages
+        id: deployment
+        uses: actions/deploy-pages@v4

.gitignore

@@ -1,24 +1,17 @@
-.pnpm-store
 dist
 out
-out-*
+out-integration
 node_modules
-package-lock.json
 coverage/
-mock/
 
 .DS_Store
 
-# IDEs
-.idea
-
 # Builds
 bin/
-*.vsix
+roo-cline-*.vsix
 
 # Local prompts and rules
 /local-prompts
-AGENTS.local.md
 
 # Test environment
 .test_env
@@ -28,30 +21,4 @@ AGENTS.local.md
 docs/_site/
 
 # Dotenv
-.env
-.env.*
-!.env.*.sample
-
-# 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*
+.env.integration

.husky/pre-commit

@@ -5,23 +5,8 @@ if [ "$branch" = "main" ]; then
   exit 1
 fi
 
-# 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
+npx lint-staged
 
-# 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
-
-$npx_cmd lint-staged
-$pnpm_cmd lint
+npm run compile
+npm run lint
+npm run check-types

.husky/pre-push

@@ -5,38 +5,13 @@ if [ "$branch" = "main" ]; then
   exit 1
 fi
 
-# 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
+npm 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.
+# 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 'pnpm changeset' to create a changeset if applicable."
+  echo "Changes detected. Please run 'npm run changeset' to create a changeset if applicable."
   echo "-------------------------------------------------------------------------------------"
-fi
+fi

.npmrc

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

.nvmrc

@@ -1 +1 @@
-v20.19.2
+lts/*

.prettierignore

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

.prettierrc.json

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

.roo/commands/cli-release.md

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

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

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

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

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

@@ -1,15 +0,0 @@
-# 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

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

.roo/rules-code/use-safeWriteJson.md

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

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

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

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

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

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

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

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

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

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

@@ -1,245 +0,0 @@
-<github_cli_usage>
-  <overview>
-    This mode uses the GitHub CLI (gh) for all GitHub operations.
-    The mode assumes the user has gh installed and authenticated. If authentication errors occur,
-    the mode will prompt the user to authenticate.
-    
-    Users must provide full GitHub issue URLs (e.g., https://github.com/owner/repo/issues/123)
-    so the mode can extract the repository information dynamically.
-  </overview>
-  
-  <url_parsing>
-    <pattern>https://github.com/[owner]/[repo]/issues/[number]</pattern>
-    <extraction>
-      - Owner: The organization or username
-      - Repo: The repository name
-      - Number: The issue number
-    </extraction>
-  </url_parsing>
-
-  <authentication_handling>
-    <approach>Assume authenticated, handle errors gracefully</approach>
-    <when>Only check authentication if a gh command fails with auth error</when>
-    <error_patterns>
-      - "gh: Not authenticated"
-      - "HTTP 401"
-      - "HTTP 403: Resource not accessible"
-    </error_patterns>
-  </authentication_handling>
-
-  <primary_commands>
-    <command name="gh_issue_view">
-      <purpose>Retrieve the issue details at the start 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@@ -1,304 +0,0 @@
-<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,106 +0,0 @@
-# 1. SUPPORTED LANGUAGES AND LOCATION
-
-- 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)
-
-# 2. VOICE, STYLE AND TONE
-
-- 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
-- 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
-
-# 3. 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
-
-# 4. 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> example:
-
-`"changeSettings": "You can always change this at the bottom of the <settingsLink>settings</settingsLink>",`
-
-```
-  <Trans
-    i18nKey="welcome:telemetry.changeSettings"
-    components={{
-      settingsLink: <VSCodeLink href="#" onClick={handleOpenSettings} />
-    }}
-  />
-```
-
-# 5. 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
-
-# 6. WORKFLOW AND APPROACH
-
-- First add or modify English strings, then ask for confirmation before translating to all other languages
-- 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
-- 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")
-    - Tooltip text: Can be slightly more descriptive
-- Preserve the original perspective: If text is a user command directed at the software, ensure the translation maintains this direction, avoiding language that makes it sound like an instruction from the system to the user
-
-# 7. 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
-
-# 8. QUALITY ASSURANCE
-
-- Maintain consistent terminology across all translations
-- Respect the JSON structure of translation files
-- Watch for placeholders and preserve them in translations
-- Be mindful of text length in UI elements when translating to languages that might require more characters
-- Use context-aware translations when the same string has different meanings
-- Always validate your translation work by running the missing translations script:
-    ```
-    node scripts/find-missing-translations.js
-    ```
-- Address any missing translations identified by the script to ensure complete coverage across all locales
-
-# 9. 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)

.roo/rules-translate/instructions-de.md

@@ -1,14 +0,0 @@
-# German (de) Translation Guidelines
-
-**Key Rule:** Always use informal speech ("du" form) in all German translations without exception.
-
-## Quick Reference
-
-| Category    | Formal (Avoid)            | Informal (Use)      | Example           |
-| ----------- | ------------------------- | ------------------- | ----------------- |
-| Pronouns    | Sie                       | du                  | you               |
-| Possessives | Ihr/Ihre/Ihrem            | dein/deine/deinem   | your              |
-| Verbs       | können Sie, müssen Sie    | kannst du, musst du | you can, you must |
-| Imperatives | Geben Sie ein, Wählen Sie | Gib ein, Wähle      | Enter, Choose     |
-
-**Technical terms** like "API", "token", "prompt" should not be translated.

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

@@ -1,277 +0,0 @@
-# Simplified Chinese (zh-CN) Translation Guidelines
-
-## Key Terminology
-
-| English Term          | Preferred (zh-CN) | Avoid        | Context/Notes |
-| --------------------- | ----------------- | ------------ | ------------- |
-| API Cost              | API 费用          | API 成本     | 财务相关术语  |
-| Tokens                | Token             | Tokens/令牌  | 保留抽象术语  |
-| Token Usage           | Token 使用量      | Token 用量   | 技术计量单位  |
-| Cache                 | 缓存              | 高速缓存     | 简洁优先      |
-| Context               | 上下文            |              | 保留抽象术语  |
-| Context Menu          | 右键菜单          | 上下文菜单   | 技术术语准确  |
-| Context Window        | 上下文窗口        |              | 技术术语准确  |
-| Proceed While Running | 强制继续          | 运行时继续   | 操作命令      |
-| Enhance Prompt        | 增强提示词        | 优化提示     | AI相关功能    |
-| Auto-approve          | 自动批准          | 始终批准     | 权限相关术语  |
-| Checkpoint            | 存档点            | 检查点/快照  | 技术概念统一  |
-| MCP Server            | MCP 服务          | MCP 服务器   | 技术组件      |
-| Network Timeout       | 请求超时          | 网络超时     | 更准确描述    |
-| Terminal              | 终端              | 命令行       | 技术术语统一  |
-| diff                  | 差异更新          | 差分/补丁    | 代码变更      |
-| prompt caching        | 提示词缓存        | 提示缓存     | AI功能        |
-| computer use          | 计算机交互        | 计算机使用   | 技术能力      |
-| rate limit            | API 请求频率限制  | 速率限制     | API控制       |
-| Browser Session       | 浏览器会话        | 浏览器进程   | 技术概念      |
-| Run Command           | 运行命令          | 执行命令     | 操作动词      |
-| power steering mode   | 增强导向模式      | 动力转向模式 | 避免直译      |
-| Boomerang Tasks       | 任务拆分          | 回旋镖任务   | 避免直译      |
-
-## Formatting Rules
-
-1. **中英文混排**
-
-    - 添加空格：在中文和英文/数字之间添加空格，如"API 费用"（不是"API费用"）
-    - 单位格式：时间单位统一为"15秒"、"1分钟"（不是"15 seconds"、"1 minute"）
-    - 数字范围："已使用: {{used}} / {{total}}"
-    - 技术符号保留原样："{{amount}} tokens"→"{{amount}}"
-
-2. **标点符号**
-
-    - 使用中文全角标点
-    - 列表项使用中文顿号："创建、编辑文件"
-
-3. **UI文本优化**
-
-    - 按钮文本：使用简洁动词，如"展开"优于"查看更多"
-    - 操作说明：使用步骤式说明（1. 2. 3.）替代长段落
-    - 错误提示：使用"确认删除？此操作不可逆"替代"Are you sure...?"
-    - 操作说明要简洁："Shift+拖拽文件"优于长描述
-    - 按钮文本控制在2-4个汉字："展开"优于"查看更多"
-
-4. **技术描述**
-
-    - 保留英文缩写：如"MCP"不翻译
-    - 统一术语：整个系统中相同概念使用相同译法
-    - 长句拆分为短句
-    - 被动语态转为主动语态
-    - 功能名称统一："计算机交互"优于"计算机使用"
-    - 参数说明："差异更新"优于"差分/补丁"
-
-5. **变量占位符**
-    - 保持原格式：`{{variable}}`
-    - 中文说明放在变量外："Token 使用量: {{used}}"
-
-## UI Element Translation Standards
-
-1. **按钮(Buttons)**
-
-    - 确认类：确定/取消/应用/保存
-    - 操作类：添加/删除/编辑/导出
-    - 状态类：启用/禁用/展开/收起
-    - 长度限制：2-4个汉字
-
-2. **菜单(Menus)**
-
-    - 主菜单：文件/编辑/视图/帮助
-    - 子菜单：使用">"连接，如"文件>打开"
-    - 快捷键：保留英文，如"Ctrl+S"
-
-3. **标签(Labels)**
-
-    - 设置项：描述功能，如"自动保存间隔"
-    - 状态提示：简洁明确，如"正在处理..."
-    - 单位说明：放在括号内，如"超时时间(秒)"
-
-4. **工具提示(Tooltips)**
-
-    - 功能说明：简洁描述，如"复制选中内容"
-    - 操作指引：步骤明确，如"双击编辑单元格"
-    - 长度限制：不超过50个汉字
-
-5. **对话框(Dialogs)**
-    - 标题：说明对话框用途
-    - 正文：分段落说明
-    - 按钮：使用动词，如"确认删除"
-
-## Contextual Translation Principles
-
-1. **根据UI位置调整**
-
-    - 按钮文本：简洁动词 (如"展开", "收起")
-    - 设置项：描述性 (如"自动批准写入操作")
-    - 帮助文本：完整说明 (如"开启后自动创建任务存档点，方便回溯修改")
-
-2. **技术文档风格**
-
-    - 使用主动语态：如"自动创建和编辑文件"
-    - 避免口语化表达
-    - 复杂功能使用分点说明
-    - 说明操作结果：如"无需二次确认"
-    - 参数说明清晰：如"延迟一段时间再自动批准写入"
-
-3. **品牌/产品名称**
-
-    - 保留英文品牌名
-    - 技术术语保持一致性
-    - 保留英文专有名词：如"Amazon Bedrock ARN"
-
-4. **用户操作**
-    - 操作动词统一：
-        - "Click"→"点击"
-        - "Type"→"输入"
-        - "Scroll"→"滚动"
-    - 按钮状态：
-        - "Enabled"→"已启用"
-        - "Disabled"→"已禁用"
-
-## Technical Documentation Guidelines
-
-1. **技术术语**
-
-    - 统一使用"Token"而非"令牌"
-    - 保留英文专有名词：如"Model Context Protocol"
-    - 功能名称统一：如"计算机功能调用"优于"计算机使用"
-
-2. **API文档**
-
-    - 端点(Endpoint)：保留原始路径
-    - 参数说明：表格形式展示
-    - 示例：保留代码格式
-    - 参数标签：
-        - 单位明确：如"最大输出 Token 数"
-        - 范围说明完整：如"模型可以处理的总 Token 数"
-
-3. **代码相关翻译**
-
-    - 代码注释：
-        - 保留技术术语：如"// Initialize MCP client"
-        - 简短说明：如"检查文件是否存在"
-    - 错误信息：
-        - 包含错误代码：如"Error 404: 文件未找到"
-        - 提供解决方案：如"请检查文件权限"
-    - 命令行：
-        - 保留原生命令：如"git commit -m 'message'"
-        - 参数说明：如"-v: 显示详细输出"
-
-4. **配置指南**
-    - 设置项命名：如"Enable prompt caching"→"启用提示词缓存"
-    - 价格描述：
-        - 单位统一：如"每百万 Token 的成本"
-        - 说明影响：如"这会影响生成内容和补全的成本"
-    - 操作说明：
-        - 使用编号步骤：如"1. 注册Google Cloud账号"
-        - 步骤动词一致：如"安装配置Google Cloud CLI工具"
-
-## Common Patterns
-
-```markdown
-<<<<<<< BEFORE
-"dragFiles": "按住shift拖动文件"
-=======
-"dragFiles": "Shift+拖拽文件"
-
-> > > > > > > AFTER
-
-<<<<<<< BEFORE
-"description": "启用后，Roo 将能够与 MCP 服务器交互以获取高级功能。"
-=======
-"description": "启用后 Roo 可与 MCP 服务交互获取高级功能。"
-
-> > > > > > > AFTER
-
-<<<<<<< BEFORE
-"cannotUndo": "此操作无法撤消。"
-=======
-"cannotUndo": "此操作不可逆。"
-
-> > > > > > > AFTER
-
-<<<<<<< BEFORE
-"hold shift to drag in files" → "按住shift拖动文件"
-=======
-"hold shift to drag in files" → "Shift+拖拽文件"
-
-> > > > > > > AFTER
-
-<<<<<<< BEFORE
-"Double click to edit" → "双击进行编辑"
-=======
-"Double click to edit" → "双击编辑"
-
-> > > > > > > AFTER
-```
-
-## Common Pitfalls
-
-1. 避免过度直译导致生硬
-
-    - ✗ "Do more with Boomerang Tasks" → "使用回旋镖任务完成更多工作"
-    - ✓ "Do more with Boomerang Tasks" → "允许任务拆分"
-
-2. 保持功能描述准确
-
-    - ✗ "Enhance prompt with additional context" → "使用附加上下文增强提示"
-    - ✓ "Enhance prompt with additional context" → "增强提示词"
-
-3. 操作指引清晰
-
-    - ✗ "hold shift to drag in files" → "按住shift拖动文件"
-    - ✓ "hold shift to drag in files" → "Shift+拖拽文件"
-
-4. 确保术语一致性
-
-    - ✗ 同一文档中混用"Token"/"令牌"/"代币"
-    - ✓ 统一使用"Token"作为技术术语
-
-5. 注意文化适应性
-
-    - ✗ "Kill the process" → "杀死进程"(过于暴力)
-    - ✓ "Kill the process" → "终止进程"
-
-6. 技术文档特殊处理
-    - 代码示例中的注释：
-      ✗ 翻译后破坏代码结构
-      ✓ 保持代码注释原样或仅翻译说明部分
-    - 命令行参数：
-      ✗ 翻译参数名称导致无法使用
-      ✓ 保持参数名称英文，仅翻译说明
-
-## Best Practices
-
-1. **翻译工作流程**
-
-    - 通读全文理解上下文
-    - 标记并统一技术术语
-    - 分段翻译并检查一致性
-    - 最终整体审校
-
-2. **质量检查要点**
-
-    - 术语一致性
-    - 功能描述准确性
-    - UI元素长度适配性
-    - 文化适应性
-
-3. **工具使用建议**
-
-    - 建立项目术语库
-    - 使用翻译记忆工具
-    - 维护风格指南
-    - 定期更新翻译资源
-
-4. **审校流程**
-    - 初翻 → 技术审校 → 语言润色 → 最终确认
-    - 重点关注技术准确性、语言流畅度和UI显示效果
-
-## Quality Checklist
-
-1. 术语是否全文一致？
-2. 是否符合中文技术文档习惯？
-3. UI控件文本是否简洁明确？
-4. 长句是否已合理拆分？
-5. 变量占位符是否保留原格式？
-6. 技术描述是否准确无误？
-7. 文化表达是否恰当？
-8. 是否保持了原文的精确含义？
-9. 特殊格式(如变量、代码)是否正确保留？

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

@@ -1,18 +0,0 @@
-# Traditional Chinese (zh-TW) Translation Guidelines
-
-## Key Terminology
-
-| English Term  | Use (zh-TW) | Avoid (Mainland) |
-| ------------- | ----------- | ---------------- |
-| file          | 檔案        | 文件             |
-| task          | 工作        | 任務             |
-| project       | 專案        | 項目             |
-| configuration | 設定        | 配置             |
-| server        | 伺服器      | 服務器           |
-| import/export | 匯入/匯出   | 導入/導出        |
-
-## Formatting Rules
-
-- Add spaces between Chinese and English/numbers: "AI 驅動" (not "AI驅動")
-- Use Traditional Chinese quotation marks: 「範例文字」(not "範例文字")
-- Use Taiwanese computing conventions rather than mainland terminology

.roo/rules/rules.md

@@ -1,24 +0,0 @@
-# Code Quality Rules
-
-1. Test Coverage:
-
-    - 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

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

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

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

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

.rooignore

@@ -1 +0,0 @@
-.env

.roomodes

@@ -1,148 +0,0 @@
-customModes:
-  - slug: translate
-    name: 🌐 Translate
-    roleDefinition: You are Roo, a linguistic specialist focused on translating and managing localization files. Your responsibility is to help maintain and update translation files for the application, ensuring consistency and accuracy across all language resources.
-    whenToUse: Translate and manage localization files.
-    description: Translate and manage localization files.
-    groups:
-      - read
-      - command
-      - - edit
-        - 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,2 +0,0 @@
-pnpm 10.8.1
-nodejs 20.19.2

.vscode-test.mjs

@@ -0,0 +1,19 @@
+/**
+ * See: https://code.visualstudio.com/api/working-with-extensions/testing-extension
+ */
+
+import { defineConfig } from '@vscode/test-cli';
+
+export default defineConfig({
+	label: 'integrationTest',
+	files: 'out-integration/test/**/*.test.js',
+	workspaceFolder: '.',
+	mocha: {
+		ui: 'tdd',
+		timeout: 60000,
+	},
+	launchArgs: [
+		'--enable-proposed-api=RooVeterinaryInc.roo-cline',
+		'--disable-extensions'
+	]
+});

.vscode/extensions.json

@@ -3,10 +3,10 @@
 	// for the documentation about the extensions.json format
 	"recommendations": [
 		"dbaeumer.vscode-eslint",
-		"esbenp.prettier-vscode",
+		"connor4312.esbuild-problem-matchers",
+		"ms-vscode.extension-test-runner",
 		"csstools.postcss",
 		"bradlc.vscode-tailwindcss",
-		"connor4312.esbuild-problem-matchers",
-		"yoavbls.pretty-ts-errors"
+		"tobermory.es6-string-html"
 	]
 }

.vscode/launch.json

@@ -10,20 +10,20 @@
 			"type": "extensionHost",
 			"request": "launch",
 			"runtimeExecutable": "${execPath}",
-			"args": ["--extensionDevelopmentPath=${workspaceFolder}/src"],
+			"args": [
+				"--extensionDevelopmentPath=${workspaceFolder}",
+			],
 			"sourceMaps": true,
-			"outFiles": ["${workspaceFolder}/src/dist/**/*.js"],
-			"preLaunchTask": "${defaultBuildTask}",
+			"outFiles": ["${workspaceFolder}/dist/**/*.js"],
+			"preLaunchTask": "compile",
 			"env": {
 				"NODE_ENV": "development",
 				"VSCODE_DEBUG_MODE": "true"
 			},
-			"resolveSourceMapLocations": ["${workspaceFolder}/**", "!**/node_modules/**"],
-			"presentation": {
-				"hidden": false,
-				"group": "tasks",
-				"order": 1
-			}
-		}
+			"resolveSourceMapLocations": [
+				"${workspaceFolder}/**",
+				"!**/node_modules/**"
+			]
+		},
 	]
 }

.vscode/settings.json

@@ -9,6 +9,5 @@
 		"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",
-	"vitest.disableWorkspaceWarning": true
+	"typescript.tsc.autoDetect": "off"
 }

.vscode/tasks.json

@@ -3,72 +3,83 @@
 {
 	"version": "2.0.0",
 	"tasks": [
+		{
+			"label": "compile",
+			"type": "npm",
+			"script": "compile",
+			"dependsOn": ["npm: build:webview"],
+			"group": {
+				"kind": "build",
+				"isDefault": true
+			},
+			"presentation": {
+				"reveal": "silent",
+				"panel": "shared"
+			},
+			"problemMatcher": ["$tsc", "$eslint-stylish"]
+		},
 		{
 			"label": "watch",
-			"dependsOn": ["watch:webview", "watch:bundle", "watch:tsc"],
+			"dependsOn": ["npm: build:webview", "npm: watch:tsc", "npm: watch:esbuild"],
 			"presentation": {
 				"reveal": "never"
 			},
 			"group": {
 				"kind": "build",
-				"isDefault": true
+				"isDefault": false
 			}
 		},
 		{
-			"label": "watch:webview",
-			"type": "shell",
-			"command": "pnpm --filter @roo-code/vscode-webview dev",
+			"type": "npm",
+			"script": "build:webview",
 			"group": "build",
-			"problemMatcher": {
-				"owner": "vite",
-				"pattern": {
-					"regexp": "^$"
-				},
-				"background": {
-					"activeOnStart": true,
-					"beginsPattern": ".*VITE.*",
-					"endsPattern": ".*Local:.*"
-				}
-			},
+			"problemMatcher": [],
 			"isBackground": true,
+			"label": "npm: build:webview",
 			"presentation": {
 				"group": "watch",
-				"reveal": "always"
+				"reveal": "never"
 			}
 		},
 		{
-			"label": "watch:bundle",
-			"type": "shell",
-			"command": "npx turbo watch:bundle",
+			"type": "npm",
+			"script": "watch:esbuild",
 			"group": "build",
-			"problemMatcher": {
-				"owner": "esbuild",
-				"pattern": {
-					"regexp": "^$"
-				},
-				"background": {
-					"activeOnStart": true,
-					"beginsPattern": "esbuild-problem-matcher#onStart",
-					"endsPattern": "esbuild-problem-matcher#onEnd"
-				}
-			},
+			"problemMatcher": "$esbuild-watch",
 			"isBackground": true,
+			"label": "npm: watch:esbuild",
 			"presentation": {
 				"group": "watch",
-				"reveal": "always"
+				"reveal": "never"
 			}
 		},
 		{
-			"label": "watch:tsc",
-			"type": "shell",
-			"command": "npx turbo watch:tsc",
+			"type": "npm",
+			"script": "watch:tsc",
 			"group": "build",
 			"problemMatcher": "$tsc-watch",
 			"isBackground": true,
+			"label": "npm: watch:tsc",
 			"presentation": {
 				"group": "watch",
-				"reveal": "always"
+				"reveal": "never"
 			}
+		},
+		{
+			"type": "npm",
+			"script": "watch-tests",
+			"problemMatcher": "$tsc-watch",
+			"isBackground": true,
+			"presentation": {
+				"reveal": "never",
+				"group": "watchers"
+			},
+			"group": "build"
+		},
+		{
+			"label": "tasks: watch-tests",
+			"dependsOn": ["npm: watch", "npm: watch-tests"],
+			"problemMatcher": []
 		}
 	]
 }

.vscodeignore

@@ -0,0 +1,42 @@
+# Default
+.vscode/**
+.vscode-test/**
+out/**
+node_modules/**
+src/**
+.gitignore
+.yarnrc
+esbuild.js
+vsc-extension-quickstart.md
+**/tsconfig.json
+**/.eslintrc.json
+**/*.map
+**/*.ts
+**/.vscode-test.*
+
+# Custom
+demo.gif
+.nvmrc
+.gitattributes
+.prettierignore
+
+# 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/**
+**/.gitignore
+
+# Fix issue where codicons don't get packaged (https://github.com/microsoft/vscode-extension-samples/issues/692)
+!node_modules/@vscode/codicons/dist/codicon.css
+!node_modules/@vscode/codicons/dist/codicon.ttf
+
+# Include default themes JSON files used in getTheme
+!src/integrations/theme/default-themes/**
+
+# Include icons
+!assets/icons/**

AGENTS.md

@@ -1,5 +0,0 @@
-# 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.

LICENSE

@@ -186,7 +186,7 @@
       same "printed page" as the copyright notice for easier
       identification within third-party archives.
 
-   Copyright 2025 Roo Code, Inc.
+   Copyright 2025 Roo Veterinary Inc.
 
    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
@@ -198,4 +198,4 @@
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
-   limitations under the License.
+   limitations under the License.