Frontend CLAUDE.md Templates — 11 Framework-Calibrated Setups | AI Code Toolkit
11 tested templates · Next.js, React, Vue, Svelte, Angular, Solid, Qwik

Frontend CLAUDE.md Templates

Framework-calibrated project setups that carry rendering-model, styling, state, and directory conventions into every Claude Code session. The single highest-leverage file to commit for frontend work.

11
Frontend Stacks
5 sections
Every Template
Version-Aware
Configs
48h
Update SLA

Why frontend projects benefit most from a well-tuned CLAUDE.md

Frontend has more moving parts — and more opinionated per-framework conventions — than almost any other part of the stack. A single page in a modern web app can involve four rendering models (SSR, SSG, RSC, CSR), three or four state systems (URL state, server state, form state, client state), a design system with hundreds of tokens, a styling framework with its own directives, and a routing convention with rules about where files can live. That's a lot for Claude to hold in mind unprompted. A well-tuned CLAUDE.md carries that context every session so Claude arrives already up-to-speed.

The 11 templates on this page are calibrated for the frameworks in current use in 2026: the two Next.js majors, Remix, Astro, SvelteKit, Nuxt, Angular, Solid, Qwik, plus plain React + Vite for SPA work. Each is refreshed within 48 hours of a meaningful framework release and includes the current-version idioms, gotchas, and Do NOTs specific to that framework.

The lens: A great frontend CLAUDE.md answers five questions Claude has to guess at otherwise. Where do files live? What's the Server/Client boundary rule? What styling system is in use? What state library handles what? What are the version-specific gotchas? Answer those five and Claude's frontend output jumps a full quality level.

The five sections every frontend CLAUDE.md needs

1. Rendering model rules

The Server/Client boundary is the single most consequential decision in a modern React app, and getting it wrong is the single most common Claude Code frontend mistake. Every Next.js 15 or Remix template on this page opens with an explicit posture: "Server Components by default; add 'use client' only when a specific interactive dependency requires it." The rule doesn't need to be elaborate — it just needs to be present, so Claude reaches for the server-side option first.

2. Styling system rules

Tailwind projects, styled-components projects, CSS Modules projects, and vanilla CSS projects all need different guidance. Tell Claude explicitly what your project uses, whether utility classes are preferred over component styles, and which design tokens exist. For Tailwind projects specifically, name the design system if you have one (shadcn, Untitled UI, custom) so Claude reaches for the right component patterns.

3. State management defaults

Modern frontends usually have three or four state systems: URL state (searchParams or router state), server state (TanStack Query, SWR, tRPC, RSC), form state (React Hook Form, Conform, framework-native), and client state (Zustand, Redux, Context). Tell Claude which system handles which kind of state so it doesn't reach for the wrong one. A one-line rule like "URL state via searchParams; server state via TanStack Query; form state via React Hook Form; client state via Zustand only when needed" is enough.

4. File conventions

Where components live, where hooks live, where utilities live, and what naming pattern is used. Frontend projects fragment into many small files, and Claude will happily invent new locations if not told the existing convention. A five-line directory map at the top of CLAUDE.md prevents that.

5. Version-specific gotchas

Next.js 15 changed caching defaults. React 19 shipped new hooks. Angular 18 added Signals. These changes are recent enough that Claude sometimes reaches for pre-change patterns. Explicit Do NOTs in the CLAUDE.md close the gap. Every template here documents its framework's most-recent-major gotchas.

Anatomy of the Next.js 15 template

markdown CLAUDE.md — Next.js 15 App Router
# App — CLAUDE.md ## Stack - Next.js 15 (App Router) + React 19 - TypeScript 5.6 strict - Tailwind CSS 4 + shadcn/ui components - TanStack Query for server state, Zustand for client state (rare) - React Hook Form + Zod for forms ## Commands - `pnpm dev` — dev server on :3000 - `pnpm test` — Vitest + Playwright - `pnpm typecheck` — no-emit type check - `pnpm build` — production build ## Rendering model - Server Components by default. Add 'use client' only when needed. - Server Actions for mutations. Route Handlers only for public APIs. - Streaming via Suspense; loading UI in loading.tsx. - URL state via searchParams (paginate, filter, sort). ## Styling - Tailwind utilities preferred over CSS files. - shadcn/ui primitives via @/components/ui/*. DO NOT edit — regenerate with `pnpm shadcn add`. - Design tokens live in app/globals.css as CSS vars. ## Directory structure - `app/` — routes, layouts, route handlers - `components/ui/` — shadcn primitives (do not edit) - `components/` — app-specific components - `lib/` — utilities and clients ## Next.js 15 specifics - Caching is opt-in. fetch() is not cached by default; use cache: 'force-cache' explicitly. - Async params/searchParams. Always await them in server components. - React 19 use() hook for promise unwrapping. ## Do NOT - Do NOT use useEffect for data fetching — use Server Components or TanStack Query. - Do NOT wrap the whole page in 'use client' to make one part interactive. - Do NOT edit next.config.js without asking.

Under 50 lines and it covers every decision Claude would otherwise guess at. That's the template pattern: dense, specific, opinionated.

Templates + framework agents: the frontend trifecta

