diff --git a/.roo/commands/release.md b/.roo/commands/release.md new file mode 100644 index 0000000000..9f38080ba9 --- /dev/null +++ b/.roo/commands/release.md @@ -0,0 +1,38 @@ +--- +description: "Create a new release of the Roo Code extension" +argument-hint: patch | minor | major +--- + +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,closingIssuesReferences --limit 1000 -q '[.[] | select(.mergedAt > "TIMESTAMP") | {number, title, author: .author.login, url, mergedAt, issues: .closingIssuesReferences}] | sort_by(.number)'` +3. For each PR with linked issues, fetch the issue details to get the issue reporter: `gh issue view ISSUE_NUMBER --json number,author -q '{number, reporter: .author.login}'` +4. Summarize the changes. If the user did not specify, ask them whether this should be a major, minor, or patch release. +5. Create a changeset in .changeset/v[version].md instead of directly modifying package.json. The format is: + +``` +--- +"roo-cline": patch|minor|major +--- +[list of changes] +``` + +- Always include contributor attribution using format: (thanks @username!) +- For PRs that close issues, also include the issue number and reporter: "- Fix: Description (#123 by @reporter, PR by @contributor)" +- For PRs without linked issues, use the standard format: "- Add support for feature (thanks @contributor!)" +- Provide brief descriptions of each item to explain the change +- Order the list from most important to least important +- Example formats: + - With issue: "- Fix: Resolve memory leak in extension (#456 by @issueReporter, PR by @prAuthor)" + - Without issue: "- 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. + +6. 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) +7. Ask the user to confirm the English version +8. 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 +9. Create a new branch for the release preparation: `git checkout -b release/v[version]` +10. Commit and push the changeset file and any documentation updates to the repository: `git add . && git commit -m "chore: add changeset for v[version]" && git push origin release/v[version]` +11. Create a pull request for the release: `gh pr create --title "Release v[version]" --body "Release preparation for v[version]. This PR includes the changeset and any necessary documentation updates." --base main --head release/v[version]` +12. 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 diff --git a/.roo/rules-issue-writer/1_workflow.xml b/.roo/rules-issue-writer/1_workflow.xml index f24b643e3d..99ef7db5d9 100644 --- a/.roo/rules-issue-writer/1_workflow.xml +++ b/.roo/rules-issue-writer/1_workflow.xml @@ -3,14 +3,24 @@ Initialize Issue Creation Process - When the user requests to create an issue, immediately set up a todo list to track the workflow. + IMPORTANT: This mode assumes the first user message is already a request to create an issue. + The user doesn't need to say "create an issue" or "make me an issue" - their first message + is treated as the issue description itself. + + When the session starts, immediately: + 1. Treat the user's first message as the issue description + 2. Initialize the workflow by using the update_todo_list tool + 3. Begin the issue creation process without asking what they want to do + [ ] Detect current repository information + [ ] Determine repository structure (monorepo/standard) + [ ] Perform initial codebase discovery [ ] Analyze user request to determine issue type - [ ] Gather initial information for the issue + [ ] Gather and verify additional information [ ] Determine if user wants to contribute - [ ] Perform technical analysis (if contributing) + [ ] Perform issue scoping (if contributing) [ ] Draft issue content [ ] Review and confirm with user [ ] Create GitHub issue @@ -21,49 +31,47 @@ - Determine Issue Type + Detect current repository information - Analyze the user's initial request to automatically assess whether they're reporting a bug or proposing a feature. - Look for keywords and context clues: + CRITICAL FIRST STEP: Verify we're in a git repository and get repository information. - Bug indicators: - - Words like "error", "broken", "not working", "fails", "crash", "bug" - - Descriptions of unexpected behavior - - Error messages or stack traces - - References to something that used to work + 1. Check if we're in a git repository: + + git rev-parse --is-inside-work-tree 2>/dev/null || echo "not-git-repo" + - Feature indicators: - - Words like "feature", "enhancement", "add", "implement", "would be nice" - - Descriptions of new functionality - - Suggestions for improvements - - "It would be great if..." + If the output is "not-git-repo", immediately stop and inform the user: - Based on your analysis, order the options with the most likely choice first: + + + This mode must be run from within a GitHub repository. Please navigate to a git repository and try again. + + - - Based on your request, what type of issue would you like to create? - - [If bug indicators found:] - Bug Report - Report a problem with existing functionality - Detailed Feature Proposal - Propose a new feature or enhancement + 2. If in a git repository, get the repository information: + + git remote get-url origin 2>/dev/null | sed -E 's/.*[:/]([^/]+)\/([^/]+)(\.git)?$/\1\/\2/' | sed 's/\.git$//' + - [If feature indicators found:] - Detailed Feature Proposal - Propose a new feature or enhancement - Bug Report - Report a problem with existing functionality + Store this as REPO_FULL_NAME for use throughout the workflow. - [If unclear:] - Bug Report - Report a problem with existing functionality - Detailed Feature Proposal - Propose a new feature or enhancement - - + If no origin remote exists, stop with: + + + No GitHub remote found. This mode requires a GitHub repository with an 'origin' remote configured. + + - After determining the type, update the todo list: + Update todo after detecting repository: - [x] Analyze user request to determine issue type - [-] Gather initial information for the issue + [x] Detect current repository information + [-] Determine repository structure (monorepo/standard) + [ ] Perform initial codebase discovery + [ ] Analyze user request to determine issue type + [ ] Gather and verify additional information [ ] Determine if user wants to contribute - [ ] Perform technical analysis (if contributing) + [ ] Perform issue scoping (if contributing) [ ] Draft issue content [ ] Review and confirm with user [ ] Create GitHub issue @@ -73,37 +81,62 @@ - Gather Initial Information + Determine Repository Structure - 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. + Check if this is a monorepo or standard repository by looking for common patterns. - 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 + First, check for monorepo indicators: + 1. Look for workspace configuration: + - package.json with "workspaces" field + - lerna.json + - pnpm-workspace.yaml + - rush.json - 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) + 2. Check for common monorepo directory patterns: + + . + false + - IMPORTANT: Do NOT ask for solution design, acceptance criteria, or technical details - unless the user explicitly states they want to contribute the implementation. + Look for directories like: + - apps/ (application packages) + - packages/ (shared packages) + - services/ (service packages) + - libs/ (library packages) + - modules/ (module packages) + - src/ (main source if not using workspaces) - Use multiple ask_followup_question calls if needed to gather all information. - Be specific in your questions based on what's missing. + If monorepo detected: + - Dynamically discover packages by looking for package.json files in detected directories + - Build a list of available packages with their paths - After gathering information, update the todo: + Based on the user's description, try to identify which package they're referring to. + If unclear, ask for clarification: + + + I see this is a monorepo with multiple packages. Which specific package or application is your issue related to? + + [Dynamically generated list of discovered packages] + Let me describe which package: [specify] + + + + If standard repository: + - Skip package selection + - Use repository root for all searches + + Store the repository context for all future codebase searches and explorations. + + Update todo after determining context: - [x] Analyze user request to determine issue type - [x] Gather initial information for the issue - [-] Determine if user wants to contribute - [ ] Perform technical analysis (if contributing) + [x] Detect current repository information + [x] Determine repository structure (monorepo/standard) + [-] Perform initial codebase discovery + [ ] Analyze user request to determine issue type + [ ] Gather and verify additional information + [ ] Determine if user wants to contribute + [ ] Perform issue scoping (if contributing) [ ] Draft issue content [ ] Review and confirm with user [ ] Create GitHub issue @@ -113,33 +146,50 @@ - Determine if User Wants to Contribute + Perform Initial Codebase Discovery - Before exploring the codebase, determine if the user wants to contribute the implementation: + Now that we know the repository structure, immediately search the codebase to understand + what the user is talking about before determining the issue type. - - Are you interested in implementing this yourself, or are you just reporting the problem for the Roo team to solve? - - Just reporting the problem - the Roo team can design the solution - I want to contribute and implement this myself - I'm not sure yet, but I'd like to provide technical analysis - - + DISCOVERY ACTIVITIES: - Based on their response: - - If just reporting: Skip to step 5 (Draft Issue - Problem Only) - - If contributing: Continue to step 4 (Technical Analysis) - - If providing analysis: Continue to step 4 but make technical sections optional + 1. Extract keywords and concepts from the user's INITIAL MESSAGE (their issue description) + 2. Search the codebase to verify these concepts exist + 3. Build understanding of the actual implementation + 4. Identify relevant files, components, and code patterns - Update the todo based on the decision: + + [Keywords from user's initial message/description] + [Repository or package path from step 2] + + + Additional searches based on initial findings: + - If error mentioned: search for exact error strings + - If feature mentioned: search for related functionality + - If component mentioned: search for implementation details + + + [repository or package path] + [specific patterns found in initial search] + + + Document findings: + - Components/features found that match user's description + - Actual implementation details discovered + - Related code sections identified + - Any discrepancies between user description and code reality + + Update todos: - [x] Analyze user request to determine issue type - [x] Gather initial information for the issue - [x] Determine if user wants to contribute - [If contributing: [ ] Perform technical analysis (if contributing)] - [If not contributing: [-] Perform technical analysis (skipped - not contributing)] - [-] Draft issue content + [x] Detect current repository information + [x] Determine repository structure (monorepo/standard) + [x] Perform initial codebase discovery + [-] Analyze user request to determine issue type + [ ] Gather and verify additional information + [ ] Determine if user wants to contribute + [ ] Perform issue scoping (if contributing) + [ ] Draft issue content [ ] Review and confirm with user [ ] Create GitHub issue @@ -148,37 +198,54 @@ - Technical Analysis for Contributors + Analyze Request to Determine Issue Type - ONLY perform this step if the user wants to contribute or provide technical analysis. + Using the codebase discoveries from step 2, analyze the user's request to determine + the appropriate issue type with informed context. - This step uses the comprehensive technical analysis sub-workflow defined in - 6_technical_analysis_workflow.xml. The sub-workflow will: + CRITICAL GUIDANCE FOR ISSUE TYPE SELECTION: + For issues that affect user workflows or require behavior changes: + - PREFER the feature proposal template over bug report + - Focus on explaining WHO is affected and WHEN this happens + - Describe the user impact before diving into technical details - 1. Create its own detailed investigation todo list - 2. Perform exhaustive codebase searches using iterative refinement - 3. Analyze all relevant files and dependencies - 4. Form and validate hypotheses about the implementation - 5. Create a comprehensive technical solution - 6. Define detailed acceptance criteria + Based on your findings, classify the issue: - To execute the technical analysis sub-workflow: - - Follow all phases defined in 6_technical_analysis_workflow.xml - - Use the aggressive investigation approach from issue-investigator mode - - Document all findings in extreme detail - - Ensure the analysis is thorough enough for automated implementation + Bug indicators (verified against code): + - Error messages that match actual error handling in code + - Broken functionality in existing features found in codebase + - Regression from previous behavior documented in code/tests + - Code paths that don't work as documented - The sub-workflow will manage its own todo list for the investigation process - and will produce a comprehensive technical analysis section for the issue. + Feature indicators (verified against code): + - New functionality not found in current codebase + - Enhancement to existing features found in code + - Missing capabilities compared to similar features + - Integration points that could be extended + - WORKFLOW IMPROVEMENTS: When existing behavior works but doesn't meet user needs - After completing the technical analysis: + IMPORTANT: Use your codebase findings to inform the question: + + + Based on your request about [specific feature/component found in code], what type of issue would you like to create? + + [Order based on codebase findings and user description] + Bug Report - [Specific component] is not working as expected + Feature Proposal - Add [specific capability] to [existing component] + + + + Update todos: + [x] Detect current repository information + [x] Determine repository structure (monorepo/standard) + [x] Perform initial codebase discovery [x] Analyze user request to determine issue type - [x] Gather initial information for the issue - [x] Determine if user wants to contribute - [x] Perform technical analysis (if contributing) - [-] Draft issue content + [-] Gather and verify additional information + [ ] Determine if user wants to contribute + [ ] Perform issue scoping (if contributing) + [ ] Draft issue content [ ] Review and confirm with user [ ] Create GitHub issue @@ -187,113 +254,709 @@ - Draft Issue Content + Gather and Verify Additional Information - Create the issue body based on whether the user is just reporting or contributing. + Based on the issue type and initial codebase discovery, gather information while + continuously verifying against the actual code implementation. - For Bug Reports, format is the same regardless of contribution intent: - ``` - ## App Version - [version from user] + CRITICAL FOR FEATURE REQUESTS: Be fact-driven and challenge assumptions! + When users describe current behavior as problematic for a feature request, you MUST verify + their claims against the actual code. If their description doesn't match reality, this + might actually be a bug report, not a feature request. - ## API Provider - [provider from dropdown list] + For Bug Reports: + 1. When user describes steps to reproduce: + - Search for the UI components/commands mentioned + - Verify the code paths that would be executed + - Check for existing error handling or known issues + + 2. When user provides error messages: + - Search for exact error strings in codebase + - Find where errors are thrown + - Understand the conditions that trigger them + + 3. For version information: + - Check package.json for actual version + - Look for version-specific code or migrations - ## Model Used - [exact model name] + Example verification searches: + + [repository or package path] + [exact error message from user] + - ## 🔁 Steps to Reproduce + + [feature or component name] implementation + [repository or package path] + - 1. [First step with specific details] - 2. [Second step with exact actions] - 3. [Continue numbering all steps] + For Feature Requests - AGGRESSIVE VERIFICATION WITH CONCRETE EXAMPLES: + 1. When user claims current behavior is X: + - ALWAYS search for the actual implementation + - Read the relevant code to verify their claim + - Check CSS/styling files if UI-related + - Look at configuration files + - Examine test files to understand expected behavior + - TRACE THE DATA FLOW: Follow values from where they're calculated to where they're used + + 2. CRITICAL: Look for existing variables/code that could be reused: + - Search for variables that are calculated but not used where expected + - Identify existing patterns that could be extended + - Find similar features that work correctly for comparison + + 3. If discrepancy found between claim and code: + - Do NOT proceed without clarification + - Present CONCRETE before/after examples with actual values + - Show exactly what happens vs what should happen + - Ask if this might be a bug instead + + Example verification approach: + User says: "Feature X doesn't work properly" - Include: - - Exact button clicks or menu selections - - Specific input text or prompts used - - File names and paths involved - - Any settings or configuration + Your investigation should follow this pattern: + a) What is calculated: Search for where X is computed/defined + b) Where it's stored: Find variables/state holding the value + c) Where it's used: Trace all usages of that value + d) What's missing: Identify gaps in the flow - ## 💥 Outcome Summary + Present findings with concrete examples: - Expected: [what should have happened] - Actual: [what actually happened] + + I investigated the implementation and found something interesting: - ## 📄 Relevant Logs or Errors + Current behavior: + - The value is calculated at [file:line]: `value = computeX()` + - It's stored in variable `calculatedValue` at [file:line] + - BUT it's only used for [purpose A] at [file:line] + - It's NOT used for [purpose B] where you expected it - ```[language] - [paste any error messages or logs] - ``` + Concrete example: + - When you do [action], the system calculates [value] + - This value goes to [location A] + - But [location B] still uses [old/different value] - [If user is contributing, add the comprehensive technical analysis section from step 4] - ``` + Is this the issue you're experiencing? This seems like the calculated value isn't being used where it should be. + + Yes, exactly! The value is calculated but not used in the right place + No, the issue is that the calculation itself is wrong + Actually, I see now that [location B] should use a different value + + - For Feature Requests - PROBLEM REPORTERS (not contributing): - ``` - ## What specific problem does this solve? + 4. Continue verification until facts are established: + - If user confirms it's a bug, switch to bug report workflow + - If user provides more specific context, search again + - Do not accept vague claims without code verification + + 5. For genuine feature requests after verification: + - Document what the code currently does (with evidence and line numbers) + - Show the exact data flow: input → processing → output + - Confirm what the user wants changed with concrete examples + - Ensure the request is based on accurate understanding - [Detailed problem description following the template guidelines] + CRITICAL: For feature requests, if user's description doesn't match codebase reality: + - Challenge the assumption with code evidence AND concrete examples + - Show actual vs expected behavior with specific values + - Suggest it might be a bug if code shows different intent + - Ask for clarification repeatedly if needed + - Do NOT proceed until facts are established - **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] + Only proceed when you have: + - Verified current behavior in code with line-by-line analysis + - Confirmed user's understanding matches reality + - Determined if it's truly a feature request or actually a bug + - Identified any existing code that could be reused for the fix - ## Additional context - - [Any mockups, screenshots, links, or other supporting information] - ``` - - 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** - - [Insert the comprehensive technical analysis section from step 4, including:] - - Root cause / Implementation target - - Affected components with file paths and line numbers - - Current implementation analysis - - Detailed proposed implementation steps - - Code architecture considerations - - Testing requirements - - Performance impact - - Security considerations - - Migration strategy - - Rollback plan - - Dependencies and breaking changes - - Implementation complexity assessment - - ## Acceptance Criteria - - [Insert the detailed acceptance criteria from the technical analysis] - ``` - - After drafting: + Update todos after verification: + [x] Detect current repository information + [x] Determine repository structure (monorepo/standard) + [x] Perform initial codebase discovery [x] Analyze user request to determine issue type - [x] Gather initial information for the issue + [x] Gather and verify additional information + [-] Determine if user wants to contribute + [ ] Perform issue scoping (if contributing) + [ ] Draft issue content + [ ] Review and confirm with user + [ ] Create GitHub issue + + + + + + + Determine Contribution Intent with Context + + Before asking about contribution, perform a quick technical assessment to provide context: + + 1. Search for complexity indicators: + - Number of files that would need changes + - Existing tests that would need updates + - Dependencies and integration points + + 2. Look for contribution helpers: + - CONTRIBUTING.md guidelines + - Existing similar implementations + - Test patterns to follow + + + CONTRIBUTING guide setup development + + + Based on findings, provide informed context in the question: + + + Based on my analysis, this [issue type] involves [brief complexity assessment from code exploration]. Are you interested in implementing this yourself, or are you reporting it for the project team to handle? + + Just reporting the problem - the project team can design the solution + I want to contribute and implement this myself + I'd like to provide issue scoping to help whoever implements it + + + + Update todos based on response: + + + [x] Detect current repository information + [x] Determine repository structure (monorepo/standard) + [x] Perform initial codebase discovery + [x] Analyze user request to determine issue type + [x] Gather and verify additional information [x] Determine if user wants to contribute - [x] Perform technical analysis (if contributing) + [If contributing: [-] Perform issue scoping (if contributing)] + [If not contributing: [-] Perform issue scoping (skipped - not contributing)] + [-] Draft issue content + [ ] Review and confirm with user + [ ] Create GitHub issue + + + + + + + Issue Scoping for Contributors + + ONLY perform this step if the user wants to contribute or provide issue scoping. + + This step performs a comprehensive, aggressive investigation to create detailed technical + scoping that can guide implementation. The process involves multiple sub-phases: + + + + Perform an exhaustive investigation to produce a comprehensive technical solution + with extreme detail, suitable for automated fix workflows. + + + + Expand the todo list to include detailed investigation steps + + When starting the issue scoping phase, update the main todo list to include + the detailed investigation steps: + + + + [x] Detect current repository information + [x] Determine repository structure (monorepo/standard) + [x] Perform initial codebase discovery + [x] Analyze user request to determine issue type + [x] Gather and verify additional information + [x] Determine if user wants to contribute + [-] Perform issue scoping (if contributing) + [ ] Extract keywords from the issue description + [ ] Perform initial broad codebase search + [ ] Analyze search results and identify key components + [ ] Deep dive into relevant files and implementations + [ ] Form initial hypothesis about the issue/feature + [ ] Attempt to disprove hypothesis through further investigation + [ ] Identify all affected files and dependencies + [ ] Map out the complete implementation approach + [ ] Document technical risks and edge cases + [ ] Formulate comprehensive technical solution + [ ] Create detailed acceptance criteria + [ ] Prepare issue scoping summary + [ ] Draft issue content + [ ] Review and confirm with user + [ ] Create GitHub issue + + + + + + + Extract all relevant keywords, concepts, and technical terms + + - Identify primary technical concepts from user's description + - Extract error messages or specific symptoms + - Note any mentioned file paths or components + - List related features or functionality + - Include synonyms and related terms + + + Update the main todo list to mark "Extract keywords" as complete and move to next phase + + + + + Perform multiple rounds of increasingly focused searches + + + Use codebase_search with all extracted keywords to get an overview of relevant code. + + [Combined keywords from extraction phase] + [Repository or package path] + + + + + Based on initial results, identify key components and search for: + - Related class/function definitions + - Import statements and dependencies + - Configuration files + - Test files that might reveal expected behavior + + + + Search for specific implementation details: + - Error handling patterns + - State management + - API endpoints or routes + - Database queries or models + - UI components and their interactions + + + + Look for: + - Edge cases in the code + - Integration points with other systems + - Configuration options that affect behavior + - Feature flags or conditional logic + + + + After completing all search iterations, update the todo list to show progress + + + + + Thoroughly analyze all relevant files discovered + + - Use list_code_definition_names to understand file structure + - Read complete files to understand full context + - Trace execution paths through the code + - Identify all dependencies and imports + - Map relationships between components + + + Document findings including: + - File paths and their purposes + - Key functions and their responsibilities + - Data flow through the system + - External dependencies + - Potential impact areas + + + + + Form a comprehensive hypothesis about the issue or feature + + - Identify the most likely root cause + - Trace the bug through the execution path + - Determine why the current implementation fails + - Consider environmental factors + + + - Identify the optimal integration points + - Determine required architectural changes + - Plan the implementation approach + - Consider scalability and maintainability + + + + + Aggressively attempt to disprove the hypothesis + + + - Look for similar features implemented differently + - Check for deprecated code that might interfere + + + - Search for configuration that could change behavior + - Look for environment-specific code paths + + + - Find existing tests that might contradict hypothesis + - Look for test cases that reveal edge cases + + + - Search for comments explaining design decisions + - Look for TODO or FIXME comments related to the area + + + + If hypothesis is disproven, return to search phase with new insights. + If hypothesis stands, proceed to solution formulation. + + + + + Create a comprehensive technical solution - PRIORITIZE SIMPLICITY + + CRITICAL: Before proposing any solution, ask yourself: + 1. What existing variables/functions can I reuse? + 2. What's the minimal change that fixes the issue? + 3. Can I leverage existing patterns in the codebase? + 4. Is there a simpler approach I'm overlooking? + + The best solution often reuses existing code rather than creating new complexity. + + + + ALWAYS consider backwards compatibility: + 1. Will existing data/configurations still work with the new code? + 2. Can we detect and handle legacy formats automatically? + 3. What migration paths are needed for existing users? + 4. Are there ways to make changes additive rather than breaking? + 5. Document any compatibility considerations clearly + + + + FIRST, identify what can be reused: + - Variables that are already calculated but not used where needed + - Functions that already do what we need + - Patterns in similar features we can follow + - Configuration that already exists but isn't applied + + Example finding: + "The variable `calculatedValue` already contains what we need at line X, + we just need to use it at line Y instead of recalculating" + + + + - Start with the SIMPLEST possible fix + - Exact files to modify with line numbers + - Prefer changing variable usage over creating new logic + - Specific code changes required (minimal diff) + - Order of implementation steps + - Migration strategy if needed + + + + - All files that import affected code + - API contracts that must be maintained + - Existing tests that validate current behavior + - Configuration changes required (prefer reusing existing) + - Documentation updates needed + + + + - Unit tests to add or modify + - Integration tests required + - Edge cases to test + - Performance testing needs + - Manual testing scenarios + + + + - Breaking changes identified + - Performance implications + - Security considerations + - Backward compatibility issues + - Rollback strategy + + + + + + Create extremely detailed acceptance criteria + + Given [detailed context including system state] + When [specific user or system action] + Then [exact expected outcome] + And [additional verifiable outcomes] + But [what should NOT happen] + + Include: + - Specific UI changes with exact text/behavior + - API response formats + - Database state changes + - Performance requirements + - Error handling scenarios + + + - Each criterion must be independently testable + - Include both positive and negative test cases + - Specify exact error messages and codes + - Define performance thresholds where applicable + + + + + Format the comprehensive issue scoping section + + + + + Additional considerations for monorepo repositories: + - Scope all searches to the identified package (if monorepo) + - Check for cross-package dependencies + - Verify against package-specific conventions + - Look for package-specific configuration + - Check if changes affect multiple packages + - Identify shared dependencies that might be impacted + - Look for workspace-specific scripts or tooling + - Consider package versioning implications + + After completing the comprehensive issue scoping, update the main todo list to show + all investigation steps are complete: + + + [x] Detect current repository information + [x] Determine repository structure (monorepo/standard) + [x] Perform initial codebase discovery + [x] Analyze user request to determine issue type + [x] Gather and verify additional information + [x] Determine if user wants to contribute + [x] Perform issue scoping (if contributing) + [x] Extract keywords from the issue description + [x] Perform initial broad codebase search + [x] Analyze search results and identify key components + [x] Deep dive into relevant files and implementations + [x] Form initial hypothesis about the issue/feature + [x] Attempt to disprove hypothesis through further investigation + [x] Identify all affected files and dependencies + [x] Map out the complete implementation approach + [x] Document technical risks and edge cases + [x] Formulate comprehensive technical solution + [x] Create detailed acceptance criteria + [x] Prepare issue scoping summary + [-] Draft issue content + [ ] Review and confirm with user + [ ] Create GitHub issue + + + + + + + Check for Repository Issue Templates + + Check if the repository has custom issue templates and use them. If not, create a simple generic template. + + 1. Check for issue templates in standard locations: + + .github/ISSUE_TEMPLATE + true + + + 2. Also check for single template file: + + .github + false + + + Look for files like: + - .github/ISSUE_TEMPLATE/*.md + - .github/ISSUE_TEMPLATE/*.yml + - .github/ISSUE_TEMPLATE/*.yaml + - .github/issue_template.md + - .github/ISSUE_TEMPLATE.md + + 3. If templates are found: + a. Parse the template files to extract: + - Template name and description + - Required fields + - Template body structure + - Labels to apply + + b. For YAML templates, look for: + - name: Template display name + - description: Template description + - labels: Default labels + - body: Form fields or markdown template + + c. For Markdown templates, look for: + - Front matter with metadata + - Template structure with placeholders + + 4. If multiple templates exist, ask user to choose: + + I found the following issue templates in this repository. Which one would you like to use? + + [Template 1 name]: [Template 1 description] + [Template 2 name]: [Template 2 description] + + + + 5. If no templates are found: + - Create a simple generic template based on issue type + - For bugs: Basic structure with description, steps to reproduce, expected vs actual + - For features: Problem description, proposed solution, impact + + 6. Store the selected/created template information: + - Template content/structure + - Required fields + - Default labels + - Any special formatting requirements + + Update todos: + + + [x] Detect current repository information + [x] Determine repository structure (monorepo/standard) + [x] Perform initial codebase discovery + [x] Analyze user request to determine issue type + [x] Gather and verify additional information + [x] Determine if user wants to contribute + [x] Perform issue scoping (if contributing) + [x] Check for repository issue templates + [-] Draft issue content + [ ] Review and confirm with user + [ ] Create GitHub issue + + + + + + + Draft Issue Content + + Create the issue body using the template from step 8 and all verified information from codebase exploration. + + If using a repository template: + - Fill in the template fields with gathered information + - Include code references and findings where appropriate + - Respect the template's structure and formatting + + If using a generated template (no repo templates found): + + For Bug Reports: + ``` + ## Description + [Clear description of the bug with code context] + + ## Steps to Reproduce + 1. [Step with relevant code paths] + 2. [Step with component references] + 3. [Continue with specific details] + + ## Expected Behavior + [What should happen based on code logic] + + ## Actual Behavior + [What actually happens] + + ## Additional Context + - Version: [from package.json if found] + - Environment: [any relevant details] + - Error logs: [if any] + + ## Code Investigation + [Include findings from codebase exploration] + - Relevant files: [list with line numbers] + - Possible cause: [hypothesis from code review] + + [If user is contributing, add the comprehensive issue scoping section from step 7] + ``` + + For Feature Requests: + ``` + ## Problem Description + [What problem does this solve, who is affected, when it happens] + + ## Current Behavior + [How it works now with specific examples] + + ## Proposed Solution + [What should change] + + ## Impact + [Who benefits and how] + + ## Technical Context + [Findings from codebase exploration] + - Similar features: [code references] + - Integration points: [from exploration] + - Architecture considerations: [if any] + + [If contributing, add the comprehensive issue scoping section from step 7] + ``` + + Update todos: + + + [x] Detect current repository information + [x] Determine repository structure (monorepo/standard) + [x] Perform initial codebase discovery + [x] Analyze user request to determine issue type + [x] Gather and verify additional information + [x] Determine if user wants to contribute + [x] Perform issue scoping (if contributing) + [x] Check for repository issue templates [x] Draft issue content [-] Review and confirm with user [ ] Create GitHub issue @@ -302,19 +965,26 @@ - + Review and Confirm with User - Present the complete drafted issue to the user for review: + Present the complete drafted issue to the user for review, highlighting the + code-verified information: - I've prepared the following GitHub issue. Please review it carefully: + I've prepared the following GitHub issue based on my analysis of the codebase and your description. I've verified the technical details against the actual implementation. Please review: [Show the complete formatted issue content] + Key verifications made: + - ✓ Component locations confirmed in code + - ✓ Error messages matched to source + - ✓ Architecture compatibility checked + [List other relevant verifications] + Would you like me to create this issue, or would you like to make any changes? - Yes, create this issue in RooCodeInc/Roo-Code + Yes, create this issue in the detected repository Modify the problem description Add more technical details Change the title to: [let me specify] @@ -326,57 +996,164 @@ After confirmation: + [x] Detect current repository information + [x] Determine repository structure (monorepo/standard) + [x] Perform initial codebase discovery [x] Analyze user request to determine issue type - [x] Gather initial information for the issue + [x] Gather and verify additional information [x] Determine if user wants to contribute - [x] Perform technical analysis (if contributing) + [x] Perform issue scoping (if contributing) + [x] Check for repository issue templates [x] Draft issue content [x] Review and confirm with user - [-] Create GitHub issue + [-] Prepare issue for submission + [ ] Handle submission choice - - Create GitHub Issue + + Prepare Issue for Submission - Once user confirms, create the issue using the GitHub CLI: + Once user confirms the issue content, prepare it for submission: - First, save the issue body to a temporary file: + First, perform final duplicate check with refined search based on our findings: - cat > /tmp/issue_body.md << 'EOF' -[The complete formatted issue body from step 5] -EOF + gh issue list --repo $REPO_FULL_NAME --search "[key terms from verified analysis]" --state all --limit 10 - Then create the issue: - - 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" - + If no exact duplicates are found, save the issue content to a temporary file within the project: - For feature requests, use labels "proposal,enhancement": - - 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" - + + ./github_issue_draft.md + [The complete formatted issue body from step 8] + [calculated line count] + - The command will return the issue URL. Inform the user of the created issue number and URL. + After saving the issue draft, ask the user how they would like to proceed: - Clean up the temporary file: - - rm /tmp/issue_body.md - + + I've saved the issue draft to ./github_issue_draft.md. The issue is ready for submission with the following details: + + Title: "[Descriptive title with component name]" + Labels: [appropriate labels based on issue type] + Repository: $REPO_FULL_NAME + + How would you like to proceed? + + Submit the issue now to the repository + Let me make some edits to the issue first + I'll submit it manually later + + - Complete the workflow: + Based on the user's response: + + If "Submit the issue now": + - Use gh issue create with the saved file + - Provide the created issue URL and number + - Clean up the temporary file + - Complete the workflow + + If "Let me make some edits": + - Ask what changes they'd like to make + - Update the draft file with their changes + - Return to the submission question + + If "I'll submit it manually": + - Inform them the draft is saved at the configured location + - Provide the gh command they can use later + - Complete the workflow without submission + + Update todos based on the outcome: + [x] Detect current repository information + [x] Determine repository structure (monorepo/standard) + [x] Perform initial codebase discovery [x] Analyze user request to determine issue type - [x] Gather initial information for the issue + [x] Gather and verify additional information [x] Determine if user wants to contribute - [x] Perform technical analysis (if contributing) + [x] Perform issue scoping (if contributing) + [x] Check for repository issue templates [x] Draft issue content [x] Review and confirm with user - [x] Create GitHub issue + [x] Prepare issue for submission + [-] Handle submission choice + + + + + + + Handle Submission Choice + + This step handles the user's choice from step 9. + + OPTION 1: Submit the issue now + If the user chooses to submit immediately: + + + gh issue create --repo $REPO_FULL_NAME --title "[Descriptive title]" --body-file ./github_issue_draft.md --label "[appropriate labels]" + + + Label selection based on findings: + - Bug: Use "bug" label + - Feature: Use "enhancement" label + - If affects multiple packages in monorepo: add "affects-multiple" label + + After successful creation: + - Capture and display the issue URL + - Clean up the temporary file: + + rm ./github_issue_draft.md + + - Provide a summary of key findings included + + OPTION 2: Make edits + If the user wants to edit: + + + What changes would you like to make to the issue? + + Update the title + Modify the problem description + Add or remove technical details + Change the labels or other metadata + + + + - Apply the requested changes to the draft + - Update the file with write_to_file + - Return to step 9 to ask about submission again + + OPTION 3: Manual submission + If the user will submit manually: + + Provide clear instructions: + "The issue draft has been saved to ./github_issue_draft.md + + To submit it later, you can use: + gh issue create --repo $REPO_FULL_NAME --title "[Your title]" --body-file ./github_issue_draft.md --label "[labels]" + + Or you can copy the content and create the issue through the GitHub web interface." + + Final todo update: + + + [x] Detect current repository information + [x] Determine repository structure (monorepo/standard) + [x] Perform initial codebase discovery + [x] Analyze user request to determine issue type + [x] Gather and verify additional information + [x] Determine if user wants to contribute + [x] Perform issue scoping (if contributing) + [x] Check for repository issue templates + [x] Draft issue content + [x] Review and confirm with user + [x] Prepare issue for submission + [x] Handle submission choice diff --git a/.roo/rules-issue-writer/2_github_issue_templates.xml b/.roo/rules-issue-writer/2_github_issue_templates.xml index 3130f2026e..36b44125dd 100644 --- a/.roo/rules-issue-writer/2_github_issue_templates.xml +++ b/.roo/rules-issue-writer/2_github_issue_templates.xml @@ -1,219 +1,190 @@ - - Bug Report - Clearly report a bug with detailed repro steps - ["bug"] - - - - What version of Roo Code are you using? (e.g., v3.3.1) - - - - - - 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 - - - - - Exact model name (e.g., Claude 3.7 Sonnet). Use N/A if irrelevant. - - - - - 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. - - - - - - Recap what went wrong in one or two lines. - - Example: "Expected code to run, but got an empty response and no error." - - Expected ___, but got ___. - - - - Paste API logs, terminal output, or errors here. Use triple backticks (```) for code formatting. - shell - - - - - - Detailed Feature Proposal - Report a specific problem that needs solving in Roo Code - ["proposal", "enhancement"] - - - - - **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.) - - Be specific about the problem, who it affects, and the impact. Avoid generic statements like "it's slow" or "it's confusing." - - - - Mockups, screenshots, links, user quotes, or other relevant information that supports your proposal. - - + + This mode prioritizes using repository-specific issue templates over hardcoded ones. + If no templates exist in the repository, simple generic templates are created on the fly. + + + + + .github/ISSUE_TEMPLATE/*.yml + .github/ISSUE_TEMPLATE/*.yaml + .github/ISSUE_TEMPLATE/*.md + .github/issue_template.md + .github/ISSUE_TEMPLATE.md + - - - - - **Important:** If you check "Yes" below, the technical sections become REQUIRED. - We need detailed technical analysis from contributors to ensure quality implementation. - - - - - - - - - - - **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? - - Describe the specific changes and how they will work. Include user interaction details if relevant. - - - - - **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 - ``` - - - 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. - - - - - - **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 - - e.g., "Will need to refactor task manager", "Could impact memory usage on large files", "Requires a large portion of code to be rewritten" - - - - - **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 - - e.g., "Alternative: use library X but it is 500KB larger", "Risk: might slow older devices", "Breaking: changes API response format" - - - - - - - Template now focuses on problem reporting first, with solution contribution as optional - - - Only problem description and context are required for basic submission - - - Technical fields (solution, acceptance criteria, etc.) are only required if user wants to contribute - - - Users can submit after describing the problem without technical details - - - Implementation guidance moved to contributor section only - - + + Display name of the template + Brief description of when to use this template + Default issue title (optional) + Array of labels to apply + Array of default assignees + Array of form elements or markdown content + + + + + Static markdown content + + The markdown content to display + + + + + Single-line text input + + Unique identifier + Display label + Help text + Placeholder text + Default value + Boolean + + + + + Multi-line text input + + Unique identifier + Display label + Help text + Placeholder text + Default value + Boolean + Language for syntax highlighting + + + + + Dropdown selection + + Unique identifier + Display label + Help text + Array of options + Boolean + + + + + Multiple checkbox options + + Unique identifier + Display label + Help text + Array of checkbox items + + + + + + + Optional YAML front matter with: + - name: Template name + - about: Template description + - title: Default title + - labels: Comma-separated or array + - assignees: Comma-separated or array + + + Markdown content with sections and placeholders + Common patterns: + - Headers with ## + - Placeholder text in brackets or as comments + - Checklists with - [ ] + - Code blocks with ``` + + + + + + + When no repository templates exist, create simple templates based on issue type. + These should be minimal and focused on gathering essential information. + + + + + - Description: Clear explanation of the bug + - Steps to Reproduce: Numbered list + - Expected Behavior: What should happen + - Actual Behavior: What actually happens + - Additional Context: Version, environment, logs + - Code Investigation: Findings from exploration (if any) + + ["bug"] + + + + + - Problem Description: What problem this solves + - Current Behavior: How it works now + - Proposed Solution: What should change + - Impact: Who benefits and how + - Technical Context: Code findings (if any) + + ["enhancement", "proposal"] + + + + + + When parsing YAML templates: + 1. Use a YAML parser to extract the structure + 2. Convert form elements to markdown sections + 3. Preserve required field indicators + 4. Include descriptions as help text + 5. Maintain the intended flow of the template + + + + When parsing Markdown templates: + 1. Extract front matter if present + 2. Identify section headers + 3. Look for placeholder patterns + 4. Preserve formatting and structure + 5. Replace generic placeholders with user's information + + + + For template selection: + 1. If only one template exists, use it automatically + 2. If multiple exist, let user choose based on name/description + 3. Match template to issue type when possible (bug vs feature) + 4. Respect template metadata (labels, assignees, etc.) + + + + + + Fill templates intelligently using gathered information: + - Map user's description to appropriate sections + - Include code investigation findings where relevant + - Preserve template structure and formatting + - Don't leave placeholder text unfilled + - Add contributor scoping if user is contributing + + + + + + + + + + + + + When no templates exist, create appropriate generic templates on the fly. + Keep them simple and focused on essential information. + + + + - Don't overwhelm with too many fields + - Focus on problem description first + - Include technical details only if user is contributing + - Use clear, simple section headers + - Adapt based on issue type (bug vs feature) + + \ No newline at end of file diff --git a/.roo/rules-issue-writer/3_best_practices.xml b/.roo/rules-issue-writer/3_best_practices.xml index 6d70cba144..f2f149ed26 100644 --- a/.roo/rules-issue-writer/3_best_practices.xml +++ b/.roo/rules-issue-writer/3_best_practices.xml @@ -1,38 +1,172 @@ + + - CRITICAL: This mode assumes the user's FIRST message is already an issue description + - Do NOT ask "What would you like to do?" or "Do you want to create an issue?" + - Immediately start the issue creation workflow when the user begins talking + - Treat their initial message as the problem/feature description + - Begin with repository detection and codebase discovery right away + - The user is already in "issue creation mode" by choosing this mode + + + + - ALWAYS check for repository-specific issue templates before creating issues + - Use templates from .github/ISSUE_TEMPLATE/ directory if they exist + - Parse both YAML (.yml/.yaml) and Markdown (.md) template formats + - If multiple templates exist, let the user choose the appropriate one + - If no templates exist, create a simple generic template on the fly + - NEVER fall back to hardcoded templates - always use repo templates or generate minimal ones + - Respect template metadata like labels, assignees, and title patterns + - Fill templates intelligently using gathered information from codebase exploration + + - Focus on helping users describe problems clearly, not solutions - - The Roo team will design solutions unless the user explicitly wants to contribute + - The project 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 + + CRITICAL: Lead with user impact: + - Always explain WHO is affected and WHEN the problem occurs + - Use concrete examples with actual values, not abstractions + - Show before/after scenarios with specific data + - Example: "Users trying to [action] see [actual result] instead of [expected result]" + + - ALWAYS verify user claims against actual code implementation + - For feature requests, aggressively check if current behavior matches user's description + - If code shows different intent than user describes, it might be a bug not a feature + - Present code evidence when challenging user assumptions + - Do not be agreeable - be fact-driven and question discrepancies + - Continue verification until facts are established + - A "feature request" where code shows the feature should already work is likely a bug + + CRITICAL additions for thorough analysis: + - Trace data flow from where values are created to where they're used + - Look for existing variables/functions that already contain needed data + - Check if the issue is just missing usage of existing code + - Follow imports and exports to understand data availability + - Identify patterns in similar features that work correctly + + - Always search for existing similar issues before creating a new one - - Search GitHub Discussions (especially feature-requests category) for related topics + - Check for and use repository issue templates before creating content - 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 + + CRITICAL: Use concrete examples throughout: + - Show actual data values, not just descriptions + - Include specific file paths and line numbers + - Demonstrate the data flow with real examples + - Bad: "The value is incorrect" + - Good: "The function returns '123' when it should return '456'" - - Only explore codebase if user wants to contribute + - Only perform issue scoping 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 + - Include implementation steps and issue scoping - Provide clear acceptance criteria in Given/When/Then format - Consider trade-offs and alternative approaches + + CRITICAL: Prioritize simple solutions: + - ALWAYS check if needed functionality already exists before proposing new code + - Look for existing variables that just need to be passed/used differently + - Prefer using existing patterns over creating new ones + - The best fix often involves minimal code changes + - Example: "Use existing `modeInfo` from line 234 in export" vs "Create new mode tracking system" + + ALWAYS consider backwards compatibility: + - Think about existing data/configurations already in use + - Propose solutions that handle both old and new formats gracefully + - Consider migration paths for existing users + - Document any breaking changes clearly + - Prefer additive changes over breaking changes when possible + + - 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 + - When presenting template choices, include template descriptions to help users choose + - Explain that you're using the repository's own templates for consistency + + + + Always check these locations in order: + 1. .github/ISSUE_TEMPLATE/*.yml or *.yaml (GitHub form syntax) + 2. .github/ISSUE_TEMPLATE/*.md (Markdown templates) + 3. .github/issue_template.md (single template) + 4. .github/ISSUE_TEMPLATE.md (alternate naming) + + + + For YAML templates: + - Extract form elements and convert to appropriate markdown sections + - Preserve required field indicators + - Include field descriptions as context + - Respect dropdown options and checkbox lists + + For Markdown templates: + - Parse front matter for metadata + - Identify section headers and structure + - Replace placeholder text with actual information + - Maintain formatting and hierarchy + + + + - Map gathered information to template sections intelligently + - Don't leave placeholder text in the final issue + - Add code investigation findings to relevant sections + - Include contributor scoping in appropriate section if applicable + - Preserve the template's intended structure and flow + + + + When no templates exist: + - Create minimal, focused templates + - Use simple section headers + - Focus on essential information only + - Adapt structure based on issue type + - Don't overwhelm with unnecessary fields + + + + + Before proposing ANY solution: + 1. Use codebase_search extensively to find all related code + 2. Read multiple files to understand the full context + 3. Trace variable usage from creation to consumption + 4. Look for similar working features to understand patterns + 5. Identify what already exists vs what's actually missing + + + + When designing solutions: + 1. Check if the data/function already exists somewhere + 2. Look for configuration options before code changes + 3. Prefer passing existing variables over creating new ones + 4. Use established patterns from similar features + 5. Aim for minimal diff size + + + + Always include: + - Exact file paths and line numbers + - Variable/function names as they appear in code + - Before/after code snippets showing minimal changes + - Clear explanation of why the simple fix works + + \ No newline at end of file diff --git a/.roo/rules-issue-writer/4_common_mistakes_to_avoid.xml b/.roo/rules-issue-writer/4_common_mistakes_to_avoid.xml index 2013bd73d8..a8dd9b590b 100644 --- a/.roo/rules-issue-writer/4_common_mistakes_to_avoid.xml +++ b/.roo/rules-issue-writer/4_common_mistakes_to_avoid.xml @@ -1,4 +1,13 @@ + + - CRITICAL: Asking "What would you like to do?" when mode starts + - Waiting for user to say "create an issue" or "make me an issue" + - Not treating the first user message as the issue description + - Delaying the workflow start with unnecessary questions + - Asking if they want to create an issue when they've already chosen this mode + - Not immediately beginning repository detection and codebase discovery + + - Vague descriptions like "doesn't work" or "broken" - Missing reproduction steps for bugs @@ -12,19 +21,106 @@ - Asking for technical details from non-contributing users - - Exploring codebase before confirming user wants to contribute + - Performing issue scoping 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 + - Using hardcoded templates instead of repository templates + - Not checking for issue templates before creating content + - Ignoring template metadata like labels and assignees - Starting implementation before approval - - Not providing detailed technical analysis when contributing + - Not providing detailed issue scoping 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 + + + Not tracing data flow completely through the system + Missing that data already exists leads to proposing unnecessary new code + + - Use codebase_search extensively to find ALL related code + - Trace variables from creation to consumption + - Check if needed data is already calculated but not used + - Look for similar working features as patterns + + + Bad: "Add mode tracking to import function" + Good: "The export already includes mode info at line 234, just use it in import at line 567" + + + + + Proposing complex new systems when simple fixes exist + Creates unnecessary complexity, maintenance burden, and potential bugs + + - ALWAYS check if functionality already exists first + - Look for minimal changes that solve the problem + - Prefer using existing variables/functions differently + - Aim for the smallest possible diff + + + Bad: "Create new state management system for mode tracking" + Good: "Pass existing modeInfo variable from line 45 to the function at line 78" + + + + + Not reading actual code before proposing solutions + Solutions don't match the actual codebase structure + + - Always read the relevant files first + - Verify exact line numbers and content + - Check imports/exports to understand data availability + - Look at similar features that work correctly + + + + + Creating new patterns instead of following existing ones + Inconsistent codebase, harder to maintain + + - Find similar features that work correctly + - Follow the same patterns and structures + - Reuse existing utilities and helpers + - Maintain consistency with the codebase style + + + + + Using hardcoded templates when repository templates exist + Issues don't follow repository conventions, may be rejected or need reformatting + + - Always check .github/ISSUE_TEMPLATE/ directory first + - Parse and use repository templates when available + - Only create generic templates when none exist + + + + + Not properly parsing YAML template structure + Missing required fields, incorrect formatting, lost metadata + + - Parse YAML templates to extract all form elements + - Convert form elements to appropriate markdown sections + - Preserve field requirements and descriptions + - Maintain dropdown options and checkbox lists + + + + + Leaving placeholder text in final issue + Unprofessional appearance, confusion about what information is needed + + - Replace all placeholders with actual information + - Remove instruction text meant for template users + - Fill every section with relevant content + - Add "N/A" for truly inapplicable sections + + \ No newline at end of file diff --git a/.roo/rules-issue-writer/5_github_cli_usage.xml b/.roo/rules-issue-writer/5_github_cli_usage.xml index 8beb024d15..1792be87eb 100644 --- a/.roo/rules-issue-writer/5_github_cli_usage.xml +++ b/.roo/rules-issue-writer/5_github_cli_usage.xml @@ -3,9 +3,8 @@ 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. + Note: This mode prioritizes using repository-specific issue templates over + hardcoded ones. Templates are detected and used dynamically from the repository. @@ -16,7 +15,7 @@ - gh issue list --repo RooCodeInc/Roo-Code --search "dark theme button visibility" --state all --limit 20 + gh issue list --repo $REPO_FULL_NAME --search "dark theme button visibility" --state all --limit 20 @@ -35,7 +34,7 @@ - gh search issues --repo RooCodeInc/Roo-Code "dark theme button" --limit 10 + gh search issues --repo $REPO_FULL_NAME "dark theme button" --limit 10 @@ -47,7 +46,7 @@ - gh issue view 123 --repo RooCodeInc/Roo-Code --comments + gh issue view 123 --repo $REPO_FULL_NAME --comments @@ -58,6 +57,46 @@ + + + + Use to check for issue templates in the repository before creating issues. + This is not a gh command but necessary for template detection. + + + Check for templates in standard location: + + .github/ISSUE_TEMPLATE + true + + + Check for single template file: + + .github + false + + + + + + + Read template files to parse their structure and content. + Used after detecting template files. + + + Read YAML template: + + .github/ISSUE_TEMPLATE/bug_report.yml + + + Read Markdown template: + + .github/ISSUE_TEMPLATE/feature_request.md + + + + + These commands should ONLY be used if the user has indicated they want to @@ -70,7 +109,7 @@ - gh repo view RooCodeInc/Roo-Code --json defaultBranchRef,description,updatedAt + gh repo view $REPO_FULL_NAME --json defaultBranchRef,description,updatedAt @@ -82,7 +121,7 @@ - gh search prs --repo RooCodeInc/Roo-Code "dark theme" --limit 10 --state all + gh search prs --repo $REPO_FULL_NAME "dark theme" --limit 10 --state all @@ -105,18 +144,19 @@ 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 + 2. Checking for and using repository templates + 3. Gathering all required information + 4. Determining if user is contributing or just reporting + 5. Getting user confirmation - gh issue create --repo RooCodeInc/Roo-Code --title "[Descriptive title of the bug]" --body-file /tmp/issue_body.md --label "bug" + gh issue create --repo $REPO_FULL_NAME --title "[Descriptive title of the bug]" --body-file /tmp/issue_body.md --label "bug" - gh issue create --repo RooCodeInc/Roo-Code --title "[Problem-focused title]" --body-file /tmp/issue_body.md --label "proposal" --label "enhancement" + gh issue create --repo $REPO_FULL_NAME --title "[Problem-focused title]" --body-file /tmp/issue_body.md --label "proposal" --label "enhancement" @@ -138,7 +178,7 @@ - gh issue comment 456 --repo RooCodeInc/Roo-Code --body "Additional context or comments." + gh issue comment 456 --repo $REPO_FULL_NAME --body "Additional context or comments." @@ -150,7 +190,7 @@ - gh issue edit 456 --repo RooCodeInc/Roo-Code --title "[Updated title]" --body "[Updated body]" + gh issue edit 456 --repo $REPO_FULL_NAME --title "[Updated title]" --body "[Updated body]" @@ -164,41 +204,41 @@ 3. Ask if they want to continue or comment on existing issue - - 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 - + + Template detection (NEW): + 1. Use list_files to check .github/ISSUE_TEMPLATE/ directory + 2. Read any template files found (YAML or Markdown) + 3. Parse template structure and metadata + 4. If multiple templates, let user choose + 5. If no templates, prepare to create generic one + - + 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 - + - + During codebase exploration (CONTRIBUTORS ONLY): - 1. Clone repo locally if needed: `gh repo clone RooCodeInc/Roo-Code` + 1. Clone repo locally if needed: `gh repo clone $REPO_FULL_NAME` 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 - + - + 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 + 1. Use repository template if found, or generic template if not + 2. Fill template with gathered information + 3. Format differently based on contributor vs problem reporter 4. Save formatted body to temporary file - 5. Use `gh issue create` with appropriate labels + 5. Use `gh issue create` with appropriate labels from template 6. Capture the returned issue URL 7. Show user the created issue URL - + @@ -270,4 +310,33 @@ gh repo clone - Clone repository + + + + When parsing YAML templates: + - Extract 'name' for template identification + - Get 'labels' array for automatic labeling + - Parse 'body' array for form elements + - Convert form elements to markdown sections + - Preserve 'required' field indicators + + + + When parsing Markdown templates: + - Check for YAML front matter + - Extract metadata (labels, assignees) + - Identify section headers + - Replace placeholder text + - Maintain formatting structure + + + + 1. Detect templates with list_files + 2. Read templates with read_file + 3. Parse structure and metadata + 4. Let user choose if multiple exist + 5. Fill template with information + 6. Create issue with template content + + \ No newline at end of file diff --git a/.roo/rules-issue-writer/6_technical_analysis_workflow.xml b/.roo/rules-issue-writer/6_technical_analysis_workflow.xml deleted file mode 100644 index c61d8fc1ca..0000000000 --- a/.roo/rules-issue-writer/6_technical_analysis_workflow.xml +++ /dev/null @@ -1,349 +0,0 @@ - - - This sub-workflow provides an aggressive, thorough, and all-encompassing investigation - process for technical analysis when creating GitHub issues. It employs methods from - the issue-investigator mode to deeply analyze the codebase and formulate comprehensive - technical solutions. This workflow is designed to produce scoped issues that can be - used in automated fix workflows. - - - - - Create Investigation Plan - - When technical analysis is requested, immediately create a comprehensive todo list - to track the investigation progress. - - - -[ ] Extract keywords from the issue description -[ ] Perform initial broad codebase search -[ ] Analyze search results and identify key components -[ ] Deep dive into relevant files and implementations -[ ] Form initial hypothesis about the issue/feature -[ ] Attempt to disprove hypothesis through further investigation -[ ] Identify all affected files and dependencies -[ ] Map out the complete implementation approach -[ ] Document technical risks and edge cases -[ ] Formulate comprehensive technical solution -[ ] Create detailed acceptance criteria -[ ] Prepare technical analysis summary - - - ]]> - - - - - - - Extract all relevant keywords, concepts, and technical terms from the issue description. - Be exhaustive - include function names, error messages, feature names, and related concepts. - - - Identify primary technical concepts - Extract error messages or specific symptoms - Note any mentioned file paths or components - List related features or functionality - Include synonyms and related terms - - Mark "Extract keywords from the issue description" as complete - - - - - Perform multiple rounds of codebase searches, starting broad and progressively - narrowing based on findings. This is an aggressive, exhaustive search process. - - - Initial Broad Search - - Use codebase_search with all extracted keywords to get an overview of relevant code. - -[Combined keywords from extraction phase] - - ]]> - - - - - Component Discovery - - Based on initial results, identify key components and search for: - - Related class/function definitions - - Import statements and dependencies - - Configuration files - - Test files that might reveal expected behavior - - - - - Deep Implementation Search - - Search for specific implementation details: - - Error handling patterns - - State management - - API endpoints or routes - - Database queries or models - - UI components and their interactions - - - - - Edge Case and Integration Search - - Look for: - - Edge cases in the code - - Integration points with other systems - - Configuration options that affect behavior - - Feature flags or conditional logic - - - - Update search-related todos as each iteration completes - - - - - Thoroughly analyze all relevant files discovered during the search phase. - - - Use list_code_definition_names to understand file structure - Read complete files to understand full context - Trace execution paths through the code - Identify all dependencies and imports - Map relationships between components - - - Document findings including: - - File paths and their purposes - - Key functions and their responsibilities - - Data flow through the system - - External dependencies - - Potential impact areas - - Mark file analysis todos as complete - - - - - Form a comprehensive hypothesis about the issue or feature implementation. - - - - Identify the most likely root cause - Trace the bug through the execution path - Determine why the current implementation fails - Consider environmental factors - - - - - Identify the optimal integration points - Determine required architectural changes - Plan the implementation approach - Consider scalability and maintainability - - - Mark hypothesis formation as complete - - - - - Aggressively attempt to disprove the hypothesis by searching for contradictory evidence. - - - - Search for Alternative Implementations - Look for similar features implemented differently - Check for deprecated code that might interfere - - - Configuration and Environment Check - Search for configuration that could change behavior - Look for environment-specific code paths - - - Test Case Analysis - Find existing tests that might contradict hypothesis - Look for test cases that reveal edge cases - - - Historical Context - Search for comments explaining design decisions - Look for TODO or FIXME comments related to the area - - - - If hypothesis is disproven, return to search phase with new insights. - If hypothesis stands, proceed to solution formulation. - - Update hypothesis validation status - - - - - Create a comprehensive technical solution with extreme detail. - - - -
- - Exact files to modify with line numbers - - New files to create with full paths - - Specific code changes required - - Order of implementation steps - - Migration strategy if needed -
- - - -
- - All files that import affected code - - API contracts that must be maintained - - Database schema changes if any - - Configuration changes required - - Documentation updates needed -
- - - -
- - Unit tests to add or modify - - Integration tests required - - Edge cases to test - - Performance testing needs - - Manual testing scenarios -
- - - -
- - Breaking changes identified - - Performance implications - - Security considerations - - Backward compatibility issues - - Rollback strategy -
- - - Mark solution formulation as complete - - - - - Create extremely detailed acceptance criteria that can guide automated implementation. - - - - Each criterion must be independently testable - Include both positive and negative test cases - Specify exact error messages and codes - Define performance thresholds where applicable - - Mark acceptance criteria creation as complete - - - - - - - - - - All keywords extracted and searched - Multiple search iterations completed - All relevant files analyzed - Hypothesis formed and validated - Comprehensive solution documented - Acceptance criteria defined - All risks and edge cases identified - Technical analysis formatted for issue - - - Mark all investigation todos as complete and update the main workflow todo list - - - \ No newline at end of file diff --git a/.roo/rules-merge-resolver/1_workflow.xml b/.roo/rules-merge-resolver/1_workflow.xml new file mode 100644 index 0000000000..a63809db70 --- /dev/null +++ b/.roo/rules-merge-resolver/1_workflow.xml @@ -0,0 +1,142 @@ + + + This mode resolves merge conflicts for a specific pull request by analyzing git history, + commit messages, and code changes to make intelligent resolution decisions. It receives + a PR number (e.g., "#123") and handles the entire conflict resolution process. + + + + + Parse PR number from user input +
+ Extract the PR number from input like "#123" or "PR #123" + Validate that a PR number was provided +
+ + + + Fetch PR information + + gh pr view [PR_NUMBER] --json title,body,headRefName,baseRefName + +
+ Get PR title and description to understand the intent + Identify the source and target branches +
+ + + + Checkout PR branch and prepare for rebase + + gh pr checkout [PR_NUMBER] --force + git fetch origin main + git rebase origin/main + +
+ Force checkout the PR branch to ensure clean state + Fetch the latest main branch + Attempt to rebase onto main to reveal conflicts +
+ + + + Check for merge conflicts + + git status --porcelain + git diff --name-only --diff-filter=U + +
+ Identify files with merge conflicts (marked with 'UU') + Create a list of files that need resolution +
+ + + + + + Analyze each conflicted file to understand the changes + + Read the conflicted file to identify conflict markers + Extract the conflicting sections between <<<<<<< and >>>>>>> + Run git blame on both sides of the conflict + Fetch commit messages and diffs for relevant commits + Analyze the intent behind each change + + + + + Determine the best resolution strategy for each conflict + + Categorize changes by intent (bugfix, feature, refactor, etc.) + Evaluate recency and relevance of changes + Check for structural overlap vs formatting differences + Identify if changes can be combined or if one should override + Consider test updates and related changes + + + + + Apply the resolution strategy to resolve conflicts + + For each conflict, apply the chosen resolution + Ensure proper escaping of conflict markers in diffs + Validate that resolved code is syntactically correct + Stage resolved files with git add + + + + + Verify the resolution and prepare for commit + + Run git status to confirm all conflicts are resolved + Check for any compilation or syntax errors + Review the final diff to ensure sensible resolutions + Prepare a summary of resolution decisions + + + + + + + gh pr checkout [PR_NUMBER] --force + Force checkout the PR branch to ensure clean state + + + + git fetch origin main + Get the latest main branch from origin + + + + git rebase origin/main + Rebase current branch onto main to reveal conflicts + + + + git blame -L [start_line],[end_line] [commit_sha] -- [file_path] + Get commit information for specific lines + + + + git show --format="%H%n%an%n%ae%n%ad%n%s%n%b" --no-patch [commit_sha] + Get commit metadata including message + + + + git show [commit_sha] -- [file_path] + Get the actual changes made in a commit + + + + git ls-files -u + List unmerged files with stage information + + + + + All merge conflicts have been resolved + Resolved files have been staged + No syntax errors in resolved code + Resolution decisions are documented + + \ No newline at end of file diff --git a/.roo/rules-merge-resolver/2_best_practices.xml b/.roo/rules-merge-resolver/2_best_practices.xml new file mode 100644 index 0000000000..5bf1b393eb --- /dev/null +++ b/.roo/rules-merge-resolver/2_best_practices.xml @@ -0,0 +1,165 @@ + + + + Intent-Based Resolution + + Always prioritize understanding the intent behind changes rather than + just looking at the code differences. Commit messages, PR descriptions, + and issue references provide crucial context. + + + Code changes have purpose - bugfixes should be preserved, features + should be integrated properly, and refactors should maintain consistency. + + + Conflict between a bugfix and a refactor + Apply the bugfix logic within the refactored structure + Simply choose one side without considering both intents + + + + + Preserve All Valuable Changes + + When possible, combine non-conflicting changes from both sides rather + than discarding one side entirely. + + + Both sides of a conflict often contain valuable changes that can coexist + if properly integrated. + + + + + Escape Conflict Markers + + When using apply_diff or search_and_replace tools, always escape merge + conflict markers with backslashes to prevent parsing errors. + + + + + + Consider Related Changes + + Look beyond the immediate conflict to understand related changes in + tests, documentation, or dependent code. + + + A change might seem isolated but could be part of a larger feature + or fix that spans multiple files. + + + + + + + Bugfixes generally take precedence over features + + Bugfixes address existing problems and should be preserved, + while features can be reintegrated around the fix. + + + + + More recent changes are often more relevant + + Recent changes likely reflect the current understanding of + requirements and may supersede older implementations. + + + When older changes are bugfixes or security patches that + haven't been addressed in newer code. + + + + + Changes that include test updates are likely more complete + + Developers who update tests alongside code changes demonstrate + thoroughness and understanding of the impact. + + + + + Logic changes take precedence over formatting changes + + Formatting can be reapplied, but logic changes represent + functional improvements or fixes. + + + + + + + Blindly choosing one side without analysis + + You might lose important changes or introduce regressions + + + Always analyze both sides using git blame and commit history + + + + + Ignoring the PR description and context + + The PR description often explains the why behind changes, + which is crucial for proper resolution + + + Always fetch and read the PR information before resolving + + + + + Not validating the resolved code + + Merged code might be syntactically incorrect or introduce + logical errors + + + Always check for syntax errors and review the final diff + + + + + Not escaping conflict markers in diffs + + Unescaped conflict markers (<<<<<<, =======, >>>>>>) in SEARCH + or REPLACE sections will be interpreted as actual diff syntax, + causing the apply_diff tool to fail or produce incorrect results + + + Always escape conflict markers with a backslash (\) when they + appear in the content you're searching for or replacing. + Example: \<<<<<<< HEAD instead of <<<<<<< HEAD + + + + + + + Fetch PR title and description for context + Identify all files with conflicts + Understand the overall change being merged + + + + Run git blame on conflicting sections + Read commit messages for intent + Consider if changes can be combined + Escape conflict markers in diffs + + + + Verify no conflict markers remain + Check for syntax/compilation errors + Review the complete diff + Document resolution decisions + + + \ No newline at end of file diff --git a/.roo/rules-merge-resolver/3_tool_usage.xml b/.roo/rules-merge-resolver/3_tool_usage.xml new file mode 100644 index 0000000000..35f3b5da75 --- /dev/null +++ b/.roo/rules-merge-resolver/3_tool_usage.xml @@ -0,0 +1,228 @@ + + + + execute_command + For all git and gh CLI operations + Git commands provide the historical context needed for intelligent resolution + + + + read_file + To examine conflicted files and understand the conflict structure + Need to see the actual conflict markers and code + + + + apply_diff or search_and_replace + To resolve conflicts by replacing conflicted sections + Precise editing of specific conflict blocks + + + + + + + Always use gh CLI for GitHub operations instead of MCP tools + Chain git commands with && for efficiency + Use --format options for structured output + Capture command output for parsing + + + + + Get PR information + gh pr view [PR_NUMBER] --json title,body,headRefName,baseRefName + + + + Checkout PR branch + gh pr checkout [PR_NUMBER] --force + + + + Fetch latest main branch + git fetch origin main + + + + Rebase onto main to reveal conflicts + git rebase origin/main + + + + Check conflict status + git status --porcelain | grep "^UU" + + + + Get blame for specific lines + git blame -L [start],[end] HEAD -- [file] | cut -d' ' -f1 + + + + Get commit message + git log -1 --format="%s%n%n%b" [commit_sha] + + + + Stage resolved file + git add [file_path] + + + + Continue rebase after resolution + git rebase --continue + + + + + + + Read the entire conflicted file first to understand structure + Note line numbers of conflict markers for precise editing + Identify the pattern of conflicts (multiple vs single) + + + + <<<<<<< HEAD - Start of current branch changes + ======= - Separator between versions + >>>>>>> [branch] - End of incoming changes + + + + + + Always escape conflict markers with backslash + Include enough context to ensure unique matches + Use :start_line: for precision + Combine multiple resolutions in one diff when possible + + + +src/feature.ts + +<<<<<<< SEARCH +:start_line:45 +------- +\<<<<<<< HEAD +function oldImplementation() { + return "old"; +} +\======= +function newImplementation() { + return "new"; +} +\>>>>>>> feature-branch +======= +function mergedImplementation() { + // Combining both approaches + return "merged"; +} +>>>>>>> REPLACE + + + ]]> + + + + + Use for simple conflict resolutions + Enable regex mode for complex patterns + Always escape special characters + + + +src/config.ts +\<<<<<<< HEAD[\s\S]*?\>>>>>>> \w+ +// Resolved configuration +const config = { + // Merged settings from both branches +} +true + + ]]> + + + + + + + execute_command - Get PR info with gh CLI + execute_command - Checkout PR with gh pr checkout --force + execute_command - Fetch origin main + execute_command - Rebase onto origin/main + execute_command - Check for conflicts with git status + + + + + + execute_command - List conflicted files + read_file - Examine conflict structure + execute_command - Git blame on conflict regions + execute_command - Fetch commit messages + + + + + + read_file - Get exact conflict content + apply_diff - Replace conflict with resolution + execute_command - Stage resolved file + execute_command - Verify resolution status + + + + + + execute_command - Check all conflicts resolved + execute_command - Continue rebase with git rebase --continue + execute_command - Verify clean status + + + + + + + Rebase completes without conflicts + + Inform user that PR can be merged without conflicts + No resolution needed + + + + + A rebase is already in progress + + Check status with git status + Either continue existing rebase or abort with git rebase --abort + + + + + Conflict markers are incomplete or nested + + Use search_and_replace with careful regex patterns + Manual inspection may be required + + + + + Binary files cannot be merged automatically + + Identify which version to keep based on PR intent + Use git checkout --theirs or --ours + + + + + Code contains literal conflict marker strings + + Extra careful escaping in diffs + Consider using search_and_replace with precise patterns + + + + \ No newline at end of file diff --git a/.roo/rules-merge-resolver/4_complete_example.xml b/.roo/rules-merge-resolver/4_complete_example.xml new file mode 100644 index 0000000000..dae8587997 --- /dev/null +++ b/.roo/rules-merge-resolver/4_complete_example.xml @@ -0,0 +1,315 @@ + + + User provides PR #123 which has merge conflicts between a bugfix branch + and a feature branch that refactored the same code. + + + + #123 + + + + + Parse PR number and fetch PR information + +gh pr view 123 --json title,body,headRefName,baseRefName + + ]]> + + + The PR is a bugfix for a memory leak issue. This context will help + prioritize preserving the fix during conflict resolution. + + + + + Checkout PR branch and prepare for rebase + +gh pr checkout 123 --force + + ]]> + + + +git fetch origin main + + ]]> + FETCH_HEAD + ]]> + + +git rebase origin/main + + ]]> + ", then run "git rebase --continue". + ]]> + + + + Check for merge conflicts + +git status --porcelain | grep "^UU" + + ]]> + + + Two files have conflicts: the main processor file and its test file. + Both need to be resolved before continuing the rebase. + + + + + Examine the conflicted processor file + +src/data/processor.ts + + ]]> + = new Map(); +47 | +48 | <<<<<<< HEAD +49 | async processData(data: DataInput): Promise { +50 | // Refactored to use async/await +51 | const result = await this.transform(data); +52 | return result; +53 | } +54 | ======= +55 | processData(data: any[]): ProcessedData { +56 | const listener = this.createListener(); +57 | this.listeners.set(data.id, listener); +58 | +59 | return this.transform(data); +60 | } +61 | >>>>>>> abc123 (Fix memory leak in data processor) +62 | +63 | cleanup() { +64 | <<<<<<< HEAD +65 | // TODO: Implement cleanup +66 | ======= +67 | // Fix: Clear all listeners to prevent memory leak +68 | this.listeners.forEach(listener => { +69 | listener.removeAllListeners(); +70 | }); +71 | this.listeners.clear(); +72 | >>>>>>> abc123 (Fix memory leak in data processor) +73 | } +74 | } + ]]> + + + + Analyze the conflicts using git blame + +git blame -L 49,53 HEAD -- src/data/processor.ts | cut -d' ' -f1 | sort -u | xargs -I {} git log -1 --format="%h %s" {} + + ]]> + + + +git log -1 --format="%h %s" abc123 + + ]]> + + + + HEAD (main after rebase): Has async/await refactor but missing listener logic + Incoming (bugfix branch): Adds listener tracking and cleanup for memory leak fix + + Resolution strategy: Combine both changes - keep async/await refactor + but include the listener tracking and cleanup logic. + + + + + Resolve the conflicts + +src/data/processor.ts + +<<<<<<< SEARCH +:start_line:48 +------- +\<<<<<<< HEAD + async processData(data: DataInput): Promise { + // Refactored to use async/await + const result = await this.transform(data); + return result; + } +\======= + processData(data: any[]): ProcessedData { + const listener = this.createListener(); + this.listeners.set(data.id, listener); + + return this.transform(data); + } +\>>>>>>> abc123 (Fix memory leak in data processor) +======= + async processData(data: DataInput): Promise { + // Create and track listener for cleanup (memory leak fix) + const listener = this.createListener(); + this.listeners.set(data.id, listener); + + // Refactored to use async/await + const result = await this.transform(data); + return result; + } +>>>>>>> REPLACE + +<<<<<<< SEARCH +:start_line:63 +------- + cleanup() { +\<<<<<<< HEAD + // TODO: Implement cleanup +\======= + // Fix: Clear all listeners to prevent memory leak + this.listeners.forEach(listener => { + listener.removeAllListeners(); + }); + this.listeners.clear(); +\>>>>>>> abc123 (Fix memory leak in data processor) + } +======= + cleanup() { + // Fix: Clear all listeners to prevent memory leak + this.listeners.forEach(listener => { + listener.removeAllListeners(); + }); + this.listeners.clear(); + } +>>>>>>> REPLACE + + + ]]> + + Combined both changes: kept the async/await refactor from main + while preserving the memory leak fix (listener tracking and cleanup) + from the bugfix branch. + + + + + Resolve test file conflicts + +src/data/processor.test.ts + + ]]> + + +src/data/processor.test.ts + + + + + ]]> + + + + Stage resolved files and continue rebase + +git add src/data/processor.ts src/data/processor.test.ts + + ]]> + + +git rebase --continue + + ]]> + + + + + Final validation + +git status + + ]]> + + + +git diff origin/main --stat + + ]]> + + + + + + +Successfully resolved merge conflicts for PR #123 "Fix memory leak in data processor". + +Resolution Summary: +- src/data/processor.ts: Combined the async/await refactor with the memory leak fix by preserving listener tracking and cleanup logic within the refactored async method +- src/data/processor.test.ts: Updated tests to work with the async implementation while maintaining memory leak test coverage + +Both the feature refactor and the critical bugfix have been preserved in the resolution. The rebase has been completed successfully and the branch is ready to be pushed. + + + ]]> + + + Always checkout PR with --force and rebase to reveal conflicts + Fetch PR context to understand the intent of changes + Use git blame and commit messages to understand the history + Combine non-conflicting improvements when possible + Prioritize bugfixes while accommodating refactors + Complete the rebase process with git rebase --continue + Validate that both sets of changes work together + + \ No newline at end of file diff --git a/.roo/rules-merge-resolver/5_communication.xml b/.roo/rules-merge-resolver/5_communication.xml new file mode 100644 index 0000000000..18594d5269 --- /dev/null +++ b/.roo/rules-merge-resolver/5_communication.xml @@ -0,0 +1,153 @@ + + + Be direct and technical when explaining resolution decisions + Focus on the rationale behind each conflict resolution + Provide clear summaries of what was merged and why + + + I'll help you resolve these conflicts... + Let me handle this for you... + Don't worry about the conflicts... + + + + Analyzing PR #123 for merge conflicts... + Resolving conflicts based on commit history analysis... + Applied resolution strategy: [specific strategy] + + + + + + Acknowledge the PR number + State that you're fetching PR information + Indicate the analysis will begin + + + + Fetching information for PR #123 to understand the context and identify merge conflicts... + + + + + During each major phase of resolution + + Analyzing [X] conflicted files... + Running git blame on [file] to understand change history... + Resolving conflicts in [file] by [strategy]... + Validating resolved changes... + + + + Number of conflicts found + Files being processed + Resolution strategy being applied + + + + + Explain each significant resolution decision + Reference specific commits when relevant + Justify why certain changes were kept or merged + + + + Conflict in [file]: + - HEAD: [brief description of changes] + - Incoming: [brief description of changes] + - Resolution: [what was decided and why] + + + + + + + + Expected a PR number (e.g., "#123" or "123"). Please provide the PR number to resolve conflicts for. + + + + + + PR #[number] does not have any merge conflicts. The branch can be merged without conflict resolution. + + + + + + Could not find PR #[number]. Please verify the PR number and ensure you have access to the repository. + + + + + + Found complex conflicts in [file] that require careful analysis. Examining commit history to determine the best resolution strategy... + + + + + + + State that conflicts are resolved + Provide resolution summary + List files that were resolved + Mention key decisions made + + + + + + Questions about next steps + Offers to do additional work + Uncertain language about the resolution + + + + + Document why specific resolutions were chosen + Reference commit SHAs when they influenced decisions + Explain trade-offs when both sides had valid changes + + + + Preserved bugfix from commit abc123 while adapting it to the refactored structure from def456 + + + Combined both implementations as they addressed different aspects of the same feature + + + Chose the more recent implementation as it included additional error handling + + + + + + + + Binary file conflict in [file]. Based on PR intent "[title]", choosing [which version] version. + + + + + + Conflict: [file] was deleted in one branch but modified in another. Based on the changes, [keeping/removing] the file because [reason]. + + + + + + Conflict in [file] involves only whitespace/formatting. Applying consistent formatting from [which] branch. + + + + \ No newline at end of file diff --git a/.roo/rules-mode-writer/1_mode_creation_workflow.xml b/.roo/rules-mode-writer/1_mode_creation_workflow.xml index 15a48aa804..77a1728599 100644 --- a/.roo/rules-mode-writer/1_mode_creation_workflow.xml +++ b/.roo/rules-mode-writer/1_mode_creation_workflow.xml @@ -1,124 +1,278 @@ - + - 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. + This workflow guides you through creating new custom modes or editing existing modes + for the Roo Code Software, ensuring comprehensive understanding and cohesive implementation. - + - Gather Requirements + Determine User Intent - Understand what the user wants the mode to accomplish + Identify whether the user wants to create a new mode or edit an existing one - - Ask about the mode's primary purpose and use cases - Identify what types of tasks the mode should handle - Determine what tools and file access the mode needs - Clarify any special behaviors or restrictions - - + + + + User mentions a specific mode by name or slug + User references a mode directory path (e.g., .roo/rules-[mode-slug]) + User asks to modify, update, enhance, or fix an existing mode + User says "edit this mode" or "change this mode" + + + + + User asks to create a new mode + User describes a new capability not covered by existing modes + User says "make a mode for" or "create a mode that" + + + + - What is the primary purpose of this new mode? What types of tasks should it handle? + I want to make sure I understand correctly. Are you looking to create a brand new mode or modify an existing one? - A mode for writing and maintaining documentation - A mode for database schema design and migrations - A mode for API endpoint development and testing - A mode for performance optimization and profiling + Create a new mode for a specific purpose + Edit an existing mode to add new capabilities + Fix issues in an existing mode + Enhance an existing mode with better workflows - + + - - Design Mode Configuration - - Create the mode definition with all required fields - - - - Unique identifier (lowercase, hyphens allowed) - Keep it short and descriptive (e.g., "api-dev", "docs-writer") - - - Display name with optional emoji - Use an emoji that represents the mode's purpose - - - Detailed description of the mode's role and expertise - - Start with "You are Roo Code, a [specialist type]..." - List specific areas of expertise - Mention key technologies or methodologies - - - - Tool groups the mode can access - - - - - - - - - - - - Clear description for the Orchestrator - Explain specific scenarios and task types - - - - 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. - - + + + + Gather Requirements for New Mode + + Understand what the user wants the new mode to accomplish + + + Ask about the mode's primary purpose and use cases + Identify what types of tasks the mode should handle + Determine what tools and file access the mode needs + Clarify any special behaviors or restrictions + + + + What is the primary purpose of this new mode? What types of tasks should it handle? + + A mode for writing and maintaining documentation + A mode for database schema design and migrations + A mode for API endpoint development and testing + A mode for performance optimization and profiling + + + + - - Implement File Restrictions - - Configure appropriate file access permissions - - - Restrict edit access to specific file types - + + Design Mode Configuration + + Create the mode definition with all required fields + + + + Unique identifier (lowercase, hyphens allowed) + Keep it short and descriptive (e.g., "api-dev", "docs-writer") + + + Display name with optional emoji + Use an emoji that represents the mode's purpose + + + Detailed description of the mode's role and expertise + + Start with "You are Roo Code, a [specialist type]..." + List specific areas of expertise + Mention key technologies or methodologies + + + + Tool groups the mode can access + + + + + + + + + + + + Clear description for the Orchestrator + Explain specific scenarios and task types + + + + 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. + + + + + Implement File Restrictions + + Configure appropriate file access permissions + + + Restrict edit access to specific file types + groups: - read - - edit - fileRegex: \.(md|txt|rst)$ description: Documentation files only - command - - - - Use regex patterns to limit file editing scope - Provide clear descriptions for restrictions - Consider the principle of least privilege - - + + + + Use regex patterns to limit file editing scope + Provide clear descriptions for restrictions + Consider the principle of least privilege + + - - Create XML Instruction Files + + Create XML Instruction Files + + Design structured instruction files in .roo/rules-[mode-slug]/ + + + Main workflow and step-by-step processes + Guidelines and conventions + Reusable code patterns and examples + Specific tool usage instructions + Complete workflow examples + + + Use semantic tag names that describe content + Nest tags hierarchically for better organization + Include code examples in CDATA sections when needed + Add comments to explain complex sections + + + + + + + Immerse in Existing Mode + + Fully understand the existing mode before making any changes + + + Locate and read the mode configuration in .roomodes + Read all XML instruction files in .roo/rules-[mode-slug]/ + Analyze the mode's current capabilities and limitations + Understand the mode's role in the broader ecosystem + + + + What specific aspects of the mode would you like to change or enhance? + + Add new capabilities or tool permissions + Fix issues with current workflows or instructions + Improve the mode's roleDefinition or whenToUse description + Enhance XML instructions for better clarity + + + + + + + Analyze Change Impact + + Understand how proposed changes will affect the mode + + + Compatibility with existing workflows + Impact on file permissions and tool access + Consistency with mode's core purpose + Integration with other modes + + + + I've analyzed the existing mode. Here's what I understand about your requested changes. Is this correct? + + Yes, that's exactly what I want to change + Mostly correct, but let me clarify some details + No, I meant something different + I'd like to add additional changes + + + + + + + Plan Modifications + + Create a detailed plan for modifying the mode + + + Identify which files need to be modified + Determine if new XML instruction files are needed + Check for potential conflicts or contradictions + Plan the order of changes for minimal disruption + + + + + Implement Changes + + Apply the planned modifications to the mode + + + Update .roomodes configuration if needed + Modify existing XML instruction files + Create new XML instruction files if required + Update examples and documentation + + + + + + + + Validate Cohesion and Consistency - Design structured instruction files in .roo/rules-[mode-slug]/ + Ensure all changes are cohesive and don't contradict each other - - Main workflow and step-by-step processes - Guidelines and conventions - Reusable code patterns and examples - Specific tool usage instructions - Complete workflow examples - - - Use semantic tag names that describe content - Nest tags hierarchically for better organization - Include code examples in CDATA sections when needed - Add comments to explain complex sections - + + + Mode slug follows naming conventions + File restrictions align with mode purpose + Tool permissions are appropriate + whenToUse clearly differentiates from other modes + + + All XML files follow consistent structure + No contradicting instructions between files + Examples align with stated workflows + Tool usage matches granted permissions + + + Mode integrates well with Orchestrator + Clear boundaries with other modes + Handoff points are well-defined + + + + + I've completed the validation checks. Would you like me to review any specific aspect in more detail? + + Review the file permission patterns + Check for workflow contradictions + Verify integration with other modes + Everything looks good, proceed to testing + + + - + Test and Refine Verify the mode works as intended @@ -129,14 +283,19 @@ groups: Instructions are clear and actionable Mode integrates well with Orchestrator All examples are accurate and helpful + Changes don't break existing functionality (for edits) + New capabilities work as expected - + Create mode in .roomodes for project-specific modes Create mode in global custom_modes.yaml for system-wide modes Use list_files to verify .roo folder structure Test file regex patterns with search_files + Use codebase_search to find existing mode implementations + Read all XML files in a mode directory to understand its structure + Always validate changes for cohesion and consistency - \ No newline at end of file + \ No newline at end of file diff --git a/.roo/rules-mode-writer/5_complete_mode_examples.xml b/.roo/rules-mode-writer/5_complete_mode_examples.xml index 45fd577c53..7c8f8a4cde 100644 --- a/.roo/rules-mode-writer/5_complete_mode_examples.xml +++ b/.roo/rules-mode-writer/5_complete_mode_examples.xml @@ -1,96 +1,214 @@ - - - Generate OpenAPI documentation for a REST API with user management endpoints - + + + + Edit the test mode to add support for performance testing and benchmarking + + + + I want to edit the test mode to add benchmark testing capabilities + - - - Discover API endpoints - -express router app.get app.post app.put app.delete @Route @Get @Post - - ]]> - Found routes in src/routes/users.ts - + + + Determine user intent and clarify scope + +I understand you want to edit the test mode to add performance testing capabilities. Before we proceed, let me confirm the scope of changes. What specific performance testing features do you need? + +Add benchmark testing with Vitest's bench API +Include performance profiling and memory usage tracking +Add load testing capabilities for API endpoints +All of the above - comprehensive performance testing suite + + + ]]> + User selected: Add benchmark testing with Vitest's bench API + - - Analyze endpoint implementation - + Immerse in existing test mode configuration + -src/routes/users.ts +.roomodes - ]]> - + ]]> + Found test mode configuration with current roleDefinition and file restrictions + - - Generate OpenAPI specification - + Explore existing test mode instructions + +.roo/rules-test +true + + ]]> + +.roo/rules-test/1_workflow.xml + + ]]> + Understood current test workflows and patterns + + + + Validate changes for cohesion + +I've analyzed the test mode. Adding benchmark testing would require: +1. Updating the roleDefinition to include performance testing expertise +2. Modifying file restrictions to include .bench.ts files +3. Adding new workflow instructions for benchmark creation +4. Including Vitest bench API examples + +This aligns well with the existing testing focus. Should I proceed with all these changes? + +Yes, implement all the changes as described +Start with just the roleDefinition and file restrictions +Focus only on the workflow instructions first +Let me review the specific changes before proceeding + + + ]]> + User selected: Yes, implement all the changes as described + + + + Update mode configuration in .roomodes + +.roomodes + +<<<<<<< SEARCH + 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 +======= + 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 - Benchmark testing with Vitest bench API - Performance profiling and optimization - Memory usage analysis in tests +>>>>>>> REPLACE + + + ]]> + + + + Update file restrictions to include benchmark files + +.roomodes + +<<<<<<< SEARCH + - 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 +======= + - fileRegex: (__tests__/.*|__mocks__/.*|\.test\.(ts|tsx|js|jsx)$|\.spec\.(ts|tsx|js|jsx)$|\.bench\.(ts|tsx|js|jsx)$|/test/.*|vitest\.config\.(js|ts)$|vitest\.setup\.(js|ts)$) + description: Test files, benchmarks, mocks, and Vitest configuration +>>>>>>> REPLACE + + + ]]> + + + + Create new benchmark workflow instructions + -docs/api/openapi.yaml +.roo/rules-test/5_benchmark_testing.xml -openapi: 3.0.0 -info: - title: User Management API - version: 1.0.0 - description: API for managing user accounts + + + Guidelines for creating and maintaining performance benchmarks using Vitest bench API + -servers: - - url: https://api.example.com/v1 - description: Production server - - url: http://localhost:3000/v1 - description: Development server + + + Basic benchmark structure + { + bench('Array.push', () => { + const arr = []; + for (let i = 0; i < 1000; i++) { + arr.push(i); + } + }); -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 \ No newline at end of file + bench('Array spread', () => { + let arr = []; + for (let i = 0; i < 1000; i++) { + arr = [...arr, i]; + } + }); +}); + ]]> + + + + + Use meaningful benchmark names that describe what's being measured + Include baseline comparisons when optimizing code + Run benchmarks in isolation to avoid interference + Document performance expectations and thresholds + + + +38 + + ]]> + + + + Validate all changes for consistency + +I've completed all the changes to add benchmark testing capabilities to the test mode: + +1. ✓ Updated roleDefinition to include benchmark expertise +2. ✓ Modified file restrictions to include .bench.ts files +3. ✓ Created new benchmark workflow instructions +4. ✓ Added Vitest bench API examples + +All changes are cohesive and align with the existing test mode structure. Would you like me to test any specific aspect of these changes? + +Test creating a new benchmark file to verify file permissions +Review the complete changes one more time +Everything looks good, the mode is ready +Create a simple benchmark example to test + + + ]]> + + + + + +I've successfully enhanced the test mode with benchmark testing capabilities: + +1. Updated the roleDefinition to include: + - Benchmark testing with Vitest bench API + - Performance profiling and optimization + - Memory usage analysis in tests + +2. Modified file restrictions to include .bench.ts files, allowing the mode to create and edit benchmark files + +3. Created new workflow instructions at .roo/rules-test/5_benchmark_testing.xml with: + - Basic benchmark patterns + - Best practices for performance testing + - Example code using Vitest's bench API + +All changes have been validated for cohesion and consistency with the existing test mode structure. The mode now supports comprehensive performance testing alongside its existing unit and integration testing capabilities. + + + ]]> + + + Always immerse yourself in the existing mode before making changes + Use ask_followup_question aggressively to clarify scope and validate changes + Validate all changes for cohesion and consistency + Update all relevant parts: configuration, file restrictions, and instructions + Test changes to ensure they work as expected + + + \ No newline at end of file diff --git a/.roo/rules-mode-writer/7_validation_cohesion_checking.xml b/.roo/rules-mode-writer/7_validation_cohesion_checking.xml new file mode 100644 index 0000000000..a327a1e465 --- /dev/null +++ b/.roo/rules-mode-writer/7_validation_cohesion_checking.xml @@ -0,0 +1,201 @@ + + + Guidelines for thoroughly validating mode changes to ensure cohesion, + consistency, and prevent contradictions across all mode components. + + + + + + Every change must be reviewed in context of the entire mode + + + Read all existing XML instruction files + Verify new changes align with existing patterns + Check for duplicate or conflicting instructions + Ensure terminology is consistent throughout + + + + + + Use ask_followup_question extensively to clarify ambiguities + + + User's intent is unclear + Multiple interpretations are possible + Changes might conflict with existing functionality + Impact on other modes needs clarification + + +I notice this change might affect how the mode interacts with file permissions. Should we also update the file regex patterns to match? + +Yes, update the file regex to include the new file types +No, keep the current file restrictions as they are +Let me explain what file types I need to work with +Show me the current file restrictions first + + + ]]> + + + + + Actively search for and resolve contradictions + + + + Permission Mismatch + Instructions reference tools the mode doesn't have access to + Either grant the tool permission or update the instructions + + + Workflow Conflicts + Different XML files describe conflicting workflows + Consolidate workflows and ensure single source of truth + + + Role Confusion + Mode's roleDefinition doesn't match its actual capabilities + Update roleDefinition to accurately reflect the mode's purpose + + + + + + + + Before making any changes + + Read and understand all existing mode files + Create a mental model of current mode behavior + Identify potential impact areas + Ask clarifying questions about intended changes + + + + + While making changes + + Document each change and its rationale + Cross-reference with other files after each change + Verify examples still work with new changes + Update related documentation immediately + + + + + After changes are complete + + + All XML files are well-formed and valid + File naming follows established patterns + Tag names are consistent across files + No orphaned or unused instructions + + + + roleDefinition accurately describes the mode + whenToUse is clear and distinguishable + Tool permissions match instruction requirements + File restrictions align with mode purpose + Examples are accurate and functional + + + + Mode boundaries are well-defined + Handoff points to other modes are clear + No overlap with other modes' responsibilities + Orchestrator can correctly route to this mode + + + + + + + + Maintain consistent tone and terminology + + Use the same terms for the same concepts throughout + Keep instruction style consistent across files + Maintain the same level of detail in similar sections + + + + + Ensure instructions flow logically + + Prerequisites come before dependent steps + Complex concepts build on simpler ones + Examples follow the explained patterns + + + + + Ensure all aspects are covered without gaps + + Every mentioned tool has usage instructions + All workflows have complete examples + Error scenarios are addressed + + + + + + + + Before we proceed with changes, I want to ensure I understand the full scope. What is the main goal of these modifications? + + Add new functionality while keeping existing features + Fix issues with current implementation + Refactor for better organization + Expand the mode's capabilities into new areas + + + + + + + This change might affect other parts of the mode. How should we handle the impact on [specific area]? + + Update all affected areas to maintain consistency + Keep the existing behavior for backward compatibility + Create a migration path from old to new behavior + Let me review the impact first + + + + + + + I've completed the changes and validation. Which aspect would you like me to test more thoroughly? + + Test the new workflow end-to-end + Verify file permissions work correctly + Check integration with other modes + Review all changes one more time + + + + + + + + Instructions reference tools not in the mode's groups + Either add the tool group or remove the instruction + + + File regex doesn't match described file types + Update regex pattern to match intended files + + + Examples don't follow stated best practices + Update examples to demonstrate best practices + + + Duplicate instructions in different files + Consolidate to single location and reference + + + \ No newline at end of file diff --git a/.roo/rules-pr-fixer/1_workflow.xml b/.roo/rules-pr-fixer/1_workflow.xml index db74ead7ee..fb487e5fdd 100644 --- a/.roo/rules-pr-fixer/1_workflow.xml +++ b/.roo/rules-pr-fixer/1_workflow.xml @@ -45,7 +45,7 @@ Determine if the PR is from a fork by checking 'gh pr view [PR_NUMBER] --repo [owner]/[repo] --json isCrossRepository'. Apply code changes based on review feedback using file editing tools. Fix failing tests by modifying test files or source code as needed. - For conflict resolution: Use GIT_EDITOR=true for non-interactive rebases, then resolve conflicts via file editing. + For conflict resolution: Delegate to merge-resolver mode using new_task with the PR number. If changes affect user-facing content (i18n files, UI components, announcements), delegate translation updates using the new_task tool with translate mode. Review modified files with 'git status --porcelain' to ensure no temporary files are included. Stage files selectively using 'git add -u' (for modified tracked files) or 'git add ' (for new files). diff --git a/.roo/rules-pr-fixer/2_best_practices.xml b/.roo/rules-pr-fixer/2_best_practices.xml index 50a8395b9c..2dc5775ced 100644 --- a/.roo/rules-pr-fixer/2_best_practices.xml +++ b/.roo/rules-pr-fixer/2_best_practices.xml @@ -41,33 +41,25 @@ - How to correctly escape conflict markers when using apply_diff. + Delegate merge conflict resolution to the merge-resolver mode. diff --git a/.roo/rules-pr-fixer/3_common_patterns.xml b/.roo/rules-pr-fixer/3_common_patterns.xml index 1c6c0bcf65..4ef2a34b9e 100644 --- a/.roo/rules-pr-fixer/3_common_patterns.xml +++ b/.roo/rules-pr-fixer/3_common_patterns.xml @@ -27,32 +27,26 @@ Commands to detect merge conflicts. - - Rebase operations using GIT_EDITOR to prevent interactive prompts. + + Delegate merge conflict resolution to the merge-resolver mode. - - Check current conflict status without interactive input. - - Check out a pull request branch locally.