Best Cursor Rules: Awesome .cursorrules Collection (2026)

Best Cursor Rules: Awesome .cursorrules Collection (2026)

Cursor's .cursorrules file is one of the most underused features in AI-assisted development. By placing a .cursorrules file in the root of your project, you give Cursor's AI a persistent set of instructions that shape how it generates code. The right rules can dramatically improve code quality, enforce team conventions, and reduce back-and-forth corrections.

This guide is a curated collection of the best .cursorrules configurations for popular frameworks, languages, and project types. Each set of rules has been refined through community contributions and real-world usage.

How .cursorrules Works

When you create a .cursorrules file in your project root, Cursor automatically includes its contents as part of the system context for every AI interaction in that project. This means:

• Tab completions follow your conventions
• Chat responses use your preferred patterns
• Code generation matches your stack and style
• Refactoring suggestions align with your architecture

File Location

your-project/
  .cursorrules    <-- Place it here
  src/
  package.json
  ...

As of 2026, Cursor also supports the newer .cursor/rules directory format for more granular rule management, but the root .cursorrules file is still widely used and fully supported.

General Best Practices for Writing Rules

Before diving into specific templates, here are principles that make rules more effective:

Principle	Example
Be specific about the tech stack	"Use Next.js 15 App Router, not Pages Router"
Define naming conventions	"Use camelCase for variables, PascalCase for components"
Specify file structure	"Place API routes in app/api/, components in components/"
Set error handling patterns	"Always use try/catch with typed errors"
Include negative instructions	"Never use any type in TypeScript"
Keep it under 2000 tokens	Long rules dilute important instructions

Next.js / React (TypeScript)

This is one of the most popular rule sets. It covers the Next.js App Router with TypeScript, Tailwind CSS, and modern React patterns.

You are an expert in TypeScript, React, Next.js App Router, and Tailwind CSS.

Key Principles:
- Write concise, type-safe TypeScript code with accurate examples.
- Use functional and declarative programming patterns. Avoid classes.
- Prefer iteration and modularization over code duplication.
- Use descriptive variable names with auxiliary verbs (isLoading, hasError).
- Use lowercase with dashes for directories (e.g., components/auth-wizard).
- Favor named exports over default exports.

Next.js Conventions:
- Use the App Router with server components by default.
- Place page-specific components in the same directory as the page.
- Use route groups (parentheses) for layout organization.
- Implement loading.tsx and error.tsx for each route segment.
- Use server actions for form submissions and mutations.
- Prefer Next.js Image component over img tags.
- Use next/font for font loading.

TypeScript:
- Use interface over type for object shapes.
- Avoid enums. Use const objects with as const.
- Use strict mode. Never use any or @ts-ignore.
- Define return types for all functions.
- Use Zod for runtime validation.

Styling:
- Use Tailwind CSS exclusively. No inline styles or CSS modules.
- Use the cn() utility (clsx + tailwind-merge) for conditional classes.
- Follow mobile-first responsive design.
- Use CSS variables for theme colors defined in globals.css.

Components:
- Use shadcn/ui as the component library.
- Create small, focused components (under 50 lines).
- Put shared components in components/ directory.
- Put page-specific components next to their page.

Data Fetching:
- Fetch data in server components where possible.
- Use React Server Components for data-heavy pages.
- Implement proper error boundaries and loading states.
- Use SWR or TanStack Query for client-side data fetching.

Python (FastAPI)

Rules optimized for building APIs with FastAPI:

You are an expert in Python, FastAPI, and scalable API development.

Key Principles:
- Write concise, technical Python code with accurate type hints.
- Use functional programming where appropriate. Avoid unnecessary classes.
- Prefer iteration and modularization over duplication.
- Use descriptive variable names (is_active, has_permission).
- Follow PEP 8 style guidelines.

