How to Set Up Memory Rules in Cursor IDE
How Cursor Handles Rules and Context
Cursor reads project context from multiple sources. The .cursorrules file in your project root is the primary mechanism, loaded automatically into every conversation in that workspace. Project-level rules configured through Cursor's settings provide additional context. Global rules in your Cursor preferences apply across all projects. These sources are concatenated into the system prompt, giving the AI a layered understanding of your environment.
The .cursorrules file is a plain text file, not Markdown or JSON. Write it in natural language with clear sections. Cursor's AI reads the entire file at the start of each conversation, so everything in the file is available as context. The practical size limit is similar to other context files: 1,000 to 3,000 words provides substantial context without crowding out space for code and conversation.
Step-by-Step Setup
Focus on the conventions, constraints, and patterns that are specific to your project and that Cursor cannot infer from the code alone. Structure the file with clear section headers so the AI can navigate it quickly.
# Project Rules
## Tech Stack
- Frontend: React 18 with TypeScript, Vite for bundling
- Backend: FastAPI with Python 3.12, SQLAlchemy ORM
- Database: PostgreSQL 16 with Alembic migrations
- Testing: pytest for backend, Vitest for frontend
## Code Conventions
- Python: use snake_case for everything, type hints on all function
signatures, no bare except clauses
- TypeScript: use strict mode, prefer const over let, no any types
except in test mocks
- All API endpoints return {"data": ...} on success and
{"error": {"code": ..., "message": ...}} on failure
- Frontend state management uses Zustand, not Redux or Context
## Architecture Rules
- Backend follows hexagonal architecture: domain models have no
framework dependencies, repositories abstract database access,
services contain business logic
- All database queries go through SQLAlchemy repositories, never
raw SQL in service layer
- Frontend components in /components are reusable, components in
/pages are route-specific and can contain business logic
## Constraints
- The third-party geocoding API allows 2500 requests per day.
All geocoding must go through the GeoCache service which caches
results in Redis.
- User uploads are stored in S3 with presigned URLs. Never serve
files through the application server.
- The legacy_users table uses a different ID format (UUID v1) than
new tables (UUID v4). Always check which table you are querying.Open Cursor Settings (Cmd/Ctrl + Shift + J) and navigate to the Rules section. Project rules configured here supplement the .cursorrules file. Use project rules for context that changes more frequently or that you do not want to commit to version control, like current sprint priorities or temporary constraints.
Project rules are stored in Cursor's local settings rather than in a file in your repository. This makes them useful for personal context that other team members do not need to see, or for temporary rules that apply during a specific phase of development.
In Cursor Settings, add global rules that apply to all your projects. These capture your personal coding style, explanation preferences, and interaction patterns. Global rules have lower priority than project rules, so project-specific conventions override your personal preferences when they conflict.
# Global Rules (in Cursor Settings)
When suggesting code changes:
- Show the complete modified function, not just the changed lines
- Include import statements if new dependencies are needed
- Run the relevant test file after making changes
When explaining code:
- Start with what the code does at a high level before details
- Use concrete examples rather than abstract descriptions
- If asked about a bug, suggest the most likely cause first
Code style preferences:
- Prefer early returns over nested if/else chains
- Use descriptive variable names over comments
- Keep functions under 30 lines when possibleCursor supports MCP servers that extend the AI's capabilities with external tools. Adding a memory server gives Cursor the ability to store observations from your sessions and retrieve relevant memories in future sessions, going beyond what static rules files can capture.
Configure the MCP server in Cursor's settings under the MCP section. The memory server provides tools that the AI can call to store and recall information. Unlike the .cursorrules file, which is static and manual, the memory server's knowledge base grows automatically as you work with the assistant.
Layer your rules from general to specific: global rules contain your personal preferences, .cursorrules contains project-specific conventions, and the MCP memory server stores the growing body of learned knowledge. When there is a conflict, project rules should take precedence over global rules, and explicit rules should take precedence over remembered observations.
Review your rules quarterly. Conventions evolve, libraries get replaced, and constraints change. An outdated .cursorrules file is worse than no file at all because it actively misleads the assistant. Keep the file accurate, and delete rules that no longer apply rather than commenting them out.
What to Include vs What to Omit
Include conventions that differ from the framework's defaults, because the AI already knows the defaults. Include constraints that are not visible in the code, like rate limits, API quirks, and business rules. Include architecture decisions with their reasoning, because the reasoning helps the AI make consistent decisions in new situations. Include common mistakes and anti-patterns specific to your codebase.
Omit things the AI can determine from the code. Do not document which files exist, what packages are installed, or which language versions you use unless the version matters for specific syntax or API choices. Omit long code examples that would be better demonstrated by referencing an actual file in the codebase. Omit temporary information like current tickets or sprint goals unless you plan to update the file regularly.
Team Workflow with .cursorrules
Commit the .cursorrules file to version control. It serves the same purpose as .editorconfig or .prettierrc: establishing shared conventions that every team member's environment respects. When the team agrees on a new convention, add it to .cursorrules in a pull request so the change is reviewed and documented like any other codebase change.
For teams where some developers use Cursor and others use Claude Code, maintain both .cursorrules and CLAUDE.md with similar content. The formats differ slightly (Cursor reads plain text, Claude Code reads Markdown), but the content categories are the same. Some teams maintain a single source of truth in one file and copy relevant sections to the other, keeping both files synchronized through a simple build step or pre-commit hook.
Extend Cursor's memory beyond static rules. Adaptive Recall's MCP server stores and retrieves project knowledge automatically, so Cursor learns from every session.
Try It Free