Django + Tailwind + pytest rules for AI coding agents
Full stack: Python + Django + Tailwind CSS v4 + pytest
Ready-to-commit rules for Python + Django + Tailwind CSS v4 + pytest 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. Server-rendered Django with Tailwind styling.
Last reviewed 2026-10-21 · Customise in the generator · Raw: AGENTS.md, CLAUDE.md
The mistake agents make most on this stack
Validation gets done by hand on `request.POST` instead of forms.
Generated files
AGENTS.md
# AGENTS.md - this project
Instructions for AI coding agents working in this repository.
## Project
A Python + Django + Tailwind CSS v4 + pytest project.
Stack: Python + Django, Tailwind CSS v4, pytest.
## Commands
- Dev server: `python manage.py runserver`
- Create migrations: `python manage.py makemigrations`
- Apply migrations: `python manage.py migrate`
- Tests: `python manage.py test`
- Tests: `uv run pytest -q`
## Project structure
- One Django app per domain. Models, views, urls, admin and tests live inside each app.
## 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.
## Python + Django
- Follow Django conventions first: fat models/managers, thin views.
- Every model change needs a migration. Never edit a migration that has already been applied in a shared environment.
- Avoid N+1 queries: use `select_related` for foreign keys and `prefetch_related` for reverse/many-to-many relations.
- Validate input with forms or DRF serializers, never by reading `request.POST` directly.
- Read `SECRET_KEY`, database URLs and API keys from env vars. `DEBUG` must be off in production.
- Use the ORM; if raw SQL is unavoidable, always pass parameters, never format strings.
- Keep CSRF protection on for all forms.
## 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.
## pytest
- Tests live in `tests/` named `test_*.py`. Use plain `assert`.
- Share setup with fixtures in `conftest.py`; use `@pytest.mark.parametrize` for input tables.
- Mock external services (HTTP, LLM APIs, payment providers); tests must not hit the network.
- Every bug fix adds a regression test.
## Reference docs
- [Django docs](https://docs.djangoproject.com)
- [Tailwind CSS docs](https://tailwindcss.com/docs)
- [pytest docs](https://docs.pytest.org)
CLAUDE.md
# CLAUDE.md - this project
Project instructions for Claude Code.
## Project
A Python + Django + Tailwind CSS v4 + pytest project.
Stack: Python + Django, Tailwind CSS v4, pytest.
## Commands
- Dev server: `python manage.py runserver`
- Create migrations: `python manage.py makemigrations`
- Apply migrations: `python manage.py migrate`
- Tests: `python manage.py test`
- Tests: `uv run pytest -q`
## Project structure
- One Django app per domain. Models, views, urls, admin and tests live inside each app.
## 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.
## Python + Django
- Follow Django conventions first: fat models/managers, thin views.
- Every model change needs a migration. Never edit a migration that has already been applied in a shared environment.
- Avoid N+1 queries: use `select_related` for foreign keys and `prefetch_related` for reverse/many-to-many relations.
- Validate input with forms or DRF serializers, never by reading `request.POST` directly.
- Read `SECRET_KEY`, database URLs and API keys from env vars. `DEBUG` must be off in production.
- Use the ORM; if raw SQL is unavoidable, always pass parameters, never format strings.
- Keep CSRF protection on for all forms.
## 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.
## pytest
- Tests live in `tests/` named `test_*.py`. Use plain `assert`.
- Share setup with fixtures in `conftest.py`; use `@pytest.mark.parametrize` for input tables.
- Mock external services (HTTP, LLM APIs, payment providers); tests must not hit the network.
- Every bug fix adds a regression test.
## Reference docs
- [Django docs](https://docs.djangoproject.com)
- [Tailwind CSS docs](https://tailwindcss.com/docs)
- [pytest docs](https://docs.pytest.org)
.cursor/rules/project.mdc
---
description: "Core rules for this project"
alwaysApply: true
---
# this project
A Python + Django + Tailwind CSS v4 + pytest project.
Stack: Python + Django, Tailwind CSS v4, pytest.
## Commands
- Dev server: `python manage.py runserver`
- Create migrations: `python manage.py makemigrations`
- Apply migrations: `python manage.py migrate`
- Tests: `python manage.py test`
- Tests: `uv run pytest -q`
## 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.
.cursor/rules/django.mdc
---
description: "Python + Django conventions: Django web app or API."
globs: **/*.py, **/templates/**/*.html
alwaysApply: false
---
# Python + Django
- Follow Django conventions first: fat models/managers, thin views.
- Every model change needs a migration. Never edit a migration that has already been applied in a shared environment.
- Avoid N+1 queries: use `select_related` for foreign keys and `prefetch_related` for reverse/many-to-many relations.
- Validate input with forms or DRF serializers, never by reading `request.POST` directly.
- Read `SECRET_KEY`, database URLs and API keys from env vars. `DEBUG` must be off in production.
- Use the ORM; if raw SQL is unavoidable, always pass parameters, never format strings.
- Keep CSRF protection on for all forms.
Docs: https://docs.djangoproject.com
.cursor/rules/tailwind.mdc
---
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
.cursor/rules/pytest.mdc
---
description: "pytest conventions: Python tests with pytest."
globs: tests/**/*.py, **/test_*.py
alwaysApply: false
---
# pytest
- Tests live in `tests/` named `test_*.py`. Use plain `assert`.
- Share setup with fixtures in `conftest.py`; use `@pytest.mark.parametrize` for input tables.
- Mock external services (HTTP, LLM APIs, payment providers); tests must not hit the network.
- Every bug fix adds a regression test.
Docs: https://docs.pytest.org
.cursorrules
# Cursor rules - this project
You are an expert Python + Django, Tailwind CSS v4, pytest engineer working on this codebase. Follow these rules.
## Project
A Python + Django + Tailwind CSS v4 + pytest project.
Stack: Python + Django, Tailwind CSS v4, pytest.
## Commands
- Dev server: `python manage.py runserver`
- Create migrations: `python manage.py makemigrations`
- Apply migrations: `python manage.py migrate`
- Tests: `python manage.py test`
- Tests: `uv run pytest -q`
## Project structure
- One Django app per domain. Models, views, urls, admin and tests live inside each app.
## 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.
## Python + Django
- Follow Django conventions first: fat models/managers, thin views.
- Every model change needs a migration. Never edit a migration that has already been applied in a shared environment.
- Avoid N+1 queries: use `select_related` for foreign keys and `prefetch_related` for reverse/many-to-many relations.
- Validate input with forms or DRF serializers, never by reading `request.POST` directly.
- Read `SECRET_KEY`, database URLs and API keys from env vars. `DEBUG` must be off in production.
- Use the ORM; if raw SQL is unavoidable, always pass parameters, never format strings.
- Keep CSRF protection on for all forms.
## 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.
## pytest
- Tests live in `tests/` named `test_*.py`. Use plain `assert`.
- Share setup with fixtures in `conftest.py`; use `@pytest.mark.parametrize` for input tables.
- Mock external services (HTTP, LLM APIs, payment providers); tests must not hit the network.
- Every bug fix adds a regression test.
## Reference docs
- [Django docs](https://docs.djangoproject.com)
- [Tailwind CSS docs](https://tailwindcss.com/docs)
- [pytest docs](https://docs.pytest.org)
.github/copilot-instructions.md
# Copilot instructions - this project
A Python + Django + Tailwind CSS v4 + pytest project.
Stack: Python + Django, Tailwind CSS v4, pytest.
## Commands
- Dev server: `python manage.py runserver`
- Create migrations: `python manage.py makemigrations`
- Apply migrations: `python manage.py migrate`
- Tests: `python manage.py test`
- Tests: `uv run pytest -q`
## 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.
.github/instructions/django.instructions.md
---
applyTo: "**/*.py,**/templates/**/*.html"
---
# Python + Django
- Follow Django conventions first: fat models/managers, thin views.
- Every model change needs a migration. Never edit a migration that has already been applied in a shared environment.
- Avoid N+1 queries: use `select_related` for foreign keys and `prefetch_related` for reverse/many-to-many relations.
- Validate input with forms or DRF serializers, never by reading `request.POST` directly.
- Read `SECRET_KEY`, database URLs and API keys from env vars. `DEBUG` must be off in production.
- Use the ORM; if raw SQL is unavoidable, always pass parameters, never format strings.
- Keep CSRF protection on for all forms.
.github/instructions/tailwind.instructions.md
---
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.
.github/instructions/pytest.instructions.md
---
applyTo: "tests/**/*.py,**/test_*.py"
---
# pytest
- Tests live in `tests/` named `test_*.py`. Use plain `assert`.
- Share setup with fixtures in `conftest.py`; use `@pytest.mark.parametrize` for input tables.
- Mock external services (HTTP, LLM APIs, payment providers); tests must not hit the network.
- Every bug fix adds a regression test.
.windsurf/rules/project.md
---
trigger: always_on
---
# this project
A Python + Django + Tailwind CSS v4 + pytest project.
Stack: Python + Django, Tailwind CSS v4, pytest.
## Commands
- Dev server: `python manage.py runserver`
- Create migrations: `python manage.py makemigrations`
- Apply migrations: `python manage.py migrate`
- Tests: `python manage.py test`
- Tests: `uv run pytest -q`
## 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.
.windsurf/rules/django.md
---
trigger: glob
globs: **/*.py, **/templates/**/*.html
---
# Python + Django
- Follow Django conventions first: fat models/managers, thin views.
- Every model change needs a migration. Never edit a migration that has already been applied in a shared environment.
- Avoid N+1 queries: use `select_related` for foreign keys and `prefetch_related` for reverse/many-to-many relations.
- Validate input with forms or DRF serializers, never by reading `request.POST` directly.
- Read `SECRET_KEY`, database URLs and API keys from env vars. `DEBUG` must be off in production.
- Use the ORM; if raw SQL is unavoidable, always pass parameters, never format strings.
- Keep CSRF protection on for all forms.
.windsurf/rules/tailwind.md
---
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.
.windsurf/rules/pytest.md
---
trigger: glob
globs: tests/**/*.py, **/test_*.py
---
# pytest
- Tests live in `tests/` named `test_*.py`. Use plain `assert`.
- Share setup with fixtures in `conftest.py`; use `@pytest.mark.parametrize` for input tables.
- Mock external services (HTTP, LLM APIs, payment providers); tests must not hit the network.
- Every bug fix adds a regression test.
GEMINI.md
# GEMINI.md - this project
Project context for Gemini CLI.
## Project
A Python + Django + Tailwind CSS v4 + pytest project.
Stack: Python + Django, Tailwind CSS v4, pytest.
## Commands
- Dev server: `python manage.py runserver`
- Create migrations: `python manage.py makemigrations`
- Apply migrations: `python manage.py migrate`
- Tests: `python manage.py test`
- Tests: `uv run pytest -q`
## Project structure
- One Django app per domain. Models, views, urls, admin and tests live inside each app.
## 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.
## Python + Django
- Follow Django conventions first: fat models/managers, thin views.
- Every model change needs a migration. Never edit a migration that has already been applied in a shared environment.
- Avoid N+1 queries: use `select_related` for foreign keys and `prefetch_related` for reverse/many-to-many relations.
- Validate input with forms or DRF serializers, never by reading `request.POST` directly.
- Read `SECRET_KEY`, database URLs and API keys from env vars. `DEBUG` must be off in production.
- Use the ORM; if raw SQL is unavoidable, always pass parameters, never format strings.
- Keep CSRF protection on for all forms.
## 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.
## pytest
- Tests live in `tests/` named `test_*.py`. Use plain `assert`.
- Share setup with fixtures in `conftest.py`; use `@pytest.mark.parametrize` for input tables.
- Mock external services (HTTP, LLM APIs, payment providers); tests must not hit the network.
- Every bug fix adds a regression test.
## Reference docs
- [Django docs](https://docs.djangoproject.com)
- [Tailwind CSS docs](https://tailwindcss.com/docs)
- [pytest docs](https://docs.pytest.org)
Commands your agent should run
| Task | Command |
|---|---|
| Dev server | python manage.py runserver |
| Create migrations | python manage.py makemigrations |
| Apply migrations | python manage.py migrate |
| Tests | python manage.py test |
| Tests | uv run pytest -q |
What the rules cover
Python + Django
Django web app or API. Scoped to **/*.py, **/templates/**/*.html in Cursor, Copilot and Windsurf.
- Follow Django conventions first: fat models/managers, thin views.
- Every model change needs a migration. Never edit a migration that has already been applied in a shared environment.
- Avoid N+1 queries: use
select_relatedfor foreign keys andprefetch_relatedfor reverse/many-to-many relations. - Validate input with forms or DRF serializers, never by reading
request.POSTdirectly. - Read
SECRET_KEY, database URLs and API keys from env vars.DEBUGmust be off in production. - Use the ORM; if raw SQL is unavoidable, always pass parameters, never format strings.
- Keep CSRF protection on for all forms.
Source docs: Django 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
pytest
Python tests with pytest. Scoped to tests/**/*.py, **/test_*.py in Cursor, Copilot and Windsurf.
- Tests live in
tests/namedtest_*.py. Use plainassert. - Share setup with fixtures in
conftest.py; use@pytest.mark.parametrizefor input tables. - Mock external services (HTTP, LLM APIs, payment providers); tests must not hit the network.
- Every bug fix adds a regression test.
Source docs: pytest 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 Python + Django + Tailwind CSS v4 + pytest?
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 Python + Django?
Validation gets done by hand on request.POST instead of forms.
Which commands should the agent run to check its work?
For this stack: python manage.py runserver, python manage.py makemigrations, python manage.py migrate, python manage.py test. They are listed in the generated files so the agent runs them before finishing a task.
Do these Python + Django + Tailwind CSS v4 + pytest 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
Python + Django + pytest + Docker
A Django app tested with pytest.
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.