---
description: Standards for placing and organizing Cursor rule files
globs:
alwaysApply: false
---
# Cursor Rules Location and Structure
Rules for placing, organizing, and formatting Cursor rule files in the repository. Rules are automatically included in AI responses when files match the specified glob patterns.
<rule>
name: cursor_rules_location
description: Standards for placing and organizing Cursor rule files. Auto-included for all .mdc files under .cursor/rules/**.**
**globs: [".cursor/rules/**/*.mdc"]
filters:
# Match any .mdc files
- type: file_extension
pattern: "\.mdc$"
# Match files that look like Cursor rules
- type: content
pattern: "(?s)<rule>.*?</rule>"
# Match file creation events
- type: event
pattern: "file_create"
actions:
- type: suggest
message: |
- Rules should be organized into these subfolders under `.cursor/rules`:
- **global**: boilerplate-wide rules (automatically included for all files)
- **project**: project-specific rules (manually included per repository)
- **examples**: illustrative rules for specific use-cases (always manual inclusion)
- `---
description: Clear, one-line description of what the rule enforces
globs: path/to/files/*.ext, other/path/**/*
alwaysApply: boolean
---
# Rule Title
Brief description of the rule's purpose and when it's auto-included.
<rule>
name: rule_name
description: Detailed description. Include "Auto-included for..." if applicable
globs: ["pattern/to/match/**/*.{ts,tsx}"] # Inside rule tag, use array format
filters:
- type: file_extension
pattern: "pattern"
# Add other relevant filters
actions:
- type: suggest
message: |
Your rule content here
examples:
- input: |
// Bad example
// Good example
output: "Description of the example"
metadata:
priority: high
version: 1.0
</rule>
`
- Use `[filename](mdc:path/to/file)` to reference files
- Example: `[prisma.mdc](mdc:.cursor/rules/prisma.mdc)` for rule references
- Example: `[schema.prisma](mdc:prisma/schema.prisma)` for code references
- Use language-specific code blocks
- `// ✅ DO: Show good examples
const goodExample = true;
// ❌ DON'T: Show anti-patterns
const badExample = false;
`
1. **File Header (Frontmatter):**
2. `---
description: Brief description of what the rule does
globs: pattern/to/match/**/*.{ts,tsx}
alwaysApply: true/false
---
`
- The `globs` field determines when this rule is automatically included
- In the header, use plain glob patterns without quotes or arrays
3. **Rule Content Guidelines:**
- Start with high-level overview
- Include specific, actionable requirements
- Show examples of correct implementation
- Reference existing code when possible
- Keep rules DRY by referencing other rules
- Use bullet points for clarity
- Keep descriptions concise
- Include both DO and DON'T examples
- Reference actual code over theoretical examples
- Use consistent formatting across rules
4. **File Location:**
Always place rule files in one of these subdirectories under .cursor/rules:
5. `PROJECT_ROOT/
└── .cursor/
└── rules/
├── global/
│ ├── your-rule-name.mdc # Boilerplate-wide rules
├── project/
│ ├── your-project-rule-name.mdc # Project-specific rules
└── examples/
└── your-example-rule-name.mdc # Example rules for specific use-cases
`
6. **Naming Convention:**
- Use kebab-case for filenames (e.g., backend-standards.mdc)
- Always use .mdc extension
- Make names descriptive of the rule's purpose
7. **Rule Maintenance:**
- Update rules when new patterns emerge
- Add examples from actual codebase
- Remove outdated patterns
- Cross-reference related rules
8. **Never place rule files:**
- In the project root
- In subdirectories outside .cursor/rules
- In any other location
9. **UPDATE THE AVAILABLE RULES FILE:**
Whenever creating a new rule, always update the .cursor/rules/global/available-rules.mdc file:
- Add your new rule to the <available_instructions> section
- Use the format: rule-name: Brief description of what the rule does
- Keep the list alphabetically sorted
examples:
- input: |
- output: "Use plain glob patterns in the header frontmatter"
- input: |
- <rule>...</rule>
- Standards for backend functions. Auto-included for controller files.
- <rule>
name: backend_standards
description: Standards for backend functions. Auto-included for controller files.
globs: ["app/controllers/**/*.ts"]
...
</rule>
output: "Correctly structured rule file with auto-inclusion information"
- input: |
- [Create a new rule without updating available-rules.mdc]
- [Create a new rule]
[Open .cursor/rules/available-rules.mdc]
[Add the new rule to the <available_instructions> section]
- `<available_instructions>
...
my-new-rule: Description of my new rule
...
</available_instructions>
`
- output: "Always update available-rules.mdc when creating a new rule"
- input: |
- `function badExample() {
// code without clear markers
}
function goodExample() {
// no indication this is preferred
}
`
- `// ❌ DON'T: Use inconsistent naming conventions
function getData() { /* ... */ }
function fetch_user_profile() { /* ... */ }
// ✅ DO: Use consistent camelCase for functions
function getData() { /* ... */ }
function getUserProfile() { /* ... */ }
`
- output: "Use clear visual indicators (✅ DO / ❌ DON'T) to distinguish between good and bad practices"
metadata:
priority: high
version: 1.1
</rule>
