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

Update issue writer rules and workflow configurations (#6230)

Browse source
This commit is contained in:
Hannes Rudolph 2025-07-27 10:20:41 -06:00 • committed by GitHub
parent 7a6e852248
commit b73c17a375
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
7 changed files with 1540 additions and 829 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

File diff suppressed because it is too large Load diff

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

@ -1,219 +1,190 @@
<github_issue_templates>
<bug_report_template>
<name>Bug Report</name>
<description>Clearly report a bug with detailed repro steps</description>
<labels>["bug"]</labels>
<fields>
<field name="version" type="input" required="true">
<label>App Version</label>
<description>What version of Roo Code are you using? (e.g., v3.3.1)</description>
</field>
<field name="provider" type="dropdown" required="true">
<label>API Provider</label>
<options>
- 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
</options>
</field>
<field name="model" type="input" required="true">
<label>Model Used</label>
<description>Exact model name (e.g., Claude 3.7 Sonnet). Use N/A if irrelevant.</description>
</field>
<field name="steps" type="textarea" required="true">
<label>🔁 Steps to Reproduce</label>
<description>
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.
</description>
</field>
<field name="what-happened" type="textarea" required="true">
<label>💥 Outcome Summary</label>
<description>
Recap what went wrong in one or two lines.
Example: "Expected code to run, but got an empty response and no error."
</description>
<placeholder>Expected ___, but got ___.</placeholder>
</field>
<field name="logs" type="textarea" required="false">
<label>📄 Relevant Logs or Errors (Optional)</label>
<description>Paste API logs, terminal output, or errors here. Use triple backticks (```) for code formatting.</description>
<render>shell</render>
</field>
</fields>
</bug_report_template>
<feature_request_template>
<name>Detailed Feature Proposal</name>
<description>Report a specific problem that needs solving in Roo Code</description>
<labels>["proposal", "enhancement"]</labels>
<required_fields>
<field name="problem-description" type="textarea" required="true">
<label>What specific problem does this solve?</label>
<description>
**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.)
</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="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>
<overview>
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.
</overview>
<template_detection>
<locations>
<location priority="1">.github/ISSUE_TEMPLATE/*.yml</location>
<location priority="2">.github/ISSUE_TEMPLATE/*.yaml</location>
<location priority="3">.github/ISSUE_TEMPLATE/*.md</location>
<location priority="4">.github/issue_template.md</location>
<location priority="5">.github/ISSUE_TEMPLATE.md</location>
</locations>
<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:**
- "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?
</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_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:**
```
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
```
</description>
<placeholder>
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.
</placeholder>
</field>
<field name="technical-considerations" type="textarea" required_if_contributing="true">
<label>Technical considerations (REQUIRED if contributing, optional otherwise)</label>
<description>
**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
</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_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.)
- Breaking changes or migration concerns
- Edge cases that need careful handling
</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>
</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>
<yaml_template_structure>
<field name="name">Display name of the template</field>
<field name="description">Brief description of when to use this template</field>
<field name="title">Default issue title (optional)</field>
<field name="labels">Array of labels to apply</field>
<field name="assignees">Array of default assignees</field>
<field name="body">Array of form elements or markdown content</field>
</yaml_template_structure>
<yaml_form_elements>
<element type="markdown">
<description>Static markdown content</description>
<attributes>
<attr name="value">The markdown content to display</attr>
</attributes>
</element>
<element type="input">
<description>Single-line text input</description>
<attributes>
<attr name="id">Unique identifier</attr>
<attr name="label">Display label</attr>
<attr name="description">Help text</attr>
<attr name="placeholder">Placeholder text</attr>
<attr name="value">Default value</attr>
<attr name="required">Boolean</attr>
</attributes>
</element>
<element type="textarea">
<description>Multi-line text input</description>
<attributes>
<attr name="id">Unique identifier</attr>
<attr name="label">Display label</attr>
<attr name="description">Help text</attr>
<attr name="placeholder">Placeholder text</attr>
<attr name="value">Default value</attr>
<attr name="required">Boolean</attr>
<attr name="render">Language for syntax highlighting</attr>
</attributes>
</element>
<element type="dropdown">
<description>Dropdown selection</description>
<attributes>
<attr name="id">Unique identifier</attr>
<attr name="label">Display label</attr>
<attr name="description">Help text</attr>
<attr name="options">Array of options</attr>
<attr name="required">Boolean</attr>
</attributes>
</element>
<element type="checkboxes">
<description>Multiple checkbox options</description>
<attributes>
<attr name="id">Unique identifier</attr>
<attr name="label">Display label</attr>
<attr name="description">Help text</attr>
<attr name="options">Array of checkbox items</attr>
</attributes>
</element>
</yaml_form_elements>
<markdown_template_structure>
<front_matter>
Optional YAML front matter with:
- name: Template name
- about: Template description
- title: Default title
- labels: Comma-separated or array
- assignees: Comma-separated or array
</front_matter>
<body>
Markdown content with sections and placeholders
Common patterns:
- Headers with ##
- Placeholder text in brackets or as comments
- Checklists with - [ ]
- Code blocks with ```
</body>
</markdown_template_structure>
</template_detection>
<generic_templates>
<description>
When no repository templates exist, create simple templates based on issue type.
These should be minimal and focused on gathering essential information.
</description>
<bug_template>
<structure>
- 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)
</structure>
<labels>["bug"]</labels>
</bug_template>
<feature_template>
<structure>
- 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)
</structure>
<labels>["enhancement", "proposal"]</labels>
</feature_template>
</generic_templates>
<template_parsing_guidelines>
<guideline>
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
</guideline>
<guideline>
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
</guideline>
<guideline>
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.)
</guideline>
</template_parsing_guidelines>
<filling_templates>
<principle>
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
</principle>
<mapping_examples>
<example from="Steps to Reproduce" to="User's reproduction steps + code paths"/>
<example from="Expected behavior" to="What user expects + code logic verification"/>
<example from="System information" to="Detected versions + environment"/>
<example from="Additional context" to="Code findings + architecture insights"/>
</mapping_examples>
</filling_templates>
<no_template_behavior>
<description>
When no templates exist, create appropriate generic templates on the fly.
Keep them simple and focused on essential information.
</description>
<guidelines>
- 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)
</guidelines>
</no_template_behavior>
</github_issue_templates>

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

