Skip to content

Commit 2ea2663

Browse files
hannesrudolphhannesrudolph
authored
feat: Add Issue Writer and Issue Fixer modes with comprehensive workflows (#4437)
* Add issue writer mode with detailed templates for bug reports and feature proposals * Refactor issue-writer mode to enhance role definition and instructions for creating GitHub issues * Add steps for searching GitHub Discussions and documenting related issues in the issue creation process * Add Issue Fixer mode with detailed workflow for resolving GitHub issues * Enhance Issue Fixer mode with detailed workflows for PR reviews and issue handling * Refactor Issue Fixer and Issue Worker modes to enhance workflow orchestration and implementation processes. Updated role definitions, added detailed workflows for issue resolution, and improved context management and communication guidelines. * Enhance issue-worker mode with branch verification steps and detailed instructions for ensuring correct branch setup before implementation. Updated workflow to include branch context in design planning and final verification processes. * Enhance pull request creation and verification workflow with detailed steps for branch verification, commit checks, and comprehensive PR status monitoring. Improved instructions for ensuring successful PR creation and linking to original issues. * feat: Add Issue Writer and Issue Fixer modes with comprehensive workflows - Add Issue Writer mode for creating well-structured GitHub issues - Add Issue Fixer mode for implementing fixes from GitHub issues - Include detailed workflow rules and best practices for both modes - Add GitHub MCP tool usage guidelines - Include PR workflow and communication guidelines
1 parent ba6490c commit 2ea2663

15 files changed

+1583
-95
lines changed

‎.roo/rules-issue-fixer/1_Workflow.xml‎

Lines changed: 492 additions & 0 deletions
Large diffs are not rendered by default.

‎.roo/rules-issue-fixer/2_best_practices.xml‎

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,14 @@
1+
<best_practices>
2+
- Always read the entire issue and all comments before starting
3+
- Follow the project's coding standards and patterns
4+
- Make minimal changes for bug fixes (don't refactor unnecessarily)
5+
- Test thoroughly - both automated and manual testing
6+
- Document complex logic with comments
7+
- Keep commits focused and well-described
8+
- Reference the issue number in commits
9+
- Verify all acceptance criteria are met
10+
- Consider performance and security implications
11+
- Update documentation when needed
12+
- Add tests for any new functionality
13+
- Check for accessibility issues (for UI changes)
14+
</best_practices>

‎.roo/rules-issue-fixer/3_common_patterns.xml‎

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
<common_patterns>
2+
<bug_fix_pattern>
3+
1. Reproduce the issue
4+
2. Identify root cause
5+
3. Implement minimal fix
6+
4. Add regression test
7+
5. Verify fix works
8+
6. Check for side effects
9+
</bug_fix_pattern>
10+
11+
<feature_implementation_pattern>
12+
1. Understand all requirements
13+
2. Design the solution
14+
3. Implement incrementally
15+
4. Test each component
16+
5. Integrate components
17+
6. Verify acceptance criteria
18+
7. Add comprehensive tests
19+
8. Update documentation
20+
</feature_implementation_pattern>
21+
</common_patterns>

‎.roo/rules-issue-fixer/4_github_mcp_tool_usage.xml‎

Lines changed: 88 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,88 @@
1+
<github_mcp_tools_usage>
2+
<primary_tools>
3+
<tool name="get_issue">
4+
<purpose>Retrieve the issue details at the start</purpose>
5+
<when>Always use first to get the full issue content</when>
6+
</tool>
7+
8+
<tool name="get_issue_comments">
9+
<purpose>Get additional context and requirements</purpose>
10+
<when>Always use after get_issue to see full discussion</when>
11+
</tool>
12+
13+
<tool name="list_commits">
14+
<purpose>Find recent changes to affected files</purpose>
15+
<when>Use during codebase exploration</when>
16+
</tool>
17+
18+
<tool name="search_code">
19+
<purpose>Find code patterns on GitHub</purpose>
20+
<when>Use to supplement local codebase_search</when>
21+
</tool>
22+
</primary_tools>
23+
24+
<optional_tools>
25+
<tool name="add_issue_comment">
26+
<purpose>Add progress updates or ask questions</purpose>
27+
<when>Use if clarification needed or to show progress</when>
28+
</tool>
29+
30+
<tool name="list_pull_requests">
31+
<purpose>Find related or similar PRs</purpose>
32+
<when>Use to understand similar changes</when>
33+
</tool>
34+
35+
<tool name="get_pull_request">
36+
<purpose>Get details of related PRs</purpose>
37+
<when>Use when issue references specific PRs</when>
38+
</tool>
39+
</optional_tools>
40+
41+
<pull_request_tools>
42+
<tool name="create_pull_request">
43+
<purpose>Create a pull request to RooCodeInc/Roo-Code</purpose>
44+
<when>Use in step 10 after user approval</when>
45+
<important>
46+
- Always target RooCodeInc/Roo-Code repository
47+
- Use "main" as the base branch unless specified otherwise
48+
- Include issue number in PR title
49+
- Set maintainer_can_modify to true
50+
</important>
51+
<example>
52+
<use_mcp_tool>
53+
<server_name>github</server_name>
54+
<tool_name>create_pull_request</tool_name>
55+
<arguments>
56+
{
57+
"owner": "RooCodeInc",
58+
"repo": "Roo-Code",
59+
"title": "fix: Resolve dark theme button visibility (#123)",
60+
"head": "username:fix/issue-123-dark-theme-button",
61+
"base": "main",
62+
"body": "## Description\n\nFixes #123\n\n[Full PR description]",
63+
"draft": false,
64+
"maintainer_can_modify": true
65+
}
66+
</arguments>
67+
</use_mcp_tool>
68+
</example>
69+
</tool>
70+
71+
<tool name="fork_repository">
72+
<purpose>Fork the repository if user doesn't have push access</purpose>
73+
<when>Use if user needs to work from a fork</when>
74+
<example>
75+
<use_mcp_tool>
76+
<server_name>github</server_name>
77+
<tool_name>fork_repository</tool_name>
78+
<arguments>
79+
{
80+
"owner": "RooCodeInc",
81+
"repo": "Roo-Code"
82+
}
83+
</arguments>
84+
</use_mcp_tool>
85+
</example>
86+
</tool>
87+
</pull_request_tools>
88+
</github_mcp_tools_usage>

‎.roo/rules-issue-fixer/5_pull_request_workflow.xml‎

Lines changed: 30 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,30 @@
1+
<pull_request_workflow>
2+
<preparation>
3+
1. Ensure all changes are committed with proper message format
4+
2. Push to appropriate branch (fork or direct)
5+
3. Prepare comprehensive PR description
6+
4. Get user approval before creating PR
7+
</preparation>
8+
9+
<pr_title_format>
10+
- Bug fixes: "fix: [description] (#[issue-number])"
11+
- Features: "feat: [description] (#[issue-number])"
12+
- Follow conventional commit format
13+
</pr_title_format>
14+
15+
<pr_description_template>
16+
Must include:
17+
- Link to issue (Fixes #[number])
18+
- Detailed description of changes
19+
- Testing performed
20+
- Verification of acceptance criteria
21+
- Checklist items
22+
- Screenshots/demos if applicable
23+
</pr_description_template>
24+
25+
<after_creation>
26+
1. Comment on original issue with PR link
27+
2. Inform user of successful creation
28+
3. Provide next steps and tracking info
29+
</after_creation>
30+
</pull_request_workflow>

‎.roo/rules-issue-fixer/6_testing_guidelines.xml‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
<testing_guidelines>
2+
- Always run existing tests before making changes (baseline)
3+
- Add tests for any new functionality
4+
- Add regression tests for bug fixes
5+
- Test edge cases and error conditions
6+
- Run the full test suite before completing
7+
- For UI changes, test in multiple themes
8+
- Verify accessibility (keyboard navigation, screen readers)
9+
- Test performance impact for large operations
10+
</testing_guidelines>

‎.roo/rules-issue-fixer/7_communication_style.xml‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
<communication_style>
2+
- Be clear about what you're doing at each step
3+
- Explain technical decisions and trade-offs
4+
- Ask for clarification if requirements are ambiguous
5+
- Provide regular progress updates for complex issues
6+
- Summarize changes clearly for non-technical stakeholders
7+
- Use issue numbers and links for reference
8+
</communication_style>

‎.roo/rules-issue-fixer/8_github_communication_guidelines.xml‎

Lines changed: 26 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
1+
<github_communication_guidelines>
2+
<pr_comments>
3+
- Keep comments concise and focused on technical substance
4+
- Avoid overly verbose explanations unless specifically requested
5+
- Sound human and conversational, not robotic
6+
- Address specific feedback points directly
7+
- Use bullet points for multiple changes
8+
- Reference line numbers or specific code when relevant
9+
- Example: "Updated the error handling in `validateInput()` to catch edge cases as requested. Also added the missing null check on line 45."
10+
</pr_comments>
11+
12+
<issue_comments>
13+
- Provide brief status updates when working on complex issues
14+
- Ask specific questions if requirements are unclear
15+
- Share findings when investigation reveals important context
16+
- Keep progress updates factual and concise
17+
- Example: "Found the root cause in the theme detection logic. Working on a fix that preserves backward compatibility."
18+
</issue_comments>
19+
20+
<commit_messages>
21+
- Follow conventional commit format: "type: description (#issue-number)"
22+
- Keep first line under 72 characters
23+
- Be specific about what changed
24+
- Example: "fix: resolve button visibility in dark theme (#123)"
25+
</commit_messages>
26+
</github_communication_guidelines>

‎.roo/rules-issue-fixer/9_pr_review_workflow.xml‎

Lines changed: 30 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,30 @@
1+
<pr_review_workflow>
2+
<handling_feedback>
3+
When working on PR review feedback:
4+
1. Read all review comments carefully
5+
2. Identify specific changes requested
6+
3. Group related feedback into logical changes
7+
4. Address each point systematically
8+
5. Test changes thoroughly
9+
6. Respond to each review comment when pushing updates
10+
7. Use "Resolved" or brief explanations for each addressed point
11+
</handling_feedback>
12+
13+
<partial_implementation>
14+
For partial workflows (user-requested changes to existing PRs):
15+
1. Focus only on the specific changes requested
16+
2. Don't refactor unrelated code unless explicitly asked
17+
3. Maintain consistency with existing PR approach
18+
4. Test only the modified functionality unless broader testing is needed
19+
5. Update PR description if significant changes are made
20+
</partial_implementation>
21+
22+
<review_response_format>
23+
When responding to review comments:
24+
- "✅ Fixed - [brief description of change]"
25+
- "✅ Added - [what was added]"
26+
- "✅ Updated - [what was changed]"
27+
- "❓ Question - [if clarification needed]"
28+
- Keep responses short and action-oriented
29+
</review_response_format>
30+
</pr_review_workflow>

0 commit comments

Comments
 (0)