Cursor rule

1---
2description: Guidelines for creating and maintaining Cursor rules to ensure consistency and effectiveness.
3globs: .cursor/rules/*.mdc
4alwaysApply: true
5---
6 
7<rule_structure_requirements>
8 
9- **Required Rule Structure:**
10 
11```markdown
12  ---
13  description: Clear, one-line description of what the rule enforces
14  globs: path/to/files/*.ext, other/path/**/*
15  alwaysApply: boolean
16  ---
17 
18  - **Main Points in Bold**
19    - Sub-points with details
20    - Examples and explanations
21```
22 
23  </rule_structure_requirements>
24 
25<file_reference_guidelines>
26 
27- **File References:**
28  - Use `[filename](mdc:path/to/file)` ([filename](mdc:filename)) to reference files
29  - Example: [prisma.mdc](mdc:.cursor/rules/prisma.mdc) for rule references
30  - Example: [schema.prisma](mdc:prisma/schema.prisma) for code references
31    </file_reference_guidelines>
32 
33<code_example_guidelines>
34 
35- **Code Examples:**
36 
37  - Use language-specific code blocks
38 
39```typescript
40  // ✅ DO: Show good examples
41  const goodExample = true;
42 
43  // ❌ DON'T: Show anti-patterns
44  const badExample = false;
45```
46 
47  </code_example_guidelines>
48 
49<content_guidelines>
50 
51- **Rule Content Guidelines:**
52  - Start with high-level overview
53  - Include specific, actionable requirements
54  - Show examples of correct implementation
55  - Reference existing code when possible
56  - Keep rules DRY by referencing other rules
57    </content_guidelines>
58 
59<rule_update_criteria>
60 
61- **Rule Updates:**
62 
63  - **Add New Rules When:**
64 
65    - A new technology/pattern is used in 3+ files
66    - Common bugs could be prevented by a rule
67    - Code reviews repeatedly mention the same feedback
68    - New security or performance patterns emerge
69 
70  - **Modify Existing Rules When:**
71 
72    - Better examples exist in the codebase
73    - Additional edge cases are discovered
74    - Related rules have been updated
75    - Implementation details have changed
76 
77  - **Rule Deprecation:**
78    - Mark outdated patterns as deprecated
79    - Remove rules that no longer apply
80    - Update references to deprecated rules
81    - Document migration paths for old patterns
82</rule_update_criteria>
83 
84<quality_checks>
85 
86- **Rule Quality Checks:**
87  - Rules should be actionable and specific
88  - Examples should come from actual code
89  - References should be up to date
90  - Patterns should be consistently enforced
91  - Use bullet points for clarity
92  - Keep descriptions concise
93  - Include both DO and DON'T examples
94  - Reference actual code over theoretical examples
95  - Use consistent formatting across rules
96    </quality_checks>
97 
98<continuous_improvement>
99 
100- **Continuous Improvement:**
101 
102  - **Improvement Triggers:**
103 
104    - New code patterns not covered by existing rules
105    - Repeated similar implementations across files
106    - Common error patterns that could be prevented
107    - New libraries or tools being used consistently
108    - Emerging best practices in the codebase
109 
110  - **Analysis Process:**
111 
112    - Compare new code with existing rules
113    - Identify patterns that should be standardized
114    - Look for references to external documentation
115    - Check for consistent error handling patterns
116    - Monitor test patterns and coverage
117 
118  - **Documentation Updates:**
119    - Keep examples synchronized with code
120    - Update references to external docs
121    - Maintain links between related rules
122    - Document breaking changes
123    - Monitor code review comments
124    - Track common development questions
125    - Update rules after major refactors
126    - Add links to relevant documentation
127    - Cross-reference related rules
128</continuous_improvement>
129