What Are Cursor Rules?
Cursor rules are custom instructions and guidelines you can set up to standardize how the AI assistant helps with your development workflow. These rules act as persistent context that shapes every AI interaction within your project, ensuring consistent coding patterns and practices.
Think of Cursor rules as your development team's style guide and best practices documentation, but specifically tailored for AI collaboration.
Types of Cursor Rules
User Rules (Global)
Stored in Cursor's global settings, these apply across ALL projects. Use for personal coding style, preferred tools, and general practices you always follow.
Best uses for User Rules:
- Personal coding style (indentation, quotes, naming)
- Language-specific patterns you always follow
- Preferred libraries and tools across projects
- General development practices and quality standards
Project Rules (Local)
Stored in a .cursorrules file in your project root, these apply only to the current project. Use for team standards, architecture decisions, and project-specific constraints.
Best uses for Project Rules:
- Project-specific architecture and tech stack
- Team coding standards and conventions
- Business logic and domain requirements
- Project constraints and limitations
Rule Application Types
Cursor offers four application modes:
- Always Apply — Active in every AI interaction. Best for fundamental standards.
- Apply Intelligently (Recommended) — AI decides when rules are contextually relevant.
- Apply to Specific Files — Rules only activate for matching file patterns (e.g., .tsx, .test.js).
- Apply Manually — Rules only apply when explicitly mentioned with @-mentions.
Why Rules Matter
- Consistency — Without rules, each AI interaction starts fresh
- Team Alignment — Everyone gets suggestions matching codebase patterns
- Context Preservation — AI understands your project without re-explaining
- Quality Control — Prevent suggestions that violate your standards
- Efficiency — Reduce back-and-forth to get useful suggestions
User Rules Example
## Personal Coding Standards
- Always use TypeScript when possible with strict mode enabled
- Prefer single quotes for strings in JavaScript/TypeScript
- Use 2-space indentation consistently
- Maximum line length of 100 characters
- Prefer const over let, avoid var entirely
## Code Quality Practices
- Write JSDoc comments for all exported functions
- Include error handling in all async operations
- Use descriptive variable names over explanatory comments
- Prefer early returns to reduce nesting
## React Preferences
- Prefer functional components with hooks
- Use React.memo for performance optimization when needed
- Custom hooks should start with 'use' prefix
- Keep components under 100 linesProject Rules Example
# Project: TaskFlow - Team Task Management App
## Tech Stack
- React 18 with TypeScript
- Vite for build tooling
- TanStack Query for server state
- Zustand for client state
- Tailwind CSS for styling
- Supabase for backend
## Code Style
- Use functional components exclusively
- File naming: kebab-case for files, PascalCase for components
- Use absolute imports with @ alias for src directory
- Maximum line length: 100 characters
## State Management
- Use Zustand for global client state
- Use TanStack Query for all server state
- Never mix server and client state in the same store
## Things to Avoid
- Don't use useEffect for data fetching — use TanStack Query
- Don't mutate state directly
- Don't use inline styles
- Don't use index as key in dynamic listsRule Hierarchy
When both User and Project Rules exist:
- Project Rules take precedence for project-specific decisions
- User Rules fill gaps where project rules don't specify anything
- Conflicts Resolution: Project rules override conflicting user rules
- Most rules work together rather than conflict
Update your .cursorrules as your project evolves. Good rules save you from repeating the same instructions in every prompt.