@ -1,38 +1,172 @@
<best_practices>
<mode_behavior>
- 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
</mode_behavior>
<template_usage>
- 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
</template_usage>
<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
- 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]"
</problem_reporting_focus>
<fact_driven_verification>
- 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
</fact_driven_verification>
<general_practices>
- 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'"
</general_practices>
<contributor_specific>
- 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"
</contributor_specific>
<backwards_compatibility_focus>
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
</backwards_compatibility_focus>
<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
- When presenting template choices, include template descriptions to help users choose
- Explain that you're using the repository's own templates for consistency
</communication_guidelines>
<template_best_practices>
<practice name="template_detection">
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)
</practice>
<practice name="template_parsing">
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
</practice>
<practice name="template_filling">
- 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
</practice>
<practice name="no_template_handling">
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
</practice>
</template_best_practices>
<technical_accuracy_guidelines>
<guideline name="thorough_code_analysis">
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
</guideline>
<guideline name="simplicity_first">
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
</guideline>
<guideline name="precise_technical_details">
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
</guideline>
</technical_accuracy_guidelines>
</best_practices>

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

@ -1,4 +1,13 @@
<common_mistakes_to_avoid>
<mode_initialization_mistakes>
- 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
</mode_initialization_mistakes>
<problem_reporting_mistakes>
- Vague descriptions like "doesn't work" or "broken"
- Missing reproduction steps for bugs
@ -12,19 +21,106 @@
<workflow_mistakes>
- 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
</workflow_mistakes>
<contributor_mistakes>
- 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
</contributor_mistakes>
<technical_analysis_mistakes>
<mistake>Not tracing data flow completely through the system</mistake>
<impact>Missing that data already exists leads to proposing unnecessary new code</impact>
<correct_approach>
- 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
</correct_approach>
<example>
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"
</example>
</technical_analysis_mistakes>
<solution_design_mistakes>
<mistake>Proposing complex new systems when simple fixes exist</mistake>
<impact>Creates unnecessary complexity, maintenance burden, and potential bugs</impact>
<correct_approach>
- 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
</correct_approach>
<example>
Bad: "Create new state management system for mode tracking"
Good: "Pass existing modeInfo variable from line 45 to the function at line 78"
</example>
</solution_design_mistakes>
<code_verification_mistakes>
<mistake>Not reading actual code before proposing solutions</mistake>
<impact>Solutions don't match the actual codebase structure</impact>
<correct_approach>
- 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
</correct_approach>
</code_verification_mistakes>
<pattern_recognition_mistakes>
<mistake>Creating new patterns instead of following existing ones</mistake>
<impact>Inconsistent codebase, harder to maintain</impact>
<correct_approach>
- Find similar features that work correctly
- Follow the same patterns and structures
- Reuse existing utilities and helpers
- Maintain consistency with the codebase style
</correct_approach>
</pattern_recognition_mistakes>
<template_usage_mistakes>
<mistake>Using hardcoded templates when repository templates exist</mistake>
<impact>Issues don't follow repository conventions, may be rejected or need reformatting</impact>
<correct_approach>
- Always check .github/ISSUE_TEMPLATE/ directory first
- Parse and use repository templates when available
- Only create generic templates when none exist
</correct_approach>
</template_usage_mistakes>
<template_parsing_mistakes>
<mistake>Not properly parsing YAML template structure</mistake>
<impact>Missing required fields, incorrect formatting, lost metadata</impact>
<correct_approach>
- 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
</correct_approach>
</template_parsing_mistakes>
<template_filling_mistakes>
<mistake>Leaving placeholder text in final issue</mistake>
<impact>Unprofessional appearance, confusion about what information is needed</impact>
<correct_approach>
- 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
</correct_approach>
</template_filling_mistakes>
</common_mistakes_to_avoid>

