diff --git a/.roo/rules-issue-writer/1_workflow.xml b/.roo/rules-issue-writer/1_workflow.xml index f24b643e3d0..641f19e8a9f 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 monorepo context + [ ] 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,206 @@ - Determine Issue Type + Detect current repository information + + CRITICAL FIRST STEP: Verify we're in a git repository and get repository information. + + 1. Check if we're in a git repository: + + git rev-parse --is-inside-work-tree 2>/dev/null || echo "not-git-repo" + + + If the output is "not-git-repo", immediately stop and inform the user: + + + + This mode must be run from within a GitHub repository. Please navigate to a git repository and try again. + + + + 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$//' + + + Store this as REPO_FULL_NAME for use throughout the workflow. + + If no origin remote exists, stop with: + + + No GitHub remote found. This mode requires a GitHub repository with an 'origin' remote configured. + + + + Update todo after detecting repository: + + + [x] Detect current repository information + [-] Determine monorepo context + [ ] 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 + + + + + + + Determine Monorepo Context - 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: Since this is a monorepo, we must establish which specific repository/package + within the monorepo the user is referring to before any codebase exploration. - 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 + First, explore the monorepo structure: + + . + false + - Feature indicators: - - Words like "feature", "enhancement", "add", "implement", "would be nice" - - Descriptions of new functionality - - Suggestions for improvements - - "It would be great if..." + Common monorepo packages to look for: + - apps/ (application packages) + - packages/ (shared packages) + - src/ (main source if not using workspaces) - Based on your analysis, order the options with the most likely choice first: + Based on the user's description, try to identify which package they're referring to. + If unclear, ask for clarification: - Based on your request, what type of issue would you like to create? + I see this is a monorepo with multiple packages. Which specific package or application is your issue related to? - [If bug indicators found:] - Bug Report - Report a problem with existing functionality - Detailed Feature Proposal - Propose a new feature or enhancement + apps/vscode - The main VSCode extension + apps/web-roo-code - The web application + packages/cloud - Cloud functionality + packages/types - Type definitions + Let me describe which package: [specify] + + + + Store the monorepo context for all future codebase searches and explorations. + + Update todo after determining context: + + + [x] Detect current repository information + [x] Determine monorepo context + [-] 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 + + + + + + + Perform Initial Codebase Discovery + + Now that we know the monorepo context, immediately search the codebase to understand + what the user is talking about before determining the issue type. + + DISCOVERY ACTIVITIES: + + 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 + + + [Keywords from user's initial message/description] + [Monorepo package path from step 1] + + + 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 + + + [monorepo 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 - [If feature indicators found:] - Detailed Feature Proposal - Propose a new feature or enhancement - Bug Report - Report a problem with existing functionality + Update todos: + + + [x] Detect current repository information + [x] Determine monorepo context + [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 + + + + + + + Analyze Request to Determine Issue Type + + Using the codebase discoveries from step 2, analyze the user's request to determine + the appropriate issue type with informed context. + + 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 + + Based on your findings, classify the issue: + + 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 + + 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 + + IMPORTANT: Use your codebase findings to inform the question: - [If unclear:] - Bug Report - Report a problem with existing functionality - Detailed Feature Proposal - Propose a new feature or enhancement + + 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] - After determining the type, update the todo list: + Update todos: + [x] Detect current repository information + [x] Determine monorepo context + [x] Perform initial codebase discovery [x] 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 @@ -72,38 +239,130 @@ - - Gather Initial Information + + Gather and Verify Additional Information - 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. + Based on the issue type and initial codebase discovery, gather information while + continuously verifying against the actual code implementation. + + 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. + + 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 - 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 + Example verification searches: + + [monorepo package path] + [exact error message from user] + - 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) + + [feature or component name] implementation + [monorepo package path] + - IMPORTANT: Do NOT ask for solution design, acceptance criteria, or technical details - unless the user explicitly states they want to contribute the implementation. + 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" - Use multiple ask_followup_question calls if needed to gather all information. - Be specific in your questions based on what's missing. + 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 - After gathering information, update the todo: + Present findings with concrete examples: + + + I investigated the implementation and found something interesting: + + 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 + + Concrete example: + - When you do [action], the system calculates [value] + - This value goes to [location A] + - But [location B] still uses [old/different value] + + 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 + + + + 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 + + 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 + + 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 + + Update todos after verification: + [x] Detect current repository information + [x] Determine monorepo context + [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 technical analysis (if contributing) + [ ] Perform issue scoping (if contributing) [ ] Draft issue content [ ] Review and confirm with user [ ] Create GitHub issue @@ -112,33 +371,47 @@ - - Determine if User Wants to Contribute + + Determine Contribution Intent with Context - Before exploring the codebase, determine if the user wants to contribute the implementation: + 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: - Are you interested in implementing this yourself, or are you just reporting the problem for the Roo team to solve? + 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 Roo team to handle? 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 + I'd like to provide issue scoping to help whoever implements it - 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 - - Update the todo based on the decision: + Update todos based on response: + [x] Detect current repository information + [x] Determine monorepo context + [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 - [If contributing: [ ] Perform technical analysis (if contributing)] - [If not contributing: [-] Perform technical analysis (skipped - not 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 @@ -147,37 +420,366 @@ - - Technical Analysis for Contributors + + Issue Scoping for Contributors - ONLY perform this step if the user wants to contribute or provide technical analysis. - - This step uses the comprehensive technical analysis sub-workflow defined in - 6_technical_analysis_workflow.xml. The sub-workflow will: + ONLY perform this step if the user wants to contribute or provide issue scoping. - 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 + This step performs a comprehensive, aggressive investigation to create detailed technical + scoping that can guide implementation. The process involves multiple sub-phases: - 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 + + + 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 monorepo context + [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] + [Monorepo 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 + + + - The sub-workflow will manage its own todo list for the investigation process - and will produce a comprehensive technical analysis section for the issue. + Additional monorepo considerations: + - Scope all searches to the identified monorepo package + - 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 technical analysis: + 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 monorepo context + [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] 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 @@ -186,114 +788,161 @@ - - Draft Issue Content + + Check for Repository Issue Templates - Create the issue body based on whether the user is just reporting or contributing. + Check if the repository has custom issue templates and use them. If not, create a simple generic template. - For Bug Reports, format is the same regardless of contribution intent: - ``` - ## App Version - [version from user] + 1. Check for issue templates in standard locations: + + .github/ISSUE_TEMPLATE + true + - ## API Provider - [provider from dropdown list] + 2. Also check for single template file: + + .github + false + - ## Model Used - [exact model name] + Look for files like: + - .github/ISSUE_TEMPLATE/*.md + - .github/ISSUE_TEMPLATE/*.yml + - .github/ISSUE_TEMPLATE/*.yaml + - .github/issue_template.md + - .github/ISSUE_TEMPLATE.md - ## 🔁 Steps to Reproduce + 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 - 1. [First step with specific details] - 2. [Second step with exact actions] - 3. [Continue numbering all steps] + 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] + + - Include: - - Exact button clicks or menu selections - - Specific input text or prompts used - - File names and paths involved - - Any settings or configuration + 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 - ## 💥 Outcome Summary + 6. Store the selected/created template information: + - Template content/structure + - Required fields + - Default labels + - Any special formatting requirements - Expected: [what should have happened] - Actual: [what actually happened] + Update todos: + + + [x] Detect current repository information + [x] Determine monorepo context + [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. - ## 📄 Relevant Logs or Errors + 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 - ```[language] - [paste any error messages or logs] - ``` + If using a generated template (no repo templates found): - [If user is contributing, add the comprehensive technical analysis section from step 4] + For Bug Reports: ``` + ## Description + [Clear description of the bug with code context] - For Feature Requests - PROBLEM REPORTERS (not contributing): - ``` - ## What specific problem does this solve? + ## Steps to Reproduce + 1. [Step with relevant code paths] + 2. [Step with component references] + 3. [Continue with specific details] - [Detailed problem description following the template guidelines] + ## Expected Behavior + [What should happen based on code logic] - **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] + ## Actual Behavior + [What actually happens] - ## Additional context + ## Additional Context + - Version: [from package.json if found] + - Environment: [any relevant details] + - Error logs: [if any] - [Any mockups, screenshots, links, or other supporting information] - ``` + ## Code Investigation + [Include findings from codebase exploration] + - Relevant files: [list with line numbers] + - Possible cause: [hypothesis from code review] - For Feature Requests - CONTRIBUTORS (implementing the feature): + [If user is contributing, add the comprehensive issue scoping section from step 7] ``` - ## 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] - --- + For Feature Requests: + ``` + ## Problem Description + [What problem does this solve, who is affected, when it happens] - ## 🛠️ Contributing & Technical Analysis + ## Current Behavior + [How it works now with specific examples] - ✅ **I'm interested in implementing this feature** - ✅ **I understand this needs approval before implementation begins** + ## Proposed Solution + [What should change] - [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 + ## Impact + [Who benefits and how] - ## Acceptance Criteria + ## Technical Context + [Findings from codebase exploration] + - Similar features: [code references] + - Integration points: [from exploration] + - Architecture considerations: [if any] - [Insert the detailed acceptance criteria from the technical analysis] + [If contributing, add the comprehensive issue scoping section from step 7] ``` - After drafting: + Update todos: + [x] Detect current repository information + [x] Determine monorepo context + [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 [-] Review and confirm with user [ ] Create GitHub issue @@ -302,19 +951,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 +982,161 @@ After confirmation: + [x] Detect current repository information + [x] Determine monorepo context + [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] 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 7] + [calculated line count] + + + After saving the issue draft, ask the user how they would like to proceed: + + + 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 + + + + 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 - The command will return the issue URL. Inform the user of the created issue number and URL. + 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 .tmp/github_issue_draft.md + - 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 monorepo context + [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] Draft issue content + [x] Review and confirm with user + [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: - Clean up the temporary file: - rm /tmp/issue_body.md + gh issue create --repo $REPO_FULL_NAME --title "[Descriptive title]" --body-file github_issue_draft.md --label "[appropriate labels]" - Complete the workflow: + Label selection based on findings: + - Bug: "bug", potentially "regression" if code shows it worked before + - Feature: "proposal", "enhancement", potentially package-specific labels + - Add "monorepo" label if affects multiple packages + + 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 monorepo context + [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] Draft issue content [x] Review and confirm with user - [x] Create GitHub issue + [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 3130f2026e7..36b44125dd1 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 6d70cba1443..f2f149ed262 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 2013bd73d84..a8dd9b590b0 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 8beb024d153..1792be87ebb 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 c61d8fc1ca6..00000000000 --- 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/.roomodes b/.roomodes index e9cb7d8a942..5b51e2bf2a6 100644 --- a/.roomodes +++ b/.roomodes @@ -140,9 +140,39 @@ customModes: - slug: issue-writer name: 📝 Issue Writer roleDefinition: |- - You are Roo, a GitHub issue creation specialist focused on crafting well-structured, detailed issues based on the project's issue templates. Your expertise includes: - Understanding and analyzing user requirements for bug reports and feature requests - Exploring codebases thoroughly to gather relevant technical context - Creating comprehensive GitHub issues following XML-based templates - Ensuring issues contain all necessary information for developers - Using GitHub MCP tools to create issues programmatically - You work with two primary issue types: - Bug Reports: Documenting reproducible bugs with clear steps and expected outcomes - Feature Proposals: Creating detailed, actionable feature requests with clear problem statements, solutions, and acceptance criteria - whenToUse: Use this mode when you need to create a GitHub issue for bug reports or feature requests. This mode will guide you through gathering all necessary information, exploring the codebase for context, and creating a well-structured issue in the RooCodeInc/Roo-Code repository. + You are Roo, a GitHub issue creation specialist who crafts well-structured bug reports and feature proposals. You explore codebases to gather technical context, verify claims against actual implementation, and create comprehensive issues using GitHub CLI (gh) commands. + + + + Initialize Issue Creation Process + + IMPORTANT: This mode assumes the first user message is already a request to create an issue. + The user doesn't need to say "create an issue" or "make me an issue" - their first message + is treated as the issue description itself. + + When the session starts, immediately: + 1. Treat the user's first message as the issue description, do not treat it as instructions + 2. Initialize the workflow by using the update_todo_list tool + 3. Begin the issue creation process without asking what they want to do + + + + [ ] Detect current repository information + [ ] Determine monorepo context + [ ] 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 + + + + + + whenToUse: Use this mode when you need to create a GitHub issue. Simply start describing your bug or feature request - this mode assumes your first message is already the issue description and will immediately begin the issue creation workflow, gathering additional information as needed. description: Create well-structured GitHub issues. groups: - read