FastAPI Conventions:
- Use Pydantic v2 models for all request and response schemas.
- Implement dependency injection using Depends().
- Use async def for all route handlers.
- Organize routes in separate router files using APIRouter.
- Use HTTPException for error responses with proper status codes.
- Implement proper request validation with Pydantic.
- Use lifespan context manager for startup/shutdown events.

Project Structure:
- app/main.py - FastAPI app initialization
- app/routers/ - Route handlers grouped by domain
- app/models/ - SQLAlchemy or Pydantic models
- app/schemas/ - Request/response Pydantic schemas
- app/services/ - Business logic
- app/dependencies/ - Shared dependencies
- app/core/ - Config, security, database setup

Error Handling:
- Create custom exception classes for domain errors.
- Use middleware for global error handling.
- Always return consistent error response schemas.
- Log errors with structlog or loguru.

Database:
- Use SQLAlchemy 2.0 with async sessions.
- Use Alembic for database migrations.
- Never write raw SQL in route handlers.
- Use repository pattern for data access.

Testing:
- Write tests with pytest and pytest-asyncio.
- Use httpx.AsyncClient for API testing.
- Mock external services in tests.
- Aim for 80%+ code coverage.

Go (Backend Services)

Rules for Go backend services:

You are an expert in Go, microservices architecture, and backend development.

Key Principles:
- Write idiomatic Go code following Effective Go guidelines.
- Prefer simplicity and readability over cleverness.
- Handle all errors explicitly. Never use _ to discard errors.
- Use meaningful variable names. Short names only for limited scopes.
- Keep functions small and focused on a single responsibility.

Conventions:
- Use the standard library whenever possible before reaching for third-party packages.
- Use context.Context as the first parameter for functions that do I/O.
- Define interfaces where they are used, not where they are implemented.
- Use table-driven tests.
- Return errors, do not panic.
- Use struct embedding for composition.

Project Structure:
- cmd/ - Application entry points
- internal/ - Private application code
- pkg/ - Public library code (if applicable)
- api/ - API definitions (OpenAPI, protobuf)
- migrations/ - Database migration files

Error Handling:
- Wrap errors with fmt.Errorf("context: %w", err).
- Define sentinel errors for expected error conditions.
- Use errors.Is() and errors.As() for error checking.
- Never log and return an error. Do one or the other.

Concurrency:
- Use goroutines with proper synchronization.
- Always use contexts for cancellation.
- Use channels for communication, mutexes for state.
- Avoid goroutine leaks - ensure every goroutine has a way to exit.

Rust

Rules for Rust projects:

You are an expert in Rust, systems programming, and safe concurrent code.

Key Principles:
- Write idiomatic Rust code that leverages the type system and ownership model.
- Prefer compile-time guarantees over runtime checks.
- Use descriptive names. Avoid abbreviations except for well-known ones (ctx, tx, rx).
- Keep functions under 40 lines. Extract helpers for complex logic.
- Write documentation comments for all public items.

Conventions:
- Use Result<T, E> for all fallible operations. Never use unwrap() in production code.
- Prefer &str over String for function parameters.
- Use thiserror for library error types, anyhow for application error types.
- Derive common traits: Debug, Clone, PartialEq where appropriate.
- Use clippy with pedantic lints enabled.
- Format all code with rustfmt.

Project Structure:
- src/lib.rs - Library root
- src/main.rs - Binary entry point
- src/models/ - Data structures
- src/handlers/ - Request handlers
- src/services/ - Business logic
- tests/ - Integration tests

Error Handling:
- Define custom error types for each module.
- Use the ? operator for error propagation.
- Provide context when converting errors.
- Map external errors to domain-specific errors at module boundaries.

Async:
- Use tokio as the async runtime.
- Prefer async functions over manual Future implementations.
- Use tokio::select! for concurrent operations.
- Always use timeouts for network operations.

Swift (iOS)

Rules for iOS development with SwiftUI:

You are an expert in Swift, SwiftUI, and iOS app development.

