diff --git a/.roo/commands/roo-resolve-conflicts.md b/.roo/commands/roo-resolve-conflicts.md
new file mode 100644
index 00000000000..4a3a80bdd34
--- /dev/null
+++ b/.roo/commands/roo-resolve-conflicts.md
@@ -0,0 +1,72 @@
+---
+description: "Resolve merge conflicts intelligently using git history analysis"
+argument-hint: "#PR-number"
+mode: merge-resolver
+---
+
+Resolve merge conflicts for a specific pull request by analyzing git history, commit messages, and code changes to make intelligent resolution decisions.
+
+## Quick Start
+
+1. **Provide a PR number** (e.g., `#123` or just `123`)
+
+2. The workflow will automatically:
+   - Fetch PR information (title, description, branches)
+   - Checkout the PR branch
+   - Rebase onto the target branch to reveal conflicts
+   - Analyze and resolve conflicts using git history
+
+## Workflow Steps
+
+### 1. Initialize PR Resolution
+
+```bash
+# Fetch PR info
+gh pr view [PR_NUMBER] --json title,body,headRefName,baseRefName
+
+# Checkout and rebase
+gh pr checkout [PR_NUMBER] --force
+git fetch origin main
+GIT_EDITOR=true git rebase origin/main
+```
+
+### 2. Identify Conflicts
+
+```bash
+git status --porcelain | grep "^UU"
+```
+
+### 3. Analyze Each Conflict
+
+For each conflicted file:
+- Read the conflict markers
+- Run `git blame` on conflicting sections
+- Fetch commit messages for context
+- Determine the intent behind each change
+
+### 4. Apply Resolution Strategy
+
+Based on the analysis:
+- **Bugfixes** generally take precedence over features
+- **Recent changes** are often more relevant (unless older is a security fix)
+- **Combine** non-conflicting changes when possible
+- **Preserve** test updates alongside code changes
+
+### 5. Complete Resolution
+
+```bash
+git add [resolved-files]
+GIT_EDITOR=true git rebase --continue
+```
+
+## Key Guidelines
+
+- Always escape conflict markers with `\` when using `apply_diff`
+- Document resolution decisions in the summary
+- Verify no syntax errors after resolution
+- Preserve valuable changes from both sides when possible
+
+## Examples
+
+- `/roo-resolve-conflicts #123` - Resolve conflicts for PR #123
+- `/roo-resolve-conflicts 456` - Resolve conflicts for PR #456
diff --git a/.roo/commands/roo-translate.md b/.roo/commands/roo-translate.md
new file mode 100644
index 00000000000..3f974948946
--- /dev/null
+++ b/.roo/commands/roo-translate.md
@@ -0,0 +1,50 @@
+---
+description: "Translate and localize strings in the Roo Code extension"
+argument-hint: "[language-code or 'all'] [string-key or file-path]"
+mode: translate
+---
+
+Perform translation and localization tasks for the Roo Code extension. This command activates the translation workflow with comprehensive i18n guidelines.
+
+## Quick Start
+
+1. **Identify the translation scope:**
+   - If a specific language code is provided (e.g., `de`, `zh-CN`), focus on that language
+   - If `all` is specified, translate to all supported languages
+   - If a string key is provided, locate and translate that specific string
+   - If a file path is provided, work with that translation file
+
+2. **Supported languages:** ca, de, en, es, fr, hi, id, it, ja, ko, nl, pl, pt-BR, ru, tr, vi, zh-CN, zh-TW
+
+3. **Translation locations:**
+   - Core Extension: `src/i18n/locales/`
+   - WebView UI: `webview-ui/src/i18n/locales/`
+
+## Workflow
+
+1. If adding new strings:
+   - Add the English string first
+   - Ask for confirmation before translating to other languages
+   - Use `apply_diff` for efficient file updates
+
+2. If updating existing strings:
+   - Identify all affected language files
+   - Update English first, then propagate changes
+
+3. Validate your changes:
+   ```bash
+   node scripts/find-missing-translations.js
+   ```
+
+## Key Guidelines
+
+- Use informal speech (e.g., "du" not "Sie" in German)
+- Keep technical terms like "token", "Prompt" in English
+- Preserve all `{{variable}}` placeholders exactly
+- Use `apply_diff` instead of `write_to_file` for existing files
+
+## Examples
+
+- `/roo-translate de` - Focus on German translations
+- `/roo-translate all welcome.title` - Translate a specific key to all languages
+- `/roo-translate zh-CN src/i18n/locales/zh-CN/core.json` - Work on specific file
diff --git a/.roo/guidance/roo-translator.md b/.roo/guidance/roo-translator.md
new file mode 100644
index 00000000000..2539778f27f
--- /dev/null
+++ b/.roo/guidance/roo-translator.md
@@ -0,0 +1,15 @@
+# Roo Code Translation Guidance
+
+This file contains brand voice, tone, and word choice guidelines for Roo Code translations.
+
+## Brand Voice
+
+<!-- Add brand voice guidelines here -->
+
+## Tone
+
+<!-- Add tone guidelines here -->
+
+## Word Choice
+
+<!-- Add word choice preferences here -->
diff --git a/.roo/skills/roo-conflict-resolution/SKILL.md b/.roo/skills/roo-conflict-resolution/SKILL.md
new file mode 100644
index 00000000000..7b123a8107b
--- /dev/null
+++ b/.roo/skills/roo-conflict-resolution/SKILL.md
@@ -0,0 +1,256 @@
+---
+name: roo-conflict-resolution
+description: Provides comprehensive guidelines for resolving merge conflicts intelligently using git history and commit context. Use when tasks involve merge conflicts, rebasing, PR conflicts, or git conflict resolution. This skill analyzes commit messages, git blame, and code intent to make intelligent resolution decisions.
+---
+
+# Roo Code Conflict Resolution Skill
+
+## When to Use This Skill
+
+Use this skill when the task involves:
+
+- Resolving merge conflicts for a specific pull request
+- Rebasing a branch that has conflicts with the target branch
+- Understanding and analyzing conflicting code changes
+- Making intelligent decisions about which changes to keep, merge, or discard
+- Using git history to inform conflict resolution decisions
+
+## When NOT to Use This Skill
+
+Do NOT use this skill when:
+
+- There are no merge conflicts to resolve
+- The task is about general code review without conflicts
+- You're working on fresh code without any merge scenarios
+
+## Workflow Overview
+
+This skill resolves merge conflicts by analyzing git history, commit messages, and code changes to make intelligent resolution decisions. Given a PR number (e.g., "#123"), it handles the entire conflict resolution process.
+
+## Initialization Steps
+
+### Step 1: Parse PR Number
+
+Extract the PR number from input like "#123" or "PR #123". Validate that a PR number was provided.
+
+### Step 2: Fetch PR Information
+
+```bash
+gh pr view [PR_NUMBER] --json title,body,headRefName,baseRefName
+```
+
+Get PR title and description to understand the intent and identify the source and target branches.
+
+### Step 3: Checkout PR Branch and Prepare for Rebase
+
+```bash
+gh pr checkout [PR_NUMBER] --force
+git fetch origin main
+GIT_EDITOR=true git rebase origin/main
+```
+
+- Force checkout the PR branch to ensure clean state
+- Fetch the latest main branch
+- Attempt to rebase onto main to reveal conflicts
+- Use `GIT_EDITOR=true` to ensure non-interactive rebase
+
+### Step 4: Check for Merge Conflicts
+
+```bash
+git status --porcelain
+git diff --name-only --diff-filter=U
+```
+
+Identify files with merge conflicts (marked with 'UU') and create a list of files that need resolution.
+
+## Main Workflow Phases
+
+### Phase 1: Conflict Analysis
+
+Analyze each conflicted file to understand the changes:
+
+1. Read the conflicted file to identify conflict markers
+2. Extract the conflicting sections between `<<<<<<<` and `>>>>>>>`
+3. Run git blame on both sides of the conflict
+4. Fetch commit messages and diffs for relevant commits
+5. Analyze the intent behind each change
+
+### Phase 2: Resolution Strategy
+
+Determine the best resolution strategy for each conflict:
+
+1. Categorize changes by intent (bugfix, feature, refactor, etc.)
+2. Evaluate recency and relevance of changes
+3. Check for structural overlap vs formatting differences
+4. Identify if changes can be combined or if one should override
+5. Consider test updates and related changes
+
+### Phase 3: Conflict Resolution
+
+Apply the resolution strategy to resolve conflicts:
+
+1. For each conflict, apply the chosen resolution
+2. Ensure proper escaping of conflict markers in diffs
+3. Validate that resolved code is syntactically correct
+4. Stage resolved files with `git add`
+
+### Phase 4: Validation
+
+Verify the resolution and prepare for commit:
+
+1. Run `git status` to confirm all conflicts are resolved
+2. Check for any compilation or syntax errors
+3. Review the final diff to ensure sensible resolutions
+4. Prepare a summary of resolution decisions
+
+## Git Commands Reference
+
+| Command | Purpose |
+|---------|---------|
+| `gh pr checkout [PR_NUMBER] --force` | Force checkout the PR branch |
+| `git fetch origin main` | Get the latest main branch |
+| `GIT_EDITOR=true git rebase origin/main` | Rebase current branch onto main (non-interactive) |
+| `git blame -L [start],[end] [commit] -- [file]` | Get commit information for specific lines |
+| `git show --format="%H%n%an%n%ae%n%ad%n%s%n%b" --no-patch [sha]` | Get commit metadata |
+| `git show [sha] -- [file]` | Get the actual changes made in a commit |
+| `git ls-files -u` | List unmerged files with stage information |
+| `GIT_EDITOR=true git rebase --continue` | Continue rebase after resolving conflicts |
+
+## Best Practices
+
+### Intent-Based Resolution (High Priority)
+
+Always prioritize understanding the intent behind changes rather than just looking at the code differences. Commit messages, PR descriptions, and issue references provide crucial context.
+
+**Example:** When there's a conflict between a bugfix and a refactor, apply the bugfix logic within the refactored structure rather than simply choosing one side.
+
+### Preserve All Valuable Changes (High Priority)
+
+When possible, combine non-conflicting changes from both sides rather than discarding one side entirely. Both sides of a conflict often contain valuable changes that can coexist if properly integrated.
+
+### Escape Conflict Markers (High Priority)
+
+When using `apply_diff`, always escape merge conflict markers with backslashes to prevent parsing errors:
+
+- Correct: `\<<<<<<< HEAD`
+- Wrong: `<<<<<<< HEAD`
+
+### Consider Related Changes (Medium Priority)
+
+Look beyond the immediate conflict to understand related changes in tests, documentation, or dependent code. A change might seem isolated but could be part of a larger feature or fix.
+
+## Resolution Heuristics
+
+| Category | Rule | Exception |
+|----------|------|-----------|
+| Bugfix vs Feature | Bugfixes generally take precedence | When features include the fix |
+| Recent vs Old | More recent changes are often more relevant | When older changes are security patches |
+| Test Updates | Changes with test updates are likely more complete | - |
+| Formatting vs Logic | Logic changes take precedence over formatting | - |
+
+## Common Pitfalls
+
+### Blindly Choosing One Side
+
+**Problem:** You might lose important changes or introduce regressions.
+**Solution:** Always analyze both sides using git blame and commit history.
+
+### Ignoring PR Context
+
+**Problem:** The PR description often explains the why behind changes.
+**Solution:** Always fetch and read the PR information before resolving.
+
+### Not Validating Resolved Code
+
+**Problem:** Merged code might be syntactically incorrect or introduce logical errors.
+**Solution:** Always check for syntax errors and review the final diff.
+
+### Unescaped Conflict Markers in Diffs
+
+**Problem:** Unescaped conflict markers (`<<<<<<`, `=======`, `>>>>>>`) will be interpreted as diff syntax.
+**Solution:** Always escape with backslash (`\`) when they appear in content.
+
+## Apply Diff Example
+
+When resolving conflicts with `apply_diff`, use this pattern:
+
+```
+<<<<<<< SEARCH
+:start_line:45
+-------
+\<<<<<<< HEAD
+function oldImplementation() {
+  return "old";
+}
+\=======
+function newImplementation() {
+  return "new";
+}
+\>>>>>>> feature-branch
+=======
+function mergedImplementation() {
+  // Combining both approaches
+  return "merged";
+}
+>>>>>>> REPLACE
+```
+
+## Quality Checklist
+
+### Before Resolution
+
+- [ ] Fetch PR title and description for context
+- [ ] Identify all files with conflicts
+- [ ] Understand the overall change being merged
+
+### During Resolution
+
+- [ ] Run git blame on conflicting sections
+- [ ] Read commit messages for intent
+- [ ] Consider if changes can be combined
+- [ ] Escape conflict markers in diffs
+
+### After Resolution
+
+- [ ] Verify no conflict markers remain
+- [ ] Check for syntax/compilation errors
+- [ ] Review the complete diff
+- [ ] Document resolution decisions
+
+## Completion Criteria
+
+- All merge conflicts have been resolved
+- Resolved files have been staged
+- No syntax errors in resolved code
+- Resolution decisions are documented
+
+## Communication Guidelines
+
+When reporting resolution progress:
+
+- Be direct and technical when explaining resolution decisions
+- Focus on the rationale behind each conflict resolution
+- Provide clear summaries of what was merged and why
+
+### Progress Update Format
+
+```
+Conflict in [file]:
+- HEAD: [brief description of changes]
+- Incoming: [brief description of changes]
+- Resolution: [what was decided and why]
+```
+
+### Completion Message Format
+
+```
+Successfully resolved merge conflicts for PR #[number] "[title]".
+
+Resolution Summary:
+- [file1]: [brief description of resolution]
+- [file2]: [brief description of resolution]
+
+[Key decision explanation if applicable]
+
+All conflicts have been resolved and files have been staged for commit.
+```
diff --git a/.roo/skills/roo-translation/SKILL.md b/.roo/skills/roo-translation/SKILL.md
new file mode 100644
index 00000000000..93d410fc651
--- /dev/null
+++ b/.roo/skills/roo-translation/SKILL.md
@@ -0,0 +1,151 @@
+---
+name: roo-translation
+description: Provides comprehensive guidelines for translating and localizing Roo Code extension strings. Use when tasks involve i18n, translation, localization, adding new languages, or updating existing translation files. This skill covers both core extension (src/i18n/locales/) and WebView UI (webview-ui/src/i18n/locales/) localization.
+---
+
+# Roo Code Translation Skill
+
+## When to Use This Skill
+
+Use this skill when the task involves:
+
+- Adding new translatable strings to the Roo Code extension
+- Translating existing strings to new languages
+- Updating or fixing translations in existing language files
+- Understanding i18n patterns used in the codebase
+- Working with localization files in either core extension or WebView UI
+
+## When NOT to Use This Skill
+
+Do NOT use this skill when:
+
+- Working on non-translation code changes
+- The task doesn't involve i18n or localization
+- You're only reading translation files for reference without modifying them
+
+## Supported Languages and Locations
+
+Localize all strings into the following locale files: ca, de, en, es, fr, hi, id, it, ja, ko, nl, pl, pt-BR, ru, tr, vi, zh-CN, zh-TW
+
+The VSCode extension has two main areas that require localization:
+
+| Component | Path | Purpose |
+|-----------|------|---------|
+| **Core Extension** | `src/i18n/locales/` | Extension backend strings |
+| **WebView UI** | `webview-ui/src/i18n/locales/` | User interface strings |
+
+## Brand Voice, Tone, and Word Choice
+
+For detailed brand voice, tone, and word choice guidance, refer to the guidance file:
+
+- [`.roo/guidance/roo-translator.md`](.roo/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