rul3s.mdc

---
description: make rules for self
globs: 
alwaysApply: true
---

# Rule Creation Framework - 

## Rule Structure
Each rule file should follow this structure:
```
---
description: Brief description of what the rule covers
globs: [optional file patterns where this rule applies]
alwaysApply: true/false (whether to apply this rule to all conversations)
---

# Rule Title

## Context (Optional)
Brief explanation of when and why this rule is useful.

## Guidelines
Specific guidelines to follow when this rule applies:

1. Guideline one
2. Guideline two
3. ...and so on
```

## Rule Categories
Consider creating rules in these categories:
- Development approaches (e.g., MVP, sustainable)
- Technical strategies (e.g., architecture patterns)
- Learning resources (e.g., documentation practices)
- Cost optimization (e.g., free alternatives)
- Specific technologies (e.g., React, Node.js best practices)
- Project management (e.g., planning, estimation)

## Rule Creation Process
1. **Identify the need**: Determine what guidance would be helpful for future projects
2. **Research best practices**: Gather information on best practices in this area
3. **Draft guidelines**: Create 8-12 specific, actionable guidelines
4. **Test the rule**: Apply the rule to a real scenario to verify its usefulness
5. **Refine and improve**: Update the rule based on experience using it

## Rule Naming Convention
- Use snake_case for filenames (e.g., `budget_dev.mdc`)
- Keep names short but descriptive, no 
- Focus on the primary purpose of the rule

## Tips for Effective Rules
- Make guidelines specific and actionable
- Focus on practical advice rather than theory
- Include examples where helpful
- Keep guidelines concise (1-2 sentences each)
- Ensure guidelines are mutually supportive
- Consider both immediate and long-term implications

## Main Workflow Template
When editing files, follow this workflow to ensure comprehensive and safe changes:

1. **Analyze Dependencies**: Before modifying a file, identify all dependencies and files that might be affected
2. **Create a Change Plan**: List all files that need modification and the specific changes required
3. **Consider Structure Impact**: Evaluate how changes might affect the overall architecture and structure
4. **Make Incremental Changes**: Implement changes one file at a time, starting with the most foundational components
5. **Test After Each Change**: Verify functionality after each file modification
6. **Update Documentation**: Ensure documentation reflects the changes made
7. **Review Dependency Chain**: Double-check that all dependent files have been updated appropriately
8. **Regression Test**: Test the entire system to ensure no unintended consequences
9. **Commit Logically**: Group related changes in meaningful commits with clear messages
10. **Create To-Do List**: If unable to complete all necessary changes, document remaining tasks clearly