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
→