# RulePaste

> Paste the rules your coding agent actually follows.

RulePaste writes a ready-to-paste rules file for Cursor, Claude Code, Windsurf, GitHub Copilot, and Codex. Pick your stack. No account and no API key.

RulePaste generates rules files from templates in the browser. It does not call a language model. The same choices always produce the same file. Stack pages are static and can be cited.

## Start here

- [Generator](https://rulepaste.com/): Pick tools and a stack, then copy or download the rules file.
- [What is a rules file?](https://rulepaste.com/guide): What a rules file is, why it matters, and how to install one.
- [All stacks](https://rulepaste.com/rules): Index of ready-made stack pages.
- [All tools](https://rulepaste.com/tools): File formats for Cursor, Claude Code, Windsurf, Copilot, Codex, and AGENTS.md.

## Stack rules

- [Next.js rules file](https://rulepaste.com/rules/nextjs): A Next.js rules file for Cursor, Claude Code, Copilot, and Codex. App Router, async params, Server Components, Tailwind, and Vitest.
- [Next.js + Supabase rules file](https://rulepaste.com/rules/nextjs-supabase): Rules for a Next.js and Supabase app: server cookies client, service-role key, Row Level Security, and generated database types.
- [Next.js + Prisma rules file](https://rulepaste.com/rules/nextjs-prisma): Rules for Next.js with Prisma and Postgres-style schemas: one shared PrismaClient, committed migrations, and no database imports in client components.
- [Next.js + Drizzle rules file](https://rulepaste.com/rules/nextjs-drizzle): Rules for Next.js and Drizzle ORM: drizzle-kit SQL migrations, one server-only client, and bound parameters.
- [Next.js + Playwright rules file](https://rulepaste.com/rules/nextjs-playwright): Next.js rules plus Playwright end-to-end tests: role locators, no fixed sleeps, and the App Router constraints.
- [React + Vite rules file](https://rulepaste.com/rules/react-vite): Rules for a React app on Vite: no Next.js APIs, public VITE_ env vars, and the router you already installed.
- [Tailwind CSS rules file](https://rulepaste.com/rules/tailwind): Tailwind rules for coding agents: v3 config versus v4 @theme, design tokens, focus styles, and class ordering.
- [SvelteKit rules file](https://rulepaste.com/rules/sveltekit): SvelteKit rules that match Svelte 4 or 5, load data on the server, and return fail() from form actions.
- [Astro rules file](https://rulepaste.com/rules/astro): Astro rules for islands, content collections, and keeping client JavaScript off static pages.
- [Nuxt rules file](https://rulepaste.com/rules/nuxt): Nuxt and Vue 3 rules: script setup, useFetch for server data, and secrets kept in server routes.
- [Remix and React Router rules file](https://rulepaste.com/rules/remix): Rules for Remix v2 or React Router 7: use the package you have, loaders for data, actions for writes.
- [Expo and React Native rules file](https://rulepaste.com/rules/expo): Expo rules that forbid HTML tags, pin SDK packages with expo install, and leave generated native projects alone.
- [Supabase rules file](https://rulepaste.com/rules/supabase): Supabase rules for any frontend: RLS stays on, the service-role key stays on the server, types come from the CLI.
- [FastAPI rules file](https://rulepaste.com/rules/python-fastapi): FastAPI rules for Pydantic v2, dependencies, uv, and pytest. Blocking IO stays out of async endpoints.
- [FastAPI + Postgres rules file](https://rulepaste.com/rules/fastapi-postgres): FastAPI rules plus parameterized PostgreSQL: pooled connections, timestamptz, and append-only SQL migrations.
- [Django rules file](https://rulepaste.com/rules/django): Django rules for migrations, the ORM, templates, and auth. Pytest and Postgres, managed with uv.
- [Flask rules file](https://rulepaste.com/rules/flask): Flask rules for the app factory, blueprints, config from the environment, and pytest.
- [Node and Express rules file](https://rulepaste.com/rules/node-express): Express rules for thin routes, Zod or the validator you already have, and one error middleware.
- [NestJS rules file](https://rulepaste.com/rules/nestjs): NestJS rules for modules, providers, the ORM you already wired, and Jest.
- [Hono rules file](https://rulepaste.com/rules/hono): Hono rules for edge and Node deploys: no Node APIs on Workers, Zod validator, HTTPException.
- [Laravel rules file](https://rulepaste.com/rules/laravel): Laravel rules for form requests, Eloquent, env() only in config files, Pest, and Pint.
- [Ruby on Rails rules file](https://rulepaste.com/rules/rails): Rails rules for strong parameters, Hotwire, reversible migrations, and RSpec or the default test suite.
- [Unity C# rules file](https://rulepaste.com/rules/unity-csharp): Unity C# rules: SerializeField instead of Find, no allocations in Update, and no edits under Library.
- [Godot 4 rules file](https://rulepaste.com/rules/godot): Godot 4 rules for scenes, signals, typed GDScript, and the GUT test addon when it is installed.
- [Rust rules file](https://rulepaste.com/rules/rust): Rust rules for Cargo: Result and expect, no casual unsafe, rustfmt, clippy, and cargo test.
- [Go rules file](https://rulepaste.com/rules/go): Go rules for gofmt, wrapped errors, context as the first parameter, and table-driven tests.
- [TypeScript rules file](https://rulepaste.com/rules/typescript): TypeScript rules with no framework attached: strict mode, no new any, import type, and no floating promises.
- [Prisma rules file](https://rulepaste.com/rules/prisma): Prisma rules with no web framework: schema migrations, one shared client, and parameterized raw SQL.

## Tools

- [Cursor](https://rulepaste.com/tools/cursor): How Cursor project rules work in 2026: .cursor/rules/*.mdc frontmatter, alwaysApply, and the legacy .cursorrules file.
- [Claude Code](https://rulepaste.com/tools/claude-code): Where Claude Code reads CLAUDE.md and how .claude/rules path-scoped rules work.
- [Windsurf](https://rulepaste.com/tools/windsurf): Windsurf and Devin Desktop rules: .devin/rules, the .windsurf/rules fallback, and legacy .windsurfrules.
- [GitHub Copilot](https://rulepaste.com/tools/github-copilot): GitHub Copilot custom instructions: .github/copilot-instructions.md and path-specific .instructions.md files.
- [Codex](https://rulepaste.com/tools/codex): How OpenAI Codex discovers AGENTS.md, nested files, and the AGENTS.override.md footgun.
- [AGENTS.md](https://rulepaste.com/tools/agents-md): What the AGENTS.md standard is, which coding agents read it, and how nested files work.

## Also

- [Pro pack](https://rulepaste.com/pro): A planned paid add-on for deeper stack packs. Coming soon until a checkout link is configured.
- [Privacy](https://rulepaste.com/privacy): The generator stores nothing. Newsletter and analytics run only when the site owner connects them.
- [Feedback](https://rulepaste.com/feedback): Report a wrong rule or a missing stack.

# What is a rules file?

A rules file is a markdown file in your project that a coding agent reads before it changes anything. Cursor, Claude Code, Windsurf, GitHub Copilot, and Codex each look for a specific name. The contents are the notes you would give a new teammate who types very fast and forgets the boring constraints.

## Why vibe coding goes sideways without one

If you do not say which stack you are on, the agent fills the gap with whatever it has seen most often. A Vite app grows a Next.js import. A Django project gets a second requirements file. A Unity script calls GameObject.Find because a tutorial did. None of that is malice. It is a missing instruction.

A short rules file makes those guesses boring. The agent already knows the package manager, the test command, and that it should not touch generated folders. You spend the chat on the feature instead of on cleanup.

## What to put in it

Write the things that are expensive when they are wrong, and skip the rest. A useful file is usually one to three screens. Past that, tools truncate it or the model skims.

- Commands. The exact install, dev, test, and lint lines. Agents will run what you name.
- Stack choices. Router, ORM, styling, language version, package manager. One of each.
- Boundaries. Secrets, migrations that must not be edited, generated directories, and how much testing you want.
- Conflicts. Say that existing code wins over the file, and that a direct instruction in chat wins over both.

Leave the product pitch, the license, and the welcome paragraph in the README. The agent does not need them, and they crowd out the commands.

## Where each tool looks

- Cursor: `.cursor/rules/project.mdc` with frontmatter. Set `alwaysApply: true` for a rule that should load every chat. Plain markdown in that folder is ignored. `.cursorrules` is the old filename.
- Claude Code: `CLAUDE.md` at the repo root, or `.claude/CLAUDE.md`. Split later topics into `.claude/rules/*.md`.
- Windsurf / Devin Desktop: `.devin/rules/project.md` with `trigger: always_on`. `.windsurfrules` is the legacy always-on file. Keep each file under about 12,000 characters.
- GitHub Copilot: `.github/copilot-instructions.md`. Path-specific files live in `.github/instructions/` and must end in `.instructions.md`.
- Codex and most other agents: `AGENTS.md` at the root. Nested files cover a single package. Do not leave an empty `AGENTS.override.md` next to a real file.

The tool pages on this site show the frontmatter and the install steps for each of those names.

## How to install a file from RulePaste

1. Open the generator. Pick the tools you actually use and the stack the repo already has. Do not pick the stack you wish you had.
2. Copy or download each file. Save it at the path shown above the code, including the folders. Create `.cursor/rules` or `.github` if they are missing.
3. Commit the file with the rest of the project so the next session, and your teammates, get the same instructions.
4. Start a new chat. Rules are loaded when a session starts. An open chat often keeps the old ones.
5. Edit the file when the repo disagrees with it. The copy in your project is the source of truth. This site does not sync it back.

## How this generator works

RulePaste does not call a language model. Each framework, database, and test runner is a written module. The generator stitches the modules you picked into one markdown document, then wraps that document in the header the tool requires. The same choices always produce the same file, which is why it is free to run.

That also means the file is a starting point, not a portrait of your repo. If you use a custom script name or an unusual folder, change that line after you paste. An agent that follows a wrong command is worse than one with no command.

## Mistakes that waste the file

- Pasting a giant style guide. The model will not hold all of it, and Windsurf may truncate the file.
- Contradicting the code. If the rule says pnpm and the repo has package-lock.json, the agent will thrash. Match the repo, then fix the rule.
- Hiding a secret in the file to "give the agent access". Commit the filename, never the key.
- Generating once and never editing. Add a line when the agent makes the same mistake twice. That line is worth more than a generic paragraph.

## Guide FAQ

### Is a rules file the same as a README?

No. A README is for people: what the project is and how to start it. A rules file is for the agent: the commands to run, the stack choices it must not guess, and the boundaries it must not cross.

### Do I need a different file for every AI tool?

Often yes. Cursor wants .cursor/rules/*.mdc, Claude Code wants CLAUDE.md, Copilot wants .github/copilot-instructions.md, and Codex wants AGENTS.md. The advice inside can be the same. RulePaste wraps one set of rules in each format.

### Will a rules file stop the agent from making mistakes?

It stops a class of mistakes: wrong package manager, invented folders, secrets in client code, tests that were never asked for. It does not review the diff. Read the change.

### Does RulePaste send my stack to an AI?

No. The generator runs in your browser from templates. Nothing is uploaded when you click Generate. Copy or download the file and commit it.

# Tool formats

## Cursor

Cursor reads project rules from .cursor/rules as .mdc files. A plain .md file in that folder is ignored. RulePaste writes one always-on rule plus the older .cursorrules file for editors that still look for it.

## The file Cursor actually loads

Put the rule at `.cursor/rules/project.mdc`. The folder can hold more than one file, and you can nest folders. Each file needs YAML frontmatter. `alwaysApply: true` puts the rule in every chat. A description without globs lets the agent pull the rule in when it sounds relevant. Globs attach the rule when a matching file is in context. If you set none of those, the rule loads only when you @-mention it.

Cursor also reads a root `AGENTS.md` with no frontmatter. Use that when you want one portable file. Use `.mdc` when you want Cursor-specific scoping. The old `.cursorrules` file at the repo root still works on older builds, but new projects should prefer `.mdc`.

## Keep it short enough to follow

- Aim for one concern per file once the rule grows. Cursor's own guidance is to keep a rule focused, well under 500 lines.
- Start a new chat after you add or edit a rule. An open chat does not always pick the change up.
- Commit the file. Project rules are meant to be shared with the repo.
- If a rule is ignored, the frontmatter is the first thing to check. A missing closing `---` means the file never loads, and Cursor does not show an error.

## Claude Code

Claude Code loads CLAUDE.md at the start of every session. RulePaste writes that file at the project root. When it gets too long, split it into .claude/rules without changing tools.

## Where to put it

Save the file as `CLAUDE.md` in the project root, or as `.claude/CLAUDE.md` if you would rather keep the root clear. A personal file at `~/.claude/CLAUDE.md` applies to every repo on that machine. Project files should be committed. Nested `CLAUDE.md` files apply when Claude works in that directory.

For a larger repo, add markdown files under `.claude/rules/`. A file with no frontmatter loads every session, same as CLAUDE.md. A file with `paths` loads only when Claude reads a matching file. `paths` is a YAML list of globs, not a single comma-separated string.

## What not to put in CLAUDE.md

- It is re-read every session and again after compaction, so a long file costs context on every task.
- Put one-off workflows in a skill or a slash command, not in CLAUDE.md.
- Do not paste secrets. Claude will treat them as instructions and may repeat them.

## Windsurf

Windsurf was rebranded to Devin Desktop in 2026. Current builds prefer .devin/rules. They still read .windsurf/rules and the legacy .windsurfrules file. RulePaste writes the new file and the legacy one.

## Which filename to use

Prefer `.devin/rules/project.md`. The frontmatter field is `trigger`. `always_on` loads the rule in every chat. `glob` needs `globs` and loads when a matching file is touched. `model_decision` uses `description` so the model can pull it in. `manual` loads only when you @-mention the rule. `.windsurf/rules/` is the fallback directory. A root `.windsurfrules` file has no frontmatter and is always on.

There is a hard size cap. Workspace rules are truncated around 12,000 characters per file, and the global rules file is shorter. A truncated rule fails silently. Keep always-on text short and move file-specific notes to a glob rule.

- Devin Desktop also reads AGENTS.md. A root file is always on. A nested file applies to that directory.
- If both `.devin/rules/project.md` and `.windsurfrules` exist, both can apply. Do not leave them contradicting each other.
- Start a new Cascade chat after editing rules.

## GitHub Copilot

Copilot's repository-wide instructions live at .github/copilot-instructions.md. Path-specific instructions are separate files under .github/instructions and need applyTo frontmatter.

## Repository instructions

Create `.github/copilot-instructions.md` and commit it. The file is ordinary Markdown. Copilot uses it for Chat and, depending on your plan, for code review and the cloud coding agent. Whitespace between lines is ignored, so write short bullets instead of a long paragraph.

For rules that only matter to some files, add `.github/instructions/something.instructions.md`. The name must end in `.instructions.md`. Frontmatter sets `applyTo` to a comma-separated glob list, for example `**/*.ts,**/*.tsx`. Copilot CLI also discovers `AGENTS.md` and `CLAUDE.md`. IDE support for those names is narrower, so the `.github` file is the one to rely on.

## Codex

Codex reads AGENTS.md before it edits. The file is plain Markdown. There is no required schema. RulePaste writes a root AGENTS.md with the commands and boundaries for your stack.

## How Codex finds instructions

Codex looks in `~/.codex` first (`AGENTS.override.md`, then `AGENTS.md`). It then walks from the git root down to the current directory and includes one file per directory: `AGENTS.override.md` if that file exists, otherwise `AGENTS.md`. Files closer to the work appear later and override earlier guidance. The combined text stops around 32 KiB unless you raise `project_doc_max_bytes`.

An empty `AGENTS.override.md` still occupies that directory's slot. Codex then contributes no project rules from the `AGENTS.md` sitting next to it. Delete an override you no longer want. Do not leave it blank.

- Put repository-wide rules at the root. Put service-specific rules in a nested AGENTS.md next to that service.
- List the real test and lint commands. Codex will try to run the checks you name.
- A repo marked untrusted in Codex config does not load project AGENTS.md. Trust the folder if you expect the file to apply.

## AGENTS.md

AGENTS.md is an open Markdown file for coding agents, stewarded by the Agentic AI Foundation under the Linux Foundation. It is a README for the agent: commands, boundaries, and tests, without the product pitch you put in README.md.

## Who reads it

Codex, Cursor, Copilot CLI, Devin Desktop, Amp, Jules, Factory, and a long list of other agents look for this filename. Tool-specific files (`.cursor/rules`, `CLAUDE.md`, `.github/copilot-instructions.md`) still matter when you want features only that tool has. AGENTS.md is the file you add when more than one agent will touch the repo.

There are no required fields. The closest AGENTS.md to the file being edited wins when instructions disagree. A direct message in the chat wins over the file. Nested files are how monorepos avoid one giant instruction set. The OpenAI repo itself carries many of them.

## What to include

- How to install, run, test, and lint, with the exact commands.
- The stack choices an agent would otherwise guess: router, ORM, styling, package manager.
- Boundaries: secrets, generated folders, migrations, and how much testing you want.
- Leave the product overview and contribution welcome in README.md.

# Sample rules files

## Next.js rules file

URL: https://rulepaste.com/rules/nextjs

This is the default file for a Next.js App Router app on TypeScript, Tailwind, and pnpm. It tells the agent that params and cookies are async, that fetch is not cached unless the project says so, and that secrets do not get a NEXT_PUBLIC_ prefix.

```md
# Project rules

Stack: TypeScript, Next.js, Tailwind CSS, Vitest, pnpm.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- JavaScript package manager is pnpm. The lockfile to commit is pnpm-lock.yaml. Do not add a second lockfile.
- Install: `pnpm install`.
- Dev server: `pnpm dev` when that script exists.
- Lint: `pnpm lint` when that script exists. Typecheck with the project's typecheck script or `tsc --noEmit` if the repo uses it.
- Build: `pnpm build` when you changed a build path.
- Tests: `pnpm test`. Single pass, not watch mode: `pnpm exec vitest run`.
- Run the narrowest command that checks the change. Do not loop install, build, or the full test suite.

## TypeScript

- Leave `strict` on. Do not weaken `tsconfig` to make a build pass.
- No new `any`, and no `// @ts-ignore`. Use `unknown` and narrow. `@ts-expect-error` needs a reason on that line.
- Match the file's style for `type` versus `interface`. Prefer a string union over a new `enum` unless the file already uses enums.
- Use `import type` for type-only imports. Await promises. Do not leave a promise floating.
- Do not use a non-null assertion on a value that came from outside the function. Narrow it instead.

## Next.js

- Use the App Router. Do not add a `pages/` router unless this repo already has one.
- Server Components are the default. Add `"use client"` only for state, effects, browser APIs, or event handlers.
- Await `params`, `searchParams`, `cookies()`, `headers()`, and `draftMode()`. On Next.js 15 and later they are async.
- Do not assume `fetch` is cached. Add a cache flag or the `use cache` directive only where the surrounding code already does.
- Mutations go through Server Actions or route handlers and are validated on the server. Client checks are not the source of truth.
- Set metadata with the Metadata API. Use `next/link` for links and `next/image` with width and height, or `fill` plus `sizes`.
- Do not import the database or secret env vars into a client component. A module that must stay on the server starts with `import "server-only"`.
- Only `NEXT_PUBLIC_` variables may reach client code. Never prefix a secret with `NEXT_PUBLIC_`.

## Tailwind CSS

- Style with Tailwind utilities. Do not add a CSS file or a CSS-in-JS library for a one-off.
- Tailwind v4 is configured in CSS with `@theme` and usually has no `tailwind.config.js`. Tailwind v3 uses that config file. Do not add the other version's config.
- Use the project's color, spacing, and radius tokens. Do not invent a second palette of arbitrary values.
- Mobile-first breakpoints. Every control keeps a visible focus style. Icon-only buttons need an accessible name.
- If `prettier-plugin-tailwindcss` is installed, let it order classes. Use `dark:` only when the project already has a dark theme.

## Vitest

- Put tests next to the code as `*.test.ts`, or in the folder the repo already uses.
- Use `describe`, `it`, and `expect`. A test name states the behavior.
- Assert on values, text, or roles. Do not snapshot a whole component tree.
- Mock only network, time, or the filesystem. Do not mock the function under test.
- Run one pass with `vitest run` or the project's test script. Do not leave watch mode running.

## pnpm

- pnpm is the package manager. The lockfile is `pnpm-lock.yaml`. Do not commit another JavaScript lockfile.
- Add packages with `pnpm add <pkg>` and dev packages with `pnpm add -D <pkg>`. Run scripts with `pnpm <script>`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## Next.js + Supabase rules file

URL: https://rulepaste.com/rules/nextjs-supabase

Use this when the app is Next.js and Supabase is the database and auth. The file keeps the service-role key on the server, refuses to turn off Row Level Security, and uses the SSR cookie client instead of a second Supabase client.

```md
# Project rules

Stack: TypeScript, Next.js, Tailwind CSS, Supabase, Vitest, pnpm.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- JavaScript package manager is pnpm. The lockfile to commit is pnpm-lock.yaml. Do not add a second lockfile.
- Install: `pnpm install`.
- Dev server: `pnpm dev` when that script exists.
- Lint: `pnpm lint` when that script exists. Typecheck with the project's typecheck script or `tsc --noEmit` if the repo uses it.
- Build: `pnpm build` when you changed a build path.
- Tests: `pnpm test`. Single pass, not watch mode: `pnpm exec vitest run`.
- Run the narrowest command that checks the change. Do not loop install, build, or the full test suite.

## TypeScript

- Leave `strict` on. Do not weaken `tsconfig` to make a build pass.
- No new `any`, and no `// @ts-ignore`. Use `unknown` and narrow. `@ts-expect-error` needs a reason on that line.
- Match the file's style for `type` versus `interface`. Prefer a string union over a new `enum` unless the file already uses enums.
- Use `import type` for type-only imports. Await promises. Do not leave a promise floating.
- Do not use a non-null assertion on a value that came from outside the function. Narrow it instead.

## Next.js

- Use the App Router. Do not add a `pages/` router unless this repo already has one.
- Server Components are the default. Add `"use client"` only for state, effects, browser APIs, or event handlers.
- Await `params`, `searchParams`, `cookies()`, `headers()`, and `draftMode()`. On Next.js 15 and later they are async.
- Do not assume `fetch` is cached. Add a cache flag or the `use cache` directive only where the surrounding code already does.
- Mutations go through Server Actions or route handlers and are validated on the server. Client checks are not the source of truth.
- Set metadata with the Metadata API. Use `next/link` for links and `next/image` with width and height, or `fill` plus `sizes`.
- Do not import the database or secret env vars into a client component. A module that must stay on the server starts with `import "server-only"`.
- Only `NEXT_PUBLIC_` variables may reach client code. Never prefix a secret with `NEXT_PUBLIC_`.

## Tailwind CSS

- Style with Tailwind utilities. Do not add a CSS file or a CSS-in-JS library for a one-off.
- Tailwind v4 is configured in CSS with `@theme` and usually has no `tailwind.config.js`. Tailwind v3 uses that config file. Do not add the other version's config.
- Use the project's color, spacing, and radius tokens. Do not invent a second palette of arbitrary values.
- Mobile-first breakpoints. Every control keeps a visible focus style. Icon-only buttons need an accessible name.
- If `prettier-plugin-tailwindcss` is installed, let it order classes. Use `dark:` only when the project already has a dark theme.

## Supabase

- Use the server and browser clients the repo already creates. Do not construct another client with a copied key.
- The service-role key bypasses Row Level Security. It stays on the server. Never put it in a `NEXT_PUBLIC_` or `VITE_` variable.
- Do not disable RLS to make a query succeed. Fix the policy, or run the query with the user session.
- Database types come from `supabase gen types`. Do not hand-write table types that will drift.
- Migrations in `supabase/migrations` are append-only once they have been applied.
- Select explicit columns and handle the `error` field. Supabase does not throw on a failed query. On the server, trust `auth.getUser()`, not an id sent from the browser.

## Vitest

- Put tests next to the code as `*.test.ts`, or in the folder the repo already uses.
- Use `describe`, `it`, and `expect`. A test name states the behavior.
- Assert on values, text, or roles. Do not snapshot a whole component tree.
- Mock only network, time, or the filesystem. Do not mock the function under test.
- Run one pass with `vitest run` or the project's test script. Do not leave watch mode running.

## pnpm

- pnpm is the package manager. The lockfile is `pnpm-lock.yaml`. Do not commit another JavaScript lockfile.
- Add packages with `pnpm add <pkg>` and dev packages with `pnpm add -D <pkg>`. Run scripts with `pnpm <script>`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## Next.js + Prisma rules file

URL: https://rulepaste.com/rules/nextjs-prisma

A Next.js app that stores data with Prisma. The rules keep a single Prisma client alive across hot reload, require a real migration instead of db push, and block Prisma imports from client components.

```md
# Project rules

Stack: TypeScript, Next.js, Tailwind CSS, Prisma, Vitest, pnpm.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- JavaScript package manager is pnpm. The lockfile to commit is pnpm-lock.yaml. Do not add a second lockfile.
- Install: `pnpm install`.
- Dev server: `pnpm dev` when that script exists.
- Lint: `pnpm lint` when that script exists. Typecheck with the project's typecheck script or `tsc --noEmit` if the repo uses it.
- Build: `pnpm build` when you changed a build path.
- Tests: `pnpm test`. Single pass, not watch mode: `pnpm exec vitest run`.
- Run the narrowest command that checks the change. Do not loop install, build, or the full test suite.

## TypeScript

- Leave `strict` on. Do not weaken `tsconfig` to make a build pass.
- No new `any`, and no `// @ts-ignore`. Use `unknown` and narrow. `@ts-expect-error` needs a reason on that line.
- Match the file's style for `type` versus `interface`. Prefer a string union over a new `enum` unless the file already uses enums.
- Use `import type` for type-only imports. Await promises. Do not leave a promise floating.
- Do not use a non-null assertion on a value that came from outside the function. Narrow it instead.

## Next.js

- Use the App Router. Do not add a `pages/` router unless this repo already has one.
- Server Components are the default. Add `"use client"` only for state, effects, browser APIs, or event handlers.
- Await `params`, `searchParams`, `cookies()`, `headers()`, and `draftMode()`. On Next.js 15 and later they are async.
- Do not assume `fetch` is cached. Add a cache flag or the `use cache` directive only where the surrounding code already does.
- Mutations go through Server Actions or route handlers and are validated on the server. Client checks are not the source of truth.
- Set metadata with the Metadata API. Use `next/link` for links and `next/image` with width and height, or `fill` plus `sizes`.
- Do not import the database or secret env vars into a client component. A module that must stay on the server starts with `import "server-only"`.
- Only `NEXT_PUBLIC_` variables may reach client code. Never prefix a secret with `NEXT_PUBLIC_`.

## Tailwind CSS

- Style with Tailwind utilities. Do not add a CSS file or a CSS-in-JS library for a one-off.
- Tailwind v4 is configured in CSS with `@theme` and usually has no `tailwind.config.js`. Tailwind v3 uses that config file. Do not add the other version's config.
- Use the project's color, spacing, and radius tokens. Do not invent a second palette of arbitrary values.
- Mobile-first breakpoints. Every control keeps a visible focus style. Icon-only buttons need an accessible name.
- If `prettier-plugin-tailwindcss` is installed, let it order classes. Use `dark:` only when the project already has a dark theme.

## Prisma

- Edit `schema.prisma`, not the generated client. Match the datasource provider already in the schema, often PostgreSQL.
- Ship schema changes as a committed migration. Do not `db push` against a shared database.
- Import one shared `PrismaClient`. In development servers that reload, reuse it on `globalThis`. Do not construct a client per request.
- Prisma is server-only. A client component must not import it.
- Use `$transaction` when several writes must succeed together. Raw SQL uses the `Prisma.sql` template, never string concatenation.

## Vitest

- Put tests next to the code as `*.test.ts`, or in the folder the repo already uses.
- Use `describe`, `it`, and `expect`. A test name states the behavior.
- Assert on values, text, or roles. Do not snapshot a whole component tree.
- Mock only network, time, or the filesystem. Do not mock the function under test.
- Run one pass with `vitest run` or the project's test script. Do not leave watch mode running.

## pnpm

- pnpm is the package manager. The lockfile is `pnpm-lock.yaml`. Do not commit another JavaScript lockfile.
- Add packages with `pnpm add <pkg>` and dev packages with `pnpm add -D <pkg>`. Run scripts with `pnpm <script>`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## Next.js + Drizzle rules file

URL: https://rulepaste.com/rules/nextjs-drizzle

For a Next.js app on Drizzle. The agent is told to generate migrations with drizzle-kit, keep the existing SQL dialect, and not introduce Prisma beside it.

```md
# Project rules

Stack: TypeScript, Next.js, Tailwind CSS, Drizzle, Vitest, pnpm.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- JavaScript package manager is pnpm. The lockfile to commit is pnpm-lock.yaml. Do not add a second lockfile.
- Install: `pnpm install`.
- Dev server: `pnpm dev` when that script exists.
- Lint: `pnpm lint` when that script exists. Typecheck with the project's typecheck script or `tsc --noEmit` if the repo uses it.
- Build: `pnpm build` when you changed a build path.
- Tests: `pnpm test`. Single pass, not watch mode: `pnpm exec vitest run`.
- Run the narrowest command that checks the change. Do not loop install, build, or the full test suite.

## TypeScript

- Leave `strict` on. Do not weaken `tsconfig` to make a build pass.
- No new `any`, and no `// @ts-ignore`. Use `unknown` and narrow. `@ts-expect-error` needs a reason on that line.
- Match the file's style for `type` versus `interface`. Prefer a string union over a new `enum` unless the file already uses enums.
- Use `import type` for type-only imports. Await promises. Do not leave a promise floating.
- Do not use a non-null assertion on a value that came from outside the function. Narrow it instead.

## Next.js

- Use the App Router. Do not add a `pages/` router unless this repo already has one.
- Server Components are the default. Add `"use client"` only for state, effects, browser APIs, or event handlers.
- Await `params`, `searchParams`, `cookies()`, `headers()`, and `draftMode()`. On Next.js 15 and later they are async.
- Do not assume `fetch` is cached. Add a cache flag or the `use cache` directive only where the surrounding code already does.
- Mutations go through Server Actions or route handlers and are validated on the server. Client checks are not the source of truth.
- Set metadata with the Metadata API. Use `next/link` for links and `next/image` with width and height, or `fill` plus `sizes`.
- Do not import the database or secret env vars into a client component. A module that must stay on the server starts with `import "server-only"`.
- Only `NEXT_PUBLIC_` variables may reach client code. Never prefix a secret with `NEXT_PUBLIC_`.

## Tailwind CSS

- Style with Tailwind utilities. Do not add a CSS file or a CSS-in-JS library for a one-off.
- Tailwind v4 is configured in CSS with `@theme` and usually has no `tailwind.config.js`. Tailwind v3 uses that config file. Do not add the other version's config.
- Use the project's color, spacing, and radius tokens. Do not invent a second palette of arbitrary values.
- Mobile-first breakpoints. Every control keeps a visible focus style. Icon-only buttons need an accessible name.
- If `prettier-plugin-tailwindcss` is installed, let it order classes. Use `dark:` only when the project already has a dark theme.

## Drizzle

- Use the dialect already configured. Do not add a second database driver.
- Generate migrations with `drizzle-kit` and commit the SQL. Do not edit a migration that has been applied.
- There is one server-only database module. Do not import it from client components, and do not add another ORM beside Drizzle.
- Pass user input through bound parameters. Do not build SQL strings by hand.

## Vitest

- Put tests next to the code as `*.test.ts`, or in the folder the repo already uses.
- Use `describe`, `it`, and `expect`. A test name states the behavior.
- Assert on values, text, or roles. Do not snapshot a whole component tree.
- Mock only network, time, or the filesystem. Do not mock the function under test.
- Run one pass with `vitest run` or the project's test script. Do not leave watch mode running.

## pnpm

- pnpm is the package manager. The lockfile is `pnpm-lock.yaml`. Do not commit another JavaScript lockfile.
- Add packages with `pnpm add <pkg>` and dev packages with `pnpm add -D <pkg>`. Run scripts with `pnpm <script>`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## Next.js + Playwright rules file

URL: https://rulepaste.com/rules/nextjs-playwright

The same Next.js App Router rules, with Playwright as the test runner. The agent is told to query by role, avoid waitForTimeout, and not depend on test order.

```md
# Project rules

Stack: TypeScript, Next.js, Tailwind CSS, Playwright, pnpm.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- JavaScript package manager is pnpm. The lockfile to commit is pnpm-lock.yaml. Do not add a second lockfile.
- Install: `pnpm install`.
- Dev server: `pnpm dev` when that script exists.
- Lint: `pnpm lint` when that script exists. Typecheck with the project's typecheck script or `tsc --noEmit` if the repo uses it.
- Build: `pnpm build` when you changed a build path.
- End-to-end tests: `pnpm test`. One file: `pnpm exec playwright test path/to.spec.ts`.
- Run the narrowest command that checks the change. Do not loop install, build, or the full test suite.

## TypeScript

- Leave `strict` on. Do not weaken `tsconfig` to make a build pass.
- No new `any`, and no `// @ts-ignore`. Use `unknown` and narrow. `@ts-expect-error` needs a reason on that line.
- Match the file's style for `type` versus `interface`. Prefer a string union over a new `enum` unless the file already uses enums.
- Use `import type` for type-only imports. Await promises. Do not leave a promise floating.
- Do not use a non-null assertion on a value that came from outside the function. Narrow it instead.

## Next.js

- Use the App Router. Do not add a `pages/` router unless this repo already has one.
- Server Components are the default. Add `"use client"` only for state, effects, browser APIs, or event handlers.
- Await `params`, `searchParams`, `cookies()`, `headers()`, and `draftMode()`. On Next.js 15 and later they are async.
- Do not assume `fetch` is cached. Add a cache flag or the `use cache` directive only where the surrounding code already does.
- Mutations go through Server Actions or route handlers and are validated on the server. Client checks are not the source of truth.
- Set metadata with the Metadata API. Use `next/link` for links and `next/image` with width and height, or `fill` plus `sizes`.
- Do not import the database or secret env vars into a client component. A module that must stay on the server starts with `import "server-only"`.
- Only `NEXT_PUBLIC_` variables may reach client code. Never prefix a secret with `NEXT_PUBLIC_`.

## Tailwind CSS

- Style with Tailwind utilities. Do not add a CSS file or a CSS-in-JS library for a one-off.
- Tailwind v4 is configured in CSS with `@theme` and usually has no `tailwind.config.js`. Tailwind v3 uses that config file. Do not add the other version's config.
- Use the project's color, spacing, and radius tokens. Do not invent a second palette of arbitrary values.
- Mobile-first breakpoints. Every control keeps a visible focus style. Icon-only buttons need an accessible name.
- If `prettier-plugin-tailwindcss` is installed, let it order classes. Use `dark:` only when the project already has a dark theme.

## Playwright

- Keep end-to-end tests in the repo's existing folder, often `e2e/` or `tests/`.
- Locate elements with `getByRole` and the accessible name before test ids, and test ids before CSS selectors.
- Each test sets up its own state. Do not depend on another test having run first.
- Do not use `waitForTimeout`. Wait for a locator, a URL, or a response.
- Do not hardcode production URLs or credentials. Run the file you changed before the full suite.

## pnpm

- pnpm is the package manager. The lockfile is `pnpm-lock.yaml`. Do not commit another JavaScript lockfile.
- Add packages with `pnpm add <pkg>` and dev packages with `pnpm add -D <pkg>`. Run scripts with `pnpm <script>`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## React + Vite rules file

URL: https://rulepaste.com/rules/react-vite

Vite apps get broken when an agent imports next/link or a Server Action. This file draws that line, keeps secrets out of VITE_ variables, and stays on the router already in the repo.

```md
# Project rules

Stack: TypeScript, React + Vite, Tailwind CSS, Vitest, pnpm.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- JavaScript package manager is pnpm. The lockfile to commit is pnpm-lock.yaml. Do not add a second lockfile.
- Install: `pnpm install`.
- Dev server: `pnpm dev` when that script exists.
- Lint: `pnpm lint` when that script exists. Typecheck with the project's typecheck script or `tsc --noEmit` if the repo uses it.
- Build: `pnpm build` when you changed a build path.
- Tests: `pnpm test`. Single pass, not watch mode: `pnpm exec vitest run`.
- Run the narrowest command that checks the change. Do not loop install, build, or the full test suite.

## TypeScript

- Leave `strict` on. Do not weaken `tsconfig` to make a build pass.
- No new `any`, and no `// @ts-ignore`. Use `unknown` and narrow. `@ts-expect-error` needs a reason on that line.
- Match the file's style for `type` versus `interface`. Prefer a string union over a new `enum` unless the file already uses enums.
- Use `import type` for type-only imports. Await promises. Do not leave a promise floating.
- Do not use a non-null assertion on a value that came from outside the function. Narrow it instead.

## React and Vite

- This is a Vite + React app. Do not add `next/link`, `next/image`, Server Actions, or an `app/` router.
- Keep the router the repo already uses. Do not install a second one.
- Variables prefixed with `VITE_` are public. Do not put secrets in client code.
- Load data with the client the repo already has. Do not invent a server layer inside Vite.
- Effects must be safe if they run twice in development. Prefer event handlers over effects.
- Use the import alias already set in `vite.config`. Do not add another one.

## Tailwind CSS

- Style with Tailwind utilities. Do not add a CSS file or a CSS-in-JS library for a one-off.
- Tailwind v4 is configured in CSS with `@theme` and usually has no `tailwind.config.js`. Tailwind v3 uses that config file. Do not add the other version's config.
- Use the project's color, spacing, and radius tokens. Do not invent a second palette of arbitrary values.
- Mobile-first breakpoints. Every control keeps a visible focus style. Icon-only buttons need an accessible name.
- If `prettier-plugin-tailwindcss` is installed, let it order classes. Use `dark:` only when the project already has a dark theme.

## Vitest

- Put tests next to the code as `*.test.ts`, or in the folder the repo already uses.
- Use `describe`, `it`, and `expect`. A test name states the behavior.
- Assert on values, text, or roles. Do not snapshot a whole component tree.
- Mock only network, time, or the filesystem. Do not mock the function under test.
- Run one pass with `vitest run` or the project's test script. Do not leave watch mode running.

## pnpm

- pnpm is the package manager. The lockfile is `pnpm-lock.yaml`. Do not commit another JavaScript lockfile.
- Add packages with `pnpm add <pkg>` and dev packages with `pnpm add -D <pkg>`. Run scripts with `pnpm <script>`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## Tailwind CSS rules file

URL: https://rulepaste.com/rules/tailwind

A styling-only file you can paste into any frontend repo, or combine with a framework in the generator. It tells the agent which Tailwind major you are on and not to invent a second color palette.

```md
# Project rules

Stack: TypeScript, Tailwind CSS, pnpm.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- JavaScript package manager is pnpm. The lockfile to commit is pnpm-lock.yaml. Do not add a second lockfile.
- Install: `pnpm install`.
- Dev server: `pnpm dev` when that script exists.
- Lint: `pnpm lint` when that script exists. Typecheck with the project's typecheck script or `tsc --noEmit` if the repo uses it.
- Build: `pnpm build` when you changed a build path.
- If package.json has a test script, run it when behavior changes. Do not invent a runner.
- Run the narrowest command that checks the change. Do not loop install, build, or the full test suite.

## TypeScript

- Leave `strict` on. Do not weaken `tsconfig` to make a build pass.
- No new `any`, and no `// @ts-ignore`. Use `unknown` and narrow. `@ts-expect-error` needs a reason on that line.
- Match the file's style for `type` versus `interface`. Prefer a string union over a new `enum` unless the file already uses enums.
- Use `import type` for type-only imports. Await promises. Do not leave a promise floating.
- Do not use a non-null assertion on a value that came from outside the function. Narrow it instead.

## Tailwind CSS

- Style with Tailwind utilities. Do not add a CSS file or a CSS-in-JS library for a one-off.
- Tailwind v4 is configured in CSS with `@theme` and usually has no `tailwind.config.js`. Tailwind v3 uses that config file. Do not add the other version's config.
- Use the project's color, spacing, and radius tokens. Do not invent a second palette of arbitrary values.
- Mobile-first breakpoints. Every control keeps a visible focus style. Icon-only buttons need an accessible name.
- If `prettier-plugin-tailwindcss` is installed, let it order classes. Use `dark:` only when the project already has a dark theme.

## pnpm

- pnpm is the package manager. The lockfile is `pnpm-lock.yaml`. Do not commit another JavaScript lockfile.
- Add packages with `pnpm add <pkg>` and dev packages with `pnpm add -D <pkg>`. Run scripts with `pnpm <script>`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## SvelteKit rules file

URL: https://rulepaste.com/rules/sveltekit

Svelte 5 runes and Svelte 4 stores do not belong in the same component. This file tells the agent to read the version you have, load data in +page.server.ts, and leave the adapter alone.

```md
# Project rules

Stack: TypeScript, SvelteKit, Tailwind CSS, Vitest, pnpm.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- JavaScript package manager is pnpm. The lockfile to commit is pnpm-lock.yaml. Do not add a second lockfile.
- Install: `pnpm install`.
- Dev server: `pnpm dev` when that script exists.
- Lint: `pnpm lint` when that script exists. Typecheck with the project's typecheck script or `tsc --noEmit` if the repo uses it.
- Build: `pnpm build` when you changed a build path.
- Tests: `pnpm test`. Single pass, not watch mode: `pnpm exec vitest run`.
- Run the narrowest command that checks the change. Do not loop install, build, or the full test suite.

## TypeScript

- Leave `strict` on. Do not weaken `tsconfig` to make a build pass.
- No new `any`, and no `// @ts-ignore`. Use `unknown` and narrow. `@ts-expect-error` needs a reason on that line.
- Match the file's style for `type` versus `interface`. Prefer a string union over a new `enum` unless the file already uses enums.
- Use `import type` for type-only imports. Await promises. Do not leave a promise floating.
- Do not use a non-null assertion on a value that came from outside the function. Narrow it instead.

## SvelteKit

- Match the Svelte major version in `package.json`. Svelte 5 uses runes (`$props`, `$state`, `$derived`, `$effect`). Svelte 4 uses `export let` and stores. Do not mix them in one component.
- Load data in `+page.server.ts` or `+layout.server.ts`. Do not fetch secrets from the browser.
- Form actions return `fail()` with field errors for invalid input. Do not throw for ordinary validation.
- Shared code lives in `$lib`. Routes live only in `src/routes`. `load` returns plain data, not class instances.
- Navigate with `<a>` and `goto` from `$app/navigation`. Do not change the SvelteKit adapter unless the task is about deployment.

## Tailwind CSS

- Style with Tailwind utilities. Do not add a CSS file or a CSS-in-JS library for a one-off.
- Tailwind v4 is configured in CSS with `@theme` and usually has no `tailwind.config.js`. Tailwind v3 uses that config file. Do not add the other version's config.
- Use the project's color, spacing, and radius tokens. Do not invent a second palette of arbitrary values.
- Mobile-first breakpoints. Every control keeps a visible focus style. Icon-only buttons need an accessible name.
- If `prettier-plugin-tailwindcss` is installed, let it order classes. Use `dark:` only when the project already has a dark theme.

## Vitest

- Put tests next to the code as `*.test.ts`, or in the folder the repo already uses.
- Use `describe`, `it`, and `expect`. A test name states the behavior.
- Assert on values, text, or roles. Do not snapshot a whole component tree.
- Mock only network, time, or the filesystem. Do not mock the function under test.
- Run one pass with `vitest run` or the project's test script. Do not leave watch mode running.

## pnpm

- pnpm is the package manager. The lockfile is `pnpm-lock.yaml`. Do not commit another JavaScript lockfile.
- Add packages with `pnpm add <pkg>` and dev packages with `pnpm add -D <pkg>`. Run scripts with `pnpm <script>`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## Astro rules file

URL: https://rulepaste.com/rules/astro

Astro pages should stay server-rendered until something on the page actually needs state. This file tells the agent which client: directive to reach for, and to use content collections instead of reading markdown by hand.

```md
# Project rules

Stack: TypeScript, Astro, Tailwind CSS, pnpm.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- JavaScript package manager is pnpm. The lockfile to commit is pnpm-lock.yaml. Do not add a second lockfile.
- Install: `pnpm install`.
- Dev server: `pnpm dev` when that script exists.
- Lint: `pnpm lint` when that script exists. Typecheck with the project's typecheck script or `tsc --noEmit` if the repo uses it.
- Build: `pnpm build` when you changed a build path.
- If package.json has a test script, run it when behavior changes. Do not invent a runner.
- Run the narrowest command that checks the change. Do not loop install, build, or the full test suite.

## TypeScript

- Leave `strict` on. Do not weaken `tsconfig` to make a build pass.
- No new `any`, and no `// @ts-ignore`. Use `unknown` and narrow. `@ts-expect-error` needs a reason on that line.
- Match the file's style for `type` versus `interface`. Prefer a string union over a new `enum` unless the file already uses enums.
- Use `import type` for type-only imports. Await promises. Do not leave a promise floating.
- Do not use a non-null assertion on a value that came from outside the function. Narrow it instead.

## Astro

- `.astro` files ship no client JavaScript until you add a `client:` directive. Do not hydrate a component that has no interaction.
- Prefer `client:visible` or `client:idle` over `client:load`.
- Content belongs in content collections under `src/content` with the collection schema. Do not read markdown with `fs` if a collection exists.
- Frontmatter runs at build or request time, not in the browser. Do not use React hooks there.
- Secrets stay in server endpoints. Do not expose a non-public env var to an island.

## Tailwind CSS

- Style with Tailwind utilities. Do not add a CSS file or a CSS-in-JS library for a one-off.
- Tailwind v4 is configured in CSS with `@theme` and usually has no `tailwind.config.js`. Tailwind v3 uses that config file. Do not add the other version's config.
- Use the project's color, spacing, and radius tokens. Do not invent a second palette of arbitrary values.
- Mobile-first breakpoints. Every control keeps a visible focus style. Icon-only buttons need an accessible name.
- If `prettier-plugin-tailwindcss` is installed, let it order classes. Use `dark:` only when the project already has a dark theme.

## pnpm

- pnpm is the package manager. The lockfile is `pnpm-lock.yaml`. Do not commit another JavaScript lockfile.
- Add packages with `pnpm add <pkg>` and dev packages with `pnpm add -D <pkg>`. Run scripts with `pnpm <script>`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## Nuxt rules file

URL: https://rulepaste.com/rules/nuxt

A Nuxt 3 or 4 file. The agent should use script setup, fetch server data with useFetch or useAsyncData, and keep secrets in server/ instead of a Vue component.

```md
# Project rules

Stack: TypeScript, Nuxt, Tailwind CSS, Vitest, pnpm.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- JavaScript package manager is pnpm. The lockfile to commit is pnpm-lock.yaml. Do not add a second lockfile.
- Install: `pnpm install`.
- Dev server: `pnpm dev` when that script exists.
- Lint: `pnpm lint` when that script exists. Typecheck with the project's typecheck script or `tsc --noEmit` if the repo uses it.
- Build: `pnpm build` when you changed a build path.
- Tests: `pnpm test`. Single pass, not watch mode: `pnpm exec vitest run`.
- Run the narrowest command that checks the change. Do not loop install, build, or the full test suite.

## TypeScript

- Leave `strict` on. Do not weaken `tsconfig` to make a build pass.
- No new `any`, and no `// @ts-ignore`. Use `unknown` and narrow. `@ts-expect-error` needs a reason on that line.
- Match the file's style for `type` versus `interface`. Prefer a string union over a new `enum` unless the file already uses enums.
- Use `import type` for type-only imports. Await promises. Do not leave a promise floating.
- Do not use a non-null assertion on a value that came from outside the function. Narrow it instead.

## Nuxt

- New components use `<script setup>` and the Vue 3 Composition API. Do not add the Options API beside script setup.
- Data that should render on the server uses `useFetch` or `useAsyncData`. Do not fetch that data in `onMounted`.
- Follow the project's auto-import setting. Do not manually import `ref` when the rest of the app relies on auto-imports, and do not rely on auto-import if the project disabled it.
- Secrets and database access live in `server/`. A secret in a Vue component is a bug.
- Do not add Pinia or another store if the project does not already have one.

## Tailwind CSS

- Style with Tailwind utilities. Do not add a CSS file or a CSS-in-JS library for a one-off.
- Tailwind v4 is configured in CSS with `@theme` and usually has no `tailwind.config.js`. Tailwind v3 uses that config file. Do not add the other version's config.
- Use the project's color, spacing, and radius tokens. Do not invent a second palette of arbitrary values.
- Mobile-first breakpoints. Every control keeps a visible focus style. Icon-only buttons need an accessible name.
- If `prettier-plugin-tailwindcss` is installed, let it order classes. Use `dark:` only when the project already has a dark theme.

## Vitest

- Put tests next to the code as `*.test.ts`, or in the folder the repo already uses.
- Use `describe`, `it`, and `expect`. A test name states the behavior.
- Assert on values, text, or roles. Do not snapshot a whole component tree.
- Mock only network, time, or the filesystem. Do not mock the function under test.
- Run one pass with `vitest run` or the project's test script. Do not leave watch mode running.

## pnpm

- pnpm is the package manager. The lockfile is `pnpm-lock.yaml`. Do not commit another JavaScript lockfile.
- Add packages with `pnpm add <pkg>` and dev packages with `pnpm add -D <pkg>`. Run scripts with `pnpm <script>`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## Remix and React Router rules file

URL: https://rulepaste.com/rules/remix

Remix's packages and React Router 7 are easy for an agent to mix up. This file tells it to use whichever one is already in package.json, and to keep data in loaders instead of effects.

```md
# Project rules

Stack: TypeScript, Remix / React Router, Tailwind CSS, Vitest, pnpm.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- JavaScript package manager is pnpm. The lockfile to commit is pnpm-lock.yaml. Do not add a second lockfile.
- Install: `pnpm install`.
- Dev server: `pnpm dev` when that script exists.
- Lint: `pnpm lint` when that script exists. Typecheck with the project's typecheck script or `tsc --noEmit` if the repo uses it.
- Build: `pnpm build` when you changed a build path.
- Tests: `pnpm test`. Single pass, not watch mode: `pnpm exec vitest run`.
- Run the narrowest command that checks the change. Do not loop install, build, or the full test suite.

## TypeScript

- Leave `strict` on. Do not weaken `tsconfig` to make a build pass.
- No new `any`, and no `// @ts-ignore`. Use `unknown` and narrow. `@ts-expect-error` needs a reason on that line.
- Match the file's style for `type` versus `interface`. Prefer a string union over a new `enum` unless the file already uses enums.
- Use `import type` for type-only imports. Await promises. Do not leave a promise floating.
- Do not use a non-null assertion on a value that came from outside the function. Narrow it instead.

## Remix and React Router

- Use the packages already in `package.json`. React Router 7 (`react-router`) and Remix v2 (`@remix-run/*`) are different. Do not install the other one.
- Loaders return data. Actions handle writes. Do not refetch loader data in an effect.
- Validate form data and URL params inside the loader or action before use.
- Return the project's error shape with a real HTTP status. Do not swallow loader errors.
- Use the router's `Link` and `Form`. Do not import server-only modules into a component that also runs on the client.

## Tailwind CSS

- Style with Tailwind utilities. Do not add a CSS file or a CSS-in-JS library for a one-off.
- Tailwind v4 is configured in CSS with `@theme` and usually has no `tailwind.config.js`. Tailwind v3 uses that config file. Do not add the other version's config.
- Use the project's color, spacing, and radius tokens. Do not invent a second palette of arbitrary values.
- Mobile-first breakpoints. Every control keeps a visible focus style. Icon-only buttons need an accessible name.
- If `prettier-plugin-tailwindcss` is installed, let it order classes. Use `dark:` only when the project already has a dark theme.

## Vitest

- Put tests next to the code as `*.test.ts`, or in the folder the repo already uses.
- Use `describe`, `it`, and `expect`. A test name states the behavior.
- Assert on values, text, or roles. Do not snapshot a whole component tree.
- Mock only network, time, or the filesystem. Do not mock the function under test.
- Run one pass with `vitest run` or the project's test script. Do not leave watch mode running.

## pnpm

- pnpm is the package manager. The lockfile is `pnpm-lock.yaml`. Do not commit another JavaScript lockfile.
- Add packages with `pnpm add <pkg>` and dev packages with `pnpm add -D <pkg>`. Run scripts with `pnpm <script>`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## Expo and React Native rules file

URL: https://rulepaste.com/rules/expo

React Native agents often emit div and className. This file requires View, Text, and Pressable, installs SDK modules with expo install, and tells the agent not to hand-edit generated ios and android folders.

```md
# Project rules

Stack: TypeScript, Expo / React Native, Jest, npm.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- JavaScript package manager is npm. The lockfile to commit is package-lock.json. Do not add a second lockfile.
- Install: `npm install`.
- Dev server: `npm run dev` when that script exists.
- Lint: `npm run lint` when that script exists. Typecheck with the project's typecheck script or `tsc --noEmit` if the repo uses it.
- Build: `npm run build` when you changed a build path.
- Tests: `npm test`. One file: `npx jest path/to/file.test.ts`.
- Add Expo SDK packages with `npx expo install <pkg>` so the version matches the SDK.
- Run the narrowest command that checks the change. Do not loop install, build, or the full test suite.

## TypeScript

- Leave `strict` on. Do not weaken `tsconfig` to make a build pass.
- No new `any`, and no `// @ts-ignore`. Use `unknown` and narrow. `@ts-expect-error` needs a reason on that line.
- Match the file's style for `type` versus `interface`. Prefer a string union over a new `enum` unless the file already uses enums.
- Use `import type` for type-only imports. Await promises. Do not leave a promise floating.
- Do not use a non-null assertion on a value that came from outside the function. Narrow it instead.

## Expo and React Native

- Use `View`, `Text`, `Pressable`, and `ScrollView` from `react-native`. Do not use `div`, `span`, or CSS files.
- Use the navigation the repo already has: Expo Router or React Navigation. Do not add both.
- Style with `StyleSheet.create` unless NativeWind or another styling library is already installed. Do not add one.
- Add Expo SDK modules with `npx expo install` so the version matches the SDK.
- If `ios/` and `android/` are generated or gitignored, change `app.json` or config plugins instead of hand-editing native projects.
- Do not import Node built-ins into components. They do not exist on device.

## Jest

- Match the existing test location and suffix. Do not add Vitest beside Jest.
- Await async assertions. Do not use `done` callbacks in new tests.
- Do not leak mock state between tests. Do not snapshot large trees, ids, or dates.

## npm

- npm is the package manager. The lockfile is `package-lock.json`. Do not commit `pnpm-lock.yaml`, `yarn.lock`, or `bun.lock`.
- Add packages with `npm install <pkg>`. Run scripts with `npm run <script>` and `npm test`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## Supabase rules file

URL: https://rulepaste.com/rules/supabase

A database-and-auth file with no frontend framework attached. Paste it next to your app rules, or combine it with Next.js on the Next.js + Supabase page.

```md
# Project rules

Stack: TypeScript, Supabase, pnpm.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- JavaScript package manager is pnpm. The lockfile to commit is pnpm-lock.yaml. Do not add a second lockfile.
- Install: `pnpm install`.
- Dev server: `pnpm dev` when that script exists.
- Lint: `pnpm lint` when that script exists. Typecheck with the project's typecheck script or `tsc --noEmit` if the repo uses it.
- Build: `pnpm build` when you changed a build path.
- If package.json has a test script, run it when behavior changes. Do not invent a runner.
- Run the narrowest command that checks the change. Do not loop install, build, or the full test suite.

## TypeScript

- Leave `strict` on. Do not weaken `tsconfig` to make a build pass.
- No new `any`, and no `// @ts-ignore`. Use `unknown` and narrow. `@ts-expect-error` needs a reason on that line.
- Match the file's style for `type` versus `interface`. Prefer a string union over a new `enum` unless the file already uses enums.
- Use `import type` for type-only imports. Await promises. Do not leave a promise floating.
- Do not use a non-null assertion on a value that came from outside the function. Narrow it instead.

## Supabase

- Use the server and browser clients the repo already creates. Do not construct another client with a copied key.
- The service-role key bypasses Row Level Security. It stays on the server. Never put it in a `NEXT_PUBLIC_` or `VITE_` variable.
- Do not disable RLS to make a query succeed. Fix the policy, or run the query with the user session.
- Database types come from `supabase gen types`. Do not hand-write table types that will drift.
- Migrations in `supabase/migrations` are append-only once they have been applied.
- Select explicit columns and handle the `error` field. Supabase does not throw on a failed query. On the server, trust `auth.getUser()`, not an id sent from the browser.

## pnpm

- pnpm is the package manager. The lockfile is `pnpm-lock.yaml`. Do not commit another JavaScript lockfile.
- Add packages with `pnpm add <pkg>` and dev packages with `pnpm add -D <pkg>`. Run scripts with `pnpm <script>`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## FastAPI rules file

URL: https://rulepaste.com/rules/python-fastapi

A FastAPI service managed by uv. Path functions stay thin, settings live on one pydantic-settings object, and a sync database call does not run inside async def.

```md
# Project rules

Stack: Python, FastAPI, pytest, uv.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- Python package manager is uv. Do not also introduce pip, Poetry, and uv in the same repo.
- Install: `uv sync`. Add a dependency: `uv add <pkg>`.
- Dev server: use the repo's start script, or `uv run fastapi dev` from the directory that contains the app.
- Tests: `uv run pytest`.
- Lint with Ruff when the repo has it: `uv run ruff check .`. Do not add a second Python linter.

## Python

- Use the Python version pinned by `.python-version`, `requires-python`, or CI. Do not use newer syntax.
- Type public functions. On 3.9+ use builtin generics such as `list[str]`.
- Never use a bare `except:` or `except Exception: pass`. Catch the specific error or log and re-raise.
- Use `pathlib` for new filesystem code unless the file you are editing already uses `os.path`.
- Lint and format with the tool the repo already runs, usually Ruff. Do not add Black or Flake8 beside Ruff.
- Declare dependencies in the project manifest. Do not install into a global Python.

## FastAPI

- Public endpoints declare Pydantic v2 request and response models. Do not return an untyped dict.
- Path functions stay thin. Put logic in plain functions that do not import FastAPI, so tests do not need HTTP.
- Inject the database session, settings, and current user with `Depends`. Do not create an engine or read `os.environ` inside a path function.
- Settings live on one `pydantic-settings` object.
- Do not call blocking IO inside `async def`. Use a plain `def` endpoint for sync database clients, or use the async client the project already chose.
- Raise `HTTPException` with the project's error shape. Do not leak tracebacks. CORS allows only the origins already configured.

## pytest

- Tests live under `tests/` unless the repo already keeps them beside modules. Names are `test_<behavior>`.
- Use fixtures and plain `assert`. Do not add unittest classes unless that file already uses them.
- Database tests use the project's temporary database fixture. Do not hit the network from a unit test.

## uv

- uv manages the environment. Run `uv sync` to install. Add dependencies with `uv add`.
- Run tools through `uv run`, for example `uv run pytest` and `uv run ruff check .`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## FastAPI + Postgres rules file

URL: https://rulepaste.com/rules/fastapi-postgres

FastAPI with SQL that you write yourself, not an ORM. Queries are parameterized, migrations are append-only, and the FastAPI rules about Pydantic and the event loop still apply.

```md
# Project rules

Stack: Python, FastAPI, PostgreSQL, pytest, uv.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- Python package manager is uv. Do not also introduce pip, Poetry, and uv in the same repo.
- Install: `uv sync`. Add a dependency: `uv add <pkg>`.
- Dev server: use the repo's start script, or `uv run fastapi dev` from the directory that contains the app.
- Tests: `uv run pytest`.
- Lint with Ruff when the repo has it: `uv run ruff check .`. Do not add a second Python linter.

## Python

- Use the Python version pinned by `.python-version`, `requires-python`, or CI. Do not use newer syntax.
- Type public functions. On 3.9+ use builtin generics such as `list[str]`.
- Never use a bare `except:` or `except Exception: pass`. Catch the specific error or log and re-raise.
- Use `pathlib` for new filesystem code unless the file you are editing already uses `os.path`.
- Lint and format with the tool the repo already runs, usually Ruff. Do not add Black or Flake8 beside Ruff.
- Declare dependencies in the project manifest. Do not install into a global Python.

## FastAPI

- Public endpoints declare Pydantic v2 request and response models. Do not return an untyped dict.
- Path functions stay thin. Put logic in plain functions that do not import FastAPI, so tests do not need HTTP.
- Inject the database session, settings, and current user with `Depends`. Do not create an engine or read `os.environ` inside a path function.
- Settings live on one `pydantic-settings` object.
- Do not call blocking IO inside `async def`. Use a plain `def` endpoint for sync database clients, or use the async client the project already chose.
- Raise `HTTPException` with the project's error shape. Do not leak tracebacks. CORS allows only the origins already configured.

## PostgreSQL

- Every query is parameterized. Never concatenate request data into SQL.
- Use the pool the repo already has. Do not open a new client per call on a hot path.
- Migrations are append-only SQL. Timestamps are `timestamptz`. New ids match the id type already in the schema.
- Name the columns you select. Add an index only for a filter, join, or ordering this change actually runs.

## pytest

- Tests live under `tests/` unless the repo already keeps them beside modules. Names are `test_<behavior>`.
- Use fixtures and plain `assert`. Do not add unittest classes unless that file already uses them.
- Database tests use the project's temporary database fixture. Do not hit the network from a unit test.

## uv

- uv manages the environment. Run `uv sync` to install. Add dependencies with `uv add`.
- Run tools through `uv run`, for example `uv run pytest` and `uv run ruff check .`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## Django rules file

URL: https://rulepaste.com/rules/django

A Django project that should not grow a homemade auth system or an edited migration. The file requires makemigrations, named URLs, autoescaped templates, and django.contrib.auth.

```md
# Project rules

Stack: Python, Django, PostgreSQL, pytest, uv.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- Python package manager is uv. Do not also introduce pip, Poetry, and uv in the same repo.
- Install: `uv sync`. Add a dependency: `uv add <pkg>`.
- Dev server: `uv run python manage.py runserver`.
- Create migrations with `uv run python manage.py makemigrations` and commit them. Migrate only a local database.
- Tests: `uv run pytest`.
- Lint with Ruff when the repo has it: `uv run ruff check .`. Do not add a second Python linter.

## Python

- Use the Python version pinned by `.python-version`, `requires-python`, or CI. Do not use newer syntax.
- Type public functions. On 3.9+ use builtin generics such as `list[str]`.
- Never use a bare `except:` or `except Exception: pass`. Catch the specific error or log and re-raise.
- Use `pathlib` for new filesystem code unless the file you are editing already uses `os.path`.
- Lint and format with the tool the repo already runs, usually Ruff. Do not add Black or Flake8 beside Ruff.
- Declare dependencies in the project manifest. Do not install into a global Python.

## Django

- Change models through migrations. Commit the migration `makemigrations` creates. Do not edit a migration that has already been applied.
- Match the view style next to the change. If Django REST framework is installed, use its serializers. Do not add it if it is not installed.
- Use `select_related` or `prefetch_related` when a loop touches a relation. Do not query the database from a template.
- Leave template autoescape on. Do not mark user content safe. Reverse URLs by name instead of hardcoding paths.
- Use `django.contrib.auth` for passwords and sessions. Secrets come from the environment, never committed in `settings.py`.

## PostgreSQL

- Every query is parameterized. Never concatenate request data into SQL.
- Use the pool the repo already has. Do not open a new client per call on a hot path.
- Migrations are append-only SQL. Timestamps are `timestamptz`. New ids match the id type already in the schema.
- Name the columns you select. Add an index only for a filter, join, or ordering this change actually runs.

## pytest

- Tests live under `tests/` unless the repo already keeps them beside modules. Names are `test_<behavior>`.
- Use fixtures and plain `assert`. Do not add unittest classes unless that file already uses them.
- Database tests use the project's temporary database fixture. Do not hit the network from a unit test.

## uv

- uv manages the environment. Run `uv sync` to install. Add dependencies with `uv add`.
- Run tools through `uv run`, for example `uv run pytest` and `uv run ruff check .`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## Flask rules file

URL: https://rulepaste.com/rules/flask

A Flask service that already has an app factory. The file tells the agent not to create a second global app, and not to commit a database session if teardown already does.

```md
# Project rules

Stack: Python, Flask, pytest, uv.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- Python package manager is uv. Do not also introduce pip, Poetry, and uv in the same repo.
- Install: `uv sync`. Add a dependency: `uv add <pkg>`.
- Dev server: use the repo's start script. Do not guess the module path if the factory is not `app:create_app`.
- Tests: `uv run pytest`.
- Lint with Ruff when the repo has it: `uv run ruff check .`. Do not add a second Python linter.

## Python

- Use the Python version pinned by `.python-version`, `requires-python`, or CI. Do not use newer syntax.
- Type public functions. On 3.9+ use builtin generics such as `list[str]`.
- Never use a bare `except:` or `except Exception: pass`. Catch the specific error or log and re-raise.
- Use `pathlib` for new filesystem code unless the file you are editing already uses `os.path`.
- Lint and format with the tool the repo already runs, usually Ruff. Do not add Black or Flake8 beside Ruff.
- Declare dependencies in the project manifest. Do not install into a global Python.

## Flask

- Use the app factory if the project has one. Do not create a second global app.
- Add routes on the blueprint the feature belongs to.
- Read config from the existing config object and the environment. Do not hardcode secrets or database URLs.
- Use the request-scoped database session the project already has. Do not commit inside a helper if a teardown handler commits.
- Tests use the app fixture and a temporary database. Do not point tests at the developer database.

## pytest

- Tests live under `tests/` unless the repo already keeps them beside modules. Names are `test_<behavior>`.
- Use fixtures and plain `assert`. Do not add unittest classes unless that file already uses them.
- Database tests use the project's temporary database fixture. Do not hit the network from a unit test.

## uv

- uv manages the environment. Run `uv sync` to install. Add dependencies with `uv add`.
- Run tools through `uv run`, for example `uv run pytest` and `uv run ruff check .`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## Node and Express rules file

URL: https://rulepaste.com/rules/node-express

An Express API on TypeScript and pnpm. Routes stay thin, async errors reach the error handler, and the agent does not convert the project between ESM and CommonJS.

```md
# Project rules

Stack: TypeScript, Node + Express, Vitest, pnpm.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- JavaScript package manager is pnpm. The lockfile to commit is pnpm-lock.yaml. Do not add a second lockfile.
- Install: `pnpm install`.
- Dev server: `pnpm dev` when that script exists.
- Lint: `pnpm lint` when that script exists. Typecheck with the project's typecheck script or `tsc --noEmit` if the repo uses it.
- Build: `pnpm build` when you changed a build path.
- Tests: `pnpm test`. Single pass, not watch mode: `pnpm exec vitest run`.
- Use the `dev` or `start` script in package.json. Do not assume nodemon is installed.
- Run the narrowest command that checks the change. Do not loop install, build, or the full test suite.

## TypeScript

- Leave `strict` on. Do not weaken `tsconfig` to make a build pass.
- No new `any`, and no `// @ts-ignore`. Use `unknown` and narrow. `@ts-expect-error` needs a reason on that line.
- Match the file's style for `type` versus `interface`. Prefer a string union over a new `enum` unless the file already uses enums.
- Use `import type` for type-only imports. Await promises. Do not leave a promise floating.
- Do not use a non-null assertion on a value that came from outside the function. Narrow it instead.

## Express

- Match the module style of the entry file, ESM or CommonJS. Do not convert the project.
- Routes stay thin. Put logic in functions that can be tested without listening on a port.
- Validate bodies, query strings, and params with the library the repo already uses. If it has none, use Zod. Do not add a second validator.
- Forward rejected promises to the Express error handler. One error middleware owns the response shape and does not send stack traces in production.
- Read config from the existing env module. If helmet or CORS is already mounted, do not remove it, and do not open CORS to every origin on an app that uses cookies.

## Vitest

- Put tests next to the code as `*.test.ts`, or in the folder the repo already uses.
- Use `describe`, `it`, and `expect`. A test name states the behavior.
- Assert on values, text, or roles. Do not snapshot a whole component tree.
- Mock only network, time, or the filesystem. Do not mock the function under test.
- Run one pass with `vitest run` or the project's test script. Do not leave watch mode running.

## pnpm

- pnpm is the package manager. The lockfile is `pnpm-lock.yaml`. Do not commit another JavaScript lockfile.
- Add packages with `pnpm add <pkg>` and dev packages with `pnpm add -D <pkg>`. Run scripts with `pnpm <script>`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## NestJS rules file

URL: https://rulepaste.com/rules/nestjs

NestJS projects fall apart when an agent puts database calls in a controller or adds a second ORM. This file keeps HTTP in controllers and persistence in the module you already have.

```md
# Project rules

Stack: TypeScript, NestJS, Jest, pnpm.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- JavaScript package manager is pnpm. The lockfile to commit is pnpm-lock.yaml. Do not add a second lockfile.
- Install: `pnpm install`.
- Dev server: `pnpm dev` when that script exists.
- Lint: `pnpm lint` when that script exists. Typecheck with the project's typecheck script or `tsc --noEmit` if the repo uses it.
- Build: `pnpm build` when you changed a build path.
- Tests: `pnpm test`. One file: `pnpm exec jest path/to/file.test.ts`.
- Run the narrowest command that checks the change. Do not loop install, build, or the full test suite.

## TypeScript

- Leave `strict` on. Do not weaken `tsconfig` to make a build pass.
- No new `any`, and no `// @ts-ignore`. Use `unknown` and narrow. `@ts-expect-error` needs a reason on that line.
- Match the file's style for `type` versus `interface`. Prefer a string union over a new `enum` unless the file already uses enums.
- Use `import type` for type-only imports. Await promises. Do not leave a promise floating.
- Do not use a non-null assertion on a value that came from outside the function. Narrow it instead.

## NestJS

- A feature is a module that wires a controller and providers. Do not construct services inside a controller.
- Business logic lives in providers. Persistence uses the ORM module already installed. Do not add a second ORM.
- Validate DTOs the way neighboring controllers do. Do not introduce a second validation style.
- Read configuration from `@nestjs/config` when it is set up, not from `process.env` deep inside a provider.
- Throw the project's HTTP exception so the filter keeps one response shape.

## Jest

- Match the existing test location and suffix. Do not add Vitest beside Jest.
- Await async assertions. Do not use `done` callbacks in new tests.
- Do not leak mock state between tests. Do not snapshot large trees, ids, or dates.

## pnpm

- pnpm is the package manager. The lockfile is `pnpm-lock.yaml`. Do not commit another JavaScript lockfile.
- Add packages with `pnpm add <pkg>` and dev packages with `pnpm add -D <pkg>`. Run scripts with `pnpm <script>`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## Hono rules file

URL: https://rulepaste.com/rules/hono

Hono runs in more than one runtime. This file tells the agent to read the entry file before importing fs, and to return errors through HTTPException instead of a new JSON shape per route.

```md
# Project rules

Stack: TypeScript, Hono, Vitest, pnpm.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- JavaScript package manager is pnpm. The lockfile to commit is pnpm-lock.yaml. Do not add a second lockfile.
- Install: `pnpm install`.
- Dev server: `pnpm dev` when that script exists.
- Lint: `pnpm lint` when that script exists. Typecheck with the project's typecheck script or `tsc --noEmit` if the repo uses it.
- Build: `pnpm build` when you changed a build path.
- Tests: `pnpm test`. Single pass, not watch mode: `pnpm exec vitest run`.
- Use the `dev` or `start` script in package.json. Do not assume nodemon is installed.
- Run the narrowest command that checks the change. Do not loop install, build, or the full test suite.

## TypeScript

- Leave `strict` on. Do not weaken `tsconfig` to make a build pass.
- No new `any`, and no `// @ts-ignore`. Use `unknown` and narrow. `@ts-expect-error` needs a reason on that line.
- Match the file's style for `type` versus `interface`. Prefer a string union over a new `enum` unless the file already uses enums.
- Use `import type` for type-only imports. Await promises. Do not leave a promise floating.
- Do not use a non-null assertion on a value that came from outside the function. Narrow it instead.

## Hono

- Check the deploy target in the entry file before using Node APIs. Do not import `fs` into a Cloudflare Workers route.
- Validate input with the validator the repo already uses, often `@hono/zod-validator`. Return `c.json()` or `c.text()` with an explicit status.
- Use `HTTPException` or the project's error helper. Do not invent a new error JSON in every route.
- Register auth middleware before the routes it protects. Mount sub-routers with `app.route`.

## Vitest

- Put tests next to the code as `*.test.ts`, or in the folder the repo already uses.
- Use `describe`, `it`, and `expect`. A test name states the behavior.
- Assert on values, text, or roles. Do not snapshot a whole component tree.
- Mock only network, time, or the filesystem. Do not mock the function under test.
- Run one pass with `vitest run` or the project's test script. Do not leave watch mode running.

## pnpm

- pnpm is the package manager. The lockfile is `pnpm-lock.yaml`. Do not commit another JavaScript lockfile.
- Add packages with `pnpm add <pkg>` and dev packages with `pnpm add -D <pkg>`. Run scripts with `pnpm <script>`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## Laravel rules file

URL: https://rulepaste.com/rules/laravel

A Laravel app on Composer and Pest. Controllers stay thin, validation is a form request, and env() is not called from a controller. The frontend stack you already have stays put.

```md
# Project rules

Stack: PHP, Laravel, Pest, Composer.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- Install PHP dependencies with `composer install`. Commit `composer.lock`.
- Composer is the package manager. A package.json, if present, is only for frontend assets.
- Prefer `composer run dev` when that script exists. Otherwise use `php artisan serve` for a local API.
- Tests: `php artisan test`. Format changed PHP with `vendor/bin/pint` when Pint is installed.
- Do not run `migrate` against a shared database unless the user asked for that.

## PHP

- Match the PHP version in `composer.json`. Type new properties, parameters, and return values.
- Keep `declare(strict_types=1);` if the file has it, and add it to new files when the package uses it.
- PSR-12 formatting. Autoload through Composer. Do not `require` class files by path.
- Do not hide errors with `@`. Queries use the query builder or bound parameters, never interpolated request data.

## Laravel

- Follow the routing style this repo uses (`routes/*.php` or `bootstrap/app.php`). Do not invent a third style.
- Controllers stay thin. Validate with a Form Request, not a long controller method.
- Define Eloquent relationships on the model and eager-load with `with()` when a loop touches a relation.
- Migrations are append-only. Create a new one with Artisan. Do not edit a migration that has run in production.
- Call `config()` in application code. Call `env()` only inside config files.
- Stay on the frontend already installed (Blade, Inertia, or Livewire). Use the auth starter already installed. Do not add a second one.
- Put slow work on the queue if the project has one. Format changed PHP with Pint when `vendor/bin/pint` exists.

## Pest

- Write `it()` or `test()` closures. Feature tests belong in `tests/Feature` and hit HTTP. Unit tests do not boot the whole framework for a pure class.
- Create records with factories. Do not depend on rows that happen to exist locally.
- Run `php artisan test`. Do not add PHPUnit classes beside Pest for the same area.

## Composer

- Install PHP dependencies with `composer install`. Add packages with `composer require`. Commit `composer.lock`.
- Do not load classes by hand. Autoload through Composer.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## Ruby on Rails rules file

URL: https://rulepaste.com/rules/rails

A Rails app that should stay on Hotwire if that is the UI. Strong parameters on every write, eager loading on lists, and the test suite you already run.

```md
# Project rules

Stack: Ruby, Ruby on Rails, PostgreSQL, RSpec, Bundler.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- Install gems with `bundle install`. Commit `Gemfile.lock` for this application.
- Start the app with `bin/dev` if that script exists, otherwise `bin/rails server`.
- Tests: `bundle exec rspec` on the file you changed.
- Run RuboCop on changed files if the project has it.

## Ruby

- Match the Ruby version in `.ruby-version` or the Gemfile.
- Run RuboCop if the repo has it. `snake_case` methods, `CamelCase` classes, two-space indent.
- Add gems to the Gemfile with a bounded version, then install with Bundler. Commit `Gemfile.lock` for applications.

## Ruby on Rails

- If the UI is Hotwire, do not add React or a second API for a server-rendered screen.
- Every write uses strong parameters. Never pass raw `params` into `create` or `update`.
- Keep validations and associations on the model. Add a service object only if the repo already has that pattern and the action is more than one model write.
- Migrations are reversible and append-only. Eager-load associations a list will touch with `includes`.
- Use the test suite the repo has, `bin/rails test` or RSpec. Do not introduce the other one. Keep secrets in credentials or the environment.

## PostgreSQL

- Every query is parameterized. Never concatenate request data into SQL.
- Use the pool the repo already has. Do not open a new client per call on a hot path.
- Migrations are append-only SQL. Timestamps are `timestamptz`. New ids match the id type already in the schema.
- Name the columns you select. Add an index only for a filter, join, or ordering this change actually runs.

## RSpec

- Specs live under `spec/` and mirror the app structure. Use `describe`, `context`, and `it`.
- An example name reads as a sentence. Use the factories the repo already has. Do not stub the object under test.
- Run `bundle exec rspec` on the file you changed.

## Bundler

- Install with `bundle install`. Add gems in the Gemfile, then update the lockfile.
- Run project executables with `bin/` or `bundle exec`, not a global gem.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## Unity C# rules file

URL: https://rulepaste.com/rules/unity-csharp

Unity agents love GameObject.Find and LINQ inside Update. This file forbids both, pins the editor version you already have, and keeps tests out of the player build.

```md
# Project rules

Stack: C#, Unity, Unity Test Framework, Unity Package Manager.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- This is a Unity project. Do not run npm, pip, or cargo at the project root.
- Add packages in the Package Manager or `Packages/manifest.json`.
- Run tests from the Test Runner. Do not commit `Library/`, `Temp/`, `Obj/`, `Logs/`, or `UserSettings/`.

## C#

- Leave nullable reference types enabled. Do not silence the compiler with `!` unless the value was just checked.
- Await `Task` and `ValueTask`. No `.Result`, `.Wait()`, or `async void`, except the event shape a framework requires.
- Match the file's namespace style. Public members are PascalCase. Private fields match the repo, usually `_camelCase`.
- Do not catch `Exception` and ignore it.

## Unity

- Target the editor version in `ProjectSettings/ProjectVersion.txt`. Do not upgrade the editor as a side effect.
- Wire references with `[SerializeField]`. Do not use `GameObject.Find`, `FindObjectOfType`, or `SendMessage` in new code.
- Cache components in `Awake` or `OnEnable`. Do not call `GetComponent` inside `Update`.
- No per-frame allocations in `Update` or `FixedUpdate`: no new collections, LINQ, or string concatenation.
- Move physics bodies in `FixedUpdate` through the `Rigidbody`. Do not set `transform.position` on a simulated object.
- Use the async style already in the project (coroutines, `Awaitable`, or UniTask). Do not add UniTask if it is not installed.
- Do not edit generated `.csproj` files or anything under `Library/`, `Temp/`, or `Obj/`. Keep scene YAML edits limited to the objects you meant to change.
- Put tests in a test assembly definition, not in a runtime folder that ships in the player.

## Unity Test Framework

- Prefer Edit Mode tests for logic. Use Play Mode only when the behavior needs a running scene.
- Keep tests in an assembly definition that references the code under test and the test runner. Do not ship tests in the player build.
- Create the smallest objects the test needs and clean them up. Do not depend on a scene that the test did not load.

## Unity packages

- Add packages through the Package Manager or `Packages/manifest.json`. Do not run npm or pip at the project root.
- Do not commit `Library/`, `Temp/`, `Obj/`, `Logs/`, or `UserSettings/`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## Godot 4 rules file

URL: https://rulepaste.com/rules/godot

Godot 4 with typed GDScript. Scripts talk to their own scene, signal upward, and do not add a new autoload for one screen's state. The .godot cache stays out of git.

```md
# Project rules

Stack: GDScript, Godot, GUT, Godot project.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- This is a Godot 4 project. Do not add a Node or Python toolchain unless a subfolder already has one.
- Do not commit the `.godot/` cache. Do commit `project.godot` and `.import` files.
- Run GUT only if `addons/gut` is installed. Use the headless command the repo already documents.

## GDScript

- Type variables, parameters, and return values.
- `snake_case` for functions, variables, and signals. `PascalCase` for classes and node names. Signal names are past tense, such as `health_changed`.
- Cache node references with `@onready` and unique names. Do not call `get_node` every frame.
- Keep the file's indentation. Godot's default is tabs. Do not convert a file to spaces.

## Godot

- Use the Godot feature tag already in `project.godot`. Do not change it as a side effect.
- A script assumes only the nodes in its own scene. Call down to children and signal up to parents.
- Do not reach across the tree with absolute node paths. Do not add an autoload for one scene's state.
- Use `_physics_process` for movement and `_process` otherwise. Multiply speeds by `delta`.
- Do not edit the `.godot/` cache. Commit `project.godot`, scenes, scripts, and `.import` files.
- Prefer containers and anchors for UI that must resize. Do not hard-code a full-screen layout in pixels.

## GUT

- If the GUT addon is installed, extend `GutTest` and use `assert_eq` and `assert_true`. Do not print and eyeball.
- Instance any scene the test needs inside the test. Do not require the editor to be open.
- Do not add a second Godot test framework beside GUT.

## Godot project files

- Do not introduce Node, Python, or another toolchain unless a subfolder already has it.
- Do not commit the `.godot/` cache. Do commit `project.godot` and `.import` files.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## Rust rules file

URL: https://rulepaste.com/rules/rust

A Cargo project. The agent should match your edition, return Result for real failures, and explain any unsafe block. Tests live next to the code or under tests/.

```md
# Project rules

Stack: Rust, Cargo test, Cargo.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- Build: `cargo build`. Run: `cargo run`. Format: `cargo fmt`.
- Tests: `cargo test`. Lint: `cargo clippy --all-targets -- -D warnings` if CI denies warnings, otherwise the clippy flags the repo already uses.
- Add crates with a real version requirement. Commit `Cargo.lock` for applications.

## Rust

- Match the edition and MSRV in `Cargo.toml`. Do not bump them as a side effect.
- Format with rustfmt. If CI denies warnings, a new clippy warning is a failure.
- Return `Result` with the crate's error type. `unwrap` and `expect` are for bugs, not for user input or IO. `expect` must name the invariant.
- No `unsafe` unless safe Rust cannot do the job. An `unsafe` block starts with a comment that states why it is sound.
- Prefer borrowing. Add dependencies with a real version, not `*`. Unit tests live in `#[cfg(test)]`. Integration tests live in `tests/`.

## Cargo tests

- Unit tests sit in the same file under `#[cfg(test)]`. Integration tests sit in `tests/`.
- A test name describes the behavior, for example `rejects_empty_name`.
- `cargo test` passes for the crate you changed. Do not `#[ignore]` a test to go green.

## Cargo

- Build with `cargo build`, test with `cargo test`, and format with `cargo fmt`.
- Add crates with `cargo add` when the cargo-edit flow is available, or by editing `Cargo.toml` with a real version. Commit `Cargo.lock` for applications.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## Go rules file

URL: https://rulepaste.com/rules/go

A Go module. Errors are wrapped with %w, context is the first argument, and the agent reaches for the standard library before a new framework.

```md
# Project rules

Stack: Go, Go test, Go modules.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- Download modules with `go mod download`. Keep `go.mod` and `go.sum` in sync.
- Tests: `go test ./...`. Vet: `go vet ./...`. Format touched files with gofmt.
- Build the package you changed with `go build` on that package, or `go build ./...` for a small module.

## Go

- Match the Go version in `go.mod`. Format with gofmt.
- Wrap errors with `fmt.Errorf("doing the thing: %w", err)`. Do not panic across a package boundary or discard an error with `_` unless it cannot fail.
- `context.Context` is the first parameter and is passed through. Do not store a context on a struct.
- Name packages for what they provide, not `util`. Exported names have a doc comment that starts with the name.
- Use the standard library before adding a dependency. If a router is already chosen, stay with it.

## Go tests

- Tests live in `_test.go` in the same package. Use table-driven tests and `t.Run` for more than one case.
- Helpers call `t.Helper()`. Use `t.Fatalf` when the rest of the test would be noise.
- Do not call a live production service. `go test ./...` passes for the packages you changed.

## Go modules

- The module path in `go.mod` stays stable. Download modules with `go mod download`.
- Add a dependency by importing it and running `go get`. Commit `go.mod` and `go.sum` together.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## TypeScript rules file

URL: https://rulepaste.com/rules/typescript

A language file for a TypeScript repo that does not want framework advice mixed in. Combine it with a framework in the generator when you know which one you use.

```md
# Project rules

Stack: TypeScript, Vitest, pnpm.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- JavaScript package manager is pnpm. The lockfile to commit is pnpm-lock.yaml. Do not add a second lockfile.
- Install: `pnpm install`.
- Dev server: `pnpm dev` when that script exists.
- Lint: `pnpm lint` when that script exists. Typecheck with the project's typecheck script or `tsc --noEmit` if the repo uses it.
- Build: `pnpm build` when you changed a build path.
- Tests: `pnpm test`. Single pass, not watch mode: `pnpm exec vitest run`.
- Run the narrowest command that checks the change. Do not loop install, build, or the full test suite.

## TypeScript

- Leave `strict` on. Do not weaken `tsconfig` to make a build pass.
- No new `any`, and no `// @ts-ignore`. Use `unknown` and narrow. `@ts-expect-error` needs a reason on that line.
- Match the file's style for `type` versus `interface`. Prefer a string union over a new `enum` unless the file already uses enums.
- Use `import type` for type-only imports. Await promises. Do not leave a promise floating.
- Do not use a non-null assertion on a value that came from outside the function. Narrow it instead.

## Vitest

- Put tests next to the code as `*.test.ts`, or in the folder the repo already uses.
- Use `describe`, `it`, and `expect`. A test name states the behavior.
- Assert on values, text, or roles. Do not snapshot a whole component tree.
- Mock only network, time, or the filesystem. Do not mock the function under test.
- Run one pass with `vitest run` or the project's test script. Do not leave watch mode running.

## pnpm

- pnpm is the package manager. The lockfile is `pnpm-lock.yaml`. Do not commit another JavaScript lockfile.
- Add packages with `pnpm add <pkg>` and dev packages with `pnpm add -D <pkg>`. Run scripts with `pnpm <script>`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```

## Prisma rules file

URL: https://rulepaste.com/rules/prisma

A data-layer file for a TypeScript service that uses Prisma. Pair it with Next.js, Nest, or Express in the generator if you want those rules in the same file.

```md
# Project rules

Stack: TypeScript, Prisma, Vitest, pnpm.

Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user.

## Working agreement

- Read the files you will change before editing them. Do not invent the project layout from memory.
- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.
- Match the patterns already in the repo over a generic style guide.
- Do not add dependencies, config files, or abstractions the task did not ask for.
- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.
- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue.

## Commands

- JavaScript package manager is pnpm. The lockfile to commit is pnpm-lock.yaml. Do not add a second lockfile.
- Install: `pnpm install`.
- Dev server: `pnpm dev` when that script exists.
- Lint: `pnpm lint` when that script exists. Typecheck with the project's typecheck script or `tsc --noEmit` if the repo uses it.
- Build: `pnpm build` when you changed a build path.
- Tests: `pnpm test`. Single pass, not watch mode: `pnpm exec vitest run`.
- Run the narrowest command that checks the change. Do not loop install, build, or the full test suite.

## TypeScript

- Leave `strict` on. Do not weaken `tsconfig` to make a build pass.
- No new `any`, and no `// @ts-ignore`. Use `unknown` and narrow. `@ts-expect-error` needs a reason on that line.
- Match the file's style for `type` versus `interface`. Prefer a string union over a new `enum` unless the file already uses enums.
- Use `import type` for type-only imports. Await promises. Do not leave a promise floating.
- Do not use a non-null assertion on a value that came from outside the function. Narrow it instead.

## Prisma

- Edit `schema.prisma`, not the generated client. Match the datasource provider already in the schema, often PostgreSQL.
- Ship schema changes as a committed migration. Do not `db push` against a shared database.
- Import one shared `PrismaClient`. In development servers that reload, reuse it on `globalThis`. Do not construct a client per request.
- Prisma is server-only. A client component must not import it.
- Use `$transaction` when several writes must succeed together. Raw SQL uses the `Prisma.sql` template, never string concatenation.

## Vitest

- Put tests next to the code as `*.test.ts`, or in the folder the repo already uses.
- Use `describe`, `it`, and `expect`. A test name states the behavior.
- Assert on values, text, or roles. Do not snapshot a whole component tree.
- Mock only network, time, or the filesystem. Do not mock the function under test.
- Run one pass with `vitest run` or the project's test script. Do not leave watch mode running.

## pnpm

- pnpm is the package manager. The lockfile is `pnpm-lock.yaml`. Do not commit another JavaScript lockfile.
- Add packages with `pnpm add <pkg>` and dev packages with `pnpm add -D <pkg>`. Run scripts with `pnpm <script>`.

## Testing expectations

- When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.
- When you change behavior a caller can observe, update or add a test for that behavior.
- Do not test private helpers, framework internals, or third-party libraries.

## Code style

- Keep strict type and lint settings on. Do not weaken them to get a green build.
- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.
- Give exported functions an explicit type when the inferred type is not obvious.
- Follow the repo formatter. Do not hand-format files the formatter owns.
- Do not add comments that restate the code.
- Comment only a constraint, invariant, or tradeoff the code itself cannot show.
- No file-header banners and no changelog comments.

## Safety

- Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.
- Do not disable authentication, authorization, or TLS checks to make a test pass.
- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.
- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate.

## Done when

- The change does what was asked and nothing extra.
- New or changed behavior is covered at the level in Testing expectations.
- The commands in this file that apply to the touched files have been run, or you say which command you could not run.
- The diff has no unrelated files, lockfile churn, or secrets.
```