Best Cursor Rules Starter Templates 2026

A .cursorrules file is 50-200 lines of plain text. It costs nothing. It takes 10 minutes to set up. And it is the single highest-leverage thing you can do to improve AI-generated code quality in your project.

In benchmarks from cursor.directory contributors, projects with framework-specific rules see 40-60% fewer "hallucinated" imports and wrong API usage compared to projects with no rules file. The reason is simple: without rules, Cursor and Claude Code guess your project conventions. With rules, they follow them.

The ecosystem of pre-built rules templates has matured significantly in 2026. You no longer need to write every rule from scratch. Community collections, GitHub repos, and commercial boilerplates ship ready-to-use rules for every major framework. This guide covers where to find them, which ones are worth using, and how to customize them for your stack.

TL;DR

cursor.directory is the best starting point for framework-specific .cursorrules — 200+ community-contributed templates covering every major framework. awesome-cursorrules on GitHub is the best curated list with categorized links. Commercial boilerplates like Supastarter, MakerKit, and ShipFast ship their own rules pre-configured. For Claude Code, the equivalent is CLAUDE.md in the project root. Start with a community template, then customize it with your project's specific conventions, file structure, and forbidden patterns.

---

Feature Matrix

Source	Framework Coverage	Maintained	Free	Format
cursor.directory	200+ frameworks	✅ Active community	✅	.cursorrules
awesome-cursorrules	80+ curated links	✅ Monthly updates	✅	.cursorrules
Supastarter	Next.js + Nuxt	✅ Author-maintained	❌ ($149+)	.cursorrules + .windsurfrules
MakerKit	Next.js + RR7	✅ Author-maintained	❌ ($299+)	.cursorrules + CLAUDE.md
ShipFast	Next.js	✅ Author-maintained	❌ ($199)	.cursorrules
Framework rule packs	Per-framework	Varies	✅	.cursorrules / CLAUDE.md
Custom (DIY)	Any	You maintain	✅	Any format

---

cursor.directory — The Community Standard

cursor.directory is the largest collection of .cursorrules files in 2026, with over 200 community-contributed templates. It functions like a package registry for AI coding rules: search by framework, preview the rules, and copy them into your project.

The collection covers every major ecosystem:

• Next.js App Router — Server components vs. client components, use server directives, routing conventions, metadata API patterns
• React + TypeScript — Component patterns, hook rules, prop typing conventions
• Python / FastAPI / Django — Type hints, Pydantic models, async patterns
• Tailwind CSS v4 — Utility-first patterns, @theme directives, no @apply in components
• tRPC — Procedure definitions, input validation, router organization
• Drizzle ORM — Schema definitions, query builder patterns, migration conventions
• Supabase — RLS policies, edge functions, auth helpers
• Swift / SwiftUI — View patterns, @Observable macro, structured concurrency

What a good cursor.directory template looks like:

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

Key Principles:
- Write concise, technical 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)

Next.js Specifics:
- Use Server Components by default; only add 'use client' when needed
- Use the App Router file conventions: page.tsx, layout.tsx, loading.tsx, error.tsx
- Implement proper error boundaries with error.tsx files
- Use next/image for all images, next/link for all navigation
- Server Actions for form mutations; do not use API routes for form handling
- Use searchParams for server-side URL state, useSearchParams for client

Naming Conventions:
- Components: PascalCase (UserProfile.tsx)
- Utilities/hooks: camelCase (useAuth.ts, formatDate.ts)
- Constants: SCREAMING_SNAKE_CASE
- Files: kebab-case for non-component files

TypeScript:
- Use interface over type for object shapes
- Avoid enums; use const objects with 'as const'
- Use strict mode; never use 'any'
- Prefer unknown over any for untyped values

The strength of cursor.directory is breadth. The weakness is quality variance — some templates are thorough (the Next.js and Python ones), others are a few lines that barely help. Always review a template before dropping it in. If a rule feels generic ("write clean code"), it's not adding signal.

How to Use cursor.directory Templates

1. Browse to cursor.directory and find your framework
2. Copy the rules content
3. Create .cursorrules in your project root
4. Paste and customize for your specific project structure

