feat: update issue-writer mode rules for streamlined feature request template (#4850)

.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 @@
   </step>
 
   <step number="4">
-    <name>Explore Codebase for Context</name>
+    <name>Determine if User Wants to Contribute</name>
     <instructions>
+      Before exploring the codebase, determine if the user wants to contribute the implementation:
+      
+      <ask_followup_question>
+      <question>Are you interested in implementing this feature yourself, or are you just reporting the problem for the Roo team to solve?</question>
+      <follow_up>
+      <suggest>Just reporting the problem - the Roo team can design the solution</suggest>
+      <suggest>I want to contribute and implement this feature myself</suggest>
+      <suggest>I'm not sure yet, but I'd like to provide technical analysis</suggest>
+      </follow_up>
+      </ask_followup_question>
+      
+      Based on their response:
+      - If just reporting: Skip to step 6 (Draft Issue - Problem Only)
+      - If contributing: Continue to step 5 (Explore Codebase)
+      - If providing analysis: Continue to step 5 but make technical sections optional
+    </instructions>
+  </step>
+
+  <step number="5">
+    <name>Explore Codebase for Contributors</name>
+    <instructions>
+      ONLY perform this step if the user wants to contribute or provide technical analysis.
+      
       Use codebase_search FIRST to understand the relevant parts of the codebase:
       
       For Bug Reports:
@@ -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
     </instructions>
   </step>
 
-  <step number="5">
-    <name>Draft Complete Issue Content</name>
+  <step number="6">
+    <name>Draft Issue Content</name>
     <instructions>
-      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 @@
     </instructions>
   </step>
 
-  <step number="6">
+  <step number="7">
     <name>Review and Confirm with User</name>
     <instructions>
       Present the complete drafted issue to the user for review:
@@ -238,7 +305,7 @@
     </instructions>
   </step>
 
-  <step number="7">
+  <step number="8">
     <name>Create GitHub Issue</name>
     <instructions>
       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]
       }
       </arguments>

.roo/rules-issue-writer/2_github_issue_templates.xml

@@ -69,9 +69,9 @@
   
   <feature_request_template>
     <name>Detailed Feature Proposal</name>
-    <description>Propose a specific, actionable feature or enhancement for implementation</description>
+    <description>Report a specific problem that needs solving in Roo Code</description>
     <labels>["proposal", "enhancement"]</labels>
-    <fields>
+    <required_fields>
       <field name="problem-description" type="textarea" required="true">
         <label>What specific problem does this solve?</label>
         <description>
@@ -95,9 +95,30 @@
         </description>
         <placeholder>Be specific about the problem, who it affects, and the impact. Avoid generic statements like "it's slow" or "it's confusing."</placeholder>
       </field>
-      <field name="proposed-solution" type="textarea" required="true">
-        <label>How should this be solved?</label>
+      <field name="additional-context" type="textarea" required="false">
+        <label>Additional context (optional)</label>
+        <description>Mockups, screenshots, links, user quotes, or other relevant information that supports your proposal.</description>
+      </field>
+    </required_fields>
+    
+    <contributor_fields>
+      <field name="willingness-to-contribute" type="checkbox">
+        <label>Interested in implementing this?</label>
+        <description>
+          **Important:** If you check "Yes" below, the technical sections become REQUIRED.
+          We need detailed technical analysis from contributors to ensure quality implementation.
+        </description>
+        <option>Yes, I'd like to help implement this feature</option>
+      </field>
+      <field name="implementation-approval" type="checkbox">
+        <label>Implementation requirements</label>
+        <option>I understand this needs approval before implementation begins</option>
+      </field>
+      <field name="proposed-solution" type="textarea" required_if_contributing="true">
+        <label>How should this be solved? (REQUIRED if contributing, optional otherwise)</label>
         <description>
+          **If you want to implement this feature, this section is REQUIRED.**
+          
           **Describe your solution in detail.** Explain not just what to build, but how it should work.
           
           ✅ **Good examples:**
