How to Write Cursor Rules in 2026
The .cursor/rules format changed. Here is the complete guide to writing .mdc rule files that Cursor actually follows.
The .cursor/rules format (current)
Cursor moved from a single .cursorrules file to a .cursor/rules/ directory of .mdc files. Each .mdc file is Markdown with YAML frontmatter. The frontmatter controls when the rule is applied: always (loaded every request), auto-attached (loaded when matching files are open), agent-requested (Cursor decides when it's relevant), or manual (only when you reference it).
YAML frontmatter options
The three frontmatter fields: description (required -tells Cursor what the rule covers, also used for agent-requested mode), globs (optional array of file patterns for auto-attachment), alwaysApply (boolean -whether to load regardless of context). Use alwaysApply: true sparingly -only for project-wide conventions. Scope everything else with globs.
Step-by-step: create your first rule file
Here is a minimal but complete example of a well-structured .mdc rule file.
---
description: React component and naming conventions for this project
globs: ["**/*.tsx", "src/components/**", "src/hooks/**"]
alwaysApply: false
---
# React Conventions
## Components
- Named exports only. No default exports.
- One component per file.
- Props typed with interfaces above the component.
## Hooks
- Custom hooks in src/hooks/ with use prefix.
- Always include dependency array in useEffect.
## Naming
- Files: kebab-case (user-card.tsx)
- Components: PascalCase (UserCard)
- Booleans: is/has/can prefix (isLoading, hasError)
## What NOT to Do
- Never use default exports for components.
- Never use useEffect to fetch data.
- Never inline anonymous functions as event handler props.Rule scoping strategy
Create separate .mdc files per concern rather than one giant file: react.mdc, typescript.mdc, testing.mdc, structure.mdc. Use globs to auto-attach the right rules to the right file types. This keeps context tight -your testing rules don't load when you're editing a UI component.
Testing your rules
After adding a rule file, test it immediately: open Cursor, open a file that matches your globs, and ask Cursor to create something that would normally violate your rules. Check if the output follows the rule. If not, the rule is too vague -add a concrete "do this, not that" example. Concrete examples beat prose descriptions every time.