RooCodeInc · mrubens · Jun 11, 2025 · Jun 6, 2025 · Jun 6, 2025 · Jun 6, 2025
@@ -0,0 +1,14 @@
+<best_practices>
+  - Always read the entire issue and all comments before starting
+  - Follow the project's coding standards and patterns
+  - Make minimal changes for bug fixes (don't refactor unnecessarily)
+  - 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)
+</best_practices>
@@ -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>
@@ -0,0 +1,88 @@
+<github_mcp_tools_usage>
+  <primary_tools>
+    <tool name="get_issue">
+      <purpose>Retrieve the issue details at the start</purpose>
+      <when>Always use first to get the full issue content</when>
+    </tool>
+
+    <tool name="get_issue_comments">
+      <purpose>Get additional context and requirements</purpose>
+      <when>Always use after get_issue to see full discussion</when>
+    </tool>
+
+    <tool name="list_commits">
+      <purpose>Find recent changes to affected files</purpose>
+      <when>Use during codebase exploration</when>
+    </tool>
+
+    <tool name="search_code">
+      <purpose>Find code patterns on GitHub</purpose>
+      <when>Use to supplement local codebase_search</when>
+    </tool>
+  </primary_tools>
+
+  <optional_tools>
+    <tool name="add_issue_comment">
+      <purpose>Add progress updates or ask questions</purpose>
+      <when>Use if clarification needed or to show progress</when>
+    </tool>
+
+    <tool name="list_pull_requests">
+      <purpose>Find related or similar PRs</purpose>
+      <when>Use to understand similar changes</when>
+    </tool>
+
+    <tool name="get_pull_request">
+      <purpose>Get details of related PRs</purpose>
+      <when>Use when issue references specific PRs</when>
+    </tool>
+  </optional_tools>
+
+  <pull_request_tools>
+    <tool name="create_pull_request">
+      <purpose>Create a pull request to RooCodeInc/Roo-Code</purpose>
+      <when>Use in step 10 after user approval</when>
+      <important>
+        - Always target RooCodeInc/Roo-Code repository
+        - Use "main" as the base branch unless specified otherwise
+        - Include issue number in PR title
+        - Set maintainer_can_modify to true
+      </important>
+      <example>
+        <use_mcp_tool>
+        <server_name>github</server_name>
+        <tool_name>create_pull_request</tool_name>
+        <arguments>
+        {
+          "owner": "RooCodeInc",
+          "repo": "Roo-Code",
+          "title": "fix: Resolve dark theme button visibility (#123)",
+          "head": "username:fix/issue-123-dark-theme-button",
+          "base": "main",
+          "body": "## Description\n\nFixes #123\n\n[Full PR description]",
+          "draft": false,
+          "maintainer_can_modify": true
+        }
+        </arguments>
+        </use_mcp_tool>
+      </example>
+    </tool>
+
+    <tool name="fork_repository">
+      <purpose>Fork the repository if user doesn't have push access</purpose>
+      <when>Use if user needs to work from a fork</when>
+      <example>
+        <use_mcp_tool>
+        <server_name>github</server_name>
+        <tool_name>fork_repository</tool_name>
+        <arguments>
+        {
+          "owner": "RooCodeInc",
+          "repo": "Roo-Code"
+        }
+        </arguments>
+        </use_mcp_tool>
+      </example>
+    </tool>
+  </pull_request_tools>
+</github_mcp_tools_usage>
@@ -0,0 +1,30 @@
+<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
+  </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>
+
+  <after_creation>
+    1. Comment on original issue with PR link
+    2. Inform user of successful creation
+    3. Provide next steps and tracking info
+  </after_creation>
+</pull_request_workflow>
@@ -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>
@@ -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>
@@ -0,0 +1,26 @@
+<github_communication_guidelines>
+  <pr_comments>
+    - Keep comments concise and focused on technical substance
+    - Avoid overly verbose explanations unless specifically requested
+    - Sound human and conversational, not robotic
+    - Address specific feedback points directly
+    - Use bullet points for multiple changes
+    - Reference line numbers or specific code when relevant
+    - Example: "Updated the error handling in `validateInput()` to catch edge cases as requested. Also added the missing null check on line 45."
+  </pr_comments>
+
+  <issue_comments>
+    - Provide brief status updates when working on complex issues
+    - Ask specific questions if requirements are unclear
+    - 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>
@@ -0,0 +1,30 @@
+<pr_review_workflow>
+  <handling_feedback>
+    When working on PR review feedback:
+    1. Read all review comments carefully
+    2. Identify specific changes requested
+    3. Group related feedback into logical changes
+    4. Address each point systematically
+    5. Test changes thoroughly
+    6. Respond to each review comment when pushing updates
+    7. Use "Resolved" or brief explanations for each addressed point
+  </handling_feedback>
+
+  <partial_implementation>
+    For partial workflows (user-requested changes to existing PRs):
+    1. Focus only on the specific changes requested
+    2. Don't refactor unrelated code unless explicitly asked
+    3. Maintain consistency with existing PR approach
+    4. Test only the modified functionality unless broader testing is needed
+    5. Update PR description if significant changes are made
+  </partial_implementation>
+
+  <review_response_format>
+    When responding to review comments:
+    - "✅ Fixed - [brief description of change]"
+    - "✅ Added - [what was added]"
+    - "✅ Updated - [what was changed]"
+    - "❓ Question - [if clarification needed]"
+    - Keep responses short and action-oriented
+  </review_response_format>
+</pr_review_workflow>