Skip to content

Instantly share code, notes, and snippets.

@marcusrbrown
Last active April 30, 2025 21:11
Show Gist options
  • Select an option

  • Save marcusrbrown/16675a4df4a5af5a64fa844352bf93f6 to your computer and use it in GitHub Desktop.

Select an option

Save marcusrbrown/16675a4df4a5af5a64fa844352bf93f6 to your computer and use it in GitHub Desktop.
A Cursor rule with guidelines for rule creation, naming, and content (meta rule). Add to `.cursor/rules` in your project and tell the Agent to create rules or use the `/Generate Cursor Rules` command.
---
description: This rule is essential for maintaining consistency and quality in rule creation across the codebase. It must be followed whenever: (1) A user requests a new rule to be created, (2) An existing rule needs modification, (3) The user asks to remember certain behaviors or patterns, or (4) Future behavior changes are requested. This rule ensures proper organization, clear documentation, and effective rule application by defining standard formats, naming conventions, and content requirements. It's particularly crucial for maintaining the rule hierarchy, ensuring rules are discoverable by the AI, and preserving the effectiveness of the rule-based system. The rule system is fundamental to project consistency, code quality, and automated assistance effectiveness.
globs: .cursor/rules/*.mdc
alwaysApply: true
tags: [core, meta-rule, standard]
---
# Standard Format for Cursor Rules
## Core Structure for Rules Files
```mdc
---
description: `Comprehensive description that provides full context and clearly indicates when this rule should be applied. Include key scenarios, impacted areas, and why following this rule is important. While being thorough, remain focused and relevant. The description should be detailed enough that the agent can confidently determine whether to apply the rule in any given situation.`
globs: *.mdc {OR blank}
alwaysApply: {true or false}
tags: [tag1, tag2] {optional, categorization key words}
priority: 1-5 {optional, 1 is highest priority, 5 is lowest priority}
---
# Rule Title
## Context
- When to apply this rule
- Prerequisites or conditions
## Requirements
- Concise, bulleted list of actionable rules the agent MUST follow
- Each requirement must be testable
## Examples
<example>
Good concise example with explanation
</example>
<example type="invalid">
Invalid concise example with explanation
</example>
## Critical Points
<critical>
- ALWAYS do X
- NEVER do Y
- ENSURE Z
</critical>
```
## Naming Convention
CATEGORY-rule-name-TYPE.mdc where CATEGORY is a number range:
- 0XX: Core standards
- 1XX: Tool configs
- 2XX: Patterns and Roles
- 3XX: Testing standards
- 4XX: Documentation standards
- 8XX: Workflows
- 9XX: Templates
- 1XXX: Language rules
- 2XXX: Framework rules
- _[XXX-]rule-name.mdc: Private rules
TYPE is one of:
- auto: rule applies to all files matching the glob pattern
- agent: rule is selected by the agent based on the description
- manual: rule is manually applied
- always: rule is always applied to every chat and cmd/ctrl-k
<required>
- Use kebab-case (e.g., api-integration.mdc)
- Choose the most specific category that applies
- IMPORTANT: Always use the lowest available number in the appropriate range:
- If creating the first file in a category, use the first number (e.g., 100 for Tool Configs)
- If adding to an existing category, use the next sequential number (e.g., if 001 exists, use 002)
</required>
## Glob Pattern Examples
Common glob patterns for different rule types:
- Core standards: .cursor/rules/*.mdc
- Language rules: *.cs, *.cpp
- Testing standards: *.test.ts, *.test.js
- React components: src/components/**/*.tsx
- Documentation: docs/**/*.md, *.md
- Configuration files: *.config.js
- Build artifacts: dist/**/*
- Multiple extensions: *.js, *.ts, *.tsx
- Multiple patterns: dist/**/*.*, docs/**/*.md, *test*.*
## Formatting Guidelines
- Use Concise Markdown primarily
- XML tags limited to:
- <example>
- <danger>
- <required>
- <rules>
- <rule>
- <critical>
- Always indent content within XML or nested XML tags by 2 spaces
- Keep rules as short as possbile
- Emojis and Mermaid diagrams are allowed and encouraged if it is not redundant and better explains the rule for the AI comprehension
- Keep examples as short as possible to clearly convey the positive or negative example
## Critical Points
- Rule files will be located and named ALWAYS as: `.cursor/rules/{XXX}-rule-name-{auto|agent|manual|always}.mdc`
- Rules will NEVER be created anywhere other than .cursor/rules/**
- You will always check to see if there is an existing rule to update under .cursor/rules
- FrontMatter Rules Types:
- The front matter section must always start the file and include all 3 fields, even if the field value will be blank - the types are:
- Manual Rule: IF a Manual rule is requested - description and globs MUST be blank and alwaysApply: false and filename ends with -manual.mdc.
- Auto Rule: IF a rule is requested that should apply always to certain glob patterns (example all typescript files or all markdown files) - description must be blank, and alwaysApply: false and filename ends with -auto.mdc.
- Always Rule: Global Rule applies to every chat and cmd/ctrl-k - description and globs blank, and alwaysApply: true and filename ends with -always.mdc.
- Agent Select Rule: The rule does not need to be loaded into every chat thread, it serves a specific purpose. The description MUST provide comprehensive context about when to apply the rule, including scenarios like code changes, architecture decisions, bug fixes, or new file creation. Globs blank, and alwaysApply:false and filename ends with -agent.mdc
- For Rule Content - focus on actionable, clear directives without unnecessary explanation
- When a rule will only be used sometimes (alwaysApply: false) the description MUST provide enough context for the AI to confidently determine when to load and apply the rule
- Use Concise Markdown Tailored to Agent Context Window usage
- While there is no strict line limit, be judicious with content length as it impacts performance. Focus on essential information that helps the agent make decisions
- Always include a valid and invalid example
- NEVER use quotes around glob patterns, NEVER group glob extensions with `{}`
- If the request for a rule or a future behavior change includes context of a mistake is made, this would be great to use in the example for the rule
- CRITICAL: For Agent Select Rules, NEVER leave the description field empty. ALWAYS provide a properly formatted description using the ACTION-TRIGGER-OUTCOME format. An empty or incorrectly formatted description will prevent proper rule activation.
- ALWAYS verify that the description field has been properly updated by checking the file after creation or modification
- After rule is created or updated, Respond with the following:
- Rule {Created or Updated}: path/rule-name.mdc
- Rule Type: {Rule Type}
- Rule Description: {The exact content of the description field}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment