React + Vite + Supabase + Zustand rules for AI coding agents
Full stack: React + Vite + Tailwind CSS v4 + Supabase + Zustand
Ready-to-commit rules for React + Vite + Tailwind CSS v4 + Supabase + Zustand 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. A client-only React app talking straight to Supabase, popular for quick prototypes and internal tools.
Last reviewed 2026-10-21 · Customise in the generator · Raw: AGENTS.md, CLAUDE.md
With no server, RLS is the only thing protecting your data, and agents forget to add it.
Generated files
# AGENTS.md - this project
Instructions for AI coding agents working in this repository.
## Project
A React + Vite + Tailwind CSS v4 + Supabase + Zustand project.
Stack: React + Vite, Tailwind CSS v4, Supabase, Zustand.
## Commands
- Dev server: `npm run dev`
- Build: `npm run build`
- Type-check: `npx tsc --noEmit`
- Lint: `npm run lint`
- New migration: `npx supabase migration new <name>`
- Generate TS types: `npx supabase gen types typescript --local > types/supabase.ts`
## Project structure
- Features live in `src/features/<name>/` with their components, hooks and tests together.
- Shared UI in `src/components/`, hooks in `src/hooks/`.
## 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.
## React + Vite
- Function components and hooks only. No class components.
- Follow the Rules of Hooks: call hooks at the top level, never inside conditions or loops.
- Derive values during render instead of syncing them into state with `useEffect`.
- Every list item needs a stable `key` from the data, never the array index if the list can change order.
- Type component props with an exported `Props` type or interface. No `any`.
- Env vars must start with `VITE_` to reach the client, which also means they are public. Never put secrets in them.
- Lazy-load heavy routes with `React.lazy` and `Suspense`.
## 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.
## Supabase
- Enable Row Level Security on every table and write explicit policies. No table ships without RLS.
- The anon/publishable key is public. The `service_role`/secret key bypasses RLS: use it only in trusted server code, never in the client.
- Change the schema with migration files in `supabase/migrations/`, not by clicking in the dashboard.
- On the server, verify the user with `supabase.auth.getUser()` (or `getClaims()`); do not trust `getSession()` alone for authorization.
- In SSR frameworks use `@supabase/ssr` (`createServerClient` / `createBrowserClient`), not the deprecated auth-helpers packages.
- Regenerate database types after each migration and type the client with them.
## Zustand
- Keep stores small and split by domain.
- Select only what a component needs (`useStore((s) => s.count)`) to avoid unnecessary re-renders.
- Use Zustand for client/UI state only. Server data belongs in the data-fetching layer.
## Avoid
- Do not reach for global state for data that only one component tree uses.
## Reference docs
- [React docs](https://react.dev)
- [Vite docs](https://vite.dev/guide/)
- [Tailwind CSS docs](https://tailwindcss.com/docs)
- [Supabase docs](https://supabase.com/docs)
- [Zustand docs](https://zustand.docs.pmnd.rs)
# CLAUDE.md - this project
Project instructions for Claude Code.
## Project
A React + Vite + Tailwind CSS v4 + Supabase + Zustand project.
Stack: React + Vite, Tailwind CSS v4, Supabase, Zustand.
## Commands
- Dev server: `npm run dev`
- Build: `npm run build`
- Type-check: `npx tsc --noEmit`
- Lint: `npm run lint`
- New migration: `npx supabase migration new <name>`
- Generate TS types: `npx supabase gen types typescript --local > types/supabase.ts`
## Project structure
- Features live in `src/features/<name>/` with their components, hooks and tests together.
- Shared UI in `src/components/`, hooks in `src/hooks/`.
## 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.
## React + Vite
- Function components and hooks only. No class components.
- Follow the Rules of Hooks: call hooks at the top level, never inside conditions or loops.
- Derive values during render instead of syncing them into state with `useEffect`.
- Every list item needs a stable `key` from the data, never the array index if the list can change order.
- Type component props with an exported `Props` type or interface. No `any`.
- Env vars must start with `VITE_` to reach the client, which also means they are public. Never put secrets in them.
- Lazy-load heavy routes with `React.lazy` and `Suspense`.
## 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.
## Supabase
- Enable Row Level Security on every table and write explicit policies. No table ships without RLS.
- The anon/publishable key is public. The `service_role`/secret key bypasses RLS: use it only in trusted server code, never in the client.
- Change the schema with migration files in `supabase/migrations/`, not by clicking in the dashboard.
- On the server, verify the user with `supabase.auth.getUser()` (or `getClaims()`); do not trust `getSession()` alone for authorization.
- In SSR frameworks use `@supabase/ssr` (`createServerClient` / `createBrowserClient`), not the deprecated auth-helpers packages.
- Regenerate database types after each migration and type the client with them.
## Zustand
- Keep stores small and split by domain.
- Select only what a component needs (`useStore((s) => s.count)`) to avoid unnecessary re-renders.
- Use Zustand for client/UI state only. Server data belongs in the data-fetching layer.
## Avoid
- Do not reach for global state for data that only one component tree uses.
## Reference docs
- [React docs](https://react.dev)
- [Vite docs](https://vite.dev/guide/)
- [Tailwind CSS docs](https://tailwindcss.com/docs)
- [Supabase docs](https://supabase.com/docs)
- [Zustand docs](https://zustand.docs.pmnd.rs)
---
description: "Core rules for this project"
alwaysApply: true
---
# this project
A React + Vite + Tailwind CSS v4 + Supabase + Zustand project.
Stack: React + Vite, Tailwind CSS v4, Supabase, Zustand.
## Commands
- Dev server: `npm run dev`
- Build: `npm run build`
- Type-check: `npx tsc --noEmit`
- Lint: `npm run lint`
- New migration: `npx supabase migration new <name>`
- Generate TS types: `npx supabase gen types typescript --local > types/supabase.ts`
## 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: "React + Vite conventions: Single-page React app built with Vite and TypeScript."
globs: src/**/*.tsx, src/**/*.ts
alwaysApply: false
---
# React + Vite
- Function components and hooks only. No class components.
- Follow the Rules of Hooks: call hooks at the top level, never inside conditions or loops.
- Derive values during render instead of syncing them into state with `useEffect`.
- Every list item needs a stable `key` from the data, never the array index if the list can change order.
- Type component props with an exported `Props` type or interface. No `any`.
- Env vars must start with `VITE_` to reach the client, which also means they are public. Never put secrets in them.
- Lazy-load heavy routes with `React.lazy` and `Suspense`.
## Avoid
- Do not reach for global state for data that only one component tree uses.
Docs: https://react.dev, https://vite.dev/guide/
---
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: "Supabase conventions: Postgres, auth and storage from Supabase."
globs: supabase/**, **/supabase/**/*.ts, lib/supabase/**
alwaysApply: false
---
# Supabase
- Enable Row Level Security on every table and write explicit policies. No table ships without RLS.
- The anon/publishable key is public. The `service_role`/secret key bypasses RLS: use it only in trusted server code, never in the client.
- Change the schema with migration files in `supabase/migrations/`, not by clicking in the dashboard.
- On the server, verify the user with `supabase.auth.getUser()` (or `getClaims()`); do not trust `getSession()` alone for authorization.
- In SSR frameworks use `@supabase/ssr` (`createServerClient` / `createBrowserClient`), not the deprecated auth-helpers packages.
- Regenerate database types after each migration and type the client with them.
Docs: https://supabase.com/docs
---
description: "Zustand conventions: Lightweight client state with Zustand."
globs: **/store/**/*.ts, **/stores/**/*.ts
alwaysApply: false
---
# Zustand
- Keep stores small and split by domain.
- Select only what a component needs (`useStore((s) => s.count)`) to avoid unnecessary re-renders.
- Use Zustand for client/UI state only. Server data belongs in the data-fetching layer.
Docs: https://zustand.docs.pmnd.rs
# Cursor rules - this project
You are an expert React + Vite, Tailwind CSS v4, Supabase, Zustand engineer working on this codebase. Follow these rules.
## Project
A React + Vite + Tailwind CSS v4 + Supabase + Zustand project.
Stack: React + Vite, Tailwind CSS v4, Supabase, Zustand.
## Commands
- Dev server: `npm run dev`
- Build: `npm run build`
- Type-check: `npx tsc --noEmit`
- Lint: `npm run lint`
- New migration: `npx supabase migration new <name>`
- Generate TS types: `npx supabase gen types typescript --local > types/supabase.ts`
## Project structure
- Features live in `src/features/<name>/` with their components, hooks and tests together.
- Shared UI in `src/components/`, hooks in `src/hooks/`.
## 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.
## React + Vite
- Function components and hooks only. No class components.
- Follow the Rules of Hooks: call hooks at the top level, never inside conditions or loops.
- Derive values during render instead of syncing them into state with `useEffect`.
- Every list item needs a stable `key` from the data, never the array index if the list can change order.
- Type component props with an exported `Props` type or interface. No `any`.
- Env vars must start with `VITE_` to reach the client, which also means they are public. Never put secrets in them.
- Lazy-load heavy routes with `React.lazy` and `Suspense`.
## 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.
## Supabase
- Enable Row Level Security on every table and write explicit policies. No table ships without RLS.
- The anon/publishable key is public. The `service_role`/secret key bypasses RLS: use it only in trusted server code, never in the client.
- Change the schema with migration files in `supabase/migrations/`, not by clicking in the dashboard.
- On the server, verify the user with `supabase.auth.getUser()` (or `getClaims()`); do not trust `getSession()` alone for authorization.
- In SSR frameworks use `@supabase/ssr` (`createServerClient` / `createBrowserClient`), not the deprecated auth-helpers packages.
- Regenerate database types after each migration and type the client with them.
## Zustand
- Keep stores small and split by domain.
- Select only what a component needs (`useStore((s) => s.count)`) to avoid unnecessary re-renders.
- Use Zustand for client/UI state only. Server data belongs in the data-fetching layer.
## Avoid
- Do not reach for global state for data that only one component tree uses.
## Reference docs
- [React docs](https://react.dev)
- [Vite docs](https://vite.dev/guide/)
- [Tailwind CSS docs](https://tailwindcss.com/docs)
- [Supabase docs](https://supabase.com/docs)
- [Zustand docs](https://zustand.docs.pmnd.rs)
# Copilot instructions - this project
A React + Vite + Tailwind CSS v4 + Supabase + Zustand project.
Stack: React + Vite, Tailwind CSS v4, Supabase, Zustand.
## Commands
- Dev server: `npm run dev`
- Build: `npm run build`
- Type-check: `npx tsc --noEmit`
- Lint: `npm run lint`
- New migration: `npx supabase migration new <name>`
- Generate TS types: `npx supabase gen types typescript --local > types/supabase.ts`
## 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: "src/**/*.tsx,src/**/*.ts"
---
# React + Vite
- Function components and hooks only. No class components.
- Follow the Rules of Hooks: call hooks at the top level, never inside conditions or loops.
- Derive values during render instead of syncing them into state with `useEffect`.
- Every list item needs a stable `key` from the data, never the array index if the list can change order.
- Type component props with an exported `Props` type or interface. No `any`.
- Env vars must start with `VITE_` to reach the client, which also means they are public. Never put secrets in them.
- Lazy-load heavy routes with `React.lazy` and `Suspense`.
---
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: "supabase/**,**/supabase/**/*.ts,lib/supabase/**"
---
# Supabase
- Enable Row Level Security on every table and write explicit policies. No table ships without RLS.
- The anon/publishable key is public. The `service_role`/secret key bypasses RLS: use it only in trusted server code, never in the client.
- Change the schema with migration files in `supabase/migrations/`, not by clicking in the dashboard.
- On the server, verify the user with `supabase.auth.getUser()` (or `getClaims()`); do not trust `getSession()` alone for authorization.
- In SSR frameworks use `@supabase/ssr` (`createServerClient` / `createBrowserClient`), not the deprecated auth-helpers packages.
- Regenerate database types after each migration and type the client with them.
---
applyTo: "**/store/**/*.ts,**/stores/**/*.ts"
---
# Zustand
- Keep stores small and split by domain.
- Select only what a component needs (`useStore((s) => s.count)`) to avoid unnecessary re-renders.
- Use Zustand for client/UI state only. Server data belongs in the data-fetching layer.
---
trigger: always_on
---
# this project
A React + Vite + Tailwind CSS v4 + Supabase + Zustand project.
Stack: React + Vite, Tailwind CSS v4, Supabase, Zustand.
## Commands
- Dev server: `npm run dev`
- Build: `npm run build`
- Type-check: `npx tsc --noEmit`
- Lint: `npm run lint`
- New migration: `npx supabase migration new <name>`
- Generate TS types: `npx supabase gen types typescript --local > types/supabase.ts`
## 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: src/**/*.tsx, src/**/*.ts
---
# React + Vite
- Function components and hooks only. No class components.
- Follow the Rules of Hooks: call hooks at the top level, never inside conditions or loops.
- Derive values during render instead of syncing them into state with `useEffect`.
- Every list item needs a stable `key` from the data, never the array index if the list can change order.
- Type component props with an exported `Props` type or interface. No `any`.
- Env vars must start with `VITE_` to reach the client, which also means they are public. Never put secrets in them.
- Lazy-load heavy routes with `React.lazy` and `Suspense`.
---
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: supabase/**, **/supabase/**/*.ts, lib/supabase/**
---
# Supabase
- Enable Row Level Security on every table and write explicit policies. No table ships without RLS.
- The anon/publishable key is public. The `service_role`/secret key bypasses RLS: use it only in trusted server code, never in the client.
- Change the schema with migration files in `supabase/migrations/`, not by clicking in the dashboard.
- On the server, verify the user with `supabase.auth.getUser()` (or `getClaims()`); do not trust `getSession()` alone for authorization.
- In SSR frameworks use `@supabase/ssr` (`createServerClient` / `createBrowserClient`), not the deprecated auth-helpers packages.
- Regenerate database types after each migration and type the client with them.
---
trigger: glob
globs: **/store/**/*.ts, **/stores/**/*.ts
---
# Zustand
- Keep stores small and split by domain.
- Select only what a component needs (`useStore((s) => s.count)`) to avoid unnecessary re-renders.
- Use Zustand for client/UI state only. Server data belongs in the data-fetching layer.
# GEMINI.md - this project
Project context for Gemini CLI.
## Project
A React + Vite + Tailwind CSS v4 + Supabase + Zustand project.
Stack: React + Vite, Tailwind CSS v4, Supabase, Zustand.
## Commands
- Dev server: `npm run dev`
- Build: `npm run build`
- Type-check: `npx tsc --noEmit`
- Lint: `npm run lint`
- New migration: `npx supabase migration new <name>`
- Generate TS types: `npx supabase gen types typescript --local > types/supabase.ts`
## Project structure
- Features live in `src/features/<name>/` with their components, hooks and tests together.
- Shared UI in `src/components/`, hooks in `src/hooks/`.
## 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.
## React + Vite
- Function components and hooks only. No class components.
- Follow the Rules of Hooks: call hooks at the top level, never inside conditions or loops.
- Derive values during render instead of syncing them into state with `useEffect`.
- Every list item needs a stable `key` from the data, never the array index if the list can change order.
- Type component props with an exported `Props` type or interface. No `any`.
- Env vars must start with `VITE_` to reach the client, which also means they are public. Never put secrets in them.
- Lazy-load heavy routes with `React.lazy` and `Suspense`.
## 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.
## Supabase
- Enable Row Level Security on every table and write explicit policies. No table ships without RLS.
- The anon/publishable key is public. The `service_role`/secret key bypasses RLS: use it only in trusted server code, never in the client.
- Change the schema with migration files in `supabase/migrations/`, not by clicking in the dashboard.
- On the server, verify the user with `supabase.auth.getUser()` (or `getClaims()`); do not trust `getSession()` alone for authorization.
- In SSR frameworks use `@supabase/ssr` (`createServerClient` / `createBrowserClient`), not the deprecated auth-helpers packages.
- Regenerate database types after each migration and type the client with them.
## Zustand
- Keep stores small and split by domain.
- Select only what a component needs (`useStore((s) => s.count)`) to avoid unnecessary re-renders.
- Use Zustand for client/UI state only. Server data belongs in the data-fetching layer.
## Avoid
- Do not reach for global state for data that only one component tree uses.
## Reference docs
- [React docs](https://react.dev)
- [Vite docs](https://vite.dev/guide/)
- [Tailwind CSS docs](https://tailwindcss.com/docs)
- [Supabase docs](https://supabase.com/docs)
- [Zustand docs](https://zustand.docs.pmnd.rs)
Commands your agent should run
| Task | Command |
|---|---|
| Dev server | npm run dev |
| Build | npm run build |
| Type-check | npx tsc --noEmit |
| Lint | npm run lint |
| New migration | npx supabase migration new <name> |
| Generate TS types | npx supabase gen types typescript --local > types/supabase.ts |
What the rules cover
React + Vite
Single-page React app built with Vite and TypeScript. Scoped to src/**/*.tsx, src/**/*.ts in Cursor, Copilot and Windsurf.
- Function components and hooks only. No class components.
- Follow the Rules of Hooks: call hooks at the top level, never inside conditions or loops.
- Derive values during render instead of syncing them into state with
useEffect. - Every list item needs a stable
keyfrom the data, never the array index if the list can change order. - Type component props with an exported
Propstype or interface. Noany. - Env vars must start with
VITE_to reach the client, which also means they are public. Never put secrets in them. - Lazy-load heavy routes with
React.lazyandSuspense.
Source docs: React docs, Vite 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
Supabase
Postgres, auth and storage from Supabase. Scoped to supabase/**, **/supabase/**/*.ts, lib/supabase/** in Cursor, Copilot and Windsurf.
- Enable Row Level Security on every table and write explicit policies. No table ships without RLS.
- The anon/publishable key is public. The
service_role/secret key bypasses RLS: use it only in trusted server code, never in the client. - Change the schema with migration files in
supabase/migrations/, not by clicking in the dashboard. - On the server, verify the user with
supabase.auth.getUser()(orgetClaims()); do not trustgetSession()alone for authorization. - In SSR frameworks use
@supabase/ssr(createServerClient/createBrowserClient), not the deprecated auth-helpers packages. - Regenerate database types after each migration and type the client with them.
Source docs: Supabase docs
Zustand
Lightweight client state with Zustand. Scoped to **/store/**/*.ts, **/stores/**/*.ts in Cursor, Copilot and Windsurf.
- Keep stores small and split by domain.
- Select only what a component needs (
useStore((s) => s.count)) to avoid unnecessary re-renders. - Use Zustand for client/UI state only. Server data belongs in the data-fetching layer.
Source docs: Zustand 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 React + Vite + Tailwind CSS v4 + Supabase + Zustand?
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 React + Vite?
With no server, RLS is the only thing protecting your data, and agents forget to add it.
Which commands should the agent run to check its work?
For this stack: npm run dev, npm run build, npx tsc --noEmit, npm run lint. They are listed in the generated files so the agent runs them before finishing a task.
Do these React + Vite + Tailwind CSS v4 + Supabase + Zustand 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
React + Vite + Tailwind CSS v4 + TanStack Query + Vitest + Zod validation
A classic single-page app: React + Vite with TanStack Query for server data.
React + Vite + Tailwind CSS v4 + Firebase + Vitest
A React SPA on Firebase Auth and Firestore.
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 + Supabase + Stripe payments + Zod validation + Vitest
The full indie-hacker SaaS kit: auth, database, payments and tests.
SvelteKit (Svelte 5) + Tailwind CSS v4 + Supabase + Zod validation
SvelteKit with Svelte 5 runes, Tailwind and Supabase.
Nuxt (Vue 3) + Tailwind CSS v4 + Supabase
Nuxt with Supabase auth and Postgres.