For Cursor, the file is read automatically when it exists in the project root. For Claude Code, you'll want to adapt the content into a CLAUDE.md file instead — same information, but Claude Code looks for that filename specifically.

---

awesome-cursorrules — Curated GitHub Collection

The awesome-cursorrules repository takes a different approach. Rather than hosting the rules directly, it's a curated directory of links to .cursorrules files across GitHub — organized by category:

• Frontend frameworks — React, Vue, Svelte, Angular, Solid
• Backend frameworks — Express, Fastify, Hono, Django, Rails, Laravel
• Full-stack — Next.js, Nuxt, Remix, SvelteKit, Astro
• Mobile — React Native, Flutter, Swift, Kotlin
• Database/ORM — Prisma, Drizzle, Supabase, Convex
• AI/ML — LangChain, Vercel AI SDK, OpenAI patterns
• DevOps — Docker, Terraform, GitHub Actions

The value here is curation. Every linked template has been reviewed by the maintainers, so quality is more consistent than cursor.directory's open submissions. The repo also links to combination templates — rules for "Next.js + Supabase + Tailwind" rather than each framework separately.

For developers building a SaaS with a specific tech stack, the combination templates save real time. A Next.js-only rules file doesn't know about your Drizzle ORM conventions. A combined template covers the interactions between your tools.

---

Boilerplate-Shipped Rules — The Best Starting Point for SaaS

The highest-quality .cursorrules files in the ecosystem aren't in community collections. They're shipped inside commercial SaaS boilerplates, written by the people who built the codebase.

This matters because generic framework rules say "use Server Components by default." A boilerplate-specific rules file says "use Server Components by default, auth checks go through requireUser() from /lib/auth/require-user, database queries use the Drizzle client in /lib/db, billing checks use requireActiveSubscription() from /lib/billing." The AI gets your project's specific patterns, not generic best practices.

Supastarter

Supastarter ships both .cursorrules and .windsurfrules pre-configured. Their rules encode the project's authentication flow, database access patterns, and component organization. The Supastarter team actively updates these files as the boilerplate evolves — when they refactored from Lucia to Better Auth, the rules were updated in the same release.

Key rules in Supastarter's .cursorrules:

• Auth: getSession() from @/lib/auth/server (server) / useSession() from @/lib/auth/client (client)
• Database: All operations through /lib/db/[entity].ts files, Drizzle query builder only
• API: Zod validation on all inputs, consistent { data, error } response shapes
• Billing: Stripe/Polar helpers in /lib/billing, never call Stripe SDK directly from components

MakerKit

MakerKit has the most thorough AI development support of any boilerplate — .cursorrules, .windsurfrules, and CLAUDE.md for Claude Code. Their architecture is designed for AI-assisted development: strict TypeScript, JSDoc comments on public APIs, and clear separation between server and client code.

MakerKit's CLAUDE.md is particularly useful because it encodes the feature-addition workflow:

# CLAUDE.md — MakerKit Project Guide

## Adding a New Feature
1. Define database schema in packages/database/src/schema/[feature].ts
2. Create server queries in lib/server/[feature]/queries.ts
3. Create server mutations in lib/server/[feature]/mutations.ts
4. Add page at apps/web/app/[organization]/[feature]/page.tsx
5. Follow existing patterns from /apps/web/app/[organization]/settings/

## Auth Patterns
- Server: const session = await requireAuth(ctx)
- Client: const { user } = useUser()
- Never access database without auth check first

## Forbidden
- Do not use 'any' type
- Do not add console.log statements
- Do not bypass auth middleware
- Do not call external APIs directly from client components

ShipFast

ShipFast ships .cursorrules focused on rapid development patterns — simpler than Supastarter or MakerKit because the codebase is simpler. The rules cover NextAuth session access, Stripe webhook handling, and MongoDB/Supabase query patterns. ShipFast's rules are optimized for solo developers who want the AI to write production-ready code without over-engineering it.

If you're using any of these boilerplates for vibe coding a SaaS, the built-in rules are a major advantage over starting from a blank Next.js project.

---

Framework-Specific Rules Packs