@@ -117,9 +138,11 @@
         </description>
         <placeholder>Describe the specific changes and how they will work. Include user interaction details if relevant.</placeholder>
       </field>
-      <field name="acceptance-criteria" type="textarea" required="true">
-        <label>How will we know it works? (Acceptance Criteria)</label>
+      <field name="acceptance-criteria" type="textarea" required_if_contributing="true">
+        <label>How will we know it works? (Acceptance Criteria - REQUIRED if contributing, optional otherwise)</label>
         <description>
+          **If you want to implement this feature, this section is REQUIRED.**
+          
           **This is crucial - don't skip it.** Define what "working" looks like with specific, testable criteria.
           
           **Format suggestion:**
@@ -146,35 +169,11 @@
           Use the Given/When/Then format above or your own clear structure.
         </placeholder>
       </field>
-      <field name="estimated-effort" type="textarea" required="true">
-        <label>Estimated effort and complexity</label>
+      <field name="technical-considerations" type="textarea" required_if_contributing="true">
+        <label>Technical considerations (REQUIRED if contributing, optional otherwise)</label>
         <description>
-          **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
-          ```
-        </description>
-        <placeholder>
-          Size: [your estimate]
-          Reasoning: [why this size?]
-          Main challenges: [what's tricky?]
-          Dependencies: [what else is needed?]
-        </placeholder>
-      </field>
-      <field name="technical-considerations" type="textarea" required="false">
-        <label>Technical considerations (optional but helpful)</label>
-        <description>
           Share technical insights that could help planning:
           - Implementation approach or architecture changes
           - Performance implications
@@ -184,9 +183,11 @@
         </description>
         <placeholder>e.g., "Will need to refactor task manager", "Could impact memory usage on large files", "Requires a large portion of code to be rewritten"</placeholder>
       </field>
-      <field name="trade-offs-and-risks" type="textarea" required="false">
-        <label>Trade-offs and risks (optional)</label>
+      <field name="trade-offs-and-risks" type="textarea" required_if_contributing="true">
+        <label>Trade-offs and risks (REQUIRED if contributing, optional otherwise)</label>
         <description>
+          **If you want to implement this feature, this section is REQUIRED.**
+          
           What could go wrong or what alternatives did you consider?
           - Alternative approaches and why you chose this one
           - Potential negative impacts (performance, UX, etc.)
@@ -195,10 +196,24 @@
         </description>
         <placeholder>e.g., "Alternative: use library X but it is 500KB larger", "Risk: might slow older devices", "Breaking: changes API response format"</placeholder>
       </field>
-      <field name="additional-context" type="textarea" required="false">
-        <label>Additional context (optional)</label>
-        <description>Mockups, screenshots, links, user quotes, or other relevant information that supports your proposal.</description>
-      </field>
-    </fields>
+    </contributor_fields>
   </feature_request_template>
+  
+  <template_changes_summary>
+    <change type="focus_shift">
+      Template now focuses on problem reporting first, with solution contribution as optional
+    </change>
+    <change type="required_fields">
+      Only problem description and context are required for basic submission
+    </change>
+    <change type="contributor_section">
+      Technical fields (solution, acceptance criteria, etc.) are only required if user wants to contribute
+    </change>
+    <change type="clear_exit_point">
+      Users can submit after describing the problem without technical details
+    </change>
+    <change type="guidance_separation">
+      Implementation guidance moved to contributor section only
+    </change>
+  </template_changes_summary>
 </github_issue_templates>

.roo/rules-issue-writer/3_best_practices.xml

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

.roo/rules-issue-writer/4_common_mistakes_to_avoid.xml

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

.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
-    <github_issue_templates><bug_report_template> and <github_issue_templates><feature_request_template>
+    2_github_issue_templates.xml, with different formats for problem reporters
+    vs contributors.
   </overview>
 
   <pre_creation_tools>
@@ -93,10 +94,15 @@
     </tool>
   </pre_creation_tools>
 
-  <codebase_investigation_tools>
+  <contributor_only_tools>
+    <note>
+      These tools should ONLY be used if the user has indicated they want to
+      contribute the implementation. Skip these for problem reporters.
+    </note>
+    
     <tool name="list_commits">
       <when_to_use>
-        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.
       </when_to_use>
       <example>
@@ -137,7 +143,7 @@
     <tool name="search_code">
       <when_to_use>
         Use to find code patterns across the repository on GitHub.
-        Complements local codebase_search tool.
+        Complements local codebase_search tool for contributors.
       </when_to_use>
       <example>
         <use_mcp_tool>
@@ -174,15 +180,15 @@
         </use_mcp_tool>
       </example>
     </tool>
-  </codebase_investigation_tools>
+  </contributor_only_tools>
 
   <issue_creation_tool>
     <tool name="create_issue">
       <when_to_use>
         Only use after:
         1. Confirming no duplicates exist
-        2. Gathering all required information per <github_issue_templates><bug_report_template> or <github_issue_templates><feature_request_template>
-        3. Exploring codebase for context
+        2. Gathering all required information
+        3. Determining if user is contributing or just reporting
         4. Getting user confirmation
       </when_to_use>
       <bug_report_example>
@@ -194,13 +200,28 @@
           "owner": "RooCodeInc",
           "repo": "Roo-Code",
           "title": "[Descriptive title of the bug]",
-          "body": "[Format according to <github_issue_templates><bug_report_template> fields]",
+          "body": "[Format according to bug report template]",
           "labels": ["bug"]
         }
         </arguments>
         </use_mcp_tool>
       </bug_report_example>
-      <feature_request_example>
+      <feature_request_problem_reporter_example>
+        <use_mcp_tool>
+        <server_name>github</server_name>
+        <tool_name>create_issue</tool_name>
+        <arguments>
+        {
+          "owner": "RooCodeInc",
+          "repo": "Roo-Code",
+          "title": "[Problem-focused title]",
+          "body": "[Problem description only - no technical details]",
+          "labels": ["proposal", "enhancement"]
+        }
+        </arguments>
+        </use_mcp_tool>
+      </feature_request_problem_reporter_example>
+      <feature_request_contributor_example>
         <use_mcp_tool>
         <server_name>github</server_name>
         <tool_name>create_issue</tool_name>
@@ -208,21 +229,20 @@
         {
           "owner": "RooCodeInc",
           "repo": "Roo-Code",
-          "title": "[Descriptive title of the feature request]",
-          "body": "[Format according to <github_issue_templates><feature_request_template> fields]",
+          "title": "[Problem-focused title with implementation intent]",
+          "body": "[Full template including technical analysis sections]",
           "labels": ["proposal", "enhancement"]
         }
         </arguments>
         </use_mcp_tool>
-      </feature_request_example>
+      </feature_request_contributor_example>
     </tool>
   </issue_creation_tool>
 
   <post_creation_tools>
     <tool name="add_issue_comment">
       <when_to_use>
-        ONLY Use if user wants to add additional information after creation.
-
+        ONLY use if user wants to add additional information after creation.
       </when_to_use>
       <example>
         <use_mcp_tool>
@@ -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."
         }
         </arguments>
         </use_mcp_tool>
@@ -281,21 +301,30 @@
     </step_3_integration>
 
     <step_4_integration>
-      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
+    </step_4_integration>
+
+    <step_5_integration>
+      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
-    </step_4_integration>
+    </step_5_integration>
 
-    <step_5_integration>
+    <step_6_integration>
       When creating the issue:
-      1. Format the issue body according to <github_issue_templates><bug_report_template> or <github_issue_templates><feature_request_template>
-      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
-    </step_5_integration>
+      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
+    </step_6_integration>
   </workflow_integration>
 
   <error_handling>