├── .cursor
├── .DS_Store
└── rules
│ ├── .DS_Store
│ ├── 000-xml-cursor-rules.mdc
│ └── 301-typescript-test-location.mdc
└── README.md
/.cursor/.DS_Store:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/bmadcode/cursor-xml-rules-trial/f046d3d91b0d898f83347a715b120578c8feb671/.cursor/.DS_Store
--------------------------------------------------------------------------------
/.cursor/rules/.DS_Store:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/bmadcode/cursor-xml-rules-trial/f046d3d91b0d898f83347a715b120578c8feb671/.cursor/rules/.DS_Store
--------------------------------------------------------------------------------
/.cursor/rules/000-xml-cursor-rules.mdc:
--------------------------------------------------------------------------------
1 | ---
2 | description: Use ALWAYS when asked to CREATE A RULE or UPDATE A RULE or taught a lesson from the user that should be retained as a new rule for Cursor
3 | globs: *.mdc
4 | ---
5 |
6 |
7 |
8 | Cursor Rules Format
9 |
10 |
11 | .cursor/rules/
12 | .mdc
13 |
14 |
15 |
16 | PREFIX-name.mdc
17 |
18 | Core standards
19 | Tool configs
20 | Testing standards
21 | Documentation standards
22 | Language rules
23 | Framework rules
24 | Workflows
25 | Templates
26 | Private rules
27 |
28 |
29 |
30 |
31 | .cursor/rules/*.mdc
32 | src/**/*.{js,ts}
33 | **/*.test.{js,ts}
34 | src/components/**/*.tsx
35 | docs/**/*.md
36 | *.config.{js,json}
37 | dist/**/*
38 | src/**/*.{js,jsx,ts,tsx}
39 | dist/**/*, docs/**/*.md
40 |
41 |
42 |
43 |
44 |
45 | ACTION TRIGGER OUTCOME format
46 | glob pattern for files and folders
47 |
48 |
49 |
50 | version tag in format X.Y.Z
51 | context: Usage conditions
52 | requirements: Actionable items
53 | examples: Both valid and invalid
54 |
55 |
56 |
57 |
58 | Always indent content within XML or nested XML tags by 2 spaces
59 | Keep rules as short as possible
60 | Use Mermaid syntax if it will be shorter or clearer than describing a complex rule
61 | Use Emojis where appropriate to convey meaning that will improve rule understanding by the AI Agent
62 | Keep examples as short as possible to clearly convey the positive or negative example
63 |
64 |
65 |
66 |
67 | Use precise, deterministic ACTION TRIGGER OUTCOME format in description
68 | Provide concise positive and negative example of rule application in practice
69 | Optimize for AI context window efficiency
70 | Remove any non-essential or redundant information
71 | Use standard glob patterns without quotes (e.g., *.js, src/**/*.ts)
72 |
73 |
74 |
75 | Keep frontmatter description under 120 characters while maintaining clear intent
76 | Limit examples to essential patterns only
77 | Use hierarchical structure for quick parsing
78 | Remove redundant information across sections
79 | Maintain high information density with minimal tokens
80 | Focus on machine-actionable instructions over human explanations
81 |
82 |
83 |
84 |
85 | The front matter can ONLY have the fields description and globs
86 | The file MUST start with the this exactly:
87 | ---
88 | description: front matter description
89 | globs: front matter glob pattern or no value
90 | ---
91 |
92 | All contents after the frontmatter will be styled as XML
93 | NEVER include verbose explanations or redundant context that increases AI token overhead
94 | Keep file as short and to the point as possible BUT NEVER at the expense of sacrificing rule impact and usefulness for the AI Agent
95 |
96 |
97 |
--------------------------------------------------------------------------------
/.cursor/rules/301-typescript-test-location.mdc:
--------------------------------------------------------------------------------
1 | ---
2 | description: WHEN creating typescript test files PLACE them adjacent to the file being tested
3 | globs: **/*.{ts,tsx}
4 | ---
5 |
6 |
7 |
8 | 1.0.0
9 |
10 |
11 | When creating unit tests for TypeScript files
12 |
13 |
14 |
15 | Create test files in the same directory as the source file
16 | Name test files with the pattern: {sourceFileName}.test.{ts,tsx}
17 | DO NOT create tests in a separate test directory
18 |
19 |
20 |
21 |
22 |
23 | src/
24 | components/
25 | Button.tsx
26 | Button.test.tsx
27 | utils/
28 | format.ts
29 | format.test.ts
30 |
31 |
32 |
33 |
34 |
35 | src/
36 | components/
37 | Button.tsx
38 | utils/
39 | format.ts
40 | tests/
41 | components/
42 | Button.test.tsx
43 | utils/
44 | format.test.ts
45 |
46 |
47 |
48 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # Old XML Approach for older version of Cursor 0.3x - DO NOT USE - Full XL rule creation is UNNECESSARY, as found through extensive testing.
2 |
3 | ## Deprecated - use [This Repo](https://github.com/bmadcode/cursor-auto-rules-agile-workflow) instead.
4 |
5 | This repository contains a base rule that will follow the cursor rules system and formatting with proper front matter, while the body using maximum XML. While this is not the most readable or easy to maintain format manually, the AI can easile add and modify rule in this format. There are some theories that the more structured XML works better in some situations, but in practice I have not found a dignificant enough difference to suggest using this, and instead would point you to what I current recommend - the [Better Updated Rule Template](https://github.com/bmadcode/cursor-auto-rules-agile-workflow) - this repo also has an extensive readme, and has recently been updated to ensure proper formatting of rules so that they do not have conflicts or disapear on generation (by specifying the proper frontmatter with no extra fields always existing).
6 |
7 | ## Getting Started
8 |
9 | The easiest and recommended way to create new rules is to ask the AI to generate them. The AI understands the required structure and will automatically format the rule correctly, including all necessary sections and proper XML formatting.
10 |
11 | ### Example Prompts
12 |
13 | Here are some examples of prompts that could generate rules similar to those in this repository:
14 |
15 | 1. "Create a rule that enforces TypeScript type safety standards. It should ensure proper type definitions, prevent any usage, and maintain strict type checking across the codebase."
16 |
17 | - This could generate something like our `1000-ts-type-safety.mdc` rule
18 |
19 | 2. "Create a rule for Test-Driven Development workflow that guides developers through the red-green-refactor cycle. It should enforce writing tests first, then implementation."
20 |
21 | - This could generate something like our `900-tdd-workflow.mdc` rule
22 |
23 | 3. "Create a rule for documentation standards that follows Google's Technical Writing Style Guide. It should enforce clear, consistent documentation in JSDoc comments and markdown files."
24 | - This could generate something like our `400-documentation-standards.mdc` rule
25 |
26 | ### Why XML?
27 |
28 | The rules use XML format for several key reasons:
29 |
30 | 1. **Structured Validation**: XML provides strict schema validation, ensuring rules maintain consistent structure
31 | 2. **Clear Hierarchy**: XML's nested structure clearly represents relationships between rule components
32 | 3. **Machine Readability**: XML is easily parsed and processed by both AI and traditional tools
33 | 4. **Metadata Support**: XML naturally supports rich metadata and attributes
34 | 5. **Standard Processing**: Extensive tooling exists for XML validation and transformation
35 |
36 | ## Overview
37 |
38 | The Cursor Rules System is a powerful framework that allows you to define, manage, and enforce coding standards, documentation requirements, and development workflows through AI-assisted rules. Each rule is defined in a `.mdc` file format that combines frontmatter configuration with XML-based rule definitions.
39 |
40 | ## Rule File Structure
41 |
42 | ### Location
43 |
44 | All rule files must be placed in the `.cursor/rules/` directory with a `.mdc` extension:
45 |
46 | ```
47 | .cursor/
48 | └── rules/
49 | ├── your-rule-name.mdc
50 | └── another-rule.mdc
51 | ```
52 |
53 | ### File Format
54 |
55 | Each rule file consists of two main sections:
56 |
57 | 1. **Frontmatter Configuration**
58 |
59 | ```yaml
60 | ---
61 | description: ALWAYS use when [TRIGGER_SCENARIO] to ensure [OUTCOME]. [BRIEF_EXPLANATION]
62 | globs: "**/*.{extension}"
63 | ---
64 | ```
65 |
66 | 2. **XML Rule Definition**
67 |
68 | ```xml
69 |
70 |
71 | ...
72 | ...
73 | ...
74 | ...
75 |
76 | ```
77 |
78 | ## Key Requirements
79 |
80 | ### Description Format
81 |
82 | - Must start with action words (e.g., "ALWAYS", "NEVER", "USE")
83 | - Clearly specify trigger scenarios
84 | - Be concise but complete (1-2 sentences)
85 | - Include relevant trigger keywords
86 | - Match exactly between frontmatter and metadata
87 |
88 | ### File Naming
89 |
90 | - Use kebab-case format
91 | - Must be descriptive of the rule's purpose
92 | - Must have `.mdc` extension
93 |
94 | ### XML Structure
95 |
96 | - Proper formatting with consistent indentation
97 | - Required sections: metadata, filters, actions, examples
98 | - CDATA tags for special characters when necessary
99 | - Example section showing correct and incorrect usage
100 |
101 | ## Creating New Rules
102 |
103 | When creating a new rule:
104 |
105 | 1. Place the file in `.cursor/rules/` directory
106 | 2. Use the proper naming convention: `your-rule-name.mdc`
107 | 3. Include required frontmatter fields
108 | 4. Structure the XML content with all required sections
109 | 5. Provide clear examples of correct and incorrect usage
110 |
111 | ## Best Practices
112 |
113 | 1. **Optimization for AI**
114 |
115 | - Use clear, actionable descriptions
116 | - Include relevant trigger keywords
117 | - Specify precise file patterns in globs
118 |
119 | 2. **Clarity and Maintainability**
120 |
121 | - Keep descriptions concise but complete
122 | - Use consistent formatting
123 | - Document examples thoroughly
124 |
125 | 3. **Rule Enforcement**
126 | - Define clear trigger scenarios
127 | - Specify precise file patterns
128 | - Include comprehensive validation rules
129 |
130 | ## Example Rule Template
131 |
132 | ```yaml
133 | ---
134 | description: ALWAYS use when writing new components to ensure consistent styling. This rule enforces design standards and best practices.
135 | globs: "**/*.{tsx,jsx}"
136 | ---
137 |
138 |
139 |
140 | ALWAYS use when writing new components to ensure consistent styling. This rule enforces design standards and best practices.
141 | high
142 | 1.0
143 |
144 |
145 |
146 | ```
147 |
148 | ## Common Mistakes to Avoid
149 |
150 | 1. Placing rule files outside `.cursor/rules/` directory
151 | 2. Missing or mismatched descriptions between frontmatter and metadata
152 | 3. Vague or non-actionable descriptions
153 | 4. Incomplete XML sections
154 | 5. Missing examples of correct/incorrect usage
155 |
156 | ## Leveraging Rules
157 |
158 | Rules can be used to:
159 |
160 | - Enforce coding standards
161 | - Maintain documentation quality
162 | - Ensure consistent workflows
163 | - Automate development processes
164 | - Guide AI-assisted development
165 |
166 | Each rule should be designed to be both human-readable and optimized for AI interpretation, enabling seamless integration with development workflows while maintaining clear standards for the development team.
167 |
--------------------------------------------------------------------------------