137
.roo/rules-issue-writer/5_github_cli_usage.xml
View file

@ -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.
</overview>
<pre_creation_commands>
@ -16,7 +15,7 @@
</when_to_use>
<example>
<execute_command>
<command>gh issue list --repo RooCodeInc/Roo-Code --search "dark theme button visibility" --state all --limit 20</command>
<command>gh issue list --repo $REPO_FULL_NAME --search "dark theme button visibility" --state all --limit 20</command>
</execute_command>
</example>
<options>
@ -35,7 +34,7 @@
</when_to_use>
<example>
<execute_command>
<command>gh search issues --repo RooCodeInc/Roo-Code "dark theme button" --limit 10</command>
<command>gh search issues --repo $REPO_FULL_NAME "dark theme button" --limit 10</command>
</execute_command>
</example>
</command>
@ -47,7 +46,7 @@
</when_to_use>
<example>
<execute_command>
<command>gh issue view 123 --repo RooCodeInc/Roo-Code --comments</command>
<command>gh issue view 123 --repo $REPO_FULL_NAME --comments</command>
</execute_command>
</example>
<options>
@ -58,6 +57,46 @@
</command>
</pre_creation_commands>
<template_detection_commands>
<command name="list_files">
<when_to_use>
Use to check for issue templates in the repository before creating issues.
This is not a gh command but necessary for template detection.
</when_to_use>
<examples>
Check for templates in standard location:
<list_files>
<path>.github/ISSUE_TEMPLATE</path>
<recursive>true</recursive>
</list_files>
Check for single template file:
<list_files>
<path>.github</path>
<recursive>false</recursive>
</list_files>
</examples>
</command>
<command name="read_file">
<when_to_use>
Read template files to parse their structure and content.
Used after detecting template files.
</when_to_use>
<examples>
Read YAML template:
<read_file>
<path>.github/ISSUE_TEMPLATE/bug_report.yml</path>
</read_file>
Read Markdown template:
<read_file>
<path>.github/ISSUE_TEMPLATE/feature_request.md</path>
</read_file>
</examples>
</command>
</template_detection_commands>
<contributor_only_commands>
<note>
These commands should ONLY be used if the user has indicated they want to
@ -70,7 +109,7 @@
</when_to_use>
<example>
<execute_command>
<command>gh repo view RooCodeInc/Roo-Code --json defaultBranchRef,description,updatedAt</command>
<command>gh repo view $REPO_FULL_NAME --json defaultBranchRef,description,updatedAt</command>
</execute_command>
</example>
</command>
@ -82,7 +121,7 @@
</when_to_use>
<example>
<execute_command>
<command>gh search prs --repo RooCodeInc/Roo-Code "dark theme" --limit 10 --state all</command>
<command>gh search prs --repo $REPO_FULL_NAME "dark theme" --limit 10 --state all</command>
</execute_command>
</example>
</command>
@ -105,18 +144,19 @@
<when_to_use>
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
</when_to_use>
<bug_report_example>
<execute_command>
<command>gh issue create --repo RooCodeInc/Roo-Code --title "[Descriptive title of the bug]" --body-file /tmp/issue_body.md --label "bug"</command>
<command>gh issue create --repo $REPO_FULL_NAME --title "[Descriptive title of the bug]" --body-file /tmp/issue_body.md --label "bug"</command>
</execute_command>
</bug_report_example>
<feature_request_example>
<execute_command>
<command>gh issue create --repo RooCodeInc/Roo-Code --title "[Problem-focused title]" --body-file /tmp/issue_body.md --label "proposal" --label "enhancement"</command>
<command>gh issue create --repo $REPO_FULL_NAME --title "[Problem-focused title]" --body-file /tmp/issue_body.md --label "proposal" --label "enhancement"</command>
</execute_command>
</feature_request_example>
<options>
@ -138,7 +178,7 @@
</when_to_use>
<example>
<execute_command>
<command>gh issue comment 456 --repo RooCodeInc/Roo-Code --body "Additional context or comments."</command>
<command>gh issue comment 456 --repo $REPO_FULL_NAME --body "Additional context or comments."</command>
</execute_command>
</example>
</command>
@ -150,7 +190,7 @@
</when_to_use>
<example>
<execute_command>
<command>gh issue edit 456 --repo RooCodeInc/Roo-Code --title "[Updated title]" --body "[Updated body]"</command>
<command>gh issue edit 456 --repo $REPO_FULL_NAME --title "[Updated title]" --body "[Updated body]"</command>
</execute_command>
</example>
</command>
@ -164,41 +204,41 @@
3. Ask if they want to continue or comment on existing issue
</step_1_integration>
<step_3_integration>
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
</step_3_integration>
<step_2_integration>
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
</step_2_integration>
<step_4_integration>
<step_3_integration>
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
</step_4_integration>
</step_3_integration>
<step_5_integration>
<step_4_integration>
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
</step_5_integration>
</step_4_integration>
<step_6_integration>
<step_5_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
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
</step_6_integration>
</step_5_integration>
</workflow_integration>
<best_practices>
@ -270,4 +310,33 @@
gh repo clone - Clone repository
</repository>
</command_reference>
<template_handling_reference>
<yaml_template_parsing>
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
</yaml_template_parsing>
<markdown_template_parsing>
When parsing Markdown templates:
- Check for YAML front matter
- Extract metadata (labels, assignees)
- Identify section headers
- Replace placeholder text
- Maintain formatting structure
</markdown_template_parsing>
<template_usage_flow>
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
</template_usage_flow>
</template_handling_reference>
</github_cli_usage>

