Cursor Rules & .cursorrules Templates

A good .cursorrules file pays for itself within a day: instead of re-explaining "use Tailwind, not CSS files; typed props; no default exports" in every chat, Cursor applies your conventions to every edit. Copy a template below into the repo root (or .cursor/rules/ for per-project setup), then adjust the stack line to match your project.

# Project Rules

- Stack: React 18 + TypeScript + Tailwind CSS + Vite
- All components are function components with explicit prop types; no default exports for components
- Tailwind first: no inline style attributes, no CSS files unless animating
- Co-locate tests as Component.test.tsx using Vitest + Testing Library
- Naming: PascalCase components, camelCase hooks (use* prefix), files match their export
- Prefer composition over prop-drilling; context only for truly global state
- Every user-facing string that will be translated goes through the t() helper
- Accessibility: interactive elements need visible focus states and aria-labels when icon-only
- Do not add new dependencies without stating what they replace

# Project Rules

- Python 3.12, FastAPI, SQLAlchemy 2.0 async, Postgres
- Type hints everywhere; mypy strict must pass
- Endpoints: thin routers -> service layer -> repositories; no business logic in routers
- Pydantic v2 models for all request/response shapes; never return ORM objects directly
- Migrations via Alembic only; never issue raw DDL
- Every DB write happens inside a transaction the service layer owns
- Tests: pytest with async fixtures; a bug fix is not done until it has a failing-first test
- Docstrings only on public service functions, Google style, under 5 lines

# Review Rules

When I ask for a review, check in this order and stop at the first category with findings:
1. Correctness: does it do what the surrounding code expects? Any edge case that errors silently?
2. Security: injection, auth bypass, secrets in code or logs, missing tenant isolation
3. Failure behavior: what happens when the network/db/dependency is down?
4. Readability: names that lie, dead code, magic numbers
5. Only then style, and only if it contradicts project conventions

Report format per finding: file:line, severity (blocker/should-fix/nit), one-sentence problem, one-sentence suggested fix. No praise, no summary of what the code does.

# Workflow Rules

- Work in steps small enough that each step compiles and passes tests
- Before editing more than 3 files for one task, present the plan as a file list and wait
- After every logical unit, show me the diff summary and run the test suite
- Commit messages: imperative mood, under 72 chars, body explains WHY not WHAT
- Never mix refactoring and feature changes in the same commit
- If a change breaks a test, fixing the test is part of the change, not a follow-up