---
description: This rule enforces Next.js App Router best practices in the 'app' directory.
globs: app/**/*.*
---
- Use server components by default
- Implement client components only when necessary
- Utilize the new file-based routing system
- Use layout.js for shared layouts
- Implement loading.js for loading states
- Use error.js for error handling
- Utilize route handlers for API routes
The Cursor team guidance on this would be appreciated.
sharing in this topic @bmadcodetopic on creating rules - I’m going to check it out this weekend. After watching his video it appears he’s solved issue #2 that I noted above around properly saving files via the agent which is really exciting.
He’s also extended the filenaming structure that’s become popular and his rules are utilize a 3rd different structure for rule structure/format:
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
globs: .cursor/rules/*.mdc
Cursor Rules Format
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
author: BMad
date: 2025-02-17
status: approved
version: 3.1.0
Core Structure
---
description: ACTION when TRIGGER to OUTCOME
globs: *.mdc
tags: [tag1, tag2] # New: For improved AI categorization
priority: 1-5 # New: For conflict resolution
version: Major.Minor.Patch
---
# Rule Title
## Context
- When to apply this rule
- Prerequisites or conditions
## Requirements
- Concise, actionable items
- Each requirement must be testable
## Examples
<example>
Good concise example with explanation
</example>
<example type="invalid">
Invalid concise example with explanation
</example>
File Organization
Location
Path: .cursor/rules/
Extension: .mdc
Naming Convention
PREFIX-name.mdc where PREFIX is:
0■■: Core standards
1■■: Tool configs
3■■: Testing standards
1■■■: Language rules
2■■■: Framework rules
8■■: Workflows
9■■: Templates
_name.mdc: Private rules
Glob Pattern Examples
Common glob patterns for different rule types:
Core standards: .cursor/rules/*.mdc
Language rules: src/**/*.{js,ts}
Testing standards: **/*.test.{js,ts}
React components: src/components/**/*.tsx
Documentation: docs/**/*.md
Configuration files: *.config.{js,json}
Build artifacts: dist/**/*
Multiple extensions: src/**/*.{js,jsx,ts,tsx}
Multiple files: dist//*, docs//*.md
Required Fields
Frontmatter
description: ACTION TRIGGER OUTCOME format
globs: glob pattern for files and folders
tags: Categorization keywords
priority: 1 (highest) to 5 (lowest)
version: Semantic versioning
Body
context: Usage conditions
requirements: Actionable items
examples: Both valid and invalid
Formatting Guidelines
Use Concise Markdown primarily
XML tags limited to:
Always indent content within XML or nested XML tags by 2 spaces
Keep rules as short as possbile
Use Mermaid syntax if it will be shorter or clearer than describing a complex rule
Use Emojis where appropriate to convey meaning that will improve rule understanding by the AI Agent
Keep examples as short as possible to clearly convey the positive or negative example
Version Control when Updating an Existing Rule
Follow semantic versioning (MAJOR.MINOR.PATCH)
Document changes in commit messages
Start at version 1.0.0 for new rule
Always update the version if modifying an existing rule - use your judgement of the impact of the change to the rule to determin if its a major minor or patch increment.
AI Optimization Tips
Use precise, deterministic ACTION TRIGGER OUTCOME format in descriptions
Include only essential tags that directly impact rule application
Set clear priority levels to resolve conflicts efficiently
Provide concise positive and negative example of rule application in practice
Optimize for AI context window efficiency
Remove any non-essential or redundant information
Use standard glob patterns without quotes (e.g., .js, src/**/.ts)
AI Context Efficiency
Keep frontmatter description under 120 characters (or less) while maintaining clear intent for rule selection by AI AGent
Limit examples to essential patterns only
Use hierarchical structure for quick parsing
Remove redundant information across sections
Maintain high information density with minimal tokens
Focus on machine-actionable instructions over human explanations
- NEVER include verbose explanations or redundant context that increases AI token overhead
- 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.
Thanks Doug - one thing to point out - getting rid of the extra fields in the front matter is needed to solve most isues ppl run into with conflicts on auto rule generation - have updated the repo and suggestion to only have description and globs in the front matter. yaml fields
Posting here for rule hackers: Agent does not see subdirectories of .cursor/rules.
You can ask Agent to verify: ‘what are your available rules? Do not execute code base search.’
This also confused me very much! I ended up embracing the simpler format of markdown file with globs: frontmatter and wrote a little prompt to generate them for my project using Cursor’s codebase search & understanding
Prompt to draft Cursor project rules
Your goal is to support the user creating a Project Rules file for the Cursor IDE.
Using rules in Cursor you can control the behavior of the underlying model.
You can think of it as instructions and/or a system prompt for LLMs.
Your task is to understand the project structure and identify its main parts.
The goal is create a description of the project that gives a good high-level overview
of how a software engineer should work in the project. It should be concise focus on whats important.
Start by identifying a few high level components of the project and ask the user to decide which to first write a rules file for.
<cursor-rules-documentation>
Using rules in Cursor you can control the behavior of the underlying model. You can think of it as instructions and/or a system prompt for LLMs.
## Project Rules (recommended)
Project rules offer a powerful and flexible system with path specific configurations. Project rules are stored in the `.cursor/rules` directory and provide granular control over AI behavior in different parts of your project.
Here’s how they work
- **Semantic Descriptions**: Each rule can include a description of when it should be applied
- **File Pattern Matching**: Use glob patterns to specify which files/folders the rule applies to
- **Automatic Attachment**: Rules can be automatically included when matching files are referenced
- **Reference files**: Use @file in your project rules to include them as context when the rule is applied.
You can create a new rule using the command palette with `Cmd + Shift + P` > `New Cursor Rule`. By using project rules you also get the benefit of version control since it’s just a file
Example use cases:
- Framework-specific rules for certain file types (e.g., SolidJS preferences for `.tsx` files)
- Special handling for auto-generated files (e.g., `.proto` files)
- Custom UI development patterns
- Code style and architecture preferences for specific folders
</cursor-rules-documentation>
<examples>
<example>
Below is an example for a rules file for a project that uses Tailwind CSS.
<file path=".cursor/rules/tailwind.mdc">
---
description: Styling via Tailwind CSS
globs: **/global.css, **/tailwind.config.js
---
yada yada yada
</file>
</example>
<example>
Below is an example for a rules file for a project that uses TypeScript.
<file path=".cursor/rules/typescript.mdc">
---
description: TypeScript rules
globs: **/*.ts, **/*.tsx
---
</file>
</example>
</examples>
Note that this is not intended to teach cursor about rules files, if I want to edit them I usually just tag them as regular files in the chat input or do the edits manually.