Beyond boilerplate-shipped rules, the community maintains focused rules packs for specific technologies. These are useful when you're building a custom stack or extending a boilerplate with additional tools.

Next.js App Router Rules

The most important rules for Next.js 15/16 center on the Server Component boundary — the most common source of AI-generated bugs:

## Server vs Client Components
- Default to Server Components (no directive needed)
- Add 'use client' only for: useState, useEffect, event handlers, browser APIs
- Never import server-only modules in client components
- Use server actions (use server) for form mutations, not API routes
- Pass serializable props from server to client components

## Data Fetching
- Server Components: fetch directly or use ORM, no useEffect
- Client Components: use React Query or SWR with API routes
- Never use getServerSideProps or getStaticProps (Pages Router patterns)
- Use generateMetadata() for dynamic SEO, not Head component

## Caching
- fetch() requests are NOT cached by default in Next.js 15+
- Use { next: { revalidate: 3600 } } for time-based caching
- Use unstable_cache for database query caching
- Use revalidatePath/revalidateTag for on-demand revalidation

Drizzle ORM Rules

## Drizzle Conventions
- Schema definitions in /db/schema/ with one file per table
- Use the query builder API over raw SQL
- Always define relations in schema files
- Use $inferSelect and $inferInsert for type inference
- Migrations via drizzle-kit push for dev, generate + migrate for prod
- Use transactions for multi-table operations: db.transaction(async (tx) => { ... })

Tailwind CSS v4 Rules

Tailwind v4 changed enough internals that v3-era rules actively mislead AI tools:

## Tailwind v4
- Import via @import "tailwindcss" in CSS (not @tailwind directives)
- Theme customization via @theme { } block in CSS, not tailwind.config
- No tailwind.config.ts file in v4 projects
- Use CSS variables for custom colors: --color-primary: #1a1a2e
- Prefer utility classes over @apply
- Dark mode via .dark class (class strategy), not media queries

These framework-specific packs are where AI coding tools get the biggest accuracy boost. Cursor trained on millions of Tailwind v3 examples will use @tailwind base unless your rules explicitly say "use @import 'tailwindcss' for v4."

---

Writing Custom Rules That Work

Community templates are a starting point. The rules that actually improve your daily coding output are custom rules tuned to your specific project. Here is what makes the difference.

Structure That AI Tools Parse Well

Both Cursor and Claude Code parse rules files as unstructured text, but consistent formatting helps. The most effective structure:

You are an expert in [your tech stack].

## Project Structure
[Describe your directory layout]

## Conventions
[List your coding patterns]

## Common Tasks
[Step-by-step patterns for frequent operations]

## Forbidden
[Things the AI should never do]

The "Forbidden" section is the highest-value part. AI tools are good at following positive instructions ("use X") but even better at avoiding explicit prohibitions. Every time you fix an AI-generated mistake, add a rule to prevent it.

Rules That Prevent Real Bugs

Generic rules ("write clean code") waste tokens. Effective rules prevent specific, recurring mistakes:

## Forbidden Patterns
- Never use fetch() in client components for data that exists in server components
- Never put API keys or secrets in client-side code (files without 'use server')
- Never use Date.now() for database timestamps; use the database's now() function
- Never import from @/lib/db in files marked 'use client'
- Never use router.push() for form submissions; use server actions
- Never hardcode Stripe price IDs; use the PLANS constant from /lib/billing/plans

CLAUDE.md vs .cursorrules vs .windsurfrules

These files serve the same purpose for different tools. The content overlaps significantly, but there are format differences worth knowing:

File	Tool	Location	Format
.cursorrules	Cursor	Project root	Plain text, no structure required
.windsurfrules	Windsurf	Project root	Plain text, same as .cursorrules
CLAUDE.md	Claude Code	Project root	Markdown, supports headers and lists
.claude/settings.json	Claude Code	Project root	JSON, for tool permissions and config
.cursor/rules/*.mdc	Cursor	.cursor/rules/	MDC format, can target specific file globs

Cursor's .cursor/rules/ directory is worth highlighting. Instead of one monolithic rules file, you can create multiple rule files that apply to specific file patterns:

.cursor/rules/
  api-routes.mdc      → applies to app/api/**/*.ts
  components.mdc      → applies to components/**/*.tsx
  database.mdc        → applies to lib/db/**/*.ts
  testing.mdc         → applies to **/*.test.ts

Each .mdc file includes a frontmatter block specifying which files it targets:

---
description: Rules for API route handlers
globs: app/api/**/*.ts
---

