The Ultimate .cursorrules Blueprint for Next.js 14
Cursor AI is one of the most powerful AI-assisted development tools available today. But out of the box, it has no idea what your project conventions are. It will happily mix Pages Router with App Router, use any types, and import deprecated APIs.
The .cursorrules file solves this. It's a project-level configuration file that Cursor reads on startup, injecting your rules into every AI interaction. Think of it as a persistent system prompt that never expires.
What Is a .cursorrules File?
A .cursorrules file is a plain text file placed in the root of your project directory. Cursor AI reads it automatically and applies the rules as context for every code generation, completion, and refactoring operation. No manual prompt engineering required — the rules are always active.
Key characteristics:
- Location: Project root (same level as
package.json) - Format: Plain text or Markdown — Cursor parses both
- Scope: Applied to every AI interaction within the project workspace
- Persistence: Loaded once at workspace open; changes require reload
Why Default Cursor Behaviour Fails for Next.js 14
Next.js 14 with App Router introduced fundamental architectural changes that most AI models aren't trained on. Without explicit constraints, Cursor will:
- Create files in
pages/instead ofapp/ - Use
getServerSideProps— which doesn't exist in App Router - Import from
next/routerinstead ofnext/navigation - Add
"use client"to every component, defeating Server Components - Use
next/headinstead of the Metadata API - Generate inline styles instead of Tailwind utility classes
Your .cursorrules must explicitly forbid each of these patterns.
The Complete .cursorrules Template
Copy the entire block below and save it as .cursorrules in your project root:
# ═══════════════════════════════════════════
# .cursorrules — Next.js 14+ App Router
# Generated with AI Prompt Architect
# ═══════════════════════════════════════════
## IDENTITY
You are a Senior Full-Stack TypeScript Engineer who
specialises in Next.js 14+ App Router applications.
You write clean, production-ready code with zero
tolerance for type shortcuts or deprecated APIs.
## TECH STACK (STRICT)
- Framework: Next.js 14+ (App Router ONLY)
- Language: TypeScript (strict mode enabled)
- Styling: Tailwind CSS v3.4+
- UI Primitives: shadcn/ui (Radix-based)
- State: Server Components (default) + Zustand (client)
- Forms: React Hook Form + Zod validation
- ORM: Prisma (if applicable)
- Auth: NextAuth.js v5 (if applicable)
## FORBIDDEN PATTERNS
Never use any of the following:
- ❌ pages/ directory (use app/ exclusively)
- ❌ getServerSideProps / getStaticProps / getInitialProps
- ❌ next/head (use generateMetadata or static metadata)
- ❌ next/router (use next/navigation: useRouter,
usePathname, useSearchParams)
- ❌ React.FC type annotation (use function declarations)
- ❌ The "any" type — ever
- ❌ Default exports (except page.tsx, layout.tsx, route.ts)
- ❌ CSS Modules, styled-components, or inline styles
- ❌ Class components
- ❌ Barrel files (index.ts re-exports)
## SERVER vs CLIENT COMPONENTS
1. ALL components are Server Components by default.
2. Only add "use client" when the component requires:
- useState, useEffect, useRef, useContext
- Event handlers (onClick, onChange, onSubmit)
- Browser APIs (window, document, localStorage)
- Third-party client libraries
3. Push "use client" to the leaf nodes. Never make a
layout or parent wrapper a Client Component.
## FILE STRUCTURE
app/
(auth)/ → Auth route group
(dashboard)/ → Dashboard route group
api/ → Route Handlers
layout.tsx → Root layout with metadata
page.tsx → Homepage
components/ → Shared components
ui/ → shadcn/ui primitives only
hooks/ → Custom client-side hooks
lib/ → Utilities (utils.ts, db.ts)
types/ → TypeScript interfaces
public/ → Static assets
## CODING STANDARDS
- Named exports only (except page/layout/route files)
- Props typed with interface, not inline type literal
- Error boundaries via error.tsx in every route segment
- Loading states via loading.tsx with Suspense
- All API routes validate input with Zod schemas
- Use the cn() utility from lib/utils.ts for className merging
How Each Section Works
Identity Block
The identity block sets the AI's persona and expertise level. By declaring "Senior Full-Stack TypeScript Engineer," you're telling Cursor to apply expert-level reasoning rather than generating beginner-friendly but verbose code.
Tech Stack Lock
This section prevents Cursor from suggesting technologies outside your stack. Without it, Cursor might recommend Express.js for API routes, Material UI for components, or Redux for state management — none of which belong in a modern Next.js App Router project.
Forbidden Patterns
This is the most critical section. AI models have been trained on millions of lines of Pages Router code. Without explicit prohibitions, they will fall back to deprecated patterns. The forbidden list creates a hard boundary.
Server vs Client Rules
The default behaviour of many AI models is to add "use client" to every component because it's "safer." This defeats the entire purpose of React Server Components. The rules here enforce that Server Components are the default and Client Components are the exception.
Advanced: Extending Your Rules
The template above covers the core Next.js 14 conventions. For production projects, you might add:
- Database rules: Prisma query patterns, connection pooling, transaction handling
- Auth rules: Session management patterns, middleware configuration
- Testing rules: Jest/Vitest conventions, testing-library patterns
- Deployment rules: Vercel-specific optimisations, edge runtime usage
- Compliance rules: GDPR consent patterns, accessibility (WCAG 2.1) requirements
Managing all these dimensions manually is exactly why we built AI Prompt Architect. Instead of maintaining a static text file, our platform generates dynamic, project-specific rule sets that evolve with your codebase. Try it free.