Key Principles:
- Write clean, idiomatic Swift code following Apple's API Design Guidelines.
- Use value types (structs, enums) over reference types (classes) by default.
- Prefer composition over inheritance.
- Use meaningful names. Avoid abbreviations.
- Keep views small and focused.

SwiftUI Conventions:
- Use @State for view-local state, @Binding for child views.
- Use @Observable (Observation framework) instead of ObservableObject for iOS 17+.
- Extract reusable views into separate files.
- Use ViewModifiers for shared styling.
- Prefer LazyVStack/LazyHStack for long lists.
- Use .task {} for async work in views.

Architecture:
- Follow MVVM pattern with SwiftUI.
- Place business logic in ViewModels, not Views.
- Use Swift Concurrency (async/await) for all asynchronous operations.
- Use protocols to define dependencies for testability.
- Use dependency injection through the Environment.

Data:
- Use SwiftData for local persistence (iOS 17+).
- Define models as @Model classes with proper relationships.
- Use ModelContainer configuration for migrations.

Error Handling:
- Use typed throws where possible (Swift 6+).
- Present errors to users with localized descriptions.
- Use Result type for operations that can fail.

Tailwind CSS / UI Design

Rules specifically for frontend styling:

You are an expert in responsive UI design with Tailwind CSS.

Key Principles:
- Use Tailwind CSS utility classes exclusively. No custom CSS unless absolutely necessary.
- Follow mobile-first responsive design (sm:, md:, lg:, xl:).
- Ensure WCAG 2.1 AA accessibility compliance.
- Use semantic HTML elements (nav, main, section, article).
- Maintain consistent spacing using Tailwind's spacing scale.

Styling Patterns:
- Use the cn() helper (clsx + tailwind-merge) for conditional classes.
- Group related utilities: layout, spacing, typography, colors, effects.
- Use @apply sparingly and only in component-level stylesheets.
- Prefer gap over margin for flex/grid layouts.
- Use container mx-auto for max-width content.

Responsive Design:
- Design mobile layout first, then add breakpoint modifiers.
- Use grid for page layouts, flex for component layouts.
- Test at 320px, 768px, 1024px, and 1440px breakpoints.
- Use clamp() for fluid typography when needed.

Dark Mode:
- Support dark mode using the dark: variant.
- Use CSS variables for colors that change between themes.
- Test both themes for contrast ratios.

Accessibility:
- Include alt text on all images.
- Use proper heading hierarchy (h1 through h6).
- Ensure focus indicators are visible.
- Use aria attributes where semantic HTML is insufficient.
- Maintain 4.5:1 contrast ratio for normal text.

Creating Your Own Rules

Here is a template to build your own .cursorrules:

You are an expert in [TECHNOLOGIES].

Key Principles:
- [CODING_STYLE_PREFERENCE]
- [NAMING_CONVENTIONS]
- [ERROR_HANDLING_APPROACH]

Project Structure:
- [DIRECTORY_LAYOUT]

Conventions:
- [FRAMEWORK_SPECIFIC_RULES]
- [TESTING_APPROACH]
- [STATE_MANAGEMENT]

Do NOT:
- [ANTI_PATTERNS_TO_AVOID]
- [DEPRECATED_APPROACHES]

Tips for Effective Rules

Do	Do Not
Be specific about versions	Say "use modern practices"
Give concrete examples	Write vague guidelines
Include negative constraints	Only write positive rules
Update rules as the project evolves	Set and forget
Keep under 2000 tokens	Write an entire style guide
Focus on what the AI gets wrong	Repeat what the AI already does well

Wrapping Up

A well-crafted .cursorrules file transforms Cursor from a generic AI assistant into a context-aware coding partner that understands your team's conventions. Start with one of the templates above, customize it for your project, and iterate as you discover what the AI needs guidance on.

If you are building AI-powered applications and need reliable APIs for image generation, video creation, or other media tasks, check out Hypereal AI. Hypereal provides developer-friendly APIs that work seamlessly with the modern tech stacks covered in this guide.