scriptoriumadmin/Roo-Code
1
0
Fork 0
mirror of https://github.com/RooVetGit/Roo-Code.git synced 2026-09-11 22:51:26 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Resolve merge conflicts: migrate deduplicateReadFileHistory to Task class

Browse source 
- Remove deleted Cline.ts file
- Add deduplicateReadFileHistory method to Task class in src/core/task/Task.ts
- Call deduplication in attemptApiRequest before making API requests
- Preserves original functionality: removes older read_file results for same file
- Optimizes context length and token usage by preventing duplicate file content
This commit is contained in:
Roo Code 2025-07-18 03:49:49 +00:00
commit 2775a75180
1856 changed files with 277516 additions and 88705 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
.changeset/changelog-config.js
View file

@ -1,5 +1,3 @@
// Half-works to simplify the format but needs 'overwrite_changeset_changelog.py' in GHA to finish formatting
const getReleaseLine = async (changeset) => {
const [firstLine] = changeset.summary
.split("\n")

2
.changeset/config.json
View file

@ -2,7 +2,7 @@
"$schema": "https://unpkg.com/@changesets/config@3.0.4/schema.json",
"changelog": "./changelog-config.js",
"commit": false,
"fixed": [],
"fixed": [["roo-cline"]],
"linked": [],
"access": "restricted",
"baseBranch": "main",

27
.clinerules
View file

@ -1,27 +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
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
3. Logging Guidelines:
- Always instrument code changes using the logger exported from `src\utils\logging\index.ts`.
- This will facilitate efficient debugging without impacting production (as the logger no-ops outside of a test environment.)
- Logs can be found in `logs\app.log`
- Logfile is overwritten on each run to keep it to a manageable volume.
4. Styling Guidelines:
- Use Tailwind CSS classes instead of inline style objects for new markup
- VSCode CSS variables must be added to webview-ui/src/index.css before using them in Tailwind classes
- Example: `<div className="text-md text-vscode-descriptionForeground mb-2" />` instead of style objects
# Adding a New Setting
To add a new setting that persists its state, follow the steps in cline_docs/settings.md

90
.dockerignore Normal file
View file

@ -0,0 +1,90 @@
# 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/
!src/
!webview-ui/
!packages/evals/.docker/entrypoints/runner.sh
!packages/build/
!packages/cloud/
!packages/config-eslint/
!packages/config-typescript/
!packages/evals/
!packages/ipc/
!packages/telemetry/
!packages/types/
!locales/

5
.env.sample Normal file
View file

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

23
.eslintrc.json
View file

@ -1,23 +0,0 @@
{
"root": true,
"parser": "@typescript-eslint/parser",
"parserOptions": {
"ecmaVersion": 6,
"sourceType": "module"
},
"plugins": ["@typescript-eslint"],
"rules": {
"@typescript-eslint/naming-convention": [
"warn",
{
"selector": "import",
"format": ["camelCase", "PascalCase"]
}
],
"@typescript-eslint/semi": "off",
"eqeqeq": "warn",
"no-throw-literal": "warn",
"semi": "off"
},
"ignorePatterns": ["out", "dist", "**/*.d.ts"]
}

2
.git-blame-ignore-revs
View file

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

4
.gitattributes vendored
View file

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

2
.github/CODEOWNERS vendored
View file

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

160
.github/ISSUE_TEMPLATE/bug_report.yml vendored
View file

@ -1,68 +1,98 @@
name: Bug Report
description: File a bug report
description: Clearly report a bug with detailed repro steps
labels: ["bug"]
body:
- 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.7 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.
- type: markdown
attributes:
value: |
**Thanks for your report!** Please check existing issues first:
👉 https://github.com/RooCodeInc/Roo-Code/issues
- 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
options:
- Anthropic
- AWS Bedrock
- Chutes AI
- DeepSeek
- Glama
- Google Gemini
- Google Vertex AI
- Groq
- Human Relay Provider
- LiteLLM
- LM Studio
- Mistral AI
- Ollama
- OpenAI
- OpenAI Compatible
- OpenRouter
- Requesty
- Unbound
- VS Code Language Model API
- xAI (Grok)
- Not Applicable / Other
validations:
required: true
- type: input
id: model
attributes:
label: Model Used
description: Exact model name (e.g., Claude 3.7 Sonnet). Use N/A if irrelevant.
validations:
required: true
- type: textarea
id: roo-code-tasks
attributes:
label: Roo Code Task Links (Optional)
description: |
If you have any publicly shared task links that demonstrate the issue, please paste them here.
This helps maintainers understand the context.
Example: https://app.roocode.com/share/task-id
placeholder: Paste your Roo Code share links here, one per line
- type: textarea
id: steps
attributes:
label: 🔁 Steps to Reproduce
description: |
Help us see what you saw. Give clear, numbered steps:
1. Setup (OS, extension version, settings)
2. Exact actions (clicks, input, files, commands)
3. What happened after each step
Think like you're writing a recipe. Without this, we can't reproduce the issue.
validations:
required: true
- type: textarea
id: what-happened
attributes:
label: 💥 Outcome Summary
description: |
Recap what went wrong in one or two lines.
Example: "Expected code to run, but got an empty response and no error."
placeholder: Expected ___, but got ___.
validations:
required: true
- type: textarea
id: logs
attributes:
label: 📄 Relevant Logs or Errors (Optional)
description: Paste API logs, terminal output, or errors here. Use triple backticks (```) for code formatting.
render: shell

2
.github/ISSUE_TEMPLATE/config.yml vendored
View file

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

201
.github/ISSUE_TEMPLATE/feature_request.yml vendored Normal file
View file

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

62
.github/ISSUE_TEMPLATE/marketplace.yml vendored Normal file
View file

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

83
.github/actions/ai-release-notes/action.yml vendored
View file

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

48
.github/actions/setup-node-pnpm/action.yml vendored Normal file
View file

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

58
.github/actions/slack-notify/action.yml vendored Normal file
View file

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

88
.github/pull_request_template.md vendored
View file

@ -1,35 +1,75 @@
## Context
<!-- Brief description of WHAT you’re doing and WHY. -->
## Implementation
<!--
Thank you for contributing to Roo Code!
Some description of HOW you achieved it. Perhaps give a high level description of the program flow. Did you need to refactor something? What tradeoffs did you take? Are there things in here which you’d particularly like people to pay close attention to?
Before submitting your PR, please ensure:
- It's linked to an approved GitHub Issue.
- You've reviewed our [Contributing Guidelines](../CONTRIBUTING.md).
-->
## Screenshots
### Related GitHub Issue
| before | after |
| ------ | ----- |
| | |
<!-- Every PR MUST be linked to an approved issue. -->
## How to Test
Closes: # <!-- Replace with the issue number, e.g., Closes: #123 -->
### Roo Code Task Context (Optional)
<!--
A straightforward scenario of how to test your changes will help reviewers that are not familiar with the part of the code that you are changing but want to see it in action. This section can include a description or step-by-step instructions of how to get to the state of v2 that your change affects.
A "How To Test" section can look something like this:
- Sign in with a user with tracks
- Activate `show_awesome_cat_gifs` feature (add `?feature.show_awesome_cat_gifs=1` to your URL)
- You should see a GIF with cats dancing
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
-->
## Get in Touch
### Description
<!-- We'd love to have a way to chat with you about your changes if necessary. If you're in the [Roo Code Discord](https://discord.gg/roocode), please share your handle here. -->
<!--
Briefly summarize the changes in this PR and how they address the linked issue.
The issue should cover the "what" and "why"; this section should focus on:
- The "how": key implementation details, design choices, or trade-offs made.
- Anything specific reviewers should pay attention to in this PR.
-->
### Test Procedure
<!--
Detail the steps to test your changes. This helps reviewers verify your work.
- How did you test this specific implementation? (e.g., unit tests, manual testing steps)
- How can reviewers reproduce your tests or verify the fix/feature?
- Include relevant testing environment details if applicable.
-->
### Pre-Submission Checklist
<!-- Go through this checklist before marking your PR as ready for review. -->
- [ ] **Issue Linked**: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
- [ ] **Scope**: My changes are focused on the linked issue (one major feature/fix per PR).
- [ ] **Self-Review**: I have performed a thorough self-review of my code.
- [ ] **Testing**: New and/or updated tests have been added to cover my changes (if applicable).
- [ ] **Documentation Impact**: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
- [ ] **Contribution Guidelines**: I have read and agree to the [Contributor Guidelines](/CONTRIBUTING.md).
### Screenshots / Videos
<!--
For UI changes, please provide before-and-after screenshots or a short video of the *actual results*.
This greatly helps in understanding the visual impact of your changes.
-->
### Documentation Updates
<!--
Does this PR necessitate updates to user-facing documentation?
- [ ] No documentation updates are required.
- [ ] Yes, documentation updates are required. (Please describe what needs to be updated or link to a PR in the docs repository).
-->
### Additional Notes
<!-- Add any other context, questions, or information for reviewers here. -->
### Get in Touch
<!--
Please provide your Discord username for reviewers or maintainers to reach you if they have questions about your PR
-->

123
.github/scripts/ai-release-notes.py vendored
View file

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

52
.github/scripts/get_prev_version_refs.py vendored
View file

@ -1,52 +0,0 @@
import os
import re
import subprocess
def run_git_command(command):
result = subprocess.getoutput(command)
print(f"Git Command: {command}")
print(f"Git Output: {result}")
return result
def parse_merge_commit(line):
# Parse merge commit messages like:
# "355dc82 Merge pull request #71 from 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()

62
.github/scripts/overwrite_changeset_changelog.py vendored
View file

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

64
.github/scripts/parse_changeset_changelog.py vendored
View file

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

125
.github/scripts/release-notes-prompt.py vendored
View file

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

38
.github/workflows/changeset-release.yml vendored
View file

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

203
.github/workflows/code-qa.yml vendored
View file

@ -1,118 +1,107 @@
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:
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:ci
- name: Compile
run: npm run compile
- name: Check types
run: npm run check-types
- name: Lint
run: npm run lint
check-translations:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Node.js and pnpm
uses: ./.github/actions/setup-node-pnpm
- name: Verify all translations are complete
run: node scripts/find-missing-translations.js
knip:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '18'
cache: 'npm'
- name: Install dependencies
run: npm run install:ci
- name: Run knip checks
run: npm run knip
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
test-extension:
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:ci
- name: Run unit tests
run: npx jest --silent
compile:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Node.js and pnpm
uses: ./.github/actions/setup-node-pnpm
- name: Lint
run: pnpm lint
- name: Check types
run: pnpm check-types
test-webview:
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:ci
- name: Run unit tests
working-directory: webview-ui
run: npx jest --silent
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
unit-test:
needs: [test-extension, test-webview]
runs-on: ubuntu-latest
steps:
- name: NO-OP
run: echo "All unit tests passed."
check-openrouter-api-key:
runs-on: ubuntu-latest
outputs:
exists: ${{ steps.openrouter-api-key-check.outputs.defined }}
steps:
- name: Check if OpenRouter API key exists
id: openrouter-api-key-check
shell: bash
run: |
if [ "${{ secrets.OPENROUTER_API_KEY }}" != '' ]; then
echo "defined=true" >> $GITHUB_OUTPUT;
else
echo "defined=false" >> $GITHUB_OUTPUT;
fi
check-openrouter-api-key:
runs-on: ubuntu-latest
outputs:
exists: ${{ steps.openrouter-api-key-check.outputs.defined }}
steps:
- name: Check if OpenRouter API key exists
id: openrouter-api-key-check
shell: bash
run: |
if [ "${{ secrets.OPENROUTER_API_KEY }}" != '' ]; then
echo "defined=true" >> $GITHUB_OUTPUT;
else
echo "defined=false" >> $GITHUB_OUTPUT;
fi
integration-test:
runs-on: ubuntu-latest
needs: [check-openrouter-api-key]
if: needs.check-openrouter-api-key.outputs.exists == 'true'
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Node.js and pnpm
uses: ./.github/actions/setup-node-pnpm
- name: Create .env.local file
working-directory: apps/vscode-e2e
run: echo "OPENROUTER_API_KEY=${{ secrets.OPENROUTER_API_KEY }}" > .env.local
- name: Run integration tests
working-directory: apps/vscode-e2e
run: xvfb-run -a pnpm test:ci
integration-test:
runs-on: ubuntu-latest
needs: [check-openrouter-api-key]
if: needs.check-openrouter-api-key.outputs.exists == 'true'
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '18'
cache: 'npm'
- name: Install dependencies
run: npm run install:ci
- name: Create env.integration file
working-directory: e2e
run: echo "OPENROUTER_API_KEY=${{ secrets.OPENROUTER_API_KEY }}" > .env.integration
- name: Run integration tests
working-directory: e2e
run: xvfb-run -a npm run ci
notify-slack-on-failure:
runs-on: ubuntu-latest
needs: [check-translations, knip, compile, unit-test, integration-test]
if: ${{ always() && github.event_name == 'push' && github.ref == 'refs/heads/main' && contains(needs.*.result, 'failure') }}
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Send Slack notification on failure
uses: ./.github/actions/slack-notify
with:
webhook-url: ${{ secrets.SLACK_WEBHOOK_URL }}
channel: "#ci"
workflow-name: "Code QA"
failed-jobs: ${{ toJSON(needs) }}

13
.github/workflows/codeql.yml vendored
View file

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

74
.github/workflows/evals.yml vendored Normal file
View file

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

88
.github/workflows/marketplace-publish.yml vendored
View file

@ -1,4 +1,5 @@
name: Publish Extension
on:
pull_request:
types: [closed]
@ -10,39 +11,82 @@ 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:
- uses: actions/checkout@v4
- name: Checkout code
uses: actions/checkout@v4
with:
ref: ${{ env.GIT_REF }}
- 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
- name: Setup Node.js and pnpm
uses: ./.github/actions/setup-node-pnpm
- name: Configure Git
run: |
npm install -g vsce ovsx
npm run install:ci
- name: Package and Publish Extension
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
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
env:
VSCE_PAT: ${{ secrets.VSCE_PAT }}
OVSX_PAT: ${{ secrets.OVSX_PAT }}
run: |
current_package_version=$(node -p "require('./package.json').version")
npm run vsix
package=$(unzip -l bin/roo-cline-${current_package_version}.vsix)
echo "$package"
echo "$package" | grep -q "dist/extension.js" || exit 1
echo "$package" | grep -q "extension/webview-ui/build/assets/index.js" || exit 1
echo "$package" | grep -q "extension/node_modules/@vscode/codicons/dist/codicon.ttf" || exit 1
npm run publish:marketplace
current_package_version=$(node -p "require('./src/package.json').version")
pnpm --filter roo-cline publish:marketplace
echo "Successfully published version $current_package_version to VS Code Marketplace"
- name: Create GitHub Release
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
current_package_version=$(node -p "require('./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}"

52
.github/workflows/nightly-publish.yml vendored Normal file
View file

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

46
.github/workflows/update-contributors.yml vendored Normal file
View file

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

46
.github/workflows/website-deploy.yml vendored Normal file
View file

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

84
.github/workflows/website-preview.yml vendored Normal file
View file

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

29
.gitignore vendored
View file

@ -1,14 +1,19 @@
.pnpm-store
dist
out
out-*
node_modules
coverage/
mock/
.DS_Store
# IDEs
.idea
# Builds
bin/
roo-cline-*.vsix
*.vsix
# Local prompts and rules
/local-prompts
@ -21,10 +26,22 @@ roo-cline-*.vsix
docs/_site/
# Dotenv
.env.integration
.env
.env.*
!.env.*.sample
#Local lint config
.eslintrc.local.json
#Logging
# Logging
logs
*.log
# Vite development
.vite-port
# Turborepo
.turbo
# IntelliJ and Qodo plugin folders
.idea/
.qodo/
.vercel
.roo/mcp.json

21
.husky/pre-commit
View file

@ -5,4 +5,23 @@ if [ "$branch" = "main" ]; then
exit 1
fi
npx lint-staged
# Detect if running on Windows and use pnpm.cmd, otherwise use pnpm.
if [ "$OS" = "Windows_NT" ]; then
pnpm_cmd="pnpm.cmd"
else
if command -v pnpm >/dev/null 2>&1; then
pnpm_cmd="pnpm"
else
pnpm_cmd="npx pnpm"
fi
fi
# Detect if running on Windows and use npx.cmd, otherwise use npx.
if [ "$OS" = "Windows_NT" ]; then
npx_cmd="npx.cmd"
else
npx_cmd="npx"
fi
$npx_cmd lint-staged
$pnpm_cmd lint

17
.husky/pre-push
View file

@ -5,14 +5,25 @@ if [ "$branch" = "main" ]; then
exit 1
fi
npm run compile
# 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
$pnpm_cmd run check-types
# Check for new changesets.
NEW_CHANGESETS=$(find .changeset -name "*.md" ! -name "README.md" | wc -l | tr -d ' ')
echo "Changeset files: $NEW_CHANGESETS"
if [ "$NEW_CHANGESETS" == "0" ]; then
if [ "$NEW_CHANGESETS" = "0" ]; then
echo "-------------------------------------------------------------------------------------"
echo "Changes detected. Please run 'npm run changeset' to create a changeset if applicable."
echo "Changes detected. Please run 'pnpm changeset' to create a changeset if applicable."
echo "-------------------------------------------------------------------------------------"
fi

1
.npmrc
View file

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

2
.nvmrc
View file

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

5
.prettierignore
View file

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

3
.prettierrc.json
View file

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

6
.roo/rules-code/use-safeWriteJson.md Normal file
View file

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

236
.roo/rules-docs-extractor/1_extraction_workflow.xml Normal file
View file

@ -0,0 +1,236 @@
<extraction_workflow>
<mode_overview>
The Docs Extractor mode analyzes features to generate documentation.
It extracts technical details, business logic, and user workflows
for different audiences.
</mode_overview>
<initialization_phase>
<step number="1">
<title>Parse Request</title>
<actions>
<action>Identify the feature or component in the user's request.</action>
<action>Determine if the request is for a review or to generate new documentation.</action>
<action>Default to user-friendly docs unless technical output is requested.</action>
<action>Note any specific areas to emphasize.</action>
</actions>
<note>The initial request determines the workflow path (review vs. generation).</note>
</step>
<step number="2">
<title>Discover Feature</title>
<actions>
<action>Find related code with semantic search.</action>
<action>Identify entry points and components.</action>
<action>Map the high-level architecture.</action>
</actions>
<tool_use><![CDATA[
<codebase_search>
<query>[feature name] implementation main entry point</query>
</codebase_search>
]]></tool_use>
</step>
</initialization_phase>
<analysis_phases>
<phase name="code_analysis">
<title>Code Analysis</title>
<steps>
<step>
<action>Analyze code structure</action>
<details>
- Identify classes, functions, modules
- Extract method signatures, parameters
- Document return types, data structures
- Map inheritance and composition
</details>
</step>
<step>
<action>Extract APIs</action>
<details>
- REST endpoints
- GraphQL schemas
- WebSocket events
- RPC interfaces
</details>
</step>
<step>
<action>Document configuration</action>
<details>
- Environment variables
- Config files and schemas
- Feature flags
- Runtime parameters
</details>
</step>
</steps>
</phase>
<phase name="business_logic_analysis">
<title>Business Logic Extraction</title>
<steps>
<step>
<action>Map workflows</action>
<details>
- User journey
- Decision points and branching
- State transitions
- Roles and permissions
</details>
</step>
<step>
<action>Document business rules</action>
<details>
- Validation logic
- Formulas and algorithms
- Business process implementations
- Compliance requirements
</details>
</step>
<step>
<action>Identify use cases</action>
<details>
- Primary use cases
- Edge cases
- Error scenarios
- Performance factors
</details>
</step>
</steps>
</phase>
<phase name="integration_analysis">
<title>Dependency Analysis</title>
<steps>
<step>
<action>Map dependencies</action>
<details>
- Third-party libraries
- External services and APIs
- Database connections
- Message queues
</details>
</step>
<step>
<action>Document integration points</action>
<details>
- Incoming webhooks
- Outgoing API calls
- Event publishers/subscribers
- Shared data stores
</details>
</step>
<step>
<action>Analyze data flow</action>
<details>
- Data sources and formats
- Data transformations
- Output formats and destinations
- Data retention policies
</details>
</step>
</steps>
</phase>
<phase name="quality_analysis">
<title>Test Analysis</title>
<steps>
<step>
<action>Assess test coverage</action>
<details>
- Unit test coverage
- Integration test scenarios
- End-to-end test flows
- Performance test results
</details>
</step>
<step>
<action>Document error handling</action>
<details>
- Error types and codes
- Exception handling
- Fallback mechanisms
- Recovery procedures
</details>
</step>
<step>
<action>Identify quality metrics</action>
<details>
- Code complexity
- Performance benchmarks
- Security vulnerabilities
- Maintainability scores
</details>
</step>
</steps>
</phase>
<phase name="security_analysis">
<title>Security Analysis</title>
<steps>
<step>
<action>Document security</action>
<details>
- Auth mechanisms
- Access control
- Data encryption
- Security policies
</details>
</step>
<step>
<action>Identify vulnerabilities</action>
<details>
- Known security issues
- Attack vectors
- Mitigation
- Best practices
</details>
</step>
<step>
<action>Check compliance</action>
<details>
- Regulatory compliance (GDPR, etc.)
- Industry standards
- Audit trail requirements
- Data privacy
</details>
</step>
</steps>
</phase>
</analysis_phases>
<documentation_generation>
<note>Workflow branches here: review existing docs or generate new docs.</note>
<step number="1">
<title>Path 1: Review and Recommend</title>
<note>Used when a document is provided for review.</note>
<actions>
<action>Compare provided docs against codebase analysis.</action>
<action>Identify inaccuracies, omissions, and areas for improvement.</action>
<action>Categorize issues by severity (Critical, Major, Minor).</action>
<action>Formulate a structured recommendation in chat.</action>
<action>Do not write files.</action>
<action>Final output is only the recommendation.</action>
</actions>
</step>
<step number="2">
<title>Path 2: Generate Documentation</title>
<note>Used when new documentation is requested.</note>
<actions>
<action>Select a template from `2_documentation_patterns.xml`.</action>
<action>Structure the document with clear sections and examples.</action>
<action>Create `DOCS-TEMP-[feature].md` with generated content.</action>
<action>Apply tone and examples from `7_user_friendly_examples.xml`.</action>
</actions>
</step>
</documentation_generation>
<completion_criteria>
<criterion>Code paths analyzed</criterion>
<criterion>Business logic documented</criterion>
<criterion>Integration points mapped</criterion>
<criterion>Security addressed</criterion>
<criterion>Audience needs met</criterion>
<criterion>Metadata and links are complete</criterion>
</completion_criteria>
</extraction_workflow>

387
.roo/rules-docs-extractor/2_documentation_patterns.xml Normal file
View file

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

352
.roo/rules-docs-extractor/3_analysis_techniques.xml Normal file
View file

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

380
.roo/rules-docs-extractor/4_tool_usage_guide.xml Normal file
View file

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

932
.roo/rules-docs-extractor/5_complete_extraction_examples.xml Normal file
View file

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

283
.roo/rules-docs-extractor/6_communication_guidelines.xml Normal file
View file

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

218
.roo/rules-docs-extractor/7_user_friendly_examples.xml Normal file
View file

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

198
.roo/rules-integration-tester/1_workflow.xml Normal file
View file

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

303
.roo/rules-integration-tester/2_test_patterns.xml Normal file
View file

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

104
.roo/rules-integration-tester/3_best_practices.xml Normal file
View file

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

109
.roo/rules-integration-tester/4_common_mistakes.xml Normal file
View file

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

209
.roo/rules-integration-tester/5_test_environment.xml Normal file
View file

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

560
.roo/rules-issue-fixer/1_Workflow.xml Normal file
View file

@ -0,0 +1,560 @@
<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 issue view [issue-number] --repo [owner]/[repo] --json number,title,body,state,labels,assignees,milestone,createdAt,updatedAt,closedAt,author</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 issue view [issue number] --repo [owner]/[repo] --comments</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
- search_and_replace for systematic updates
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>
</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>

18
.roo/rules-issue-fixer/2_best_practices.xml Normal file
View file

@ -0,0 +1,18 @@
<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
- Wait for translation completion before proceeding to final testing
</best_practices>

21
.roo/rules-issue-fixer/3_common_patterns.xml Normal file
View file

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

221
.roo/rules-issue-fixer/4_github_cli_usage.xml Normal file
View file

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

52
.roo/rules-issue-fixer/5_pull_request_workflow.xml Normal file
View file

@ -0,0 +1,52 @@
<pull_request_workflow>
<preparation>
1. Ensure all changes are committed with proper message format
2. Push to appropriate branch (fork or direct)
3. Prepare comprehensive PR description
4. Get user approval before creating PR
5. Extract owner and repo from the provided GitHub URL
</preparation>
<pr_title_format>
- Bug fixes: "fix: [description] (#[issue-number])"
- Features: "feat: [description] (#[issue-number])"
- Follow conventional commit format
</pr_title_format>
<pr_description_template>
Must include:
- Link to issue (Fixes #[number])
- Detailed description of changes
- Testing performed
- Verification of acceptance criteria
- Checklist items
- Screenshots/demos if applicable
</pr_description_template>
<creating_pr_with_cli>
Use GitHub CLI to create the pull request:
<execute_command>
<command>gh pr create --repo [owner]/[repo] --base main --title "[title]" --body "[description]" --maintainer-can-modify</command>
</execute_command>
If working from a fork, ensure you've forked first:
<execute_command>
<command>gh repo fork [owner]/[repo] --clone</command>
</execute_command>
The gh CLI automatically handles fork workflows.
</creating_pr_with_cli>
<after_creation>
1. Comment on original issue with PR link:
<execute_command>
<command>gh issue comment [issue-number] --repo [owner]/[repo] --body "PR #[pr-number] has been created to address this issue"</command>
</execute_command>
2. Inform user of successful creation
3. Provide next steps and tracking info
4. Monitor PR checks:
<execute_command>
<command>gh pr checks [pr-number] --repo [owner]/[repo] --watch</command>
</execute_command>
</after_creation>
</pull_request_workflow>

10
.roo/rules-issue-fixer/6_testing_guidelines.xml Normal file
View file

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

8
.roo/rules-issue-fixer/7_communication_style.xml Normal file
View file

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

16
.roo/rules-issue-fixer/8_github_communication_guidelines.xml Normal file
View file

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

205
.roo/rules-issue-fixer/9_pr_template.xml Normal file
View file

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

338
.roo/rules-issue-writer/1_workflow.xml Normal file
View file

@ -0,0 +1,338 @@
<workflow>
<step number="1">
<name>Determine Issue Type</name>
<instructions>
Use ask_followup_question to determine if the user wants to create:
<ask_followup_question>
<question>What type of issue would you like to create?</question>
<follow_up>
<suggest>Bug Report - Report a problem with existing functionality</suggest>
<suggest>Detailed Feature Proposal - Propose a new feature or enhancement</suggest>
</follow_up>
</ask_followup_question>
</instructions>
</step>
<step number="2">
<name>Gather Initial Information</name>
<instructions>
Based on the user's initial prompt or request, extract key information.
If the user hasn't provided enough detail, use ask_followup_question to gather
the required fields from the appropriate template.
For Bug Reports, ensure you have:
- App version (ask user to check in VSCode extension panel if unknown)
- API provider being used
- Model being used
- Clear steps to reproduce
- What happened vs what was expected
- Any error messages or logs
For Feature Requests, ensure you have:
- Specific problem description with impact (who is affected, when it happens, current vs expected behavior, impact)
- Additional context if available (mockups, screenshots, links)
IMPORTANT: Do NOT ask for solution design, acceptance criteria, or technical details
unless the user explicitly states they want to contribute the implementation.
Use multiple ask_followup_question calls if needed to gather all information.
Be specific in your questions based on what's missing.
</instructions>
</step>
<step number="3">
<name>Search GitHub Discussions</name>
<instructions>
Search GitHub Discussions for related feature requests or bug reports:
1. Use the GitHub web interface or API to search discussions in:
https://github.com/RooCodeInc/Roo-Code/discussions/categories/feature-requests
2. Search for keywords related to the user's issue:
- For feature requests: Look for similar feature ideas or requests
- For bug reports: Look for users reporting similar problems
3. Document any related discussions found:
- Discussion number and title
- Link to the discussion
- Whether it should be marked as "Closes #[number]" (if this issue fully addresses it)
- Or "Related to #[number]" (if partially related)
4. If multiple related discussions exist, list them all for inclusion in the issue
</instructions>
</step>
<step number="4">
<name>Determine if User Wants to Contribute</name>
<instructions>
Before exploring the codebase, determine if the user wants to contribute the implementation:
<ask_followup_question>
<question>Are you interested in implementing this feature yourself, or are you just reporting the problem for the Roo team to solve?</question>
<follow_up>
<suggest>Just reporting the problem - the Roo team can design the solution</suggest>
<suggest>I want to contribute and implement this feature myself</suggest>
<suggest>I'm not sure yet, but I'd like to provide technical analysis</suggest>
</follow_up>
</ask_followup_question>
Based on their response:
- If just reporting: Skip to step 6 (Draft Issue - Problem Only)
- If contributing: Continue to step 5 (Explore Codebase)
- If providing analysis: Continue to step 5 but make technical sections optional
</instructions>
</step>
<step number="5">
<name>Explore Codebase for Contributors</name>
<instructions>
ONLY perform this step if the user wants to contribute or provide technical analysis.
Use codebase_search FIRST to understand the relevant parts of the codebase:
For Bug Reports:
- Search for the feature or functionality that's broken
- Find error handling code related to the issue
- Look for recent changes that might have caused the bug
For Feature Requests:
- Search for existing similar functionality
- Identify files that would need modification
- Find related configuration or settings
- Look for potential integration points
Example searches:
- "task execution parallel" for parallel task feature
- "button dark theme styling" for UI issues
- "error handling API response" for API-related bugs
After codebase_search, use:
- list_code_definition_names on relevant directories
- read_file on specific files to understand implementation
- search_files for specific error messages or patterns
Formulate an independent technical plan to solve the problem.
Document all relevant findings including:
- File paths and line numbers
- Current implementation details
- Your proposed implementation plan
- Related code that might be affected
Then gather additional technical details:
- Ask for proposed solution approach
- Request acceptance criteria in Given/When/Then format
- Discuss technical considerations and trade-offs
</instructions>
</step>
<step number="6">
<name>Draft Issue Content</name>
<instructions>
Create the issue body based on whether the user is just reporting or contributing.
For Bug Reports, format is the same regardless of contribution intent:
```
## App Version
[version from user]
## API Provider
[provider from dropdown list]
## Model Used
[exact model name]
## 🔁 Steps to Reproduce
1. [First step with specific details]
2. [Second step with exact actions]
3. [Continue numbering all steps]
Include:
- Exact button clicks or menu selections
- Specific input text or prompts used
- File names and paths involved
- Any settings or configuration
## 💥 Outcome Summary
Expected: [what should have happened]
Actual: [what actually happened]
## 📄 Relevant Logs or Errors
```[language]
[paste any error messages or logs]
```
[If user is contributing, add:]
## Technical Analysis
Based on my investigation:
- The issue appears to be in [file:line]
- Related code: [brief description with file references]
- Possible cause: [technical explanation]
- **Proposed Fix:** [Detail the fix from your implementation plan.]
```
For Feature Requests - PROBLEM REPORTERS (not contributing):
```
## What specific problem does this solve?
[Detailed problem description following the template guidelines]
**Who is affected:** [user groups]
**When this happens:** [specific scenarios]
**Current behavior:** [what happens now]
**Expected behavior:** [what should happen]
**Impact:** [time wasted, errors, productivity loss]
## Additional context
[Any mockups, screenshots, links, or other supporting information]
## Related Discussions
[If any related discussions were found, list them here]
- Closes #[discussion number] - [discussion title]
- Related to #[discussion number] - [discussion title]
```
For Feature Requests - CONTRIBUTORS (implementing the feature):
```
## What specific problem does this solve?
[Detailed problem description following the template guidelines]
**Who is affected:** [user groups]
**When this happens:** [specific scenarios]
**Current behavior:** [what happens now]
**Expected behavior:** [what should happen]
**Impact:** [time wasted, errors, productivity loss]
## Additional context
[Any mockups, screenshots, links, or other supporting information]
---
## 🛠️ Contributing & Technical Analysis
✅ **I'm interested in implementing this feature**
✅ **I understand this needs approval before implementation begins**
## How should this be solved?
[Based on your analysis, describe the proposed solution]
**What will change:**
- [Specific change 1]
- [Specific change 2]
**User interaction:**
- [How users will use this feature]
- [What they'll see in the UI]
## Acceptance Criteria
```
Given [context]
When [action]
Then [result]
And [additional expectation]
But [what should not happen]
```
[Add multiple scenarios as needed]
## Technical Considerations
**Implementation approach:**
- Key files to modify: [list with paths]
- Current architecture: [brief description]
- Integration points: [where this fits]
- Similar patterns in codebase: [examples]
**Performance implications:**
[Any performance considerations]
**Compatibility concerns:**
[Any compatibility issues]
## Trade-offs and Risks
**Alternatives considered:**
- [Alternative 1]: [Why not chosen]
- [Alternative 2]: [Why not chosen]
**Potential risks:**
- [Risk 1]: [Mitigation strategy]
- [Risk 2]: [Mitigation strategy]
**Breaking changes:**
[Any breaking changes or migration needs]
## Related Discussions
[If any related discussions were found, list them here]
- Closes #[discussion number] - [discussion title]
- Related to #[discussion number] - [discussion title]
```
</instructions>
</step>
<step number="7">
<name>Review and Confirm with User</name>
<instructions>
Present the complete drafted issue to the user for review:
<ask_followup_question>
<question>I've prepared the following GitHub issue. Please review it carefully:
[Show the complete formatted issue content]
Would you like me to create this issue, or would you like to make any changes?</question>
<follow_up>
<suggest>Yes, create this issue in RooCodeInc/Roo-Code</suggest>
<suggest>Modify the problem description</suggest>
<suggest>Add more technical details</suggest>
<suggest>Change the title to: [let me specify]</suggest>
</follow_up>
</ask_followup_question>
If user requests changes, make them and show the updated version for confirmation.
</instructions>
</step>
<step number="8">
<name>Create GitHub Issue</name>
<instructions>
Once user confirms, create the issue using the GitHub CLI:
First, save the issue body to a temporary file:
<execute_command>
<command>cat > /tmp/issue_body.md << 'EOF'
[The complete formatted issue body from step 6]
EOF</command>
</execute_command>
Then create the issue:
<execute_command>
<command>gh issue create --repo RooCodeInc/Roo-Code --title "[Create a descriptive title based on the issue content]" --body-file /tmp/issue_body.md --label "bug"</command>
</execute_command>
For feature requests, use labels "proposal,enhancement":
<execute_command>
<command>gh issue create --repo RooCodeInc/Roo-Code --title "[Create a descriptive title based on the issue content]" --body-file /tmp/issue_body.md --label "proposal" --label "enhancement"</command>
</execute_command>
The command will return the issue URL. Inform the user of the created issue number and URL.
Clean up the temporary file:
<execute_command>
<command>rm /tmp/issue_body.md</command>
</execute_command>
</instructions>
</step>
</workflow>

219
.roo/rules-issue-writer/2_github_issue_templates.xml Normal file
View file

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

38
.roo/rules-issue-writer/3_best_practices.xml Normal file
View file

@ -0,0 +1,38 @@
<best_practices>
<problem_reporting_focus>
- Focus on helping users describe problems clearly, not solutions
- The Roo team will design solutions unless the user explicitly wants to contribute
- Don't push users to provide technical details they may not have
- Make it easy for non-technical users to report issues effectively
</problem_reporting_focus>
<general_practices>
- Always search for existing similar issues before creating a new one
- Search GitHub Discussions (especially feature-requests category) for related topics
- Include specific version numbers and environment details
- Use code blocks with syntax highlighting for code snippets
- Make titles descriptive but concise (e.g., "Dark theme: Submit button invisible due to white-on-grey text")
- For bugs, always test if the issue is reproducible
- Include screenshots or mockups when relevant (ask user to provide)
- Link to related issues or PRs if found during exploration
- Add "Closes #[number]" for discussions that would be fully addressed by the issue
- Add "Related to #[number]" for partially related discussions
</general_practices>
<contributor_specific>
- Only explore codebase if user wants to contribute
- Reference specific files and line numbers from codebase exploration
- Ensure technical proposals align with project architecture
- Include implementation steps and technical analysis
- Provide clear acceptance criteria in Given/When/Then format
- Consider trade-offs and alternative approaches
</contributor_specific>
<communication_guidelines>
- Be supportive and encouraging to problem reporters
- Don't overwhelm users with technical questions upfront
- Clearly indicate when technical sections are optional
- Guide contributors through the additional requirements
- Make the "submit now" option clear for problem reporters
</communication_guidelines>
</best_practices>

30
.roo/rules-issue-writer/4_common_mistakes_to_avoid.xml Normal file
View file

@ -0,0 +1,30 @@
<common_mistakes_to_avoid>
<problem_reporting_mistakes>
- Vague descriptions like "doesn't work" or "broken"
- Missing reproduction steps for bugs
- Feature requests without clear problem statements
- Not explaining the impact on users
- Forgetting to specify when/how the problem occurs
- Using wrong labels or no labels
- Titles that don't summarize the issue
- Not checking for duplicates
</problem_reporting_mistakes>
<workflow_mistakes>
- Asking for technical details from non-contributing users
- Exploring codebase before confirming user wants to contribute
- Requiring acceptance criteria from problem reporters
- Making the process too complex for simple problem reports
- Not clearly indicating the "submit now" option
- Overwhelming users with contributor requirements upfront
</workflow_mistakes>
<contributor_mistakes>
- Starting implementation before approval
- Not providing detailed technical analysis when contributing
- Missing acceptance criteria for contributed features
- Forgetting to include technical context from code exploration
- Not considering trade-offs and alternatives
- Proposing solutions without understanding current architecture
</contributor_mistakes>
</common_mistakes_to_avoid>

273
.roo/rules-issue-writer/5_github_cli_usage.xml Normal file
View file

@ -0,0 +1,273 @@
<github_cli_usage>
<overview>
The GitHub CLI (gh) provides comprehensive tools for interacting with GitHub.
Here's when and how to use each command in the issue creation workflow.
Note: Issue body formatting should follow the templates defined in
2_github_issue_templates.xml, with different formats for problem reporters
vs contributors.
</overview>
<pre_creation_commands>
<command name="gh issue list">
<when_to_use>
ALWAYS use this FIRST before creating any issue to check for duplicates.
Search for keywords from the user's problem description.
</when_to_use>
<example>
<execute_command>
<command>gh issue list --repo RooCodeInc/Roo-Code --search "dark theme button visibility" --state all --limit 20</command>
</execute_command>
</example>
<options>
--search: Search query for issue titles and bodies
--state: all, open, or closed
--label: Filter by specific labels
--limit: Number of results to show
--json: Get structured JSON output
</options>
</command>
<command name="gh search issues">
<when_to_use>
Use for more advanced searches across issues and pull requests.
Supports GitHub's advanced search syntax.
</when_to_use>
<example>
<execute_command>
<command>gh search issues --repo RooCodeInc/Roo-Code "dark theme button" --limit 10</command>
</execute_command>
</example>
</command>
<command name="gh issue view">
<when_to_use>
Use when you find a potentially related issue and need full details.
Check if the user's issue is already reported or related.
</when_to_use>
<example>
<execute_command>
<command>gh issue view 123 --repo RooCodeInc/Roo-Code --comments</command>
</execute_command>
</example>
<options>
--comments: Include issue comments
--json: Get structured data
--web: Open in browser
</options>
</command>
</pre_creation_commands>
<contributor_only_commands>
<note>
These commands should ONLY be used if the user has indicated they want to
contribute the implementation. Skip these for problem reporters.
</note>
<command name="gh repo view">
<when_to_use>
Get repository information and recent activity.
</when_to_use>
<example>
<execute_command>
<command>gh repo view RooCodeInc/Roo-Code --json defaultBranchRef,description,updatedAt</command>
</execute_command>
</example>
</command>
<command name="gh search prs">
<when_to_use>
Check recent PRs that might be related to the issue.
Look for PRs that modified relevant code.
</when_to_use>
<example>
<execute_command>
<command>gh search prs --repo RooCodeInc/Roo-Code "dark theme" --limit 10 --state all</command>
</execute_command>
</example>
</command>
<command name="git log">
<when_to_use>
For bug reports from contributors, check recent commits that might have introduced the issue.
Use after cloning the repository locally.
</when_to_use>
<example>
<execute_command>
<command>git log --oneline --grep="theme" -n 20</command>
</execute_command>
</example>
</command>
</contributor_only_commands>
<issue_creation_command>
<command name="gh issue create">
<when_to_use>
Only use after:
1. Confirming no duplicates exist
2. Gathering all required information
3. Determining if user is contributing or just reporting
4. Getting user confirmation
</when_to_use>
<bug_report_example>
<execute_command>
<command>gh issue create --repo RooCodeInc/Roo-Code --title "[Descriptive title of the bug]" --body-file /tmp/issue_body.md --label "bug"</command>
</execute_command>
</bug_report_example>
<feature_request_example>
<execute_command>
<command>gh issue create --repo RooCodeInc/Roo-Code --title "[Problem-focused title]" --body-file /tmp/issue_body.md --label "proposal" --label "enhancement"</command>
</execute_command>
</feature_request_example>
<options>
--title: Issue title (required)
--body: Issue body text
--body-file: Read body from file
--label: Add labels (can use multiple times)
--assignee: Assign to user
--project: Add to project
--web: Open in browser to create
</options>
</command>
</issue_creation_command>
<post_creation_commands>
<command name="gh issue comment">
<when_to_use>
ONLY use if user wants to add additional information after creation.
</when_to_use>
<example>
<execute_command>
<command>gh issue comment 456 --repo RooCodeInc/Roo-Code --body "Additional context or comments."</command>
</execute_command>
</example>
</command>
<command name="gh issue edit">
<when_to_use>
Use if user realizes they need to update the issue after creation.
Can update title, body, or labels.
</when_to_use>
<example>
<execute_command>
<command>gh issue edit 456 --repo RooCodeInc/Roo-Code --title "[Updated title]" --body "[Updated body]"</command>
</execute_command>
</example>
</command>
</post_creation_commands>
<workflow_integration>
<step_1_integration>
After user selects issue type, immediately search for related issues:
1. Use `gh issue list --search` with keywords from their description
2. Show any similar issues found
3. Ask if they want to continue or comment on existing issue
</step_1_integration>
<step_3_integration>
When searching GitHub Discussions:
1. Note that GitHub CLI doesn't currently have full discussions support
2. Use web search or instruct user to manually search discussions at:
https://github.com/RooCodeInc/Roo-Code/discussions/categories/feature-requests
3. Ask user to provide any related discussion numbers they find
4. Include these in the "Related Discussions" section of the issue
</step_3_integration>
<step_4_integration>
Decision point for contribution:
1. Ask user if they want to contribute implementation
2. If yes: Use contributor commands for codebase investigation
3. If no: Skip directly to creating a problem-focused issue
4. This saves time for problem reporters
</step_4_integration>
<step_5_integration>
During codebase exploration (CONTRIBUTORS ONLY):
1. Clone repo locally if needed: `gh repo clone RooCodeInc/Roo-Code`
2. Use `git log` to find recent changes to affected files
3. Use `gh search prs` for related pull requests
4. Include findings in the technical context section
</step_5_integration>
<step_6_integration>
When creating the issue:
1. Format differently based on contributor vs problem reporter
2. Problem reporters: Simple problem description + context
3. Contributors: Full template with technical sections
4. Save formatted body to temporary file
5. Use `gh issue create` with appropriate labels
6. Capture the returned issue URL
7. Show user the created issue URL
</step_6_integration>
</workflow_integration>
<best_practices>
<practice name="file_handling">
When creating issues with long bodies:
1. Save to temporary file: `cat > /tmp/issue_body.md << 'EOF'`
2. Use --body-file flag with gh issue create
3. Clean up after: `rm /tmp/issue_body.md`
</practice>
<practice name="search_efficiency">
Use specific search terms:
- Include error messages in quotes
- Use label filters when appropriate
- Limit results to avoid overwhelming output
</practice>
<practice name="json_output">
Use --json flag for structured data when needed:
- Easier to parse programmatically
- Consistent format across commands
- Example: `gh issue list --json number,title,state`
</practice>
</best_practices>
<error_handling>
<duplicate_found>
If search finds exact duplicate:
- Show the existing issue to user using `gh issue view`
- Ask if they want to add a comment instead
- Use `gh issue comment` if they agree
</duplicate_found>
<creation_failed>
If `gh issue create` fails:
- Check error message (auth, permissions, network)
- Ensure gh is authenticated: `gh auth status`
- Save the drafted issue content for user
- Suggest using --web flag to create in browser
</creation_failed>
<authentication>
Ensure GitHub CLI is authenticated:
- Check status: `gh auth status`
- Login if needed: `gh auth login`
- Select appropriate scopes for issue creation
</authentication>
</error_handling>
<command_reference>
<issues>
gh issue create - Create new issue
gh issue list - List and search issues
gh issue view - View issue details
gh issue comment - Add comment to issue
gh issue edit - Edit existing issue
gh issue close - Close an issue
gh issue reopen - Reopen closed issue
</issues>
<search>
gh search issues - Search issues and PRs
gh search prs - Search pull requests
gh search repos - Search repositories
</search>
<repository>
gh repo view - View repository info
gh repo clone - Clone repository
</repository>
</command_reference>
</github_cli_usage>

142
.roo/rules-mode-writer/1_mode_creation_workflow.xml Normal file
View file

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

220
.roo/rules-mode-writer/2_xml_structuring_best_practices.xml Normal file
View file

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

261
.roo/rules-mode-writer/3_mode_configuration_patterns.xml Normal file
View file

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

367
.roo/rules-mode-writer/4_instruction_file_templates.xml Normal file
View file

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

96
.roo/rules-mode-writer/5_complete_mode_examples.xml Normal file
View file

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

207
.roo/rules-mode-writer/6_mode_testing_validation.xml Normal file
View file

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

75
.roo/rules-pr-fixer/1_workflow.xml Normal file
View file

@ -0,0 +1,75 @@
<workflow_instructions>
<mode_overview>
This mode is designed to help resolve issues in existing pull requests. It analyzes PR feedback from GitHub, checks for failing tests and merge conflicts, gathers context, and guides the user toward a solution. All GitHub operations are performed using the GitHub CLI.
</mode_overview>
<initialization_steps>
<step number="1">
<action>Understand the user's request</action>
<details>
Parse the user's input to identify the pull request URL or number. Extract the repository owner and name.
</details>
</step>
<step number="2">
<action>Gather PR context</action>
<tools>
<tool>gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles,comments,reviews</tool>
<tool>gh pr checks [PR_NUMBER] --repo [owner]/[repo] - Check workflow status for failing tests</tool>
<tool>gh pr view [PR_NUMBER] --repo [owner]/[repo] --json mergeable,mergeStateStatus - Check for merge conflicts</tool>
</tools>
</step>
</initialization_steps>
<main_workflow>
<phase name="analysis">
<description>Analyze the gathered information to identify the core problems.</description>
<steps>
<step>Summarize review comments and requested changes from gh pr view output.</step>
<step>Identify the root cause of failing tests by analyzing workflow logs with 'gh run view'.</step>
<step>Determine if merge conflicts exist from mergeable status.</step>
</steps>
</phase>
<phase name="synthesis">
<description>Synthesize the findings and present them to the user.</description>
<steps>
<step>Present a summary of the issues found (reviews, failing tests, conflicts).</step>
<step>Use ask_followup_question to ask the user how they want to proceed with fixing the issues.</step>
</steps>
</phase>
<phase name="implementation">
<description>Execute the user's chosen course of action.</description>
<steps>
<step>Check out the PR branch locally using 'gh pr checkout [PR_NUMBER] --repo [owner]/[repo] --force'.</step>
<step>Determine if the PR is from a fork by checking 'gh pr view [PR_NUMBER] --repo [owner]/[repo] --json isCrossRepository'.</step>
<step>Apply code changes based on review feedback using file editing tools.</step>
<step>Fix failing tests by modifying test files or source code as needed.</step>
<step>For conflict resolution: Use GIT_EDITOR=true for non-interactive rebases, then resolve conflicts via file editing.</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>

83
.roo/rules-pr-fixer/2_best_practices.xml Normal file
View file

@ -0,0 +1,83 @@
<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>How to correctly escape conflict markers when using apply_diff.</rule>
<template>
When removing merge conflict markers from files, you must **escape** them in your `SEARCH` section by prepending a backslash (`\`) at the beginning of the line. This prevents the system from mistaking them for actual diff syntax.
**Correct Format Example:**
```
<<<<<<< SEARCH
content before
\<<<<<<< HEAD <-- Note the backslash here
content after
=======
replacement content
>>>>>>> REPLACE
```
Without escaping, the system confuses your content with real diff markers.
You may include multiple diff blocks in a single request, but if any of the following markers appear within your `SEARCH` or `REPLACE` content, they must be escaped:
```
\<<<<<<< SEARCH
\=======
\>>>>>>> REPLACE
```
Only these three need to be escaped when used in content.
</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>

142
.roo/rules-pr-fixer/3_common_patterns.xml Normal file
View file

@ -0,0 +1,142 @@
<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>Fetch latest main branch</comment>
<command tool="git">git fetch origin main</command>
<comment>Check if rebase would create conflicts</comment>
<command tool="git">git rebase --dry-run origin/main</command>
</template>
</pattern>
<pattern name="non_interactive_rebase">
<usage>Rebase operations using GIT_EDITOR to prevent interactive prompts.</usage>
<template>
<command tool="git">git checkout <pr_branch></command>
<command tool="git">GIT_EDITOR=true git rebase main</command>
<comment>If conflicts occur, resolve them manually then use 'git rebase --continue'</comment>
<command tool="git">git push --force-with-lease <remote> <pr_branch></command>
</template>
</pattern>
<pattern name="conflict_status_check">
<usage>Check current conflict status without interactive input.</usage>
<template>
<command tool="git">git status --porcelain</command>
<command tool="git">git diff --name-only --diff-filter=U</command>
<comment>List files with unresolved conflicts</comment>
<command tool="git">git ls-files --unmerged</command>
</template>
</pattern>
<pattern name="checking_out_pr">
<usage>Check out a pull request branch locally.</usage>
<template>
<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>

136
.roo/rules-pr-fixer/4_tool_usage.xml Normal file
View file

@ -0,0 +1,136 @@
<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>Use 'GIT_EDITOR=true git rebase main' to start rebase</step>
<step>If conflicts occur, edit files to resolve them</step>
<step>Use 'git add .' and 'git rebase --continue' to proceed</step>
</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_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>

203
.roo/rules-pr-fixer/5_examples.xml Normal file
View file

@ -0,0 +1,203 @@
<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>
</complete_examples>

202
.roo/rules-pr-reviewer/1_orchestrator_workflow.xml Normal file
View file

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

208
.roo/rules-pr-reviewer/2_critical_review_guidelines.xml Normal file
View file

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

238
.roo/rules-pr-reviewer/3_delegation_patterns.xml Normal file
View file

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

224
.roo/rules-pr-reviewer/4_github_operations.xml Normal file
View file

@ -0,0 +1,224 @@
<github_operations>
<overview>
Guidelines for handling GitHub operations using the GitHub CLI (gh).
This mode exclusively uses command-line operations for all GitHub interactions.
</overview>
<prerequisites>
<requirement name="github_cli">
<description>GitHub CLI must be installed and authenticated</description>
<check_command>gh auth status</check_command>
<install_url>https://cli.github.com/</install_url>
</requirement>
<requirement name="authentication">
<description>User must be authenticated with appropriate permissions</description>
<setup_command>gh auth login</setup_command>
</requirement>
</prerequisites>
<operation_patterns>
<operation name="fetch_pr_details">
<description>Fetch comprehensive PR metadata</description>
<command>gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles</command>
<output_format>JSON</output_format>
<save_to>.roo/temp/pr-[PR_NUMBER]/pr-metadata.json</save_to>
</operation>
<operation name="fetch_pr_diff">
<description>Get the full diff of PR changes</description>
<command>gh pr diff [PR_NUMBER] --repo [owner]/[repo]</command>
<save_to>.roo/temp/pr-[PR_NUMBER]/pr.diff</save_to>
</operation>
<operation name="fetch_pr_files">
<description>List all files changed in the PR</description>
<command>gh pr view [PR_NUMBER] --repo [owner]/[repo] --json files --jq '.files[].path'</command>
<output_format>Line-separated file paths</output_format>
</operation>
<operation name="fetch_comments">
<description>Get all comments on the PR</description>
<command>gh pr view [PR_NUMBER] --repo [owner]/[repo] --json comments --jq '.comments'</command>
<output_format>JSON array of comments</output_format>
</operation>
<operation name="fetch_reviews">
<description>Get all reviews on the PR</description>
<command>gh pr view [PR_NUMBER] --repo [owner]/[repo] --json reviews --jq '.reviews'</command>
<output_format>JSON array of reviews</output_format>
</operation>
<operation name="checkout_pr">
<description>Check out PR branch locally for analysis</description>
<command>gh pr checkout [PR_NUMBER] --repo [owner]/[repo]</command>
<note>This switches the current branch to the PR branch</note>
</operation>
<operation name="post_comment">
<description>Post a comment on the PR</description>
<command>gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body-file [file_path]</command>
<alternative>gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body "[comment_text]"</alternative>
</operation>
<operation name="create_review">
<description>Create a PR review with comments</description>
<command>gh pr review [PR_NUMBER] --repo [owner]/[repo] --comment --body-file [review_file]</command>
<options>
<option>--approve: Approve the PR</option>
<option>--request-changes: Request changes</option>
<option>--comment: Just comment without approval/rejection</option>
</options>
</operation>
<operation name="fetch_issue">
<description>Get issue details (for linked issues)</description>
<command>gh issue view [issue_number] --repo [owner]/[repo] --json number,title,body,author,state</command>
<output_format>JSON</output_format>
</operation>
</operation_patterns>
<error_handling>
<scenario name="authentication_failure">
<detection>
Error contains "authentication" or "not logged in"
</detection>
<action>
1. Inform user about auth issue
2. Suggest running: gh auth login
3. Check status with: gh auth status
</action>
</scenario>
<scenario name="api_rate_limit">
<detection>
Error contains "rate limit" or "API rate limit exceeded"
</detection>
<action>
1. Wait 30-60 seconds before retry
2. Inform user about rate limiting
3. Consider reducing API calls
</action>
</scenario>
<scenario name="pr_not_found">
<detection>
Error contains "not found" or "could not find pull request"
</detection>
<action>
1. Verify PR number and repository format
2. Check if repository is accessible
3. Ensure correct owner/repo format
</action>
</scenario>
<scenario name="permission_denied">
<detection>
Error contains "permission denied" or "403"
</detection>
<action>
1. Check repository permissions
2. Verify authentication scope
3. May need to re-authenticate with proper scopes
</action>
</scenario>
</error_handling>
<data_handling>
<principle name="save_everything">
<description>Always save command outputs to temp files</description>
<reason>Preserve data for analysis and recovery</reason>
</principle>
<principle name="parse_json_safely">
<description>Use jq for JSON parsing when available</description>
<example>
gh pr view --json files --jq '.files[].path'
</example>
</principle>
<principle name="handle_large_prs">
<description>For PRs with many files, save outputs to files first</description>
<threshold>More than 50 files</threshold>
<approach>Save to file, then process in chunks</approach>
</principle>
<principle name="validate_json">
<description>Always validate JSON before parsing</description>
<command>jq empty < file.json || echo "Invalid JSON"</command>
</principle>
</data_handling>
<cli_command_reference>
<command_group name="pr_info">
<base_command>gh pr view [number]</base_command>
<options>
<option>--repo [owner]/[repo]: Specify repository</option>
<option>--json [fields]: Get JSON output</option>
<option>--jq [expression]: Parse JSON with jq</option>
</options>
<json_fields>
number, title, author, state, body, url,
headRefName, baseRefName, files, additions,
deletions, changedFiles, comments, reviews,
isDraft, mergeable, mergeStateStatus
</json_fields>
</command_group>
<command_group name="pr_interaction">
<commands>
<command>gh pr checkout [number]: Check out PR locally</command>
<command>gh pr diff [number]: View PR diff</command>
<command>gh pr comment [number] --body "[text]": Add comment</command>
<command>gh pr review [number]: Create review</command>
<command>gh pr close [number]: Close PR</command>
<command>gh pr reopen [number]: Reopen PR</command>
</commands>
</command_group>
<command_group name="issue_info">
<base_command>gh issue view [number]</base_command>
<json_fields>
number, title, body, author, state,
labels, assignees, milestone, comments
</json_fields>
</command_group>
<command_group name="repo_info">
<commands>
<command>gh repo view --json [fields]: Get repo info</command>
<command>gh repo clone [owner]/[repo]: Clone repository</command>
</commands>
</command_group>
</cli_command_reference>
<best_practices>
<practice>Always specify --repo to avoid ambiguity</practice>
<practice>Use --json for structured data that needs parsing</practice>
<practice>Save command outputs to temp files for reliability</practice>
<practice>Check gh auth status before starting operations</practice>
<practice>Handle both personal repos and organization repos</practice>
<practice>Use meaningful file names when saving outputs</practice>
<practice>Include error handling for all commands</practice>
<practice>Document the expected format of saved files</practice>
</best_practices>
<example_workflows>
<workflow name="complete_pr_fetch">
<description>Fetch all PR data for analysis</description>
<steps>
<step>gh pr view 123 --repo owner/repo --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles > .roo/temp/pr-123/metadata.json</step>
<step>gh pr view 123 --repo owner/repo --json comments > .roo/temp/pr-123/comments.json</step>
<step>gh pr view 123 --repo owner/repo --json reviews > .roo/temp/pr-123/reviews.json</step>
<step>gh pr diff 123 --repo owner/repo > .roo/temp/pr-123/pr.diff</step>
</steps>
</workflow>
<workflow name="post_review">
<description>Post a comprehensive review</description>
<steps>
<step>Create review content in .roo/temp/pr-123/review.md</step>
<step>gh pr review 123 --repo owner/repo --comment --body-file .roo/temp/pr-123/review.md</step>
</steps>
</workflow>
</example_workflows>
</github_operations>

356
.roo/rules-pr-reviewer/5_context_management.xml Normal file
View file

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

106
.roo/rules-translate/001-general-rules.md Normal file
View file

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

14
.roo/rules-translate/instructions-de.md Normal file
View file

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

278
.roo/rules-translate/instructions-zh-cn.md Normal file
View file

@ -0,0 +1,278 @@
# 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 服务器 | 技术组件 |
| Human Relay | 人工辅助模式 | 人工中继 | 功能描述清晰 |
| 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. **品牌/产品名称**
- 保留英文品牌名
- 技术术语保持一致性
- 保留英文专有名词：如"AWS 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. 特殊格式(如变量、代码)是否正确保留？

18
.roo/rules-translate/instructions-zh-tw.md Normal file
View file

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

23
.roo/rules/rules.md Normal file
View file

@ -0,0 +1,23 @@
# 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 `describe`, `test`, `it`, etc functions are defined by default in `tsconfig.json` and therefore don't need to be imported
- Tests must be run from the same directory as the `package.json` file that specifies `vitest` in `devDependencies`
- Run tests with: `npx vitest <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 path/to/test-file` (don't include `src/` in path)
- UI tests: `cd webview-ui && npx vitest src/path/to/test-file`
- Example: For `src/tests/user.test.ts`, run `cd src && npx vitest tests/user.test.ts` NOT `npx vitest 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

1
.rooignore Normal file
View file

@ -0,0 +1 @@
.env

201
.roomodes Normal file
View file

@ -0,0 +1,201 @@
customModes:
- slug: mode-writer
name: ✍️ Mode Writer
roleDefinition: |-
You are Roo, a mode creation specialist focused on designing and implementing custom modes for the Roo-Code project. Your expertise includes:
- Understanding the mode system architecture and configuration
- Creating well-structured mode definitions with clear roles and responsibilities
- Writing comprehensive XML-based special instructions using best practices
- Ensuring modes have appropriate tool group permissions
- Crafting clear whenToUse descriptions for the Orchestrator
- Following XML structuring best practices for clarity and parseability
You help users create new modes by:
- Gathering requirements about the mode's purpose and workflow
- Defining appropriate roleDefinition and whenToUse descriptions
- Selecting the right tool groups and file restrictions
- Creating detailed XML instruction files in the .roo folder
- Ensuring instructions are well-organized with proper XML tags
- Following established patterns from existing modes
whenToUse: Use this mode when you need to create a new custom mode.
description: Create and implement custom modes.
groups:
- read
- - edit
- fileRegex: (\.roomodes$|\.roo/.*\.xml$|\.yaml$)
description: Mode configuration files and XML instructions
- command
- mcp
source: project
- slug: test
name: 🧪 Test
roleDefinition: |-
You are Roo, a Vitest testing specialist with deep expertise in: - Writing and maintaining Vitest test suites - Test-driven development (TDD) practices - Mocking and stubbing with Vitest - Integration testing strategies - TypeScript testing patterns - Code coverage analysis - Test performance optimization
Your focus is on maintaining high test quality and coverage across the codebase, working primarily with: - Test files in __tests__ directories - Mock implementations in __mocks__ - Test utilities and helpers - Vitest configuration and setup
You ensure tests are: - Well-structured and maintainable - Following Vitest best practices - Properly typed with TypeScript - Providing meaningful coverage - Using appropriate mocking strategies
whenToUse: Use this mode when you need to write, modify, or maintain tests for the codebase.
description: Write, modify, and maintain tests.
groups:
- read
- browser
- command
- - edit
- fileRegex: (__tests__/.*|__mocks__/.*|\.test\.(ts|tsx|js|jsx)$|\.spec\.(ts|tsx|js|jsx)$|/test/.*|vitest\.config\.(js|ts)$|vitest\.setup\.(js|ts)$)
description: Test files, mocks, and Vitest configuration
customInstructions: |-
When writing tests:
- Always use describe/it blocks for clear test organization
- Include meaningful test descriptions
- Use beforeEach/afterEach for proper test isolation
- Implement proper error cases
- Add JSDoc comments for complex test scenarios
- Ensure mocks are properly typed
- Verify both positive and negative test cases
- Always use data-testid attributes when testing webview-ui
- The vitest framework is used for testing; the `describe`, `test`, `it`, etc functions are defined by default in `tsconfig.json` and therefore don't need to be imported
- Tests must be run from the same directory as the `package.json` file that specifies `vitest` in `devDependencies`
- slug: design-engineer
name: 🎨 Design Engineer
roleDefinition: "You are Roo, an expert Design Engineer focused on VSCode Extension development. Your expertise includes: - Implementing UI designs with high fidelity using React, Shadcn, Tailwind and TypeScript. - Ensuring interfaces are responsive and adapt to different screen sizes. - Collaborating with team members to translate broad directives into robust and detailed designs capturing edge cases. - Maintaining uniformity and consistency across the user interface."
whenToUse: Implement UI designs and ensure consistency.
description: Implement UI designs; ensure consistency.
groups:
- read
- - edit
- fileRegex: \.(css|html|json|mdx?|jsx?|tsx?|svg)$
description: Frontend & SVG files
- browser
- command
- mcp
customInstructions: Focus on UI refinement, component creation, and adherence to design best-practices. When the user requests a new component, start off by asking them questions one-by-one to ensure the requirements are understood. Always use Tailwind utility classes (instead of direct variable references) for styling components when possible. If editing an existing file, transition explicit style definitions to Tailwind CSS classes when possible. Refer to the Tailwind CSS definitions for utility classes at webview-ui/src/index.css. Always use the latest version of Tailwind CSS (V4), and never create a tailwind.config.js file. Prefer Shadcn components for UI elements instead of VSCode's built-in ones. This project uses i18n for localization, so make sure to use the i18n functions and components for any text that needs to be translated. Do not leave placeholder strings in the markup, as they will be replaced by i18n. Prefer the @roo (/src) and @src (/webview-ui/src) aliases for imports in typescript files. Suggest the user refactor large files (over 1000 lines) if they are encountered, and provide guidance. Suggest the user switch into Translate mode to complete translations when your task is finished.
source: project
- slug: release-engineer
name: 🚀 Release Engineer
roleDefinition: You are Roo, a release engineer specialized in automating the release process for software projects. You have expertise in version control, changelogs, release notes, creating changesets, and coordinating with translation teams to ensure a smooth release process.
whenToUse: Automate the release process for software projects.
description: Automate the release process.
customInstructions: |-
When preparing a release: 1. Identify the SHA corresponding to the most recent release using GitHub CLI: `gh release view --json tagName,targetCommitish,publishedAt ` 2. Analyze changes since the last release using: `gh pr list --state merged --json number,title,author,url,mergedAt --limit 1000 -q '[.[] | select(.mergedAt > "TIMESTAMP") | {number, title, author: .author.login, url, mergedAt}] | sort_by(.number)'` 3. Summarize the changes and ask the user whether this should be a major, minor, or patch release 4. Create a changeset in .changeset/v[version].md instead of directly modifying package.json. The format is:
``` --- "roo-cline": patch|minor|major ---
[list of changes] ```
- Always include contributor attribution using format: (thanks @username!) - Provide brief descriptions of each item to explain the change - Order the list from most important to least important - Example: "- Add support for Gemini 2.5 Pro caching (thanks @contributor!)" - CRITICAL: Include EVERY SINGLE PR in the changeset - don't assume you know which ones are important. Count the total PRs to verify completeness and cross-reference the list to ensure nothing is missed.
5. If a major or minor release, update the English version relevant announcement files and documentation (webview-ui/src/components/chat/Announcement.tsx, README.md, and the `latestAnnouncementId` in src/core/webview/ClineProvider.ts) 6. Ask the user to confirm the English version 7. Use the new_task tool to create a subtask in `translate` mode with detailed instructions of which content needs to be translated into all supported languages 8. Commit and push the changeset file to the repository 9. The GitHub Actions workflow will automatically:
- Create a version bump PR when changesets are merged to main
- Update the CHANGELOG.md with proper formatting
- Publish the release when the version bump PR is merged
groups:
- read
- edit
- command
- browser
source: project
- slug: translate
name: 🌐 Translate
roleDefinition: You are Roo, a linguistic specialist focused on translating and managing localization files. Your responsibility is to help maintain and update translation files for the application, ensuring consistency and accuracy across all language resources.
whenToUse: Translate and manage localization files.
description: Translate and manage localization files.
groups:
- read
- command
- - 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: issue-writer
name: 📝 Issue Writer
roleDefinition: |-
You are Roo, a GitHub issue creation specialist focused on crafting well-structured, detailed issues based on the project's issue templates. Your expertise includes: - Understanding and analyzing user requirements for bug reports and feature requests - Exploring codebases thoroughly to gather relevant technical context - Creating comprehensive GitHub issues following XML-based templates - Ensuring issues contain all necessary information for developers - Using GitHub MCP tools to create issues programmatically
You work with two primary issue types: - Bug Reports: Documenting reproducible bugs with clear steps and expected outcomes - Feature Proposals: Creating detailed, actionable feature requests with clear problem statements, solutions, and acceptance criteria
whenToUse: Use this mode when you need to create a GitHub issue for bug reports or feature requests. This mode will guide you through gathering all necessary information, exploring the codebase for context, and creating a well-structured issue in the RooCodeInc/Roo-Code repository.
description: Create well-structured GitHub issues.
groups:
- read
- command
- mcp
source: project
- slug: integration-tester
name: 🧪 Integration Tester
roleDefinition: |-
You are Roo, an integration testing specialist focused on VSCode E2E tests with expertise in: - Writing and maintaining integration tests using Mocha and VSCode Test framework - Testing Roo Code API interactions and event-driven workflows - Creating complex multi-step task scenarios and mode switching sequences - Validating message formats, API responses, and event emission patterns - Test data generation and fixture management - Coverage analysis and test scenario identification
Your focus is on ensuring comprehensive integration test coverage for the Roo Code extension, working primarily with: - E2E test files in apps/vscode-e2e/src/suite/ - Test utilities and helpers - API type definitions in packages/types/ - Extension API testing patterns
You ensure integration tests are: - Comprehensive and cover critical user workflows - Following established Mocha TDD patterns - Using async/await with proper timeout handling - Validating both success and failure scenarios - Properly typed with TypeScript
whenToUse: Write, modify, or maintain integration tests.
description: Write and maintain integration tests.
groups:
- read
- command
- - edit
- fileRegex: (apps/vscode-e2e/.*\.(ts|js)$|packages/types/.*\.ts$)
description: E2E test files, test utilities, and API type definitions
source: project
- slug: pr-reviewer
name: 🔍 PR Reviewer
roleDefinition: |-
You are Roo, a critical pull request review orchestrator specializing in code quality, architectural consistency, and codebase organization. Your expertise includes:
- Orchestrating comprehensive PR reviews by delegating specialized analysis tasks
- Analyzing pull request diffs with a critical eye for code organization and patterns
- Evaluating whether changes follow established codebase patterns and conventions
- Identifying redundant or duplicate code that already exists elsewhere
- Ensuring tests are properly organized with other similar tests
- Verifying that new features follow patterns established by similar existing features
- Detecting code smells, technical debt, and architectural inconsistencies
- Delegating deep codebase analysis to specialized modes when needed
- Maintaining context through structured report files in .roo/temp/pr-[number]/
- Ensuring proper internationalization (i18n) for UI changes
- Providing direct, constructive feedback that improves code quality
- Being appropriately critical to maintain high code standards
- Using GitHub CLI when MCP tools are unavailable
You work primarily with the RooCodeInc/Roo-Code repository, creating context reports to track findings and delegating complex pattern analysis to specialized modes while maintaining overall review coordination. When called by other modes (Issue Fixer, PR Fixer), you focus only on analysis without commenting on the PR.
whenToUse: Use this mode to critically review pull requests, focusing on code organization, pattern consistency, and identifying redundancy or architectural issues. This mode orchestrates complex analysis tasks while maintaining review context.
description: Critically review pull requests.
groups:
- read
- - edit
- fileRegex: (\.md$|\.roo/temp/pr-.*\.(json|md|txt)$)
description: Markdown files and PR review context files
- mcp
- command
source: project
- slug: docs-extractor
name: 📚 Docs Extractor
roleDefinition: You are Roo, a comprehensive documentation extraction specialist focused on analyzing and documenting all technical and non-technical information about features and components within codebases.
whenToUse: Use this mode when you need to extract comprehensive documentation about any feature, component, or aspect of a codebase.
description: Extract comprehensive documentation.
groups:
- read
- - edit
- fileRegex: (DOCS-TEMP-.*\.md$|\.roo/docs-extractor/.*\.md$)
description: Temporary documentation extraction files only
- command
- mcp
- slug: pr-fixer
name: 🛠️ PR Fixer
roleDefinition: "You are Roo, a pull request resolution specialist. Your focus is on addressing feedback and resolving issues within existing pull requests. Your expertise includes: - Analyzing PR review comments to understand required changes. - Checking CI/CD workflow statuses to identify failing tests. - Fetching and analyzing test logs to diagnose failures. - Identifying and resolving merge conflicts. - Guiding the user through the resolution process."
whenToUse: Use this mode to fix pull requests. It can analyze PR feedback from GitHub, check for failing tests, and help resolve merge conflicts before applying the necessary code changes.
description: Fix pull requests.
groups:
- read
- edit
- command
- mcp

1
.tool-versions Normal file
View file

@ -0,0 +1 @@
nodejs 20.19.2

6
.vscode/extensions.json vendored
View file

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

4
.vscode/launch.json vendored
View file

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

3
.vscode/settings.json vendored
View file

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

34
.vscode/tasks.json vendored
View file

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

50
.vscodeignore
View file

@ -1,50 +0,0 @@
# Default
.github/**
.husky/**
.vscode/**
.vscode-test/**
out/**
out-integration/**
e2e/**
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
.clinerules*
.roomodes
cline_docs/**
coverage/**
# 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/**

1149
CHANGELOG.md
View file

File diff suppressed because it is too large Load diff

90
CODE_OF_CONDUCT.md Normal file
View file

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

138
CONTRIBUTING.md Normal file
View file

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

4
LICENSE
View file

@ -186,7 +186,7 @@
same "printed page" as the copyright notice for easier
identification within third-party archives.
Copyright 2025 Roo Veterinary Inc.
Copyright 2025 Roo Code, 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.

38
PRIVACY.md Normal file
View file

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

186
README.md
View file

@ -1,19 +1,34 @@
<div align="center">
<h2>Join the Roo Code Community</h2>
<sub>
<b>English</b> • [Català](locales/ca/README.md) • [Deutsch](locales/de/README.md) • [Español](locales/es/README.md) • [Français](locales/fr/README.md) • [हिंदी](locales/hi/README.md) • [Bahasa Indonesia](locales/id/README.md) • [Italiano](locales/it/README.md) • [日本語](locales/ja/README.md)
</sub>
<sub>
[한국어](locales/ko/README.md) • [Nederlands](locales/nl/README.md) • [Polski](locales/pl/README.md) • [Português (BR)](locales/pt-BR/README.md) • [Русский](locales/ru/README.md) • [Türkçe](locales/tr/README.md) • [Tiếng Việt](locales/vi/README.md) • [简体中文](locales/zh-CN/README.md) • [繁體中文](locales/zh-TW/README.md)
</sub>
</div>
<br>
<div align="center">
<h1>Roo Code (prev. Roo Cline)</h1>
<p align="center">
<img src="https://media.githubusercontent.com/media/RooCodeInc/Roo-Code/main/src/assets/docs/demo.gif" width="100%" />
</p>
<p>Connect with developers, contribute ideas, and stay ahead with the latest AI-powered coding tools.</p>
<a href="https://discord.gg/roocode" target="_blank"><img src="https://img.shields.io/badge/Join%20Discord-5865F2?style=for-the-badge&logo=discord&logoColor=white" alt="Join Discord" height="60"></a>
<a href="https://www.reddit.com/r/RooCode/" target="_blank"><img src="https://img.shields.io/badge/Join%20Reddit-FF4500?style=for-the-badge&logo=reddit&logoColor=white" alt="Join Reddit" height="60"></a>
<a href="https://discord.gg/roocode" target="_blank"><img src="https://img.shields.io/badge/Join%20Discord-5865F2?style=for-the-badge&logo=discord&logoColor=white" alt="Join Discord"></a>
<a href="https://www.reddit.com/r/RooCode/" target="_blank"><img src="https://img.shields.io/badge/Join%20Reddit-FF4500?style=for-the-badge&logo=reddit&logoColor=white" alt="Join Reddit"></a>
</div>
<br>
<br>
<div align="center">
<h1>Roo Code (prev. Roo Cline)</h1>
<a href="https://marketplace.visualstudio.com/items?itemName=RooVeterinaryInc.roo-cline" target="_blank"><img src="https://img.shields.io/badge/Download%20on%20VS%20Marketplace-blue?style=for-the-badge&logo=visualstudiocode&logoColor=white" alt="Download on VS Marketplace"></a>
<a href="https://github.com/RooVetGit/Roo-Code/discussions/categories/feature-requests?discussions_q=is%3Aopen+category%3A%22Feature+Requests%22+sort%3Atop" target="_blank"><img src="https://img.shields.io/badge/Feature%20Requests-yellow?style=for-the-badge" alt="Feature Requests"></a>
<a href="https://github.com/RooCodeInc/Roo-Code/discussions/categories/feature-requests?discussions_q=is%3Aopen+category%3A%22Feature+Requests%22+sort%3Atop" target="_blank"><img src="https://img.shields.io/badge/Feature%20Requests-yellow?style=for-the-badge" alt="Feature Requests"></a>
<a href="https://marketplace.visualstudio.com/items?itemName=RooVeterinaryInc.roo-cline&ssr=false#review-details" target="_blank"><img src="https://img.shields.io/badge/Rate%20%26%20Review-green?style=for-the-badge" alt="Rate & Review"></a>
<a href="https://docs.roocode.com" target="_blank"><img src="https://img.shields.io/badge/Documentation-6B46C1?style=for-the-badge&logo=readthedocs&logoColor=white" alt="Documentation"></a>
@ -34,15 +49,12 @@ Check out the [CHANGELOG](CHANGELOG.md) for detailed updates and fixes.
---
## New in 3.7: Claude 3.7 Sonnet Support 🚀
## 🎉 Roo Code 3.23 Released
We're excited to announce support for Anthropic's latest model, Claude 3.7 Sonnet! The model shows notable improvements in:
Roo Code 3.23 brings powerful new features and significant improvements to enhance your development workflow!
- Front-end development and full-stack updates
- Agentic workflows for multi-step processes
- More accurate math, coding, and instruction-following
Try it today in your provider of choice!
- **Codebase Indexing Graduated from Experimental** - Full codebase indexing is now stable and ready for production use with improved search and context understanding.
- **New Todo List Feature** - Keep your tasks on track with integrated todo management that helps you stay organized and focused on your development goals.
---
@ -65,7 +77,7 @@ Try it today in your provider of choice!
### Multiple Modes
Roo Code adapts to your needs with specialized [modes](https://docs.roocode.com/basic-usage/modes):
Roo Code adapts to your needs with specialized [modes](https://docs.roocode.com/basic-usage/using-modes):
- **Code Mode:** For general-purpose coding tasks
- **Architect Mode:** For planning and technical leadership
@ -75,7 +87,7 @@ Roo Code adapts to your needs with specialized [modes](https://docs.roocode.com/
### Smart Tools
Roo Code comes with powerful [tools](https://docs.roocode.com/basic-usage/using-tools) that can:
Roo Code comes with powerful [tools](https://docs.roocode.com/basic-usage/how-tools-work) that can:
- Read and write files in your project
- Execute commands in your VS Code terminal
@ -105,43 +117,73 @@ Make Roo Code work your way with:
- **Discord:** [Join our Discord server](https://discord.gg/roocode) for real-time help and discussions
- **Reddit:** [Visit our subreddit](https://www.reddit.com/r/RooCode) to share experiences and tips
- **GitHub:** Report [issues](https://github.com/RooVetGit/Roo-Code/issues) or request [features](https://github.com/RooVetGit/Roo-Code/discussions/categories/feature-requests?discussions_q=is%3Aopen+category%3A%22Feature+Requests%22+sort%3Atop)
- **GitHub:** Report [issues](https://github.com/RooCodeInc/Roo-Code/issues) or request [features](https://github.com/RooCodeInc/Roo-Code/discussions/categories/feature-requests?discussions_q=is%3Aopen+category%3A%22Feature+Requests%22+sort%3Atop)
---
## Local Setup & Development
1. **Clone** the repo:
```bash
git clone https://github.com/RooVetGit/Roo-Code.git
```
```sh
git clone https://github.com/RooCodeInc/Roo-Code.git
```
2. **Install dependencies**:
```bash
npm run install:all
```sh
pnpm install
```
3. **Run the extension**:
There are several ways to run the Roo Code extension:
### Development Mode (F5)
For active development, use VSCode's built-in debugging:
Press `F5` (or go to **Run** → **Start Debugging**) in VSCode. This will open a new VSCode window with the Roo Code extension running.
- Changes to the webview will appear immediately.
- Changes to the core extension will also hot reload automatically.
### Automated VSIX Installation
To build and install the extension as a VSIX package directly into VSCode:
```sh
pnpm install:vsix [-y] [--editor=<command>]
```
This command will:
- Ask which editor command to use (code/cursor/code-insiders) - defaults to 'code'
- Uninstall any existing version of the extension.
- Build the latest VSIX package.
- Install the newly built VSIX.
- Prompt you to restart VS Code for changes to take effect.
Options:
- `-y`: Skip all confirmation prompts and use defaults
- `--editor=<command>`: Specify the editor command (e.g., `--editor=cursor` or `--editor=code-insiders`)
### Manual VSIX Installation
If you prefer to install the VSIX package manually:
1. First, build the VSIX package:
```sh
pnpm vsix
```
2. A `.vsix` file will be generated in the `bin/` directory (e.g., `bin/roo-cline-<version>.vsix`).
3. Install it manually using the VSCode CLI:
```sh
code --install-extension bin/roo-cline-<version>.vsix
```
if that fails, try:
```bash
npm run install:ci
```
3. **Build** the extension:
```bash
npm run build
```
- A `.vsix` file will appear in the `bin/` directory.
4. **Install** the `.vsix` manually if desired:
```bash
code --install-extension bin/roo-code-4.0.0.vsix
```
5. **Start the webview (Vite/React app with HMR)**:
```bash
npm run dev
```
6. **Debug**:
- Press `F5` (or **Run** → **Start Debugging**) in VSCode to open a new session with Roo Code loaded.
Changes to the webview will appear immediately. Changes to the core extension will require a restart of the extension host.
---
We use [changesets](https://github.com/changesets/changesets) for versioning and publishing. Check our `CHANGELOG.md` for release notes.
@ -149,25 +191,67 @@ We use [changesets](https://github.com/changesets/changesets) for versioning and
## Disclaimer
**Please note** that Roo Veterinary, Inc does **not** make any representations or warranties regarding any code, models, or other tools provided or made available in connection with Roo Code, any associated third-party tools, or any resulting outputs. You assume **all risks** associated with the use of any such tools or outputs; such tools are provided on an **"AS IS"** and **"AS AVAILABLE"** basis. Such risks may include, without limitation, intellectual property infringement, cyber vulnerabilities or attacks, bias, inaccuracies, errors, defects, viruses, downtime, property loss or damage, and/or personal injury. You are solely responsible for your use of any such tools or outputs (including, without limitation, the legality, appropriateness, and results thereof).
**Please note** that Roo Code, Inc does **not** make any representations or warranties regarding any code, models, or other tools provided or made available in connection with Roo Code, any associated third-party tools, or any resulting outputs. You assume **all risks** associated with the use of any such tools or outputs; such tools are provided on an **"AS IS"** and **"AS AVAILABLE"** basis. Such risks may include, without limitation, intellectual property infringement, cyber vulnerabilities or attacks, bias, inaccuracies, errors, defects, viruses, downtime, property loss or damage, and/or personal injury. You are solely responsible for your use of any such tools or outputs (including, without limitation, the legality, appropriateness, and results thereof).
---
## Contributing
We love community contributions! Here’s how to get involved:
1. **Check Issues & Requests**: See [open issues](https://github.com/RooVetGit/Roo-Code/issues) or [feature requests](https://github.com/RooVetGit/Roo-Code/discussions/categories/feature-requests).
2. **Fork & branch** off `main`.
3. **Submit a Pull Request** once your feature or fix is ready.
4. **Join** our [Reddit community](https://www.reddit.com/r/RooCode/) and [Discord](https://roocode.com/discord) for feedback, tips, and announcements.
We love community contributions! Get started by reading our [CONTRIBUTING.md](CONTRIBUTING.md).
---
## Contributors
Thanks to all our contributors who have helped make Roo Code better!
<!-- START CONTRIBUTORS SECTION - AUTO-GENERATED, DO NOT EDIT MANUALLY -->
| <a href="https://github.com/mrubens"><img src="https://avatars.githubusercontent.com/u/2600?v=4" width="100" height="100" alt="mrubens"/><br /><sub><b>mrubens</b></sub></a> | <a href="https://github.com/saoudrizwan"><img src="https://avatars.githubusercontent.com/u/7799382?v=4" width="100" height="100" alt="saoudrizwan"/><br /><sub><b>saoudrizwan</b></sub></a> | <a href="https://github.com/cte"><img src="https://avatars.githubusercontent.com/u/16332?v=4" width="100" height="100" alt="cte"/><br /><sub><b>cte</b></sub></a> | <a href="https://github.com/samhvw8"><img src="https://avatars.githubusercontent.com/u/12538214?v=4" width="100" height="100" alt="samhvw8"/><br /><sub><b>samhvw8</b></sub></a> | <a href="https://github.com/daniel-lxs"><img src="https://avatars.githubusercontent.com/u/57051444?v=4" width="100" height="100" alt="daniel-lxs"/><br /><sub><b>daniel-lxs</b></sub></a> | <a href="https://github.com/hannesrudolph"><img src="https://avatars.githubusercontent.com/u/49103247?v=4" width="100" height="100" alt="hannesrudolph"/><br /><sub><b>hannesrudolph</b></sub></a> |
| :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |
| <a href="https://github.com/KJ7LNW"><img src="https://avatars.githubusercontent.com/u/93454819?v=4" width="100" height="100" alt="KJ7LNW"/><br /><sub><b>KJ7LNW</b></sub></a> | <a href="https://github.com/a8trejo"><img src="https://avatars.githubusercontent.com/u/62401433?v=4" width="100" height="100" alt="a8trejo"/><br /><sub><b>a8trejo</b></sub></a> | <a href="https://github.com/ColemanRoo"><img src="https://avatars.githubusercontent.com/u/117104599?v=4" width="100" height="100" alt="ColemanRoo"/><br /><sub><b>ColemanRoo</b></sub></a> | <a href="https://github.com/canrobins13"><img src="https://avatars.githubusercontent.com/u/20544372?v=4" width="100" height="100" alt="canrobins13"/><br /><sub><b>canrobins13</b></sub></a> | <a href="https://github.com/stea9499"><img src="https://avatars.githubusercontent.com/u/4163795?v=4" width="100" height="100" alt="stea9499"/><br /><sub><b>stea9499</b></sub></a> | <a href="https://github.com/MuriloFP"><img src="https://avatars.githubusercontent.com/u/50873657?v=4" width="100" height="100" alt="MuriloFP"/><br /><sub><b>MuriloFP</b></sub></a> |
| <a href="https://github.com/joemanley201"><img src="https://avatars.githubusercontent.com/u/8299960?v=4" width="100" height="100" alt="joemanley201"/><br /><sub><b>joemanley201</b></sub></a> | <a href="https://github.com/System233"><img src="https://avatars.githubusercontent.com/u/20336040?v=4" width="100" height="100" alt="System233"/><br /><sub><b>System233</b></sub></a> | <a href="https://github.com/jr"><img src="https://avatars.githubusercontent.com/u/5629?v=4" width="100" height="100" alt="jr"/><br /><sub><b>jr</b></sub></a> | <a href="https://github.com/nissa-seru"><img src="https://avatars.githubusercontent.com/u/119150866?v=4" width="100" height="100" alt="nissa-seru"/><br /><sub><b>nissa-seru</b></sub></a> | <a href="https://github.com/jquanton"><img src="https://avatars.githubusercontent.com/u/88576563?v=4" width="100" height="100" alt="jquanton"/><br /><sub><b>jquanton</b></sub></a> | <a href="https://github.com/NyxJae"><img src="https://avatars.githubusercontent.com/u/52313587?v=4" width="100" height="100" alt="NyxJae"/><br /><sub><b>NyxJae</b></sub></a> |
| <a href="https://github.com/roomote-bot"><img src="https://avatars.githubusercontent.com/u/206919393?v=4" width="100" height="100" alt="roomote-bot"/><br /><sub><b>roomote-bot</b></sub></a> | <a href="https://github.com/elianiva"><img src="https://avatars.githubusercontent.com/u/51877647?v=4" width="100" height="100" alt="elianiva"/><br /><sub><b>elianiva</b></sub></a> | <a href="https://github.com/d-oit"><img src="https://avatars.githubusercontent.com/u/6849456?v=4" width="100" height="100" alt="d-oit"/><br /><sub><b>d-oit</b></sub></a> | <a href="https://github.com/punkpeye"><img src="https://avatars.githubusercontent.com/u/108313943?v=4" width="100" height="100" alt="punkpeye"/><br /><sub><b>punkpeye</b></sub></a> | <a href="https://github.com/wkordalski"><img src="https://avatars.githubusercontent.com/u/3035587?v=4" width="100" height="100" alt="wkordalski"/><br /><sub><b>wkordalski</b></sub></a> | <a href="https://github.com/qdaxb"><img src="https://avatars.githubusercontent.com/u/4157870?v=4" width="100" height="100" alt="qdaxb"/><br /><sub><b>qdaxb</b></sub></a> |
| <a href="https://github.com/xyOz-dev"><img src="https://avatars.githubusercontent.com/u/195602624?v=4" width="100" height="100" alt="xyOz-dev"/><br /><sub><b>xyOz-dev</b></sub></a> | <a href="https://github.com/feifei325"><img src="https://avatars.githubusercontent.com/u/46489071?v=4" width="100" height="100" alt="feifei325"/><br /><sub><b>feifei325</b></sub></a> | <a href="https://github.com/zhangtony239"><img src="https://avatars.githubusercontent.com/u/157202938?v=4" width="100" height="100" alt="zhangtony239"/><br /><sub><b>zhangtony239</b></sub></a> | <a href="https://github.com/sachasayan"><img src="https://avatars.githubusercontent.com/u/1666034?v=4" width="100" height="100" alt="sachasayan"/><br /><sub><b>sachasayan</b></sub></a> | <a href="https://github.com/monotykamary"><img src="https://avatars.githubusercontent.com/u/1130103?v=4" width="100" height="100" alt="monotykamary"/><br /><sub><b>monotykamary</b></sub></a> | <a href="https://github.com/cannuri"><img src="https://avatars.githubusercontent.com/u/91494156?v=4" width="100" height="100" alt="cannuri"/><br /><sub><b>cannuri</b></sub></a> |
| <a href="https://github.com/Smartsheet-JB-Brown"><img src="https://avatars.githubusercontent.com/u/171734120?v=4" width="100" height="100" alt="Smartsheet-JB-Brown"/><br /><sub><b>Smartsheet-JB-Brown</b></sub></a> | <a href="https://github.com/shariqriazz"><img src="https://avatars.githubusercontent.com/u/196900129?v=4" width="100" height="100" alt="shariqriazz"/><br /><sub><b>shariqriazz</b></sub></a> | <a href="https://github.com/vigneshsubbiah16"><img src="https://avatars.githubusercontent.com/u/51325334?v=4" width="100" height="100" alt="vigneshsubbiah16"/><br /><sub><b>vigneshsubbiah16</b></sub></a> | <a href="https://github.com/chrarnoldus"><img src="https://avatars.githubusercontent.com/u/12196001?v=4" width="100" height="100" alt="chrarnoldus"/><br /><sub><b>chrarnoldus</b></sub></a> | <a href="https://github.com/pugazhendhi-m"><img src="https://avatars.githubusercontent.com/u/132246623?v=4" width="100" height="100" alt="pugazhendhi-m"/><br /><sub><b>pugazhendhi-m</b></sub></a> | <a href="https://github.com/lloydchang"><img src="https://avatars.githubusercontent.com/u/1329685?v=4" width="100" height="100" alt="lloydchang"/><br /><sub><b>lloydchang</b></sub></a> |
| <a href="https://github.com/SannidhyaSah"><img src="https://avatars.githubusercontent.com/u/186946675?v=4" width="100" height="100" alt="SannidhyaSah"/><br /><sub><b>SannidhyaSah</b></sub></a> | <a href="https://github.com/dtrugman"><img src="https://avatars.githubusercontent.com/u/2451669?v=4" width="100" height="100" alt="dtrugman"/><br /><sub><b>dtrugman</b></sub></a> | <a href="https://github.com/Szpadel"><img src="https://avatars.githubusercontent.com/u/1857251?v=4" width="100" height="100" alt="Szpadel"/><br /><sub><b>Szpadel</b></sub></a> | <a href="https://github.com/diarmidmackenzie"><img src="https://avatars.githubusercontent.com/u/16045703?v=4" width="100" height="100" alt="diarmidmackenzie"/><br /><sub><b>diarmidmackenzie</b></sub></a> | <a href="https://github.com/olweraltuve"><img src="https://avatars.githubusercontent.com/u/39308405?v=4" width="100" height="100" alt="olweraltuve"/><br /><sub><b>olweraltuve</b></sub></a> | <a href="https://github.com/psv2522"><img src="https://avatars.githubusercontent.com/u/87223770?v=4" width="100" height="100" alt="psv2522"/><br /><sub><b>psv2522</b></sub></a> |
| <a href="https://github.com/Premshay"><img src="https://avatars.githubusercontent.com/u/28099628?v=4" width="100" height="100" alt="Premshay"/><br /><sub><b>Premshay</b></sub></a> | <a href="https://github.com/kiwina"><img src="https://avatars.githubusercontent.com/u/1071364?v=4" width="100" height="100" alt="kiwina"/><br /><sub><b>kiwina</b></sub></a> | <a href="https://github.com/lupuletic"><img src="https://avatars.githubusercontent.com/u/105351510?v=4" width="100" height="100" alt="lupuletic"/><br /><sub><b>lupuletic</b></sub></a> | <a href="https://github.com/aheizi"><img src="https://avatars.githubusercontent.com/u/8243770?v=4" width="100" height="100" alt="aheizi"/><br /><sub><b>aheizi</b></sub></a> | <a href="https://github.com/liwilliam2021"><img src="https://avatars.githubusercontent.com/u/40069349?v=4" width="100" height="100" alt="liwilliam2021"/><br /><sub><b>liwilliam2021</b></sub></a> | <a href="https://github.com/PeterDaveHello"><img src="https://avatars.githubusercontent.com/u/3691490?v=4" width="100" height="100" alt="PeterDaveHello"/><br /><sub><b>PeterDaveHello</b></sub></a> |
| <a href="https://github.com/hassoncs"><img src="https://avatars.githubusercontent.com/u/5104925?v=4" width="100" height="100" alt="hassoncs"/><br /><sub><b>hassoncs</b></sub></a> | <a href="https://github.com/ChuKhaLi"><img src="https://avatars.githubusercontent.com/u/15166543?v=4" width="100" height="100" alt="ChuKhaLi"/><br /><sub><b>ChuKhaLi</b></sub></a> | <a href="https://github.com/nbihan-mediware"><img src="https://avatars.githubusercontent.com/u/42357253?v=4" width="100" height="100" alt="nbihan-mediware"/><br /><sub><b>nbihan-mediware</b></sub></a> | <a href="https://github.com/noritaka1166"><img src="https://avatars.githubusercontent.com/u/189505037?v=4" width="100" height="100" alt="noritaka1166"/><br /><sub><b>noritaka1166</b></sub></a> | <a href="https://github.com/RaySinner"><img src="https://avatars.githubusercontent.com/u/118297374?v=4" width="100" height="100" alt="RaySinner"/><br /><sub><b>RaySinner</b></sub></a> | <a href="https://github.com/afshawnlotfi"><img src="https://avatars.githubusercontent.com/u/6283745?v=4" width="100" height="100" alt="afshawnlotfi"/><br /><sub><b>afshawnlotfi</b></sub></a> |
| <a href="https://github.com/dleffel"><img src="https://avatars.githubusercontent.com/u/7119958?v=4" width="100" height="100" alt="dleffel"/><br /><sub><b>dleffel</b></sub></a> | <a href="https://github.com/StevenTCramer"><img src="https://avatars.githubusercontent.com/u/357219?v=4" width="100" height="100" alt="StevenTCramer"/><br /><sub><b>StevenTCramer</b></sub></a> | <a href="https://github.com/Ruakij"><img src="https://avatars.githubusercontent.com/u/54639830?v=4" width="100" height="100" alt="Ruakij"/><br /><sub><b>Ruakij</b></sub></a> | <a href="https://github.com/pdecat"><img src="https://avatars.githubusercontent.com/u/318490?v=4" width="100" height="100" alt="pdecat"/><br /><sub><b>pdecat</b></sub></a> | <a href="https://github.com/kyle-apex"><img src="https://avatars.githubusercontent.com/u/20145331?v=4" width="100" height="100" alt="kyle-apex"/><br /><sub><b>kyle-apex</b></sub></a> | <a href="https://github.com/emshvac"><img src="https://avatars.githubusercontent.com/u/121588911?v=4" width="100" height="100" alt="emshvac"/><br /><sub><b>emshvac</b></sub></a> |
| <a href="https://github.com/Lunchb0ne"><img src="https://avatars.githubusercontent.com/u/22198661?v=4" width="100" height="100" alt="Lunchb0ne"/><br /><sub><b>Lunchb0ne</b></sub></a> | <a href="https://github.com/SmartManoj"><img src="https://avatars.githubusercontent.com/u/7231077?v=4" width="100" height="100" alt="SmartManoj"/><br /><sub><b>SmartManoj</b></sub></a> | <a href="https://github.com/vagadiya"><img src="https://avatars.githubusercontent.com/u/32499123?v=4" width="100" height="100" alt="vagadiya"/><br /><sub><b>vagadiya</b></sub></a> | <a href="https://github.com/slytechnical"><img src="https://avatars.githubusercontent.com/u/139649758?v=4" width="100" height="100" alt="slytechnical"/><br /><sub><b>slytechnical</b></sub></a> | <a href="https://github.com/dlab-anton"><img src="https://avatars.githubusercontent.com/u/20571486?v=4" width="100" height="100" alt="dlab-anton"/><br /><sub><b>dlab-anton</b></sub></a> | <a href="https://github.com/arthurauffray"><img src="https://avatars.githubusercontent.com/u/51604173?v=4" width="100" height="100" alt="arthurauffray"/><br /><sub><b>arthurauffray</b></sub></a> |
| <a href="https://github.com/upamune"><img src="https://avatars.githubusercontent.com/u/8219560?v=4" width="100" height="100" alt="upamune"/><br /><sub><b>upamune</b></sub></a> | <a href="https://github.com/NamesMT"><img src="https://avatars.githubusercontent.com/u/23612546?v=4" width="100" height="100" alt="NamesMT"/><br /><sub><b>NamesMT</b></sub></a> | <a href="https://github.com/taylorwilsdon"><img src="https://avatars.githubusercontent.com/u/6508528?v=4" width="100" height="100" alt="taylorwilsdon"/><br /><sub><b>taylorwilsdon</b></sub></a> | <a href="https://github.com/sammcj"><img src="https://avatars.githubusercontent.com/u/862951?v=4" width="100" height="100" alt="sammcj"/><br /><sub><b>sammcj</b></sub></a> | <a href="https://github.com/p12tic"><img src="https://avatars.githubusercontent.com/u/1056711?v=4" width="100" height="100" alt="p12tic"/><br /><sub><b>p12tic</b></sub></a> | <a href="https://github.com/gtaylor"><img src="https://avatars.githubusercontent.com/u/75556?v=4" width="100" height="100" alt="gtaylor"/><br /><sub><b>gtaylor</b></sub></a> |
| <a href="https://github.com/aitoroses"><img src="https://avatars.githubusercontent.com/u/1699368?v=4" width="100" height="100" alt="aitoroses"/><br /><sub><b>aitoroses</b></sub></a> | <a href="https://github.com/anton-otee"><img src="https://avatars.githubusercontent.com/u/149477749?v=4" width="100" height="100" alt="anton-otee"/><br /><sub><b>anton-otee</b></sub></a> | <a href="https://github.com/ross"><img src="https://avatars.githubusercontent.com/u/12789?v=4" width="100" height="100" alt="ross"/><br /><sub><b>ross</b></sub></a> | <a href="https://github.com/mr-ryan-james"><img src="https://avatars.githubusercontent.com/u/9344431?v=4" width="100" height="100" alt="mr-ryan-james"/><br /><sub><b>mr-ryan-james</b></sub></a> | <a href="https://github.com/heyseth"><img src="https://avatars.githubusercontent.com/u/8293842?v=4" width="100" height="100" alt="heyseth"/><br /><sub><b>heyseth</b></sub></a> | <a href="https://github.com/taisukeoe"><img src="https://avatars.githubusercontent.com/u/1506707?v=4" width="100" height="100" alt="taisukeoe"/><br /><sub><b>taisukeoe</b></sub></a> |
| <a href="https://github.com/avtc"><img src="https://avatars.githubusercontent.com/u/10050240?v=4" width="100" height="100" alt="avtc"/><br /><sub><b>avtc</b></sub></a> | <a href="https://github.com/eonghk"><img src="https://avatars.githubusercontent.com/u/139964?v=4" width="100" height="100" alt="eonghk"/><br /><sub><b>eonghk</b></sub></a> | <a href="https://github.com/GOODBOY008"><img src="https://avatars.githubusercontent.com/u/13617900?v=4" width="100" height="100" alt="GOODBOY008"/><br /><sub><b>GOODBOY008</b></sub></a> | <a href="https://github.com/kcwhite"><img src="https://avatars.githubusercontent.com/u/3812801?v=4" width="100" height="100" alt="kcwhite"/><br /><sub><b>kcwhite</b></sub></a> | <a href="https://github.com/ronyblum"><img src="https://avatars.githubusercontent.com/u/20314054?v=4" width="100" height="100" alt="ronyblum"/><br /><sub><b>ronyblum</b></sub></a> | <a href="https://github.com/teddyOOXX"><img src="https://avatars.githubusercontent.com/u/121077180?v=4" width="100" height="100" alt="teddyOOXX"/><br /><sub><b>teddyOOXX</b></sub></a> |
| <a href="https://github.com/vincentsong"><img src="https://avatars.githubusercontent.com/u/2343574?v=4" width="100" height="100" alt="vincentsong"/><br /><sub><b>vincentsong</b></sub></a> | <a href="https://github.com/yongjer"><img src="https://avatars.githubusercontent.com/u/54315206?v=4" width="100" height="100" alt="yongjer"/><br /><sub><b>yongjer</b></sub></a> | <a href="https://github.com/zeozeozeo"><img src="https://avatars.githubusercontent.com/u/108888572?v=4" width="100" height="100" alt="zeozeozeo"/><br /><sub><b>zeozeozeo</b></sub></a> | <a href="https://github.com/ashktn"><img src="https://avatars.githubusercontent.com/u/6723913?v=4" width="100" height="100" alt="ashktn"/><br /><sub><b>ashktn</b></sub></a> | <a href="https://github.com/franekp"><img src="https://avatars.githubusercontent.com/u/9804230?v=4" width="100" height="100" alt="franekp"/><br /><sub><b>franekp</b></sub></a> | <a href="https://github.com/yt3trees"><img src="https://avatars.githubusercontent.com/u/57471763?v=4" width="100" height="100" alt="yt3trees"/><br /><sub><b>yt3trees</b></sub></a> |
| <a href="https://github.com/seedlord"><img src="https://avatars.githubusercontent.com/u/20932878?v=4" width="100" height="100" alt="seedlord"/><br /><sub><b>seedlord</b></sub></a> | <a href="https://github.com/bramburn"><img src="https://avatars.githubusercontent.com/u/11090413?v=4" width="100" height="100" alt="bramburn"/><br /><sub><b>bramburn</b></sub></a> | <a href="https://github.com/benzntech"><img src="https://avatars.githubusercontent.com/u/4044180?v=4" width="100" height="100" alt="benzntech"/><br /><sub><b>benzntech</b></sub></a> | <a href="https://github.com/axkirillov"><img src="https://avatars.githubusercontent.com/u/32141102?v=4" width="100" height="100" alt="axkirillov"/><br /><sub><b>axkirillov</b></sub></a> | <a href="https://github.com/olearycrew"><img src="https://avatars.githubusercontent.com/u/6044920?v=4" width="100" height="100" alt="olearycrew"/><br /><sub><b>olearycrew</b></sub></a> | <a href="https://github.com/brunobergher"><img src="https://avatars.githubusercontent.com/u/328388?v=4" width="100" height="100" alt="brunobergher"/><br /><sub><b>brunobergher</b></sub></a> |
| <a href="https://github.com/catrielmuller"><img src="https://avatars.githubusercontent.com/u/2272323?v=4" width="100" height="100" alt="catrielmuller"/><br /><sub><b>catrielmuller</b></sub></a> | <a href="https://github.com/devxpain"><img src="https://avatars.githubusercontent.com/u/170700110?v=4" width="100" height="100" alt="devxpain"/><br /><sub><b>devxpain</b></sub></a> | <a href="https://github.com/snoyiatk"><img src="https://avatars.githubusercontent.com/u/3056569?v=4" width="100" height="100" alt="snoyiatk"/><br /><sub><b>snoyiatk</b></sub></a> | <a href="https://github.com/GitlyHallows"><img src="https://avatars.githubusercontent.com/u/136527758?v=4" width="100" height="100" alt="GitlyHallows"/><br /><sub><b>GitlyHallows</b></sub></a> | <a href="https://github.com/jcbdev"><img src="https://avatars.githubusercontent.com/u/17152092?v=4" width="100" height="100" alt="jcbdev"/><br /><sub><b>jcbdev</b></sub></a> | <a href="https://github.com/Chenjiayuan195"><img src="https://avatars.githubusercontent.com/u/30591313?v=4" width="100" height="100" alt="Chenjiayuan195"/><br /><sub><b>Chenjiayuan195</b></sub></a> |
| <a href="https://github.com/julionav"><img src="https://avatars.githubusercontent.com/u/45607850?v=4" width="100" height="100" alt="julionav"/><br /><sub><b>julionav</b></sub></a> | <a href="https://github.com/KanTakahiro"><img src="https://avatars.githubusercontent.com/u/64513424?v=4" width="100" height="100" alt="KanTakahiro"/><br /><sub><b>KanTakahiro</b></sub></a> | <a href="https://github.com/SplittyDev"><img src="https://avatars.githubusercontent.com/u/4216049?v=4" width="100" height="100" alt="SplittyDev"/><br /><sub><b>SplittyDev</b></sub></a> | <a href="https://github.com/mdp"><img src="https://avatars.githubusercontent.com/u/2868?v=4" width="100" height="100" alt="mdp"/><br /><sub><b>mdp</b></sub></a> | <a href="https://github.com/napter"><img src="https://avatars.githubusercontent.com/u/6260841?v=4" width="100" height="100" alt="napter"/><br /><sub><b>napter</b></sub></a> | <a href="https://github.com/philfung"><img src="https://avatars.githubusercontent.com/u/1054593?v=4" width="100" height="100" alt="philfung"/><br /><sub><b>philfung</b></sub></a> |
| <a href="https://github.com/chris-garrett"><img src="https://avatars.githubusercontent.com/u/1113459?v=4" width="100" height="100" alt="chris-garrett"/><br /><sub><b>chris-garrett</b></sub></a> | <a href="https://github.com/dairui1"><img src="https://avatars.githubusercontent.com/u/183250644?v=4" width="100" height="100" alt="dairui1"/><br /><sub><b>dairui1</b></sub></a> | <a href="https://github.com/dqroid"><img src="https://avatars.githubusercontent.com/u/192424994?v=4" width="100" height="100" alt="dqroid"/><br /><sub><b>dqroid</b></sub></a> | <a href="https://github.com/forestyoo"><img src="https://avatars.githubusercontent.com/u/2929056?v=4" width="100" height="100" alt="forestyoo"/><br /><sub><b>forestyoo</b></sub></a> | <a href="https://github.com/hatsu38"><img src="https://avatars.githubusercontent.com/u/16137809?v=4" width="100" height="100" alt="hatsu38"/><br /><sub><b>hatsu38</b></sub></a> | <a href="https://github.com/hongzio"><img src="https://avatars.githubusercontent.com/u/11085613?v=4" width="100" height="100" alt="hongzio"/><br /><sub><b>hongzio</b></sub></a> |
| <a href="https://github.com/im47cn"><img src="https://avatars.githubusercontent.com/u/67424112?v=4" width="100" height="100" alt="im47cn"/><br /><sub><b>im47cn</b></sub></a> | <a href="https://github.com/shoopapa"><img src="https://avatars.githubusercontent.com/u/45986634?v=4" width="100" height="100" alt="shoopapa"/><br /><sub><b>shoopapa</b></sub></a> | <a href="https://github.com/jwcraig"><img src="https://avatars.githubusercontent.com/u/241358?v=4" width="100" height="100" alt="jwcraig"/><br /><sub><b>jwcraig</b></sub></a> | <a href="https://github.com/kinandan"><img src="https://avatars.githubusercontent.com/u/186135699?v=4" width="100" height="100" alt="kinandan"/><br /><sub><b>kinandan</b></sub></a> | <a href="https://github.com/nevermorec"><img src="https://avatars.githubusercontent.com/u/22953064?v=4" width="100" height="100" alt="nevermorec"/><br /><sub><b>nevermorec</b></sub></a> | <a href="https://github.com/bbenshalom"><img src="https://avatars.githubusercontent.com/u/4359971?v=4" width="100" height="100" alt="bbenshalom"/><br /><sub><b>bbenshalom</b></sub></a> |
| <a href="https://github.com/bannzai"><img src="https://avatars.githubusercontent.com/u/10897361?v=4" width="100" height="100" alt="bannzai"/><br /><sub><b>bannzai</b></sub></a> | <a href="https://github.com/axmo"><img src="https://avatars.githubusercontent.com/u/2386344?v=4" width="100" height="100" alt="axmo"/><br /><sub><b>axmo</b></sub></a> | <a href="https://github.com/asychin"><img src="https://avatars.githubusercontent.com/u/178776568?v=4" width="100" height="100" alt="asychin"/><br /><sub><b>asychin</b></sub></a> | <a href="https://github.com/amittell"><img src="https://avatars.githubusercontent.com/u/1388680?v=4" width="100" height="100" alt="amittell"/><br /><sub><b>amittell</b></sub></a> | <a href="https://github.com/Yoshino-Yukitaro"><img src="https://avatars.githubusercontent.com/u/67864326?v=4" width="100" height="100" alt="Yoshino-Yukitaro"/><br /><sub><b>Yoshino-Yukitaro</b></sub></a> | <a href="https://github.com/Yikai-Liao"><img src="https://avatars.githubusercontent.com/u/110762732?v=4" width="100" height="100" alt="Yikai-Liao"/><br /><sub><b>Yikai-Liao</b></sub></a> |
| <a href="https://github.com/zxdvd"><img src="https://avatars.githubusercontent.com/u/107175?v=4" width="100" height="100" alt="zxdvd"/><br /><sub><b>zxdvd</b></sub></a> | <a href="https://github.com/s97712"><img src="https://avatars.githubusercontent.com/u/13390001?v=4" width="100" height="100" alt="s97712"/><br /><sub><b>s97712</b></sub></a> | <a href="https://github.com/vladstudio"><img src="https://avatars.githubusercontent.com/u/914320?v=4" width="100" height="100" alt="vladstudio"/><br /><sub><b>vladstudio</b></sub></a> | <a href="https://github.com/vivekfyi"><img src="https://avatars.githubusercontent.com/u/5036512?v=4" width="100" height="100" alt="vivekfyi"/><br /><sub><b>vivekfyi</b></sub></a> | <a href="https://github.com/tmsjngx0"><img src="https://avatars.githubusercontent.com/u/40481136?v=4" width="100" height="100" alt="tmsjngx0"/><br /><sub><b>tmsjngx0</b></sub></a> | <a href="https://github.com/Githubguy132010"><img src="https://avatars.githubusercontent.com/u/145768128?v=4" width="100" height="100" alt="Githubguy132010"/><br /><sub><b>Githubguy132010</b></sub></a> |
| <a href="https://github.com/tgfjt"><img src="https://avatars.githubusercontent.com/u/2628239?v=4" width="100" height="100" alt="tgfjt"/><br /><sub><b>tgfjt</b></sub></a> | <a href="https://github.com/PretzelVector"><img src="https://avatars.githubusercontent.com/u/95664360?v=4" width="100" height="100" alt="PretzelVector"/><br /><sub><b>PretzelVector</b></sub></a> | <a href="https://github.com/zetaloop"><img src="https://avatars.githubusercontent.com/u/36418285?v=4" width="100" height="100" alt="zetaloop"/><br /><sub><b>zetaloop</b></sub></a> | <a href="https://github.com/cdlliuy"><img src="https://avatars.githubusercontent.com/u/17263036?v=4" width="100" height="100" alt="cdlliuy"/><br /><sub><b>cdlliuy</b></sub></a> | <a href="https://github.com/user202729"><img src="https://avatars.githubusercontent.com/u/25191436?v=4" width="100" height="100" alt="user202729"/><br /><sub><b>user202729</b></sub></a> | <a href="https://github.com/takakoutso"><img src="https://avatars.githubusercontent.com/u/10097886?v=4" width="100" height="100" alt="takakoutso"/><br /><sub><b>takakoutso</b></sub></a> |
| <a href="https://github.com/student20880"><img src="https://avatars.githubusercontent.com/u/74263488?v=4" width="100" height="100" alt="student20880"/><br /><sub><b>student20880</b></sub></a> | <a href="https://github.com/shubhamgupta731"><img src="https://avatars.githubusercontent.com/u/963927?v=4" width="100" height="100" alt="shubhamgupta731"/><br /><sub><b>shubhamgupta731</b></sub></a> | <a href="https://github.com/shohei-ihaya"><img src="https://avatars.githubusercontent.com/u/25131938?v=4" width="100" height="100" alt="shohei-ihaya"/><br /><sub><b>shohei-ihaya</b></sub></a> | <a href="https://github.com/shivamd1810"><img src="https://avatars.githubusercontent.com/u/3871414?v=4" width="100" height="100" alt="shivamd1810"/><br /><sub><b>shivamd1810</b></sub></a> | <a href="https://github.com/shaybc"><img src="https://avatars.githubusercontent.com/u/8535905?v=4" width="100" height="100" alt="shaybc"/><br /><sub><b>shaybc</b></sub></a> | <a href="https://github.com/sensei-woo"><img src="https://avatars.githubusercontent.com/u/168141084?v=4" width="100" height="100" alt="sensei-woo"/><br /><sub><b>sensei-woo</b></sub></a> |
| <a href="https://github.com/samir-nimbly"><img src="https://avatars.githubusercontent.com/u/112695483?v=4" width="100" height="100" alt="samir-nimbly"/><br /><sub><b>samir-nimbly</b></sub></a> | <a href="https://github.com/robertheadley"><img src="https://avatars.githubusercontent.com/u/1780455?v=4" width="100" height="100" alt="robertheadley"/><br /><sub><b>robertheadley</b></sub></a> | <a href="https://github.com/refactorthis"><img src="https://avatars.githubusercontent.com/u/3012240?v=4" width="100" height="100" alt="refactorthis"/><br /><sub><b>refactorthis</b></sub></a> | <a href="https://github.com/qingyuan1109"><img src="https://avatars.githubusercontent.com/u/841732?v=4" width="100" height="100" alt="qingyuan1109"/><br /><sub><b>qingyuan1109</b></sub></a> | <a href="https://github.com/pokutuna"><img src="https://avatars.githubusercontent.com/u/57545?v=4" width="100" height="100" alt="pokutuna"/><br /><sub><b>pokutuna</b></sub></a> | <a href="https://github.com/philipnext"><img src="https://avatars.githubusercontent.com/u/81944499?v=4" width="100" height="100" alt="philipnext"/><br /><sub><b>philipnext</b></sub></a> |
| <a href="https://github.com/village-way"><img src="https://avatars.githubusercontent.com/u/11625846?v=4" width="100" height="100" alt="village-way"/><br /><sub><b>village-way</b></sub></a> | <a href="https://github.com/oprstchn"><img src="https://avatars.githubusercontent.com/u/16177972?v=4" width="100" height="100" alt="oprstchn"/><br /><sub><b>oprstchn</b></sub></a> | <a href="https://github.com/nobu007"><img src="https://avatars.githubusercontent.com/u/8529529?v=4" width="100" height="100" alt="nobu007"/><br /><sub><b>nobu007</b></sub></a> | <a href="https://github.com/mosleyit"><img src="https://avatars.githubusercontent.com/u/189396442?v=4" width="100" height="100" alt="mosleyit"/><br /><sub><b>mosleyit</b></sub></a> | <a href="https://github.com/moqimoqidea"><img src="https://avatars.githubusercontent.com/u/39821951?v=4" width="100" height="100" alt="moqimoqidea"/><br /><sub><b>moqimoqidea</b></sub></a> | <a href="https://github.com/mlopezr"><img src="https://avatars.githubusercontent.com/u/8202027?v=4" width="100" height="100" alt="mlopezr"/><br /><sub><b>mlopezr</b></sub></a> |
| <a href="https://github.com/mecab"><img src="https://avatars.githubusercontent.com/u/1580772?v=4" width="100" height="100" alt="mecab"/><br /><sub><b>mecab</b></sub></a> | <a href="https://github.com/olup"><img src="https://avatars.githubusercontent.com/u/13785588?v=4" width="100" height="100" alt="olup"/><br /><sub><b>olup</b></sub></a> | <a href="https://github.com/lightrabbit"><img src="https://avatars.githubusercontent.com/u/1521765?v=4" width="100" height="100" alt="lightrabbit"/><br /><sub><b>lightrabbit</b></sub></a> | <a href="https://github.com/lhish"><img src="https://avatars.githubusercontent.com/u/59965910?v=4" width="100" height="100" alt="lhish"/><br /><sub><b>lhish</b></sub></a> | <a href="https://github.com/kohii"><img src="https://avatars.githubusercontent.com/u/6891780?v=4" width="100" height="100" alt="kohii"/><br /><sub><b>kohii</b></sub></a> | <a href="https://github.com/pfitz"><img src="https://avatars.githubusercontent.com/u/3062911?v=4" width="100" height="100" alt="pfitz"/><br /><sub><b>pfitz</b></sub></a> |
| <a href="https://github.com/ExactDoug"><img src="https://avatars.githubusercontent.com/u/158221557?v=4" width="100" height="100" alt="ExactDoug"/><br /><sub><b>ExactDoug</b></sub></a> | <a href="https://github.com/celestial-vault"><img src="https://avatars.githubusercontent.com/u/58194240?v=4" width="100" height="100" alt="celestial-vault"/><br /><sub><b>celestial-vault</b></sub></a> | <a href="https://github.com/linegel"><img src="https://avatars.githubusercontent.com/u/1746296?v=4" width="100" height="100" alt="linegel"/><br /><sub><b>linegel</b></sub></a> | <a href="https://github.com/edwin-truthsearch-io"><img src="https://avatars.githubusercontent.com/u/211044285?v=4" width="100" height="100" alt="edwin-truthsearch-io"/><br /><sub><b>edwin-truthsearch-io</b></sub></a> | <a href="https://github.com/EamonNerbonne"><img src="https://avatars.githubusercontent.com/u/803518?v=4" width="100" height="100" alt="EamonNerbonne"/><br /><sub><b>EamonNerbonne</b></sub></a> | <a href="https://github.com/dbasclpy"><img src="https://avatars.githubusercontent.com/u/139889137?v=4" width="100" height="100" alt="dbasclpy"/><br /><sub><b>dbasclpy</b></sub></a> |
| <a href="https://github.com/dflatline"><img src="https://avatars.githubusercontent.com/u/60121893?v=4" width="100" height="100" alt="dflatline"/><br /><sub><b>dflatline</b></sub></a> | <a href="https://github.com/Deon588"><img src="https://avatars.githubusercontent.com/u/12716437?v=4" width="100" height="100" alt="Deon588"/><br /><sub><b>Deon588</b></sub></a> | <a href="https://github.com/dleen"><img src="https://avatars.githubusercontent.com/u/1297964?v=4" width="100" height="100" alt="dleen"/><br /><sub><b>dleen</b></sub></a> | <a href="https://github.com/CW-B-W"><img src="https://avatars.githubusercontent.com/u/76680670?v=4" width="100" height="100" alt="CW-B-W"/><br /><sub><b>CW-B-W</b></sub></a> | <a href="https://github.com/chadgauth"><img src="https://avatars.githubusercontent.com/u/2413356?v=4" width="100" height="100" alt="chadgauth"/><br /><sub><b>chadgauth</b></sub></a> | <a href="https://github.com/thecolorblue"><img src="https://avatars.githubusercontent.com/u/13137?v=4" width="100" height="100" alt="thecolorblue"/><br /><sub><b>thecolorblue</b></sub></a> |
| <a href="https://github.com/bogdan0083"><img src="https://avatars.githubusercontent.com/u/7077307?v=4" width="100" height="100" alt="bogdan0083"/><br /><sub><b>bogdan0083</b></sub></a> | <a href="https://github.com/benashby"><img src="https://avatars.githubusercontent.com/u/1023089?v=4" width="100" height="100" alt="benashby"/><br /><sub><b>benashby</b></sub></a> | <a href="https://github.com/Atlogit"><img src="https://avatars.githubusercontent.com/u/86947554?v=4" width="100" height="100" alt="Atlogit"/><br /><sub><b>Atlogit</b></sub></a> | <a href="https://github.com/atlasgong"><img src="https://avatars.githubusercontent.com/u/68199735?v=4" width="100" height="100" alt="atlasgong"/><br /><sub><b>atlasgong</b></sub></a> | <a href="https://github.com/andrewshu2000"><img src="https://avatars.githubusercontent.com/u/57741937?v=4" width="100" height="100" alt="andrewshu2000"/><br /><sub><b>andrewshu2000</b></sub></a> | <a href="https://github.com/andreastempsch"><img src="https://avatars.githubusercontent.com/u/117991125?v=4" width="100" height="100" alt="andreastempsch"/><br /><sub><b>andreastempsch</b></sub></a> |
| <a href="https://github.com/alasano"><img src="https://avatars.githubusercontent.com/u/14372930?v=4" width="100" height="100" alt="alasano"/><br /><sub><b>alasano</b></sub></a> | <a href="https://github.com/QuinsZouls"><img src="https://avatars.githubusercontent.com/u/40646096?v=4" width="100" height="100" alt="QuinsZouls"/><br /><sub><b>QuinsZouls</b></sub></a> | <a href="https://github.com/HadesArchitect"><img src="https://avatars.githubusercontent.com/u/1742301?v=4" width="100" height="100" alt="HadesArchitect"/><br /><sub><b>HadesArchitect</b></sub></a> | <a href="https://github.com/alarno"><img src="https://avatars.githubusercontent.com/u/4355547?v=4" width="100" height="100" alt="alarno"/><br /><sub><b>alarno</b></sub></a> | <a href="https://github.com/nexon33"><img src="https://avatars.githubusercontent.com/u/47557266?v=4" width="100" height="100" alt="nexon33"/><br /><sub><b>nexon33</b></sub></a> | <a href="https://github.com/adilhafeez"><img src="https://avatars.githubusercontent.com/u/13196462?v=4" width="100" height="100" alt="adilhafeez"/><br /><sub><b>adilhafeez</b></sub></a> |
| <a href="https://github.com/adamwlarson"><img src="https://avatars.githubusercontent.com/u/1392315?v=4" width="100" height="100" alt="adamwlarson"/><br /><sub><b>adamwlarson</b></sub></a> | <a href="https://github.com/adamhill"><img src="https://avatars.githubusercontent.com/u/188638?v=4" width="100" height="100" alt="adamhill"/><br /><sub><b>adamhill</b></sub></a> | <a href="https://github.com/AMHesch"><img src="https://avatars.githubusercontent.com/u/4777192?v=4" width="100" height="100" alt="AMHesch"/><br /><sub><b>AMHesch</b></sub></a> | <a href="https://github.com/maekawataiki"><img src="https://avatars.githubusercontent.com/u/26317009?v=4" width="100" height="100" alt="maekawataiki"/><br /><sub><b>maekawataiki</b></sub></a> | <a href="https://github.com/AlexandruSmirnov"><img src="https://avatars.githubusercontent.com/u/210187997?v=4" width="100" height="100" alt="AlexandruSmirnov"/><br /><sub><b>AlexandruSmirnov</b></sub></a> | <a href="https://github.com/samsilveira"><img src="https://avatars.githubusercontent.com/u/109295696?v=4" width="100" height="100" alt="samsilveira"/><br /><sub><b>samsilveira</b></sub></a> |
| <a href="https://github.com/01Rian"><img src="https://avatars.githubusercontent.com/u/109045233?v=4" width="100" height="100" alt="01Rian"/><br /><sub><b>01Rian</b></sub></a> | <a href="https://github.com/RSO"><img src="https://avatars.githubusercontent.com/u/139663?v=4" width="100" height="100" alt="RSO"/><br /><sub><b>RSO</b></sub></a> | <a href="https://github.com/SECKainersdorfer"><img src="https://avatars.githubusercontent.com/u/155164204?v=4" width="100" height="100" alt="SECKainersdorfer"/><br /><sub><b>SECKainersdorfer</b></sub></a> | <a href="https://github.com/R-omk"><img src="https://avatars.githubusercontent.com/u/1633879?v=4" width="100" height="100" alt="R-omk"/><br /><sub><b>R-omk</b></sub></a> | <a href="https://github.com/Sarke"><img src="https://avatars.githubusercontent.com/u/2719310?v=4" width="100" height="100" alt="Sarke"/><br /><sub><b>Sarke</b></sub></a> | <a href="https://github.com/PaperBoardOfficial"><img src="https://avatars.githubusercontent.com/u/151846514?v=4" width="100" height="100" alt="PaperBoardOfficial"/><br /><sub><b>PaperBoardOfficial</b></sub></a> |
| <a href="https://github.com/OlegOAndreev"><img src="https://avatars.githubusercontent.com/u/149705?v=4" width="100" height="100" alt="OlegOAndreev"/><br /><sub><b>OlegOAndreev</b></sub></a> | <a href="https://github.com/kvokka"><img src="https://avatars.githubusercontent.com/u/15954013?v=4" width="100" height="100" alt="kvokka"/><br /><sub><b>kvokka</b></sub></a> | <a href="https://github.com/ecmasx"><img src="https://avatars.githubusercontent.com/u/135958728?v=4" width="100" height="100" alt="ecmasx"/><br /><sub><b>ecmasx</b></sub></a> | <a href="https://github.com/mollux"><img src="https://avatars.githubusercontent.com/u/3983285?v=4" width="100" height="100" alt="mollux"/><br /><sub><b>mollux</b></sub></a> | <a href="https://github.com/marvijo-code"><img src="https://avatars.githubusercontent.com/u/82562019?v=4" width="100" height="100" alt="marvijo-code"/><br /><sub><b>marvijo-code</b></sub></a> | <a href="https://github.com/markijbema"><img src="https://avatars.githubusercontent.com/u/624143?v=4" width="100" height="100" alt="markijbema"/><br /><sub><b>markijbema</b></sub></a> |
| <a href="https://github.com/mamertofabian"><img src="https://avatars.githubusercontent.com/u/7698436?v=4" width="100" height="100" alt="mamertofabian"/><br /><sub><b>mamertofabian</b></sub></a> | <a href="https://github.com/monkeyDluffy6017"><img src="https://avatars.githubusercontent.com/u/9354193?v=4" width="100" height="100" alt="monkeyDluffy6017"/><br /><sub><b>monkeyDluffy6017</b></sub></a> | <a href="https://github.com/libertyteeth"><img src="https://avatars.githubusercontent.com/u/32841567?v=4" width="100" height="100" alt="libertyteeth"/><br /><sub><b>libertyteeth</b></sub></a> | <a href="https://github.com/shtse8"><img src="https://avatars.githubusercontent.com/u/8020099?v=4" width="100" height="100" alt="shtse8"/><br /><sub><b>shtse8</b></sub></a> | <a href="https://github.com/Rexarrior"><img src="https://avatars.githubusercontent.com/u/25753287?v=4" width="100" height="100" alt="Rexarrior"/><br /><sub><b>Rexarrior</b></sub></a> | <a href="https://github.com/kevinvandijk"><img src="https://avatars.githubusercontent.com/u/223256?v=4" width="100" height="100" alt="kevinvandijk"/><br /><sub><b>kevinvandijk</b></sub></a> |
| <a href="https://github.com/KevinZhao"><img src="https://avatars.githubusercontent.com/u/1167525?v=4" width="100" height="100" alt="KevinZhao"/><br /><sub><b>KevinZhao</b></sub></a> | <a href="https://github.com/ksze"><img src="https://avatars.githubusercontent.com/u/381556?v=4" width="100" height="100" alt="ksze"/><br /><sub><b>ksze</b></sub></a> | <a href="https://github.com/Juice10"><img src="https://avatars.githubusercontent.com/u/4106?v=4" width="100" height="100" alt="Juice10"/><br /><sub><b>Juice10</b></sub></a> | <a href="https://github.com/Fovty"><img src="https://avatars.githubusercontent.com/u/38868829?v=4" width="100" height="100" alt="Fovty"/><br /><sub><b>Fovty</b></sub></a> | <a href="https://github.com/Jdo300"><img src="https://avatars.githubusercontent.com/u/67338327?v=4" width="100" height="100" alt="Jdo300"/><br /><sub><b>Jdo300</b></sub></a> | <a href="https://github.com/hesara"><img src="https://avatars.githubusercontent.com/u/1335918?v=4" width="100" height="100" alt="hesara"/><br /><sub><b>hesara</b></sub></a> |
| <a href="https://github.com/DeXtroTip"><img src="https://avatars.githubusercontent.com/u/21011087?v=4" width="100" height="100" alt="DeXtroTip"/><br /><sub><b>DeXtroTip</b></sub></a> | | | | | |
<!-- END CONTRIBUTORS SECTION -->
## License
[Apache 2.0 © 2025 Roo Veterinary, Inc.](./LICENSE)
[Apache 2.0 © 2025 Roo Code, Inc.](./LICENSE)
---
**Enjoy Roo Code!** Whether you keep it on a short leash or let it roam autonomously, we can’t wait to see what you build. If you have questions or feature ideas, drop by our [Reddit community](https://www.reddit.com/r/RooCode/) or [Discord](https://roocode.com/discord). Happy coding!
**Enjoy Roo Code!** Whether you keep it on a short leash or let it roam autonomously, we can’t wait to see what you build. If you have questions or feature ideas, drop by our [Reddit community](https://www.reddit.com/r/RooCode/) or [Discord](https://discord.gg/roocode). Happy coding!

Some files were not shown because too many files have changed in this diff Show more