Cursor Rules Files: Examples for Next.js, Python and SQL Repos

Rules work best when each one names a behavior a reviewer could check in a pull request. Put these in:

• Your stack and versions, so the assistant doesn't suggest a deprecated API or the wrong framework style.
• Naming, file layout and where new code goes.
• Commands: how to run tests, the linter and the type checker.
• Hard prohibitions, such as never editing generated files or committing secrets.
• Patterns you want repeated, with a pointer to a real example file in the repo.

Leave out general advice like "write clean code" and "follow best practices". The model already tries to, and the sentence gives it nothing to act on. Also leave out anything long. Every rule competes for attention with your actual prompt, so a rules file of a few dozen lines usually beats one of several hundred.

Adapt these to your repo. Each line is a rule you can check:

• Use the App Router. New pages go in `app/`, and shared components in `components/`. Don't create files under `pages/`.
• Components are server components by default. Add `"use client"` only when a component needs state, effects or browser APIs.
• Use TypeScript strict mode and never use `any`. If a type is unknown, use `unknown` and narrow it.
• Validate all request bodies with a schema before using them. Reuse the schemas in `lib/schemas/`.
• Fetch data in server components or route handlers, never with a client-side call to an internal API for data the page could load itself.
• Read configuration through `lib/env.ts`, never directly from `process.env` in components.
• Run the type check and the test suite before finishing a task, and report the result.

Notice the pointers to real paths. A rule that names `lib/schemas/` gives the assistant something to open and copy from.

For a small API service, rules often cover typing, error handling and testing:

• Target the Python version pinned in the project file. Use type hints on all function signatures.
• Keep request and response models in `schemas/` and business logic in `services/`. Route handlers stay thin.
• Raise domain exceptions from services and translate them to HTTP errors in one place.
• Never build SQL by string concatenation. Use parameterized queries or the existing data access layer.
• Every new endpoint needs a test in `tests/` covering one success case and one validation failure.
• Don't add a new dependency without saying why, and prefer what's already in the lockfile.

The last rule matters more than it looks. Assistants readily add packages, and each one is a supply chain decision. The review checklist for AI-written code covers how to verify them.

Database code is where a wrong suggestion is most expensive, so rules here should be strict:

• Every schema change is a new migration file. Never edit an applied migration.
• Every new table enables row-level security in the same migration and ships with at least one policy.
• Policies check the authenticated user or tenant, never `true`.
• Additive changes first: add a column as nullable, backfill, then add the constraint in a later migration.
• Never drop a column or table in the same release that stops using it.

Pair these with a look at real policy patterns in the row-level security examples, and keep a policy test in your suite so a missing policy fails the build rather than a review.

Test rules the way you'd test code. Pick a rule, ask the assistant for a small task that would normally break it, and see what happens with the rule on and off. If behavior doesn't change, the rule is too vague, too long or in the wrong scope, and you should rewrite it more concretely or move it closer to the files it governs.

Review the file every couple of months. Delete rules for problems the model no longer has, and add a rule whenever the same review comment appears three times. Keep the file in version control so changes get reviewed, and tie it to your team's assistant policy, since rules can encode part of it, such as which directories are off limits.

Rules are guidance, not enforcement. Anything that must never happen, such as committing a secret, still needs a check in CI.