Next.js + Firebase + Tailwind rules for AI coding agents
Full stack: Next.js (App Router) + Tailwind CSS v4 + Firebase
Ready-to-commit rules for Next.js (App Router) + Tailwind CSS v4 + Firebase in every major format: AGENTS.md (Codex, Cursor, Copilot), CLAUDE.md (Claude Code), Cursor .mdc project rules, legacy .cursorrules, Copilot instructions, Windsurf rules and GEMINI.md. Next.js with Firebase Auth and Firestore.
Last reviewed 2026-10-21 · Customise in the generator · Raw: AGENTS.md, CLAUDE.md
Agents leave Firestore in test mode (`allow read, write: if true`) or import the Admin SDK into client bundles.
Generated files
# AGENTS.md - this project
Instructions for AI coding agents working in this repository.
## Project
A Next.js (App Router) + Tailwind CSS v4 + Firebase project.
Stack: Next.js (App Router), Tailwind CSS v4, Firebase.
## Commands
- Dev server: `npm run dev`
- Production build (also type-checks): `npm run build`
- Lint: `npm run lint`
- Local emulators: `firebase emulators:start`
- Deploy rules only: `firebase deploy --only firestore:rules`
## Project structure
- `app/` holds routes: `page.tsx`, `layout.tsx`, `loading.tsx`, `error.tsx`, `route.ts` for API handlers.
- Shared UI in `components/`, server-only helpers in `lib/` (mark them with `import "server-only"`).
## How to work in this repo
- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.
## Next.js (App Router)
- Check the Next.js major version in `package.json` before using an API; follow the docs for that version.
- Components are Server Components by default. Add `"use client"` only to the smallest leaf component that needs state, effects, or browser APIs.
- Fetch data in Server Components or Server Actions, not in `useEffect`.
- In Next.js 15+, `params`, `searchParams`, `cookies()` and `headers()` are async: always `await` them.
- Mutations go through Server Actions (`"use server"`) or `route.ts` handlers. Validate every input on the server and re-check auth inside the action.
- After a mutation, call `revalidatePath()` or `revalidateTag()` instead of forcing the whole route dynamic.
- Use `next/image` for images, `next/font` for fonts and `next/link` for internal links.
- Export `metadata` or `generateMetadata` from every page for title, description and Open Graph tags.
- Only variables prefixed `NEXT_PUBLIC_` reach the browser. Never put secrets in them.
- In Next.js 16, `middleware.ts` is renamed `proxy.ts`. Use whichever file the project already has.
## Tailwind CSS v4
- Tailwind v4 is configured in CSS: `@import "tailwindcss";` plus `@theme { ... }` for design tokens. Do not create a `tailwind.config.js` unless the project already has one.
- Use theme tokens (colors, spacing) instead of arbitrary values like `w-[37px]`.
- Build responsive layouts mobile-first with `sm:`, `md:`, `lg:` prefixes.
- Extract repeated class lists into components, not `@apply` chains.
- Support dark mode with the `dark:` variant when the project uses it.
## Firebase
- Firebase web config is public by design; security comes from Firestore/Storage Security Rules. Never ship `allow read, write: if true`.
- Every collection needs rules that check `request.auth` and validate the written fields.
- Admin SDK credentials are server-only (Cloud Functions or your backend).
- Model Firestore data for your queries: avoid deeply nested data and unbounded arrays; denormalize deliberately.
- Test rules and functions against the Emulator Suite, not production.
## Avoid
- Do not add `"use client"` to layouts or pages just to silence an error; move the interactive part into a child component.
- Do not use the Pages Router (`pages/`) APIs such as `getServerSideProps` in an App Router project.
## Reference docs
- [Next.js docs](https://nextjs.org/docs)
- [Tailwind CSS docs](https://tailwindcss.com/docs)
- [Firebase docs](https://firebase.google.com/docs)
# CLAUDE.md - this project
Project instructions for Claude Code.
## Project
A Next.js (App Router) + Tailwind CSS v4 + Firebase project.
Stack: Next.js (App Router), Tailwind CSS v4, Firebase.
## Commands
- Dev server: `npm run dev`
- Production build (also type-checks): `npm run build`
- Lint: `npm run lint`
- Local emulators: `firebase emulators:start`
- Deploy rules only: `firebase deploy --only firestore:rules`
## Project structure
- `app/` holds routes: `page.tsx`, `layout.tsx`, `loading.tsx`, `error.tsx`, `route.ts` for API handlers.
- Shared UI in `components/`, server-only helpers in `lib/` (mark them with `import "server-only"`).
## How to work in this repo
- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.
## Next.js (App Router)
- Check the Next.js major version in `package.json` before using an API; follow the docs for that version.
- Components are Server Components by default. Add `"use client"` only to the smallest leaf component that needs state, effects, or browser APIs.
- Fetch data in Server Components or Server Actions, not in `useEffect`.
- In Next.js 15+, `params`, `searchParams`, `cookies()` and `headers()` are async: always `await` them.
- Mutations go through Server Actions (`"use server"`) or `route.ts` handlers. Validate every input on the server and re-check auth inside the action.
- After a mutation, call `revalidatePath()` or `revalidateTag()` instead of forcing the whole route dynamic.
- Use `next/image` for images, `next/font` for fonts and `next/link` for internal links.
- Export `metadata` or `generateMetadata` from every page for title, description and Open Graph tags.
- Only variables prefixed `NEXT_PUBLIC_` reach the browser. Never put secrets in them.
- In Next.js 16, `middleware.ts` is renamed `proxy.ts`. Use whichever file the project already has.
## Tailwind CSS v4
- Tailwind v4 is configured in CSS: `@import "tailwindcss";` plus `@theme { ... }` for design tokens. Do not create a `tailwind.config.js` unless the project already has one.
- Use theme tokens (colors, spacing) instead of arbitrary values like `w-[37px]`.
- Build responsive layouts mobile-first with `sm:`, `md:`, `lg:` prefixes.
- Extract repeated class lists into components, not `@apply` chains.
- Support dark mode with the `dark:` variant when the project uses it.
## Firebase
- Firebase web config is public by design; security comes from Firestore/Storage Security Rules. Never ship `allow read, write: if true`.
- Every collection needs rules that check `request.auth` and validate the written fields.
- Admin SDK credentials are server-only (Cloud Functions or your backend).
- Model Firestore data for your queries: avoid deeply nested data and unbounded arrays; denormalize deliberately.
- Test rules and functions against the Emulator Suite, not production.
## Avoid
- Do not add `"use client"` to layouts or pages just to silence an error; move the interactive part into a child component.
- Do not use the Pages Router (`pages/`) APIs such as `getServerSideProps` in an App Router project.
## Reference docs
- [Next.js docs](https://nextjs.org/docs)
- [Tailwind CSS docs](https://tailwindcss.com/docs)
- [Firebase docs](https://firebase.google.com/docs)
---
description: "Core rules for this project"
alwaysApply: true
---
# this project
A Next.js (App Router) + Tailwind CSS v4 + Firebase project.
Stack: Next.js (App Router), Tailwind CSS v4, Firebase.
## Commands
- Dev server: `npm run dev`
- Production build (also type-checks): `npm run build`
- Lint: `npm run lint`
- Local emulators: `firebase emulators:start`
- Deploy rules only: `firebase deploy --only firestore:rules`
## How to work in this repo
- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.
---
description: "Next.js (App Router) conventions: Next.js App Router with React Server Components and TypeScript."
globs: app/**/*.tsx, app/**/*.ts, src/**/*.tsx, src/**/*.ts
alwaysApply: false
---
# Next.js (App Router)
- Check the Next.js major version in `package.json` before using an API; follow the docs for that version.
- Components are Server Components by default. Add `"use client"` only to the smallest leaf component that needs state, effects, or browser APIs.
- Fetch data in Server Components or Server Actions, not in `useEffect`.
- In Next.js 15+, `params`, `searchParams`, `cookies()` and `headers()` are async: always `await` them.
- Mutations go through Server Actions (`"use server"`) or `route.ts` handlers. Validate every input on the server and re-check auth inside the action.
- After a mutation, call `revalidatePath()` or `revalidateTag()` instead of forcing the whole route dynamic.
- Use `next/image` for images, `next/font` for fonts and `next/link` for internal links.
- Export `metadata` or `generateMetadata` from every page for title, description and Open Graph tags.
- Only variables prefixed `NEXT_PUBLIC_` reach the browser. Never put secrets in them.
- In Next.js 16, `middleware.ts` is renamed `proxy.ts`. Use whichever file the project already has.
## Avoid
- Do not add `"use client"` to layouts or pages just to silence an error; move the interactive part into a child component.
- Do not use the Pages Router (`pages/`) APIs such as `getServerSideProps` in an App Router project.
Docs: https://nextjs.org/docs
---
description: "Tailwind CSS v4 conventions: Utility-first styling with Tailwind CSS v4."
globs: **/*.css, **/*.tsx, **/*.vue, **/*.svelte, **/*.astro, **/*.html, **/*.blade.php, **/*.erb
alwaysApply: false
---
# Tailwind CSS v4
- Tailwind v4 is configured in CSS: `@import "tailwindcss";` plus `@theme { ... }` for design tokens. Do not create a `tailwind.config.js` unless the project already has one.
- Use theme tokens (colors, spacing) instead of arbitrary values like `w-[37px]`.
- Build responsive layouts mobile-first with `sm:`, `md:`, `lg:` prefixes.
- Extract repeated class lists into components, not `@apply` chains.
- Support dark mode with the `dark:` variant when the project uses it.
Docs: https://tailwindcss.com/docs
---
description: "Firebase conventions: Firebase Auth, Firestore and Cloud Functions."
globs: firestore.rules, functions/**, **/firebase/**
alwaysApply: false
---
# Firebase
- Firebase web config is public by design; security comes from Firestore/Storage Security Rules. Never ship `allow read, write: if true`.
- Every collection needs rules that check `request.auth` and validate the written fields.
- Admin SDK credentials are server-only (Cloud Functions or your backend).
- Model Firestore data for your queries: avoid deeply nested data and unbounded arrays; denormalize deliberately.
- Test rules and functions against the Emulator Suite, not production.
Docs: https://firebase.google.com/docs
# Cursor rules - this project
You are an expert Next.js (App Router), Tailwind CSS v4, Firebase engineer working on this codebase. Follow these rules.
## Project
A Next.js (App Router) + Tailwind CSS v4 + Firebase project.
Stack: Next.js (App Router), Tailwind CSS v4, Firebase.
## Commands
- Dev server: `npm run dev`
- Production build (also type-checks): `npm run build`
- Lint: `npm run lint`
- Local emulators: `firebase emulators:start`
- Deploy rules only: `firebase deploy --only firestore:rules`
## Project structure
- `app/` holds routes: `page.tsx`, `layout.tsx`, `loading.tsx`, `error.tsx`, `route.ts` for API handlers.
- Shared UI in `components/`, server-only helpers in `lib/` (mark them with `import "server-only"`).
## How to work in this repo
- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.
## Next.js (App Router)
- Check the Next.js major version in `package.json` before using an API; follow the docs for that version.
- Components are Server Components by default. Add `"use client"` only to the smallest leaf component that needs state, effects, or browser APIs.
- Fetch data in Server Components or Server Actions, not in `useEffect`.
- In Next.js 15+, `params`, `searchParams`, `cookies()` and `headers()` are async: always `await` them.
- Mutations go through Server Actions (`"use server"`) or `route.ts` handlers. Validate every input on the server and re-check auth inside the action.
- After a mutation, call `revalidatePath()` or `revalidateTag()` instead of forcing the whole route dynamic.
- Use `next/image` for images, `next/font` for fonts and `next/link` for internal links.
- Export `metadata` or `generateMetadata` from every page for title, description and Open Graph tags.
- Only variables prefixed `NEXT_PUBLIC_` reach the browser. Never put secrets in them.
- In Next.js 16, `middleware.ts` is renamed `proxy.ts`. Use whichever file the project already has.
## Tailwind CSS v4
- Tailwind v4 is configured in CSS: `@import "tailwindcss";` plus `@theme { ... }` for design tokens. Do not create a `tailwind.config.js` unless the project already has one.
- Use theme tokens (colors, spacing) instead of arbitrary values like `w-[37px]`.
- Build responsive layouts mobile-first with `sm:`, `md:`, `lg:` prefixes.
- Extract repeated class lists into components, not `@apply` chains.
- Support dark mode with the `dark:` variant when the project uses it.
## Firebase
- Firebase web config is public by design; security comes from Firestore/Storage Security Rules. Never ship `allow read, write: if true`.
- Every collection needs rules that check `request.auth` and validate the written fields.
- Admin SDK credentials are server-only (Cloud Functions or your backend).
- Model Firestore data for your queries: avoid deeply nested data and unbounded arrays; denormalize deliberately.
- Test rules and functions against the Emulator Suite, not production.
## Avoid
- Do not add `"use client"` to layouts or pages just to silence an error; move the interactive part into a child component.
- Do not use the Pages Router (`pages/`) APIs such as `getServerSideProps` in an App Router project.
## Reference docs
- [Next.js docs](https://nextjs.org/docs)
- [Tailwind CSS docs](https://tailwindcss.com/docs)
- [Firebase docs](https://firebase.google.com/docs)
# Copilot instructions - this project
A Next.js (App Router) + Tailwind CSS v4 + Firebase project.
Stack: Next.js (App Router), Tailwind CSS v4, Firebase.
## Commands
- Dev server: `npm run dev`
- Production build (also type-checks): `npm run build`
- Lint: `npm run lint`
- Local emulators: `firebase emulators:start`
- Deploy rules only: `firebase deploy --only firestore:rules`
## How to work in this repo
- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.
---
applyTo: "app/**/*.tsx,app/**/*.ts,src/**/*.tsx,src/**/*.ts"
---
# Next.js (App Router)
- Check the Next.js major version in `package.json` before using an API; follow the docs for that version.
- Components are Server Components by default. Add `"use client"` only to the smallest leaf component that needs state, effects, or browser APIs.
- Fetch data in Server Components or Server Actions, not in `useEffect`.
- In Next.js 15+, `params`, `searchParams`, `cookies()` and `headers()` are async: always `await` them.
- Mutations go through Server Actions (`"use server"`) or `route.ts` handlers. Validate every input on the server and re-check auth inside the action.
- After a mutation, call `revalidatePath()` or `revalidateTag()` instead of forcing the whole route dynamic.
- Use `next/image` for images, `next/font` for fonts and `next/link` for internal links.
- Export `metadata` or `generateMetadata` from every page for title, description and Open Graph tags.
- Only variables prefixed `NEXT_PUBLIC_` reach the browser. Never put secrets in them.
- In Next.js 16, `middleware.ts` is renamed `proxy.ts`. Use whichever file the project already has.
---
applyTo: "**/*.css,**/*.tsx,**/*.vue,**/*.svelte,**/*.astro,**/*.html,**/*.blade.php,**/*.erb"
---
# Tailwind CSS v4
- Tailwind v4 is configured in CSS: `@import "tailwindcss";` plus `@theme { ... }` for design tokens. Do not create a `tailwind.config.js` unless the project already has one.
- Use theme tokens (colors, spacing) instead of arbitrary values like `w-[37px]`.
- Build responsive layouts mobile-first with `sm:`, `md:`, `lg:` prefixes.
- Extract repeated class lists into components, not `@apply` chains.
- Support dark mode with the `dark:` variant when the project uses it.
---
applyTo: "firestore.rules,functions/**,**/firebase/**"
---
# Firebase
- Firebase web config is public by design; security comes from Firestore/Storage Security Rules. Never ship `allow read, write: if true`.
- Every collection needs rules that check `request.auth` and validate the written fields.
- Admin SDK credentials are server-only (Cloud Functions or your backend).
- Model Firestore data for your queries: avoid deeply nested data and unbounded arrays; denormalize deliberately.
- Test rules and functions against the Emulator Suite, not production.
---
trigger: always_on
---
# this project
A Next.js (App Router) + Tailwind CSS v4 + Firebase project.
Stack: Next.js (App Router), Tailwind CSS v4, Firebase.
## Commands
- Dev server: `npm run dev`
- Production build (also type-checks): `npm run build`
- Lint: `npm run lint`
- Local emulators: `firebase emulators:start`
- Deploy rules only: `firebase deploy --only firestore:rules`
## How to work in this repo
- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.
---
trigger: glob
globs: app/**/*.tsx, app/**/*.ts, src/**/*.tsx, src/**/*.ts
---
# Next.js (App Router)
- Check the Next.js major version in `package.json` before using an API; follow the docs for that version.
- Components are Server Components by default. Add `"use client"` only to the smallest leaf component that needs state, effects, or browser APIs.
- Fetch data in Server Components or Server Actions, not in `useEffect`.
- In Next.js 15+, `params`, `searchParams`, `cookies()` and `headers()` are async: always `await` them.
- Mutations go through Server Actions (`"use server"`) or `route.ts` handlers. Validate every input on the server and re-check auth inside the action.
- After a mutation, call `revalidatePath()` or `revalidateTag()` instead of forcing the whole route dynamic.
- Use `next/image` for images, `next/font` for fonts and `next/link` for internal links.
- Export `metadata` or `generateMetadata` from every page for title, description and Open Graph tags.
- Only variables prefixed `NEXT_PUBLIC_` reach the browser. Never put secrets in them.
- In Next.js 16, `middleware.ts` is renamed `proxy.ts`. Use whichever file the project already has.
---
trigger: glob
globs: **/*.css, **/*.tsx, **/*.vue, **/*.svelte, **/*.astro, **/*.html, **/*.blade.php, **/*.erb
---
# Tailwind CSS v4
- Tailwind v4 is configured in CSS: `@import "tailwindcss";` plus `@theme { ... }` for design tokens. Do not create a `tailwind.config.js` unless the project already has one.
- Use theme tokens (colors, spacing) instead of arbitrary values like `w-[37px]`.
- Build responsive layouts mobile-first with `sm:`, `md:`, `lg:` prefixes.
- Extract repeated class lists into components, not `@apply` chains.
- Support dark mode with the `dark:` variant when the project uses it.
---
trigger: glob
globs: firestore.rules, functions/**, **/firebase/**
---
# Firebase
- Firebase web config is public by design; security comes from Firestore/Storage Security Rules. Never ship `allow read, write: if true`.
- Every collection needs rules that check `request.auth` and validate the written fields.
- Admin SDK credentials are server-only (Cloud Functions or your backend).
- Model Firestore data for your queries: avoid deeply nested data and unbounded arrays; denormalize deliberately.
- Test rules and functions against the Emulator Suite, not production.
# GEMINI.md - this project
Project context for Gemini CLI.
## Project
A Next.js (App Router) + Tailwind CSS v4 + Firebase project.
Stack: Next.js (App Router), Tailwind CSS v4, Firebase.
## Commands
- Dev server: `npm run dev`
- Production build (also type-checks): `npm run build`
- Lint: `npm run lint`
- Local emulators: `firebase emulators:start`
- Deploy rules only: `firebase deploy --only firestore:rules`
## Project structure
- `app/` holds routes: `page.tsx`, `layout.tsx`, `loading.tsx`, `error.tsx`, `route.ts` for API handlers.
- Shared UI in `components/`, server-only helpers in `lib/` (mark them with `import "server-only"`).
## How to work in this repo
- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.
## Next.js (App Router)
- Check the Next.js major version in `package.json` before using an API; follow the docs for that version.
- Components are Server Components by default. Add `"use client"` only to the smallest leaf component that needs state, effects, or browser APIs.
- Fetch data in Server Components or Server Actions, not in `useEffect`.
- In Next.js 15+, `params`, `searchParams`, `cookies()` and `headers()` are async: always `await` them.
- Mutations go through Server Actions (`"use server"`) or `route.ts` handlers. Validate every input on the server and re-check auth inside the action.
- After a mutation, call `revalidatePath()` or `revalidateTag()` instead of forcing the whole route dynamic.
- Use `next/image` for images, `next/font` for fonts and `next/link` for internal links.
- Export `metadata` or `generateMetadata` from every page for title, description and Open Graph tags.
- Only variables prefixed `NEXT_PUBLIC_` reach the browser. Never put secrets in them.
- In Next.js 16, `middleware.ts` is renamed `proxy.ts`. Use whichever file the project already has.
## Tailwind CSS v4
- Tailwind v4 is configured in CSS: `@import "tailwindcss";` plus `@theme { ... }` for design tokens. Do not create a `tailwind.config.js` unless the project already has one.
- Use theme tokens (colors, spacing) instead of arbitrary values like `w-[37px]`.
- Build responsive layouts mobile-first with `sm:`, `md:`, `lg:` prefixes.
- Extract repeated class lists into components, not `@apply` chains.
- Support dark mode with the `dark:` variant when the project uses it.
## Firebase
- Firebase web config is public by design; security comes from Firestore/Storage Security Rules. Never ship `allow read, write: if true`.
- Every collection needs rules that check `request.auth` and validate the written fields.
- Admin SDK credentials are server-only (Cloud Functions or your backend).
- Model Firestore data for your queries: avoid deeply nested data and unbounded arrays; denormalize deliberately.
- Test rules and functions against the Emulator Suite, not production.
## Avoid
- Do not add `"use client"` to layouts or pages just to silence an error; move the interactive part into a child component.
- Do not use the Pages Router (`pages/`) APIs such as `getServerSideProps` in an App Router project.
## Reference docs
- [Next.js docs](https://nextjs.org/docs)
- [Tailwind CSS docs](https://tailwindcss.com/docs)
- [Firebase docs](https://firebase.google.com/docs)
Commands your agent should run
| Task | Command |
|---|---|
| Dev server | npm run dev |
| Production build (also type-checks) | npm run build |
| Lint | npm run lint |
| Local emulators | firebase emulators:start |
| Deploy rules only | firebase deploy --only firestore:rules |
What the rules cover
Next.js (App Router)
Next.js App Router with React Server Components and TypeScript. Scoped to app/**/*.tsx, app/**/*.ts, src/**/*.tsx, src/**/*.ts in Cursor, Copilot and Windsurf.
- Check the Next.js major version in
package.jsonbefore using an API; follow the docs for that version. - Components are Server Components by default. Add
"use client"only to the smallest leaf component that needs state, effects, or browser APIs. - Fetch data in Server Components or Server Actions, not in
useEffect. - In Next.js 15+,
params,searchParams,cookies()andheaders()are async: alwaysawaitthem. - Mutations go through Server Actions (
"use server") orroute.tshandlers. Validate every input on the server and re-check auth inside the action. - After a mutation, call
revalidatePath()orrevalidateTag()instead of forcing the whole route dynamic. - Use
next/imagefor images,next/fontfor fonts andnext/linkfor internal links. - Export
metadataorgenerateMetadatafrom every page for title, description and Open Graph tags. - Only variables prefixed
NEXT_PUBLIC_reach the browser. Never put secrets in them. - In Next.js 16,
middleware.tsis renamedproxy.ts. Use whichever file the project already has.
Source docs: Next.js docs
Tailwind CSS v4
Utility-first styling with Tailwind CSS v4. Scoped to **/*.css, **/*.tsx, **/*.vue, **/*.svelte, **/*.astro, **/*.html, **/*.blade.php, **/*.erb in Cursor, Copilot and Windsurf.
- Tailwind v4 is configured in CSS:
@import "tailwindcss";plus@theme { ... }for design tokens. Do not create atailwind.config.jsunless the project already has one. - Use theme tokens (colors, spacing) instead of arbitrary values like
w-[37px]. - Build responsive layouts mobile-first with
sm:,md:,lg:prefixes. - Extract repeated class lists into components, not
@applychains. - Support dark mode with the
dark:variant when the project uses it.
Source docs: Tailwind CSS docs
Firebase
Firebase Auth, Firestore and Cloud Functions. Scoped to firestore.rules, functions/**, **/firebase/** in Cursor, Copilot and Windsurf.
- Firebase web config is public by design; security comes from Firestore/Storage Security Rules. Never ship
allow read, write: if true. - Every collection needs rules that check
request.authand validate the written fields. - Admin SDK credentials are server-only (Cloud Functions or your backend).
- Model Firestore data for your queries: avoid deeply nested data and unbounded arrays; denormalize deliberately.
- Test rules and functions against the Emulator Suite, not production.
Source docs: Firebase docs
How to install
- Copy
AGENTS.mdto your repo root. That covers Codex, Cursor, GitHub Copilot and most other agents. - Using Claude Code? Add a
CLAUDE.mdwith the single line@AGENTS.md, or use the standalone CLAUDE.md tab above. - Want rules that only load for certain files in Cursor? Add the
.cursor/rules/*.mdcfiles. - Commit the files so your whole team (and every agent) shares them.
FAQ
Where do I put the AGENTS.md for Next.js (App Router) + Tailwind CSS v4 + Firebase?
Save it as AGENTS.md in the root of your repository, next to your main config file. Codex, Cursor and GitHub Copilot pick it up automatically. For Claude Code, add a CLAUDE.md containing @AGENTS.md (or use the standalone CLAUDE.md on this page).
What is the most common mistake AI agents make with Next.js (App Router)?
Agents leave Firestore in test mode (allow read, write: if true) or import the Admin SDK into client bundles.
Which commands should the agent run to check its work?
For this stack: npm run dev, npm run build, npm run lint, firebase emulators:start. They are listed in the generated files so the agent runs them before finishing a task.
Do these Next.js (App Router) + Tailwind CSS v4 + Firebase rules work with Cursor and Claude Code?
Yes. This page includes the same rules as AGENTS.md, CLAUDE.md, Cursor .mdc project rules, a legacy .cursorrules file, GitHub Copilot instructions, Windsurf rules and GEMINI.md.
Can I customise these rules?
Yes. Open this stack in the generator to add or remove libraries, set your project name and package manager, switch beginner explanations on, and download everything as a zip.
Related stacks
Next.js (App Router) + Tailwind CSS v4 + shadcn/ui + Supabase + Zod validation
The default vibe-coding SaaS stack: Next.js App Router, Supabase for auth and Postgres, Tailwind and shadcn/ui for the interface.
Next.js (App Router) + Tailwind CSS v4
A plain Next.js + TypeScript + Tailwind v4 starter, the most common front-end setup in 2026.
Next.js (App Router) + Tailwind CSS v4 + Prisma + Stripe payments + Zod validation
A paid SaaS on Next.js with Prisma and Stripe subscriptions.
Next.js (App Router) + Tailwind CSS v4 + Drizzle ORM + Clerk auth + Zod validation
Next.js with Clerk for auth and Drizzle ORM on Postgres: fast to build, type-safe end to end.
Next.js (App Router) + Tailwind CSS v4 + shadcn/ui + Vercel AI SDK + Zod validation
Build an AI chat app or agent UI with Next.js and the Vercel AI SDK.
Next.js (App Router) + Tailwind CSS v4 + Supabase + Stripe payments + Zod validation + Vitest
The full indie-hacker SaaS kit: auth, database, payments and tests.