Skip to content

Commit 69ffa43

Browse files
hannesrudolphhannesrudolph
authored
Add Mode Writer mode to repo (#4600)
1 parent e618fa9 commit 69ffa43

File tree

7 files changed

+1320
-2
lines changed

7 files changed

+1320
-2
lines changed

‎.roo/rules-mode-writer/1_mode_creation_workflow.xml‎

Lines changed: 142 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,142 @@
1+
<mode_creation_workflow>
2+
<overview>
3+
This workflow guides you through creating a new custom mode to be used in the Roo Code Software,
4+
from initial requirements gathering to final implementation.
5+
</overview>
6+
7+
<detailed_steps>
8+
<step number="1">
9+
<title>Gather Requirements</title>
10+
<description>
11+
Understand what the user wants the mode to accomplish
12+
</description>
13+
<actions>
14+
<action>Ask about the mode's primary purpose and use cases</action>
15+
<action>Identify what types of tasks the mode should handle</action>
16+
<action>Determine what tools and file access the mode needs</action>
17+
<action>Clarify any special behaviors or restrictions</action>
18+
</actions>
19+
<example>
20+
<ask_followup_question>
21+
<question>What is the primary purpose of this new mode? What types of tasks should it handle?</question>
22+
<follow_up>
23+
<suggest>A mode for writing and maintaining documentation</suggest>
24+
<suggest>A mode for database schema design and migrations</suggest>
25+
<suggest>A mode for API endpoint development and testing</suggest>
26+
<suggest>A mode for performance optimization and profiling</suggest>
27+
</follow_up>
28+
</ask_followup_question>
29+
</example>
30+
</step>
31+
32+
<step number="2">
33+
<title>Design Mode Configuration</title>
34+
<description>
35+
Create the mode definition with all required fields
36+
</description>
37+
<required_fields>
38+
<field name="slug">
39+
<description>Unique identifier (lowercase, hyphens allowed)</description>
40+
<best_practice>Keep it short and descriptive (e.g., "api-dev", "docs-writer")</best_practice>
41+
</field>
42+
<field name="name">
43+
<description>Display name with optional emoji</description>
44+
<best_practice>Use an emoji that represents the mode's purpose</best_practice>
45+
</field>
46+
<field name="roleDefinition">
47+
<description>Detailed description of the mode's role and expertise</description>
48+
<best_practice>
49+
Start with "You are Roo Code, a [specialist type]..."
50+
List specific areas of expertise
51+
Mention key technologies or methodologies
52+
</best_practice>
53+
</field>
54+
<field name="groups">
55+
<description>Tool groups the mode can access</description>
56+
<options>
57+
<option name="read">File reading and searching tools</option>
58+
<option name="edit">File editing tools (can be restricted by regex)</option>
59+
<option name="command">Command execution tools</option>
60+
<option name="browser">Browser interaction tools</option>
61+
<option name="mcp">MCP server tools</option>
62+
</options>
63+
</field>
64+
</required_fields>
65+
<recommended_fields>
66+
<field name="whenToUse">
67+
<description>Clear description for the Orchestrator</description>
68+
<best_practice>Explain specific scenarios and task types</best_practice>
69+
</field>
70+
</recommended_fields>
71+
<important_note>
72+
Do not include customInstructions in the .roomodes configuration.
73+
All detailed instructions should be placed in XML files within
74+
the .roo/rules-[mode-slug]/ directory instead.
75+
</important_note>
76+
</step>
77+
78+
<step number="3">
79+
<title>Implement File Restrictions</title>
80+
<description>
81+
Configure appropriate file access permissions
82+
</description>
83+
<example>
84+
<comment>Restrict edit access to specific file types</comment>
85+
<code>
86+
groups:
87+
- read
88+
- - edit
89+
- fileRegex: \.(md|txt|rst)$
90+
description: Documentation files only
91+
- command
92+
</code>
93+
</example>
94+
<guidelines>
95+
<guideline>Use regex patterns to limit file editing scope</guideline>
96+
<guideline>Provide clear descriptions for restrictions</guideline>
97+
<guideline>Consider the principle of least privilege</guideline>
98+
</guidelines>
99+
</step>
100+
101+
<step number="4">
102+
<title>Create XML Instruction Files</title>
103+
<description>
104+
Design structured instruction files in .roo/rules-[mode-slug]/
105+
</description>
106+
<file_structure>
107+
<file name="1_workflow.xml">Main workflow and step-by-step processes</file>
108+
<file name="2_best_practices.xml">Guidelines and conventions</file>
109+
<file name="3_common_patterns.xml">Reusable code patterns and examples</file>
110+
<file name="4_tool_usage.xml">Specific tool usage instructions</file>
111+
<file name="5_examples.xml">Complete workflow examples</file>
112+
</file_structure>
113+
<xml_best_practices>
114+
<practice>Use semantic tag names that describe content</practice>
115+
<practice>Nest tags hierarchically for better organization</practice>
116+
<practice>Include code examples in CDATA sections when needed</practice>
117+
<practice>Add comments to explain complex sections</practice>
118+
</xml_best_practices>
119+
</step>
120+
121+
<step number="5">
122+
<title>Test and Refine</title>
123+
<description>
124+
Verify the mode works as intended
125+
</description>
126+
<checklist>
127+
<item>Mode appears in the mode list</item>
128+
<item>File restrictions work correctly</item>
129+
<item>Instructions are clear and actionable</item>
130+
<item>Mode integrates well with Orchestrator</item>
131+
<item>All examples are accurate and helpful</item>
132+
</checklist>
133+
</step>
134+
</detailed_steps>
135+
136+
<quick_reference>
137+
<command>Create mode in .roomodes for project-specific modes</command>
138+
<command>Create mode in global custom_modes.yaml for system-wide modes</command>
139+
<command>Use list_files to verify .roo folder structure</command>
140+
<command>Test file regex patterns with search_files</command>
141+
</quick_reference>
142+
</mode_creation_workflow>

‎.roo/rules-mode-writer/2_xml_structuring_best_practices.xml‎

Lines changed: 220 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,220 @@
1+
<xml_structuring_best_practices>
2+
<overview>
3+
XML tags help Claude parse prompts more accurately, leading to higher-quality outputs.
4+
This guide covers best practices for structuring mode instructions using XML.
5+
</overview>
6+
7+
<why_use_xml_tags>
8+
<benefit type="clarity">
9+
Clearly separate different parts of your instructions and ensure well-structured content
10+
</benefit>
11+
<benefit type="accuracy">
12+
Reduce errors caused by Claude misinterpreting parts of your instructions
13+
</benefit>
14+
<benefit type="flexibility">
15+
Easily find, add, remove, or modify parts of instructions without rewriting everything
16+
</benefit>
17+
<benefit type="parseability">
18+
Having Claude use XML tags in its output makes it easier to extract specific parts of responses
19+
</benefit>
20+
</why_use_xml_tags>
21+
22+
<core_principles>
23+
<principle name="consistency">
24+
<description>Use the same tag names throughout your instructions</description>
25+
<example>
26+
Always use <step> for workflow steps, not sometimes <action> or <task>
27+
</example>
28+
</principle>
29+
30+
<principle name="semantic_naming">
31+
<description>Tag names should clearly describe their content</description>
32+
<good_examples>
33+
<tag>detailed_steps</tag>
34+
<tag>error_handling</tag>
35+
<tag>validation_rules</tag>
36+
</good_examples>
37+
<bad_examples>
38+
<tag>stuff</tag>
39+
<tag>misc</tag>
40+
<tag>data1</tag>
41+
</bad_examples>
42+
</principle>
43+
44+
<principle name="hierarchical_nesting">
45+
<description>Nest tags to show relationships and structure</description>
46+
<example>
47+
<workflow>
48+
<phase name="preparation">
49+
<step>Gather requirements</step>
50+
<step>Validate inputs</step>
51+
</phase>
52+
<phase name="execution">
53+
<step>Process data</step>
54+
<step>Generate output</step>
55+
</phase>
56+
</workflow>
57+
</example>
58+
</principle>
59+
</core_principles>
60+
61+
<common_tag_patterns>
62+
<pattern name="workflow_structure">
63+
<usage>For step-by-step processes</usage>
64+
<template><![CDATA[
65+
<workflow>
66+
<overview>High-level description</overview>
67+
<prerequisites>
68+
<prerequisite>Required condition 1</prerequisite>
69+
<prerequisite>Required condition 2</prerequisite>
70+
</prerequisites>
71+
<steps>
72+
<step number="1">
73+
<title>Step Title</title>
74+
<description>What this step accomplishes</description>
75+
<actions>
76+
<action>Specific action to take</action>
77+
</actions>
78+
<validation>How to verify success</validation>
79+
</step>
80+
</steps>
81+
</workflow>
82+
]]></template>
83+
</pattern>
84+
85+
<pattern name="examples_structure">
86+
<usage>For providing code examples and demonstrations</usage>
87+
<template><![CDATA[
88+
<examples>
89+
<example name="descriptive_name">
90+
<description>What this example demonstrates</description>
91+
<context>When to use this approach</context>
92+
<code language="typescript">
93+
// Your code example here
94+
</code>
95+
<explanation>
96+
Key points about the implementation
97+
</explanation>
98+
</example>
99+
</examples>
100+
]]></template>
101+
</pattern>
102+
103+
<pattern name="guidelines_structure">
104+
<usage>For rules and best practices</usage>
105+
<template><![CDATA[
106+
<guidelines category="category_name">
107+
<guideline priority="high">
108+
<rule>The specific rule or guideline</rule>
109+
<rationale>Why this is important</rationale>
110+
<exceptions>When this doesn't apply</exceptions>
111+
</guideline>
112+
</guidelines>
113+
]]></template>
114+
</pattern>
115+
116+
<pattern name="tool_usage_structure">
117+
<usage>For documenting how to use specific tools</usage>
118+
<template><![CDATA[
119+
<tool_usage tool="tool_name">
120+
<purpose>What this tool accomplishes</purpose>
121+
<when_to_use>Specific scenarios for this tool</when_to_use>
122+
<syntax>
123+
<command>The exact command format</command>
124+
<parameters>
125+
<parameter name="param1" required="true">
126+
<description>What this parameter does</description>
127+
<type>string|number|boolean</type>
128+
<example>example_value</example>
129+
</parameter>
130+
</parameters>
131+
</syntax>
132+
<examples>
133+
<example scenario="common_use_case">
134+
<code>Actual usage example</code>
135+
<output>Expected output</output>
136+
</example>
137+
</examples>
138+
</tool_usage>
139+
]]></template>
140+
</pattern>
141+
</common_tag_patterns>
142+
143+
<formatting_guidelines>
144+
<guideline name="indentation">
145+
Use consistent indentation (2 or 4 spaces) for nested elements
146+
</guideline>
147+
<guideline name="line_breaks">
148+
Add line breaks between major sections for readability
149+
</guideline>
150+
<guideline name="comments">
151+
Use XML comments <!-- like this --> to explain complex sections
152+
</guideline>
153+
<guideline name="cdata_sections">
154+
Use CDATA for code blocks or content with special characters:
155+
<![CDATA[<code><![CDATA[your code here]]></code>]]>
156+
</guideline>
157+
<guideline name="attributes_vs_elements">
158+
Use attributes for metadata, elements for content:
159+
<example type="good">
160+
<step number="1" priority="high">
161+
<description>The actual step content</description>
162+
</step>
163+
</example>
164+
</guideline>
165+
</formatting_guidelines>
166+
167+
<anti_patterns>
168+
<anti_pattern name="flat_structure">
169+
<description>Avoid completely flat structures without hierarchy</description>
170+
<bad><![CDATA[
171+
<instructions>
172+
<item1>Do this</item1>
173+
<item2>Then this</item2>
174+
<item3>Finally this</item3>
175+
</instructions>
176+
]]></bad>
177+
<good><![CDATA[
178+
<instructions>
179+
<steps>
180+
<step order="1">Do this</step>
181+
<step order="2">Then this</step>
182+
<step order="3">Finally this</step>
183+
</steps>
184+
</instructions>
185+
]]></good>
186+
</anti_pattern>
187+
188+
<anti_pattern name="inconsistent_naming">
189+
<description>Don't mix naming conventions</description>
190+
<bad>
191+
Mixing camelCase, snake_case, and kebab-case in tag names
192+
</bad>
193+
<good>
194+
Pick one convention (preferably snake_case for XML) and stick to it
195+
</good>
196+
</anti_pattern>
197+
198+
<anti_pattern name="overly_generic_tags">
199+
<description>Avoid tags that don't convey meaning</description>
200+
<bad>data, info, stuff, thing, item</bad>
201+
<good>user_input, validation_result, error_message, configuration</good>
202+
</anti_pattern>
203+
</anti_patterns>
204+
205+
<integration_tips>
206+
<tip>
207+
Reference XML content in instructions:
208+
"Using the workflow defined in &lt;workflow&gt; tags..."
209+
</tip>
210+
<tip>
211+
Combine XML structure with other techniques like multishot prompting
212+
</tip>
213+
<tip>
214+
Use XML tags in expected outputs to make parsing easier
215+
</tip>
216+
<tip>
217+
Create reusable XML templates for common patterns
218+
</tip>
219+
</integration_tips>
220+
</xml_structuring_best_practices>

0 commit comments

Comments
 (0)