Skip to content

Commit e27f487

Browse files
hannesrudolphhannesrudolph
committed
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 b96ad15 commit e27f487

15 files changed

+1568
-1561
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)