Day 04 Advanced Topics

Cursor Rules: Teach Cursor Your Codebase Standards

Cursor Rules let you define coding standards, style preferences, and project-specific instructions that apply to every AI interaction. Stop repeating yourself — teach Cursor once.

~1 hour Hands-on Precision AI Academy

Today’s Objective

Cursor Rules let you define coding standards, style preferences, and project-specific instructions that apply to every AI interaction. Stop repeating yourself — teach Cursor once.

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?

What to Put in .cursorrules
TEXT
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:

.cursorrules
TEXT
# 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 credentials

Rules 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:

.cursorrules (writing project)
TEXT
# 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.

80%

Supporting Resources

Go deeper with these references.

Cursor
Cursor Documentation Official Cursor IDE documentation covering features, keybindings, and configuration.
YouTube
Cursor AI Tutorials Community video tutorials demonstrating Cursor workflows in real projects.
GitHub
Awesome Cursor Rules Community-shared .cursorrules files for popular frameworks and languages.

Day 4 Checkpoint

Before moving on, make sure you can answer these without looking:

Continue To Day 5
Advanced Cursor: Workflows for Real Projects