A .cursorrules file for your project that encodes your coding standards, tech stack details, and style preferences — so every AI suggestion follows your rules automatically.
What Are Cursor Rules?
Cursor Rules are a plain text file (.cursorrules) at the root of your project. Everything in this file is included as system context in every AI interaction — every Tab completion, every Chat message, every Composer request.
Think of it as the onboarding document you'd give a new developer. What stack are you using? What patterns should they follow? What should they never do?
Tech stack specifics:
Python 3.12, FastAPI, SQLAlchemy, PostgreSQL
Code style:
Use type hints always. No raw SQL (use ORM).
Async by default for route handlers.
Architecture patterns:
Separate routes/ models/ services/ — no business logic in routes
What to avoid:
Never use eval(). No print() statements (use logging).
Testing:
pytest with fixtures in conftest.py. Test all error cases.Writing an Effective .cursorrules File
Here's a template for a Python/FastAPI project. Adapt it to your stack:
# Project: My AI API
# Stack: Python 3.12, FastAPI, SQLAlchemy, PostgreSQL
Code Style:
- Use type hints on all function signatures
- Use Pydantic BaseModel for all request/response bodies
- Route handlers are always async
- Use f-strings, not .format()
Architecture:
- routes/ for HTTP handlers (no business logic)
- services/ for business logic
- models/ for database models
- schemas/ for Pydantic models
Error Handling:
- Always use HTTPException with specific status codes
- Log errors with logger.error(), not print()
- Never expose stack traces in API responses
Testing:
- pytest with TestClient
- Each endpoint needs: success case, 400 case, auth failure case
- Use factory_boy for test data
Never:
- No raw SQL queries (use SQLAlchemy ORM)
- No synchronous I/O in async functions
- No hardcoded credentialsRules for Non-Code Projects
Cursor Rules work for any type of project, not just code. If you're using Cursor to write documentation, blog posts, or analysis:
# Writing Project Rules
Voice: Direct and conversational. No jargon.
Sentence length: Vary between short (5 words) and medium (20 words).
Never use: "leverage", "utilize", "synergize", "game-changing"
Headers: Sentence case (not Title Case)
Code examples: Always include, always runnable
Tone: Teach don't preach. Assume smart reader, not expert.With rules like this in place, every AI suggestion in Cursor follows your defined standards without you having to re-state them in every prompt.
What You Learned Today
- What Cursor Rules are and how they work: project-level system context for all AI interactions
- What to put in .cursorrules: stack, style, architecture, error handling, testing standards
- How to structure rules for code projects vs. writing projects
- Why writing rules once is more efficient than repeating instructions in every prompt
Go Further on Your Own
- Write a .cursorrules file for your primary project. After 3 days of using it, review: what did it get right? What needed adjustment?
- Compare AI output quality with and without .cursorrules: generate the same function twice (once before, once after adding rules) and compare.
- Write rules specifically for Cursor's Composer mode: what files should it always be aware of? What patterns must it follow for new features?
Nice work. Keep going.
Day 5 is ready when you are.
Continue to Day 5Want live instruction and hands-on projects? Join the AI bootcamp — 3 days, 5 cities.