Cursor Rules allow you to provide system-level guidance to the AI Agent and Cmd-K. Think of them as a persistent way to encode context, preferences, or workflows for your projects or for yourself. This helps the AI understand your coding standards, preferred libraries, project-specific terminology, and overall goals, leading to more relevant and higher-quality suggestions. Effectively using rules is key to maximizing Cursor's potential.
Large language models do not retain memory between completions. Rules solve this by providing persistent, reusable context at the prompt level. When a rule is applied, its contents are included at the start of the model context. This gives the AI consistent guidance whether it is generating code, interpreting edits, or helping with a workflow.
Cursor supports three types of rules:
Project rules live in the .cursor/rules directory within your project. Each rule is a separate file written in MDC (.mdc), a lightweight format supporting metadata and content.
Rule Structure (MDC File):
---
description: Brief explanation of what the rule does. Essential for 'Agent Requested' rules.
globs: ["**/frontend/**/*.tsx", "**/components/*.js"] # Optional: for 'Auto Attached' rules
alwaysApply: false # Optional: true for 'Always' rules, false otherwise
---
# Rule Content Section
- Your detailed instructions go here.
- Use markdown for clarity.
- You can reference other files like @path/to/template.ts to include their content.
Project Rule Types:
Rule Type | Description |
---|---|
Always | Always included in the model context. Set alwaysApply: true in the MDC metadata. |
Auto Attached | Included when files matching a globs pattern are referenced in your prompt or context. |
Agent Requested | The rule is available to the AI, which decides whether to include it based on its description. Ensure your description is clear and informative. |
Manual | Only included when explicitly mentioned in your prompt using @ruleName (where ruleName is the filename of the rule without the .mdc extension). |
Creating Project Rules:
Defining Instructions:
User Rules:
Please reply in a concise style. Avoid unnecessary repetition or filler language.
Legacy .cursorrules file:
If you have an existing .cursorrules file in your project root, Cursor will still use it. However, for new projects or when organizing existing ones, it's better to migrate these to the .cursor/rules directory structure. The content of a .cursorrules file is typically plain Markdown.
Example based on this course's .cursorrules:
This learning path project itself uses a .cursorrules file to guide the AI assistant (like me!). Here's a snippet of how it might look, defining personality and coding principles:
# Project Overview
This is a course aimed at teaching people how to use Cursor AI assistant. The audience is technical people who may not be familiar with AI tools.
# Personality
You are an expert in writing and teaching and knowledgeable about Cursor AI assistant. You have vast experience in writing rich frontend applications and designing easy-to-maintain apps.
# Fundamental Principles
- Write clean, simple, readable code
- Implement features in the simplest possible way
- Keep files small and focused (<200 lines)
- ALWAYS write simple, clean and modular code.
# Comments
- ALWAYS try to add more helpful and explanatory comments into our code
- Include LOTS of explanatory comments in your code. ALWAYS write well-documented code.
If this were a Project Rule in .cursor/rules/course_guidelines.mdc, it might look like this:
---
description: Guidelines for the AI assistant working on the NSTECH Learning Path AI course, covering personality, coding principles, and commenting style.
alwaysApply: true
---
# Project Overview
This is a course aimed at teaching people how to use Cursor AI assistant. The audience is technical people who may not be familiar with AI tools.
# Personality
You are an expert in writing and teaching and knowledgeable about Cursor AI assistant. You have vast experience in writing rich frontend applications and designing easy-to-maintain apps.
# Fundamental Principles
- Write clean, simple, readable code
- Implement features in the simplest possible way
- Keep files small and focused (<200 lines)
- ALWAYS write simple, clean and modular code.
# Comments
- ALWAYS try to add more helpful and explanatory comments into our code
- Include LOTS of explanatory comments in your code. ALWAYS write well-documented code.
Examples of Good Rules:
For Frontend Development (e.g., .cursor/rules/frontend-standards.mdc):
---
description: Standards for frontend components and API validation in our React/Tailwind project.
globs: ["**/src/components/**/*.tsx", "**/src/pages/api/**/*.ts"]
alwaysApply: false
---
# Frontend Development Standards
## Component Design
- Always use Tailwind CSS for styling.
- Use Framer Motion for animations.
- Follow our component naming conventions (PascalCase for components, camelCase for props).
- Reference: @../../assets/css/styles.css
## API Validation (Next.js API Routes)
- Use Zod for all request and response validation.
- Define return types with Zod schemas.
- Export types generated from Zod schemas.
For Boilerplate/Templates (e.g., .cursor/rules/express-service-template.mdc):
---
description: Template for creating new Express.js services.
alwaysApply: false
# This rule would typically be manually invoked: @express-service-template
---
# Express Service Template
Use this template when creating a new Express service:
- Follow RESTful principles.
- Include error handling middleware.
- Set up proper logging using our standard logger.
- See @path/to/your/express-service-template.ts for the base structure.
The exact features, file names, and syntax for custom instructions can vary and evolve. Always refer to the official Cursor documentation for the most up-to-date information. You can find it here: Cursor Rules Documentation.
For a wide variety of community-contributed examples and inspiration, check out the awesome-cursorrules repository on GitHub.