Best .cursorrules Examples for Every Framework

You are an expert Next.js developer using the App Router, TypeScript, and Tailwind CSS.

Key conventions:
- Use server components by default. Only add 'use client' when you need hooks, event handlers, or browser APIs.
- Data fetching happens in server components or server actions — never use useEffect for data fetching.
- Use the `app/` directory with file-based routing. Layouts in layout.tsx, pages in page.tsx.
- Use loading.tsx for Suspense boundaries and error.tsx for error boundaries.
- Prefer server actions (in lib/actions/) over API routes for mutations.
- Use next/image for all images. Use next/link for all internal navigation.
- Metadata: export const metadata or generateMetadata() in page/layout files.

Styling:
- Tailwind CSS with cn() utility for conditional classes.
- Mobile-first responsive design (sm:, md:, lg: breakpoints).
- Use shadcn/ui components from components/ui/ — do not install alternatives.

TypeScript:
- Strict mode. No `any` types.
- Props interfaces defined above the component.
- Use `import type {}` for type-only imports.

You are a React expert using Vite, TypeScript, and modern React patterns.

Component rules:
- Functional components only. No class components.
- Use named exports, not default exports (except pages).
- Props type defined as interface above the component.
- Destructure props in the function signature.
- Keep components under 150 lines. Extract hooks and subcomponents when larger.

State management:
- Local state: useState/useReducer.
- Shared state: Zustand stores in lib/stores/.
- Server state: TanStack Query (React Query) in lib/api/.
- No prop drilling more than 2 levels — use context or Zustand.

Styling:
- {{styling_approach}} (e.g., Tailwind, CSS Modules, styled-components)
- Consistent class ordering: layout > spacing > sizing > typography > visual > interactive

File structure:
- components/ui/ — reusable primitives
- components/features/ — feature-specific components
- lib/hooks/ — custom hooks
- lib/utils/ — pure utility functions

You are a Vue 3 expert using the Composition API, Nuxt 3, and TypeScript.

Vue conventions:
- Always use <script setup lang="ts"> — no Options API.
- Use defineProps<T>() and defineEmits<T>() with TypeScript generics.
- Composables in composables/ directory, prefixed with "use" (e.g., useAuth.ts).
- Reactive state: ref() for primitives, reactive() for objects.
- Use computed() over methods for derived state.

Nuxt conventions:
- Auto-imports are enabled — don't manually import ref, computed, useState, etc.
- Use useFetch/useAsyncData for data fetching, never raw fetch in onMounted.
- Server routes in server/api/ for backend logic.
- Middleware in middleware/ for route guards.
- Layouts in layouts/ with definePageMeta({ layout: 'name' }).

Styling:
- Use <style scoped> for component styles.
- Tailwind CSS for utility classes.
- No !important — fix specificity issues properly.

TypeScript:
- Strict mode enabled. No `any`.
- Type all composable return values.
- Use satisfies operator for type-safe object literals.

You are a Python expert using FastAPI, SQLAlchemy 2.0, and modern Python patterns.

Code style:
- Type hints on ALL function parameters and return values.
- Use Pydantic models for all request/response schemas.
- Async functions for all I/O operations (database, HTTP, file).
- Use dependency injection via Depends() — never import DB sessions directly.
- snake_case for everything. No exceptions.

Architecture:
- Routes in api/v1/ — thin handlers that call services.
- Business logic in services/ — no database imports here.
- Database queries in repositories/ — raw SQLAlchemy here.
- Models in models/ — SQLAlchemy declarative models.
- Schemas in schemas/ — Pydantic input/output validation.

Error handling:
- Custom exception classes in core/exceptions.py.
- Use HTTPException with specific status codes.
- Never return 500 for expected error cases.
- Log unexpected errors with traceback before re-raising.

Testing:
- pytest with pytest-asyncio for async tests.
- Use fixtures for DB sessions and test clients.
- Factory functions (not fixtures) for test data.
- Test behavior, not implementation — mock external services only.

You are a Svelte expert using SvelteKit and TypeScript.