349
.roo/rules-issue-writer/6_technical_analysis_workflow.xml
View file

@ -1,349 +0,0 @@
<technical_analysis_workflow>
<overview>
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.
</overview>
<initialization>
<step number="1">
<name>Create Investigation Plan</name>
<instructions>
When technical analysis is requested, immediately create a comprehensive todo list
to track the investigation progress.
</instructions>
<tool_use><![CDATA[
<update_todo_list>
<todos>
[ ] 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
</todos>
</update_todo_list>
]]></tool_use>
</step>
</initialization>
<investigation_phases>
<phase name="keyword_extraction">
<description>
Extract all relevant keywords, concepts, and technical terms from the issue description.
Be exhaustive - include function names, error messages, feature names, and related concepts.
</description>
<actions>
<action>Identify primary technical concepts</action>
<action>Extract error messages or specific symptoms</action>
<action>Note any mentioned file paths or components</action>
<action>List related features or functionality</action>
<action>Include synonyms and related terms</action>
</actions>
<update_todo>Mark "Extract keywords from the issue description" as complete</update_todo>
</phase>
<phase name="iterative_search">
<description>
Perform multiple rounds of codebase searches, starting broad and progressively
narrowing based on findings. This is an aggressive, exhaustive search process.
</description>
<iteration number="1">
<title>Initial Broad Search</title>
<instructions>
Use codebase_search with all extracted keywords to get an overview of relevant code.
<tool_use><![CDATA[
<codebase_search>
<query>[Combined keywords from extraction phase]</query>
</codebase_search>
]]></tool_use>
</instructions>
</iteration>
<iteration number="2">
<title>Component Discovery</title>
<instructions>
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
</instructions>
</iteration>
<iteration number="3">
<title>Deep Implementation Search</title>
<instructions>
Search for specific implementation details:
- Error handling patterns
- State management
- API endpoints or routes
- Database queries or models
- UI components and their interactions
</instructions>
</iteration>
<iteration number="4">
<title>Edge Case and Integration Search</title>
<instructions>
Look for:
- Edge cases in the code
- Integration points with other systems
- Configuration options that affect behavior
- Feature flags or conditional logic
</instructions>
</iteration>
<update_todo>Update search-related todos as each iteration completes</update_todo>
</phase>
<phase name="file_analysis">
<description>
Thoroughly analyze all relevant files discovered during the search phase.
</description>
<actions>
<action>Use list_code_definition_names to understand file structure</action>
<action>Read complete files to understand full context</action>
<action>Trace execution paths through the code</action>
<action>Identify all dependencies and imports</action>
<action>Map relationships between components</action>
</actions>
<documentation>
Document findings including:
- File paths and their purposes
- Key functions and their responsibilities
- Data flow through the system
- External dependencies
- Potential impact areas
</documentation>
<update_todo>Mark file analysis todos as complete</update_todo>
</phase>
<phase name="hypothesis_formation">
<description>
Form a comprehensive hypothesis about the issue or feature implementation.
</description>
<for_bugs>
<steps>
<step>Identify the most likely root cause</step>
<step>Trace the bug through the execution path</step>
<step>Determine why the current implementation fails</step>
<step>Consider environmental factors</step>
</steps>
</for_bugs>
<for_features>
<steps>
<step>Identify the optimal integration points</step>
<step>Determine required architectural changes</step>
<step>Plan the implementation approach</step>
<step>Consider scalability and maintainability</step>
</steps>
</for_features>
<update_todo>Mark hypothesis formation as complete</update_todo>
</phase>
<phase name="hypothesis_validation">
<description>
Aggressively attempt to disprove the hypothesis by searching for contradictory evidence.
</description>
<validation_steps>
<step>
<title>Search for Alternative Implementations</title>
<action>Look for similar features implemented differently</action>
<action>Check for deprecated code that might interfere</action>
</step>
<step>
<title>Configuration and Environment Check</title>
<action>Search for configuration that could change behavior</action>
<action>Look for environment-specific code paths</action>
</step>
<step>
<title>Test Case Analysis</title>
<action>Find existing tests that might contradict hypothesis</action>
<action>Look for test cases that reveal edge cases</action>
</step>
<step>
<title>Historical Context</title>
<action>Search for comments explaining design decisions</action>
<action>Look for TODO or FIXME comments related to the area</action>
</step>
</validation_steps>
<outcome>
If hypothesis is disproven, return to search phase with new insights.
If hypothesis stands, proceed to solution formulation.
</outcome>
<update_todo>Update hypothesis validation status</update_todo>
</phase>
<phase name="solution_formulation">
<description>
Create a comprehensive technical solution with extreme detail.
</description>
<components>
<component name="implementation_plan">
<details>
- 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
</details>
</component>
<component name="dependency_analysis">
<details>
- All files that import affected code
- API contracts that must be maintained
- Database schema changes if any
- Configuration changes required
- Documentation updates needed
</details>
</component>
<component name="test_strategy">
<details>
- Unit tests to add or modify
- Integration tests required
- Edge cases to test
- Performance testing needs
- Manual testing scenarios
</details>
</component>
<component name="risk_assessment">
<details>
- Breaking changes identified
- Performance implications
- Security considerations
- Backward compatibility issues
- Rollback strategy
</details>
</component>
</components>
<update_todo>Mark solution formulation as complete</update_todo>
</phase>
<phase name="acceptance_criteria">
<description>
Create extremely detailed acceptance criteria that can guide automated implementation.
</description>
<format><![CDATA[
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
]]></format>
<guidelines>
<guideline>Each criterion must be independently testable</guideline>
<guideline>Include both positive and negative test cases</guideline>
<guideline>Specify exact error messages and codes</guideline>
<guideline>Define performance thresholds where applicable</guideline>
</guidelines>
<update_todo>Mark acceptance criteria creation as complete</update_todo>
</phase>
</investigation_phases>
<output_format>
<technical_analysis_section><![CDATA[
## 🔍 Comprehensive Technical Analysis
### Root Cause / Implementation Target
[Detailed explanation of the core issue or feature target]
### Affected Components
- **Primary Files:**
- `path/to/file1.ts` (lines X-Y): [Purpose and changes needed]
- `path/to/file2.ts` (lines A-B): [Purpose and changes needed]
- **Secondary Impact:**
- Files that import affected components
- Related test files
- Documentation files
### Current Implementation Analysis
[Detailed explanation of how the current code works and why it's insufficient]
### Proposed Implementation
#### Step 1: [First implementation step]
- File: `path/to/file.ts`
- Changes: [Specific code changes]
- Rationale: [Why this change is needed]
#### Step 2: [Second implementation step]
[Continue for all steps...]
### Code Architecture Considerations
- Design patterns to follow
- Existing patterns in codebase to match
- Architectural constraints
### Testing Requirements
- Unit Tests:
- [ ] Test case 1: [Description]
- [ ] Test case 2: [Description]
- Integration Tests:
- [ ] Test scenario 1: [Description]
- Edge Cases:
- [ ] Edge case 1: [Description]
### Performance Impact
- Expected performance change: [Increase/Decrease/Neutral]
- Benchmarking needed: [Yes/No, specifics]
- Optimization opportunities: [List any]
### Security Considerations
- Input validation requirements
- Authentication/Authorization changes
- Data exposure risks
### Migration Strategy
[If applicable, how to migrate existing data/functionality]
### Rollback Plan
[How to safely rollback if issues arise]
### Dependencies and Breaking Changes
- External dependencies affected: [List]
- API contract changes: [List]
- Breaking changes for users: [List with mitigation]
### Implementation Complexity
- Estimated effort: [Small/Medium/Large]
- Risk level: [Low/Medium/High]
- Prerequisites: [Any required changes that must happen first]
]]></technical_analysis_section>
</output_format>
<completion>
<checklist>
<item>All keywords extracted and searched</item>
<item>Multiple search iterations completed</item>
<item>All relevant files analyzed</item>
<item>Hypothesis formed and validated</item>
<item>Comprehensive solution documented</item>
<item>Acceptance criteria defined</item>
<item>All risks and edge cases identified</item>
<item>Technical analysis formatted for issue</item>
</checklist>
<final_todo_update>
Mark all investigation todos as complete and update the main workflow todo list
</final_todo_update>
</completion>
</technical_analysis_workflow>

36
.roomodes
View file

@ -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.
<initialization>
<step number="1">
<name>Initialize Issue Creation Process</name>
<instructions>
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
<update_todo_list>
<todos>
[ ] 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
</todos>
</update_todo_list>
</instructions>
</step>
</initialization>
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