|
| 1 | +# Custom Rules |
| 2 | + |
| 3 | +Custom rules allow you to define specific guidelines and behaviors for Roo Code to follow when working with your projects. These rules help ensure consistent code quality, adherence to project standards, and tailored assistance for your specific needs. |
| 4 | + |
| 5 | +## What Are Custom Rules? |
| 6 | + |
| 7 | +Custom rules are guidelines stored in special files in your project's root directory. They tell Roo how to approach various aspects of your codebase, such as: |
| 8 | + |
| 9 | +- Coding style and formatting preferences |
| 10 | +- Documentation requirements |
| 11 | +- Testing practices |
| 12 | +- Error handling approaches |
| 13 | +- Project-specific conventions |
| 14 | + |
| 15 | +Unlike general custom instructions, rules are typically more structured and focused on specific technical requirements. |
| 16 | + |
| 17 | +## Rule File Types |
| 18 | + |
| 19 | +Roo Code supports several rule file formats: |
| 20 | + |
| 21 | +| File Name | Purpose | |
| 22 | +|-----------|---------| |
| 23 | +| `.clinerules` | Primary rule file for all modes | |
| 24 | +| `.clinerules-code` | Rules specific to Code mode | |
| 25 | +| `.clinerules-architect` | Rules specific to Architect mode | |
| 26 | +| `.clinerules-[mode]` | Rules for any custom mode | |
| 27 | +| `.cursorrules` | Alternative format (compatible with Cursor AI) | |
| 28 | +| `.windsurfrules` | Alternative format (compatible with Windsurf) | |
| 29 | + |
| 30 | +All rule files should be placed in your project's root directory. |
| 31 | + |
| 32 | +## Rule File Format |
| 33 | + |
| 34 | +Rule files use a simple, markdown-based format that's easy to read and write: |
| 35 | + |
| 36 | +```markdown |
| 37 | +# Category Title |
| 38 | + |
| 39 | +1. Rule Group Title: |
| 40 | + - Specific guideline |
| 41 | + - Another guideline |
| 42 | + - Technical requirement |
| 43 | + |
| 44 | +2. Another Rule Group: |
| 45 | + - Guideline one |
| 46 | + - Guideline two |
| 47 | +``` |
| 48 | + |
| 49 | +This format makes rules easy to read for both humans and AI. |
| 50 | + |
| 51 | +## Global vs. Mode-Specific Rules |
| 52 | + |
| 53 | +Roo Code allows you to create both global rules and mode-specific rules: |
| 54 | + |
| 55 | +- **Global Rules** (`.clinerules`) apply to all modes |
| 56 | +- **Mode-Specific Rules** (`.clinerules-[mode]`) only apply when using that specific mode |
| 57 | + |
| 58 | +When both exist, mode-specific rules take priority, but global rules still apply if they don't conflict. |
| 59 | + |
| 60 | +## Example Rule Categories |
| 61 | + |
| 62 | +### Code Style Rules |
| 63 | + |
| 64 | +```markdown |
| 65 | +# Code Style |
| 66 | + |
| 67 | +1. Formatting: |
| 68 | + - Use 2-space indentation for all files |
| 69 | + - Keep line length under 100 characters |
| 70 | + - Place opening braces on the same line |
| 71 | + - Use trailing commas in multi-line arrays and objects |
| 72 | + |
| 73 | +2. Naming Conventions: |
| 74 | + - Use camelCase for variables and functions |
| 75 | + - Use PascalCase for classes and components |
| 76 | + - Use UPPER_SNAKE_CASE for constants |
| 77 | + - Prefix private methods with underscore |
| 78 | +``` |
| 79 | + |
| 80 | +### Testing Rules |
| 81 | + |
| 82 | +```markdown |
| 83 | +# Testing Requirements |
| 84 | + |
| 85 | +1. Test Coverage: |
| 86 | + - Write tests for all new functions |
| 87 | + - Maintain at least 80% code coverage |
| 88 | + - Test both success and error paths |
| 89 | + - Use descriptive test names |
| 90 | + |
| 91 | +2. Test Structure: |
| 92 | + - Organize tests by feature or component |
| 93 | + - Use setup and teardown for common operations |
| 94 | + - Mock external dependencies |
| 95 | + - Test edge cases explicitly |
| 96 | +``` |
| 97 | + |
| 98 | +### Documentation Rules |
| 99 | + |
| 100 | +```markdown |
| 101 | +# Documentation Standards |
| 102 | + |
| 103 | +1. Code Documentation: |
| 104 | + - Document all public functions with JSDoc |
| 105 | + - Explain complex algorithms with comments |
| 106 | + - Include examples for APIs |
| 107 | + - Document parameters and return values |
| 108 | + |
| 109 | +2. Project Documentation: |
| 110 | + - Keep README up-to-date |
| 111 | + - Document setup steps |
| 112 | + - Include troubleshooting guidance |
| 113 | + - Add comments for non-obvious code |
| 114 | +``` |
| 115 | + |
| 116 | +## Best Practices for Writing Effective Rules |
| 117 | + |
| 118 | +### 1. Be Specific and Clear |
| 119 | + |
| 120 | +Write clear, actionable guidelines rather than vague principles: |
| 121 | + |
| 122 | +**Good:** |
| 123 | +```markdown |
| 124 | +- Validate all user inputs before processing |
| 125 | +- Log errors with stack traces and context |
| 126 | +- Use parameterized queries for database operations |
| 127 | +``` |
| 128 | + |
| 129 | +**Not as helpful:** |
| 130 | +```markdown |
| 131 | +- Make sure code is secure |
| 132 | +- Handle errors properly |
| 133 | +- Be careful with databases |
| 134 | +``` |
| 135 | + |
| 136 | +### 2. Organize Logically |
| 137 | + |
| 138 | +Group related rules together under clear categories: |
| 139 | + |
| 140 | +```markdown |
| 141 | +# Security |
| 142 | + |
| 143 | +1. Input Validation: |
| 144 | + - Validate all user inputs |
| 145 | + - Sanitize data before use |
| 146 | + - Reject unexpected values |
| 147 | + |
| 148 | +2. Authentication: |
| 149 | + - Require strong passwords |
| 150 | + - Implement account lockouts |
| 151 | + - Log authentication attempts |
| 152 | +``` |
| 153 | + |
| 154 | +### 3. Prioritize Important Rules |
| 155 | + |
| 156 | +Put the most important rules first: |
| 157 | + |
| 158 | +```markdown |
| 159 | +# Performance |
| 160 | + |
| 161 | +1. Critical Paths: |
| 162 | + - Optimize database queries |
| 163 | + - Cache frequently accessed data |
| 164 | + - Minimize network requests |
| 165 | + |
| 166 | +2. General Optimizations: |
| 167 | + - Use efficient algorithms |
| 168 | + - Minimize DOM manipulations |
| 169 | + - Implement lazy loading |
| 170 | +``` |
| 171 | + |
| 172 | +### 4. Keep Rules Updated |
| 173 | + |
| 174 | +Review and update your rules as your project evolves: |
| 175 | + |
| 176 | +- Remove outdated guidelines |
| 177 | +- Add rules for new technologies |
| 178 | +- Refine based on project learnings |
| 179 | + |
| 180 | +## Practical Rule Examples by Project Type |
| 181 | + |
| 182 | +### Web Development Project |
| 183 | + |
| 184 | +```markdown |
| 185 | +# Web Project Rules |
| 186 | + |
| 187 | +1. Accessibility: |
| 188 | + - Use semantic HTML elements |
| 189 | + - Include alt text for images |
| 190 | + - Ensure keyboard navigation works |
| 191 | + - Maintain WCAG AA compliance |
| 192 | + |
| 193 | +2. Performance: |
| 194 | + - Keep bundle size under 500KB |
| 195 | + - Optimize images before adding |
| 196 | + - Implement code splitting |
| 197 | + - Lazy load non-critical resources |
| 198 | +``` |
| 199 | + |
| 200 | +### Data Science Project |
| 201 | + |
| 202 | +```markdown |
| 203 | +# Data Science Rules |
| 204 | + |
| 205 | +1. Data Management: |
| 206 | + - Document data sources |
| 207 | + - Version control datasets |
| 208 | + - Include data cleaning steps |
| 209 | + - Note missing value handling |
| 210 | + |
| 211 | +2. Models: |
| 212 | + - Document training parameters |
| 213 | + - Include accuracy metrics |
| 214 | + - Validate against test data |
| 215 | + - Explain feature importance |
| 216 | +``` |
| 217 | + |
| 218 | +### Mobile App Project |
| 219 | + |
| 220 | +```markdown |
| 221 | +# Mobile App Rules |
| 222 | + |
| 223 | +1. UI/UX: |
| 224 | + - Support both light and dark themes |
| 225 | + - Implement responsive layouts |
| 226 | + - Follow platform design guidelines |
| 227 | + - Test on multiple device sizes |
| 228 | + |
| 229 | +2. Performance: |
| 230 | + - Minimize app size |
| 231 | + - Optimize battery usage |
| 232 | + - Cache network responses |
| 233 | + - Use efficient list rendering |
| 234 | +``` |
| 235 | + |
| 236 | +## Combining Rules with Custom Modes |
| 237 | + |
| 238 | +For an even more tailored experience, you can: |
| 239 | + |
| 240 | +1. Create a custom mode with specific capabilities |
| 241 | +2. Create matching `.clinerules-[mode]` file |
| 242 | +3. Get specialized assistance that follows your guidelines |
| 243 | + |
| 244 | +For example, you might create a "security-auditor" mode with a `.clinerules-security-auditor` file containing security-focused rules. |
| 245 | + |
| 246 | +## How to Test Your Rules |
| 247 | + |
| 248 | +To verify your rules are working: |
| 249 | + |
| 250 | +1. Create your rule file in the project root |
| 251 | +2. Switch to the appropriate mode if using mode-specific rules |
| 252 | +3. Ask Roo to perform a task related to your rules |
| 253 | +4. Check if the response follows your guidelines |
| 254 | + |
| 255 | +For example, after adding code style rules, ask Roo to write a new function and see if it follows your specified style. |
| 256 | + |
| 257 | +By using custom rules effectively, you can transform Roo into a team member who understands and follows your project's unique needs and standards. |
0 commit comments