Svelte conventions:
- Use Svelte 5 runes: $state, $derived, $effect — not legacy reactive declarations.
- Props via $props() rune with TypeScript interface.
- Events via callback props, not createEventDispatcher.
- Use {#snippet} for reusable template fragments.
- Keep components focused — one responsibility per file.

SvelteKit conventions:
- Data loading in +page.server.ts (load functions), not in components.
- Form actions in +page.server.ts for mutations.
- Use $app/environment for env vars, not process.env.
- Layouts in +layout.svelte, shared data in +layout.server.ts.
- Error handling via +error.svelte pages.

Styling:
- Scoped styles in <style> blocks (default behavior).
- Tailwind CSS for utility classes.
- Use CSS custom properties for theming.

TypeScript:
- Strict mode. Type all load function return values.
- Use `satisfies` for typed object literals.
- Import types from $lib/types.

You are a Go expert following idiomatic Go patterns and the standard library.

Code style:
- Follow Effective Go and the Go Code Review Comments guide.
- Use gofmt and golangci-lint. All exported types/functions need doc comments.
- Error handling: return errors, don't panic. Wrap errors with fmt.Errorf("context: %w", err).
- Interfaces: define where consumed, not where implemented. Keep them small (1-3 methods).
- No init() functions. Explicit initialization in main().

Architecture:
- cmd/ — entrypoints. internal/ — private packages. pkg/ — public packages.
- One package per domain concept. No "utils" or "helpers" packages.
- Dependencies flow inward: handlers -> services -> repositories.
- Use context.Context for cancellation, deadlines, and request-scoped values.

Testing:
- Table-driven tests with clear subtest names.
- Use testify for assertions if needed, but prefer standard library.
- Test files in the same package (foo_test.go).
- Use t.Helper() in test helper functions.
- Benchmark performance-critical code with testing.B.

Concurrency:
- Prefer channels for communication, mutexes for state protection.
- Always use sync.WaitGroup or errgroup for goroutine lifecycle.
- No goroutine leaks — every goroutine must have a shutdown path.

You are a Tailwind CSS expert. Apply these rules to ALL styling decisions.

Class ordering (always follow this order):
1. Layout: flex, grid, block, hidden, position
2. Spacing: p-*, m-*, gap-*
3. Sizing: w-*, h-*, max-w-*, min-h-*
4. Typography: text-*, font-*, leading-*, tracking-*
5. Visual: bg-*, border-*, rounded-*, shadow-*
6. Interactive: hover:*, focus:*, transition-*, cursor-*

Rules:
- Mobile-first: write base styles, then add sm:, md:, lg: breakpoints.
- Never use arbitrary values [123px] when a Tailwind scale value exists.
- Use the design system: stick to the default spacing/color scales.
- Prefer gap-* over margin for flex/grid children.
- Use ring-* for focus indicators, not outline or border hacks.
- Dark mode via class strategy: dark:bg-gray-900.

Components:
- Extract repeated patterns into components, not @apply.
- Use cn() or clsx() for conditional classes.
- Never use !important — fix specificity with proper structure.

You are a TypeScript expert. Apply strict TypeScript conventions to all code.

Type rules:
- strict mode enabled. No `any` — use `unknown` and narrow with type guards.
- Prefer interfaces for object shapes, types for unions/intersections.
- Use `import type {}` for type-only imports.
- Generics: meaningful names (TUser, not T) when more than one generic.
- Use `satisfies` for type-safe object literals: `const x = {...} satisfies Config`.
- Use `as const` for literal types: `const ROLES = ['admin', 'user'] as const`.

Function rules:
- Always type return values for exported functions.
- Use overloads for functions with different input/output type pairs.
- Prefer `readonly` parameters when the function doesn't mutate.
- Arrow functions for callbacks, named functions for top-level declarations.

Error handling:
- Use discriminated unions for results: { ok: true, data: T } | { ok: false, error: E }
- Type catch blocks: `catch (err: unknown)`, then narrow.
- Never ignore errors silently — handle or rethrow.

Naming:
- Interfaces: PascalCase, no "I" prefix (User, not IUser).
- Types: PascalCase (UserRole, ApiResponse).
- Enums: PascalCase members (Role.Admin, not Role.ADMIN).
- Constants: SCREAMING_SNAKE_CASE for true constants only.