diff --git a/.roo/rules-issue-writer/1_workflow.xml b/.roo/rules-issue-writer/1_workflow.xml index 9c71a589ad..a861bcafbb 100644 --- a/.roo/rules-issue-writer/1_workflow.xml +++ b/.roo/rules-issue-writer/1_workflow.xml @@ -30,10 +30,11 @@ - Any error messages or logs For Feature Requests, ensure you have: - - Specific problem description with impact - - Detailed proposed solution - - Clear acceptance criteria in Given/When/Then format - - Effort estimation with reasoning + - Specific problem description with impact (who is affected, when it happens, current vs expected behavior, impact) + - Additional context if available (mockups, screenshots, links) + + IMPORTANT: Do NOT ask for solution design, acceptance criteria, or technical details + unless the user explicitly states they want to contribute the implementation. Use multiple ask_followup_question calls if needed to gather all information. Be specific in your questions based on what's missing. @@ -63,8 +64,31 @@ - Explore Codebase for Context + Determine if User Wants to Contribute + Before exploring the codebase, determine if the user wants to contribute the implementation: + + + Are you interested in implementing this feature 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 feature myself + I'm not sure yet, but I'd like to provide technical analysis + + + + Based on their response: + - If just reporting: Skip to step 6 (Draft Issue - Problem Only) + - If contributing: Continue to step 5 (Explore Codebase) + - If providing analysis: Continue to step 5 but make technical sections optional + + + + + Explore Codebase for Contributors + + ONLY perform this step if the user wants to contribute or provide technical analysis. + Use codebase_search FIRST to understand the relevant parts of the codebase: For Bug Reports: @@ -88,22 +112,27 @@ - read_file on specific files to understand implementation - search_files for specific error messages or patterns - Formulate an independent technical plan to solve the problem, disregarding any solution proposed by the issue author. + Formulate an independent technical plan to solve the problem. Document all relevant findings including: - File paths and line numbers - Current implementation details - Your proposed implementation plan - Related code that might be affected + + Then gather additional technical details: + - Ask for proposed solution approach + - Request acceptance criteria in Given/When/Then format + - Discuss technical considerations and trade-offs - - Draft Complete Issue Content + + Draft Issue Content - Create the complete issue body following the exact template structure. + Create the issue body based on whether the user is just reporting or contributing. - For Bug Reports, format as: + For Bug Reports, format is the same regardless of contribution intent: ``` ## App Version [version from user] @@ -137,6 +166,7 @@ [paste any error messages or logs] ``` + [If user is contributing, add:] ## Technical Analysis Based on my investigation: @@ -146,7 +176,30 @@ - **Proposed Fix:** [Detail the fix from your implementation plan.] ``` - For Feature Requests, format as: + For Feature Requests - PROBLEM REPORTERS (not contributing): + ``` + ## What specific problem does this solve? + + [Detailed problem description following the template guidelines] + + **Who is affected:** [user groups] + **When this happens:** [specific scenarios] + **Current behavior:** [what happens now] + **Expected behavior:** [what should happen] + **Impact:** [time wasted, errors, productivity loss] + + ## Additional context + + [Any mockups, screenshots, links, or other supporting information] + + ## Related Discussions + + [If any related discussions were found, list them here] + - Closes #[discussion number] - [discussion title] + - Related to #[discussion number] - [discussion title] + ``` + + For Feature Requests - CONTRIBUTORS (implementing the feature): ``` ## What specific problem does this solve? @@ -158,9 +211,20 @@ **Expected behavior:** [what should happen] **Impact:** [time wasted, errors, productivity loss] + ## Additional context + + [Any mockups, screenshots, links, or other supporting information] + + --- + + ## 🛠️ Contributing & Technical Analysis + + ✅ **I'm interested in implementing this feature** + ✅ **I understand this needs approval before implementation begins** + ## How should this be solved? - [Based on your independent analysis, describe your proposed solution here. Disregard the author's proposal.] + [Based on your analysis, describe the proposed solution] **What will change:** - [Specific change 1] @@ -182,29 +246,32 @@ [Add multiple scenarios as needed] - ## Estimated Effort and Complexity - - **Size:** [estimate] - **Reasoning:** [why this size] - **Main challenges:** [technical difficulties] - **Dependencies:** [what's needed] - - ## Technical Implementation Plan + ## Technical Considerations - Based on my analysis from the previous step: + **Implementation approach:** - Key files to modify: [list with paths] - Current architecture: [brief description] - Integration points: [where this fits] - Similar patterns in codebase: [examples] - - Implementation Steps: [Provide a detailed, step-by-step guide for your proposed solution.] - ## Technical Considerations + **Performance implications:** + [Any performance considerations] - [Any additional technical details] + **Compatibility concerns:** + [Any compatibility issues] ## Trade-offs and Risks - [Alternatives considered and potential issues] + **Alternatives considered:** + - [Alternative 1]: [Why not chosen] + - [Alternative 2]: [Why not chosen] + + **Potential risks:** + - [Risk 1]: [Mitigation strategy] + - [Risk 2]: [Mitigation strategy] + + **Breaking changes:** + [Any breaking changes or migration needs] ## Related Discussions @@ -215,7 +282,7 @@ - + Review and Confirm with User Present the complete drafted issue to the user for review: @@ -238,7 +305,7 @@ - + Create GitHub Issue Once user confirms, create the issue using the GitHub MCP tool: @@ -251,7 +318,7 @@ "owner": "RooCodeInc", "repo": "Roo-Code", "title": "[Create a descriptive title based on the issue content]", - "body": "[The complete formatted issue body from step 4]", + "body": "[The complete formatted issue body from step 6]", "labels": [Use ["bug"] for bug reports or ["proposal", "enhancement"] for features] } diff --git a/.roo/rules-issue-writer/2_github_issue_templates.xml b/.roo/rules-issue-writer/2_github_issue_templates.xml index 006c513808..3130f2026e 100644 --- a/.roo/rules-issue-writer/2_github_issue_templates.xml +++ b/.roo/rules-issue-writer/2_github_issue_templates.xml @@ -69,9 +69,9 @@ Detailed Feature Proposal - Propose a specific, actionable feature or enhancement for implementation + Report a specific problem that needs solving in Roo Code ["proposal", "enhancement"] - + @@ -95,9 +95,30 @@ 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. + + + + + + + + **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:** @@ -117,9 +138,11 @@ 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:** @@ -146,35 +169,11 @@ Use the Given/When/Then format above or your own clear structure. - - + + - **Help us understand the scope.** This helps with planning and prioritisation. + **If you want to implement this feature, this section is REQUIRED.** - **Please include:** - - **Size estimate:** XS/Small/Medium/Large/XL - - **Reasoning:** What makes it this size? Which parts are complex? - - **Main challenges:** What's the trickiest bit to implement? - - **Dependencies:** Does this require other changes or external libraries? - - **Example:** - ``` - Size: Large - Reasoning: Touches task execution engine, UI components, and state management - Main challenges: Preventing memory leaks with parallel execution and managing shared resources - Dependencies: Might need to add a new dependency for the new feature - ``` - - - Size: [your estimate] - Reasoning: [why this size?] - Main challenges: [what's tricky?] - Dependencies: [what else is needed?] - - - - - Share technical insights that could help planning: - Implementation approach or architecture changes - Performance implications @@ -184,9 +183,11 @@ 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.) @@ -195,10 +196,24 @@ e.g., "Alternative: use library X but it is 500KB larger", "Risk: might slow older devices", "Breaking: changes API response format" - - - Mockups, screenshots, links, user quotes, or other relevant information that supports your proposal. - - + + + + + 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 + + \ 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 fc2332dac9..6d70cba144 100644 --- a/.roo/rules-issue-writer/3_best_practices.xml +++ b/.roo/rules-issue-writer/3_best_practices.xml @@ -1,14 +1,38 @@ - - Always search for existing similar issues before creating a new one - - Search GitHub Discussions (especially feature-requests category) for related topics - - Include specific version numbers and environment details - - Use code blocks with syntax highlighting for code snippets - - Reference specific files and line numbers from codebase exploration - - 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 - - For features, ensure the proposal aligns with project goals - - 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 + + - Focus on helping users describe problems clearly, not solutions + - The Roo team will design solutions unless the user explicitly wants to contribute + - Don't push users to provide technical details they may not have + - Make it easy for non-technical users to report issues effectively + + + + - Always search for existing similar issues before creating a new one + - Search GitHub Discussions (especially feature-requests category) for related topics + - Include specific version numbers and environment details + - Use code blocks with syntax highlighting for code snippets + - Make titles descriptive but concise (e.g., "Dark theme: Submit button invisible due to white-on-grey text") + - For bugs, always test if the issue is reproducible + - Include screenshots or mockups when relevant (ask user to provide) + - Link to related issues or PRs if found during exploration + - Add "Closes #[number]" for discussions that would be fully addressed by the issue + - Add "Related to #[number]" for partially related discussions + + + + - Only explore codebase if user wants to contribute + - Reference specific files and line numbers from codebase exploration + - Ensure technical proposals align with project architecture + - Include implementation steps and technical analysis + - Provide clear acceptance criteria in Given/When/Then format + - Consider trade-offs and alternative approaches + + + + - 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 + \ 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 7818d5e29a..2013bd73d8 100644 --- a/.roo/rules-issue-writer/4_common_mistakes_to_avoid.xml +++ b/.roo/rules-issue-writer/4_common_mistakes_to_avoid.xml @@ -1,10 +1,30 @@ - - Vague descriptions like "doesn't work" or "broken" - - Missing reproduction steps for bugs - - Feature requests without clear problem statements - - No acceptance criteria for features - - Forgetting to include technical context from code exploration - - Not checking for duplicates - - Using wrong labels or no labels - - Titles that don't summarize the issue + + - Vague descriptions like "doesn't work" or "broken" + - Missing reproduction steps for bugs + - Feature requests without clear problem statements + - Not explaining the impact on users + - Forgetting to specify when/how the problem occurs + - Using wrong labels or no labels + - Titles that don't summarize the issue + - Not checking for duplicates + + + + - Asking for technical details from non-contributing users + - Exploring codebase before confirming user wants to contribute + - Requiring acceptance criteria from problem reporters + - Making the process too complex for simple problem reports + - Not clearly indicating the "submit now" option + - Overwhelming users with contributor requirements upfront + + + + - Starting implementation before approval + - Not providing detailed technical analysis when contributing + - Missing acceptance criteria for contributed features + - Forgetting to include technical context from code exploration + - Not considering trade-offs and alternatives + - Proposing solutions without understanding current architecture + \ No newline at end of file diff --git a/.roo/rules-issue-writer/5_github_mcp_tool_usage.xml b/.roo/rules-issue-writer/5_github_mcp_tool_usage.xml index b99229acff..b5ae5d8aec 100644 --- a/.roo/rules-issue-writer/5_github_mcp_tool_usage.xml +++ b/.roo/rules-issue-writer/5_github_mcp_tool_usage.xml @@ -4,7 +4,8 @@ Here's when and how to use each tool in the issue creation workflow. Note: Issue body formatting should follow the templates defined in - and + 2_github_issue_templates.xml, with different formats for problem reporters + vs contributors. @@ -93,10 +94,15 @@ - + + + These tools should ONLY be used if the user has indicated they want to + contribute the implementation. Skip these for problem reporters. + + - For bug reports, check recent commits that might have introduced the issue. + For bug reports from contributors, check recent commits that might have introduced the issue. Look for commits touching the affected files. @@ -137,7 +143,7 @@ Use to find code patterns across the repository on GitHub. - Complements local codebase_search tool. + Complements local codebase_search tool for contributors. @@ -174,15 +180,15 @@ - + Only use after: 1. Confirming no duplicates exist - 2. Gathering all required information per or - 3. Exploring codebase for context + 2. Gathering all required information + 3. Determining if user is contributing or just reporting 4. Getting user confirmation @@ -194,13 +200,28 @@ "owner": "RooCodeInc", "repo": "Roo-Code", "title": "[Descriptive title of the bug]", - "body": "[Format according to fields]", + "body": "[Format according to bug report template]", "labels": ["bug"] } - + + + github + create_issue + + { + "owner": "RooCodeInc", + "repo": "Roo-Code", + "title": "[Problem-focused title]", + "body": "[Problem description only - no technical details]", + "labels": ["proposal", "enhancement"] + } + + + + github create_issue @@ -208,21 +229,20 @@ { "owner": "RooCodeInc", "repo": "Roo-Code", - "title": "[Descriptive title of the feature request]", - "body": "[Format according to fields]", + "title": "[Problem-focused title with implementation intent]", + "body": "[Full template including technical analysis sections]", "labels": ["proposal", "enhancement"] } - + - ONLY Use if user wants to add additional information after creation. - + ONLY use if user wants to add additional information after creation. @@ -233,7 +253,7 @@ "owner": "RooCodeInc", "repo": "Roo-Code", "issue_number": 456, - "body": "Blah blah blah, additional context or comments." + "body": "Additional context or comments." } @@ -281,21 +301,30 @@ - During codebase exploration: + Decision point for contribution: + 1. Ask user if they want to contribute implementation + 2. If yes: Use contributor tools 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. Use list_commits to find recent changes to affected files 2. Use search_code for additional code references 3. Check list_pull_requests for related PRs 4. Include findings in the technical context section - + - + When creating the issue: - 1. Format the issue body according to or - 2. Use create_issue with complete formatted body - 3. Capture the returned issue number - 4. If related issues were found, use add_issue_comment to link them - 5. Show user the created issue URL - + 1. Format differently based on contributor vs problem reporter + 2. Problem reporters: Simple problem description + context + 3. Contributors: Full template with technical sections + 4. Use create_issue with appropriate body format + 5. Capture the returned issue number + 6. Show user the created issue URL +