A CLAUDE.md tells Claude about your project. A framework subagent tells Claude about the framework itself. Install both for maximum leverage on frontend work:

  • Next.js 15 template — project conventions loaded every session.
  • nextjs-15-expert subagent — deep framework expertise on demand.
  • Optional: matching testing template for the framework-specific test setup (Playwright config, Vitest workspace patterns).

The pair produces frontend code that reads like a senior on the team wrote it — not because Claude is different, but because it now has the context it always needed.

Complete Listing

All 11 frontend templates, grouped by ecosystem

Each template covers rendering model, styling system, state management, directory conventions, and version-specific gotchas — the five sections that matter most.

Decision Framework

Which frontend template should I use?

Match your framework and major version exactly. Mixing versions is the top source of broken generated code.

You're on Next.js
Match your major version: nextjs-15-app-router for 15+, nextjs-14-pages for anything older. Next.js 15's caching-is-opt-in change is significant enough that mixing agent versions produces broken code.
You're on a React SPA (no framework)
Use react-vite. Includes TanStack Query defaults, TanStack Router patterns, and Vite-specific conventions. Skip the Next.js templates — they encode server-side rendering assumptions you don't have.
You're building content-heavy static sites
Use astro. Islands architecture, content collections, and MDX defaults are baked in. Optimized for the marketing-site / blog / docs use case.
You're on a Vue-family stack
Full-stack Vue → nuxt-3. SPA-only Vue → vue-3. The two templates encode different rendering-model assumptions — pick the one matching your reality.
You're on a modern reactive framework
solid for SolidJS + SolidStart, qwik for Qwik City. Both have different mental models from React — a generic template would encode wrong defaults. Use the specific one.
You're on Angular
angular. The template is calibrated for Angular 18's standalone components, Signals, and new control-flow syntax — not legacy Angular patterns. Verify your version matches before copying.

🐛 Hit an error while using these?

Our sister site AI Error Hub covers Claude Code errors, MCP connection failures, and stack traces — cross-referenced with everything on this site.

Visit AI Error Hub →
FAQ

Frequently asked questions

The questions developers ask most about frontend.

Match your project's actual Next.js version. Next.js 15 changed defaults significantly:

  • Caching is opt-in (was opt-out).
  • Params and searchParams are async (were sync).

Mixing templates produces code that looks right but fails at runtime. Check package.json, then install the matching template.

If you're migrating from 14 to 15, keep both installed briefly and remove the older one once the migration is complete.

CLAUDE.md is project-specific and versioned in git. That gives you:

  • Every developer on the team gets the same conventions on their next pull.
  • New hires get productive on day one.
  • Changes go through PR review.

A system prompt is either global (all projects share it, which is wrong) or per-session (nobody remembers to set it, so it drifts). CLAUDE.md solves both.

Under 300 lines is the discipline target — every line eats tokens on every session start.

The Next.js 15 template on this page is about 50 lines and covers rendering model, styling, state, directory structure, version specifics, and Do NOTs. That's the density you want.

If your CLAUDE.md exceeds 300 lines, move detailed sub-topics to separate docs and reference them via @path/to/file.md imports.

A short section, yes. Name:

  • The test frameworks in use (Vitest, Playwright).
  • The test file convention (colocated .test.tsx or __tests__/ folder).
  • The coverage bar if you have one.

Deep testing rules belong in a separate testing.md file that CLAUDE.md references. That way the main file stays scannable.

No, and you'd be worse off. The react-vite template assumes:

  • Client-side rendering.
  • No server.
  • No framework routing.
  • No build-time optimization beyond Vite defaults.

A Next.js project reads those assumptions and produces wrong-shaped code — server-side rendering opportunities missed, no data-fetching primitives used, no Server Component boundary.

Use the Next.js template for Next.js.

Whenever a change makes it stale:

  • New dependency? Update CLAUDE.md in the same PR.
  • Renamed a directory convention? Update.
  • Upgraded framework major? Copy the new template and diff against your current file.

A stale frontend CLAUDE.md is worse than none — Claude will confidently use the wrong test command or dead directory name.

Yes, for maximum leverage:

  • CLAUDE.md — tells Claude about your project (which framework version, where files live, team conventions).
  • Framework subagent — tells Claude about the framework itself (current-version idioms, gotchas, output patterns).

Together they're the frontend trifecta — project brief plus framework expert, loaded on every session.

In a monorepo, use nested CLAUDE.md files:

  • Root CLAUDE.md — shared conventions (pnpm workspace commands, Turborepo, top-level directory structure).
  • apps/web/CLAUDE.md — Next.js rules.
  • apps/marketing/CLAUDE.md — Astro rules.

Nested files augment the parent rather than replacing it. Claude Code loads all of them hierarchically at session start.

Yes, with light adaptation:

  1. Remove app-specific sections (rendering model, routing conventions).
  2. Keep technical stack, styling system, and Do NOT sections.
  3. Add a peer dependencies section — "Consumers use React 19+; do not import React internals; do not depend on Next.js primitives."

That kind of boundary-defining rule is exactly what CLAUDE.md is for.

Reference it, don't duplicate it. If your design system has its own CLAUDE.md or documentation, reference the specific parts you rely on from your app's CLAUDE.md.

For shadcn/ui specifically, the useful rule is:

"shadcn primitives live at components/ui/; do not edit — regenerate with pnpm shadcn add."

That single line prevents Claude from breaking your customization boundary.

Share with