scriptoriumadmin/Roo-Code
1
0
Fork 0
mirror of https://github.com/RooVetGit/Roo-Code.git synced 2026-08-28 05:27:24 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

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

Browse source
This commit is contained in:
Hannes Rudolph 2025-06-18 13:36:31 -06:00 • committed by GitHub
parent 775457c59a
commit b0f4ea78e1
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
5 changed files with 268 additions and 113 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

123
.roo/rules-issue-writer/1_workflow.xml
View file

@ -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,7 @@
- **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?
@ -158,9 +188,43 @@
**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?
[Detailed problem description following the template guidelines]
**Who is affected:** [user groups]
**When this happens:** [specific scenarios]
**Current behavior:** [what happens now]
**Expected behavior:** [what should happen]
**Impact:** [time wasted, errors, productivity loss]
## Additional context
[Any mockups, screenshots, links, or other supporting information]
---
## 🛠️ Contributing & Technical Analysis
✅ **I'm interested in implementing this feature**
✅ **I understand this needs approval before implementation begins**
## 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
## Technical Considerations
**Size:** [estimate]
**Reasoning:** [why this size]
**Main challenges:** [technical difficulties]
**Dependencies:** [what's needed]
## Technical Implementation Plan
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>

95
.roo/rules-issue-writer/2_github_issue_templates.xml
View file

@ -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>

48
.roo/rules-issue-writer/3_best_practices.xml
View file

@ -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>

36
.roo/rules-issue-writer/4_common_mistakes_to_avoid.xml
View file

@ -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>

79
.roo/rules-issue-writer/5_github_mcp_tool_usage.xml
View file

@ -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,13 @@
"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>
@ -208,21 +214,35 @@
{
"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]",
"body": "[Problem description only - no technical details]",
"labels": ["proposal", "enhancement"]
}
</arguments>
</use_mcp_tool>
</feature_request_example>
</feature_request_problem_reporter_example>
<feature_request_contributor_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 with implementation intent]",
"body": "[Full template including technical analysis sections]",
"labels": ["proposal", "enhancement"]
}
</arguments>
</use_mcp_tool>
</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>
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>
<step_6_integration>
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
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>