A generic .cursorrules file helps. Stack-specific rules help more. Here are the rules that fix the actual problems each stack has with Cursor.
Next.js (App Router)
This project uses Next.js App Router. Do not use Pages Router patterns.
Use Server Components by default. Only add 'use client' when the component uses browser APIs, event handlers, or React hooks.
Do not use useEffect for data fetching — use async Server Components or React Query.
New routes go in app/, not pages/.
Import from next/navigation, not next/router.
Why: Cursor trained on large amounts of Pages Router code. Without these rules, it defaults to old patterns even in App Router projects.
FastAPI
All endpoints are async. Validate all request inputs with Pydantic models.
Never use bare except:. Catch specific exceptions and log with context.
Database calls go through the dependency injection pattern already in the codebase.
Do not use global state.
Why: FastAPI patterns are less uniformly established than older frameworks. Cursor guesses at patterns.
Django
Use class-based views where the codebase uses them already. Check existing views before choosing CBV vs FBV.
Migrations are generated with makemigrations, not written by hand.
Do not hardcode URLs — use reverse() or url tags.
All database queries go through the ORM. No raw SQL unless it already exists in the codebase.
Why: Django has many ways to do the same thing. Without guidance, Cursor picks arbitrarily.
Go
Errors are returned, not panicked. Check err after every function that returns one.
Package names are single lowercase words.
No global mutable state.
Context is the first parameter when functions are I/O bound.
Why: Go idioms are specific and Cursor sometimes misses them.
Generating your .cursorrules
Free tool at builtbyzac.com/tools/cursorrules-generator.html — pick your stack, get a starting .cursorrules file in 30 seconds.
Top comments (0)