All API routes must:
1. Validate input with Zod
2. Check authentication via requireAuth()
3. Return consistent { data, error } response shape
4. Handle errors with try/catch, never let exceptions propagate

This granular approach means database rules don't clutter the context when you're editing a React component, and component rules don't appear when you're writing a migration.

---

When to Use Which

Starting a new project with a boilerplate? Use the boilerplate's built-in rules. Supastarter, MakerKit, and ShipFast all ship .cursorrules that encode their specific conventions. Don't replace them with generic community rules — the boilerplate-specific rules are better. If you're evaluating which boilerplate to buy, check whether it ships AI rules files as part of your assessment.

Starting a new project from scratch? Start with a cursor.directory template for your primary framework, then add rules for your secondary tools (ORM, CSS framework, auth library). Within the first week, add 10-20 custom rules based on the mistakes Cursor or Claude Code makes in your codebase.

Adding rules to an existing project? Skip the community templates. Open your last 20 pull requests, find every AI-generated bug you fixed, and write a "Forbidden" rule for each one. Your custom rules will outperform any template because they encode your specific patterns.

Using Cursor vs other AI coding tools? .cursorrules only works in Cursor. If you're switching between tools, maintain a CLAUDE.md (for Claude Code) alongside .cursorrules (for Cursor) and .windsurfrules (for Windsurf). The content will be 80% identical — the 20% difference is tool-specific formatting and capabilities.

Building a SaaS for launch? Combine boilerplate rules with the framework-specific packs above. The boilerplate rules handle architecture; the framework packs handle API-level correctness. A weekend build with good rules files will produce cleaner code than a week of coding without them. For the full weekend SaaS build playbook, rules setup is part of the Friday evening prep.

---

Setting Up Rules in Under 10 Minutes

Here is a concrete setup sequence for a Next.js + Drizzle + Tailwind v4 project:

Step 1: Grab the base template (2 minutes)

Go to cursor.directory, search "Next.js," and copy the highest-rated Next.js App Router template into .cursorrules at your project root.

Step 2: Add your ORM rules (2 minutes)

Append Drizzle-specific rules (schema location, query patterns, migration workflow) below the Next.js rules.

Step 3: Add your Tailwind v4 rules (1 minute)

Append the v4-specific rules — particularly the @import "tailwindcss" directive and @theme block patterns that override v3 habits in AI training data.

Step 4: Add your project-specific section (3 minutes)

Add a "Project Structure" section listing your key directories and a "Forbidden" section with at least 5 rules based on your conventions. Where is auth? Where is the database client? What should the AI never do?

Step 5: Copy to CLAUDE.md (2 minutes)

If you use Claude Code, copy the same content to CLAUDE.md in the project root. Add markdown headers for better readability.

This 10-minute setup pays for itself on the first AI-generated feature. When choosing your ideal tech stack for a SaaS in 2026, factor in how well each tool's ecosystem supports rules files — frameworks with active cursor.directory templates give you a head start.

---

Key Takeaways

1. Start with community templates, not a blank file. cursor.directory and awesome-cursorrules have good defaults for every major framework.
2. Boilerplate-shipped rules are the gold standard. If you're using Supastarter, MakerKit, or ShipFast, their built-in rules encode conventions that no generic template can match.
3. The "Forbidden" section is the highest-ROI part of any rules file. Every bug you catch from AI output should become a new rule.
4. Use .cursor/rules/ for granular control. File-glob-targeted rules keep context relevant and reduce noise.
5. Maintain parallel files for each tool. .cursorrules for Cursor, .windsurfrules for Windsurf, CLAUDE.md for Claude Code. The content is 80% shared.
6. Update your rules weekly. The first week's rules file should look nothing like the month-three version. Good rules evolve with your codebase.