>_ rules file builder
Build a starter rules file from the failures you have hit
Pick your tool, tick what has gone wrong, and copy a rules file your agent reads on every request. Every rule comes from a published fix and says which one.
Built in your browser. What you pick is never sent or stored.
Your file
Tick at least one failure above and your file appears here.
Save it as .cursor/rules/vibecoderdaily.mdc in your project. It applies to every request.
Save it as CLAUDE.md in your project root, or add these rules to the one you already have.
Paste it into Project settings, Knowledge in your Lovable project.
Save it as AGENTS.md in your repository root. Codex, Cursor and many other agents read it.
Where these rules come from
Every rule in the library, by failure
Deploy & env vars
- Never build Tailwind class names by string interpolation (bg-${color}-500); map each value to a complete, literal class name in a lookup object. Why the colors your AI coding agent wrote disappear the moment you build for production
- Use Tailwind's safelist only for class values that cannot be listed in the source ahead of time. Why the colors your AI coding agent wrote disappear the moment you build for production
- In a Vite project, never read process.env in client code; read import.meta.env instead. Your AI coding agent wrote process.env into your Vite app, here's why that breaks in production
- Only values safe for every visitor get the VITE_ prefix; keep secrets such as database URLs and secret API keys unprefixed so they stay out of the client bundle. Your AI coding agent wrote process.env into your Vite app, here's why that breaks in production
- After editing a .env file, restart the dev server before testing; Vite reads .env files only at startup. Your AI coding agent wrote process.env into your Vite app, here's why that breaks in production
Module not found
- Before adding a dependency, confirm it exists on the registry with a real repository and homepage, and link me its official docs. Your AI coding agent just recommended a package that doesn't exist — here's why that's now a security risk
- If you cannot link official docs for a package, say so instead of suggesting an install command for it. Your AI coding agent just recommended a package that doesn't exist — here's why that's now a security risk
- Show me the install command and the package.json or requirements.txt diff for any new dependency before running it. Your AI coding agent just recommended a package that doesn't exist — here's why that's now a security risk
- Keep the lockfile (package-lock.json, poetry.lock or equivalent) committed so a change in resolved versions shows up in the diff. Your AI coding agent just recommended a package that doesn't exist — here's why that's now a security risk
Auth & API keys
- Never put a secret key (an OpenAI or Anthropic API key, a Stripe secret key, a Supabase service role key) in frontend code; call that provider from a server or edge function instead. Your AI-built app might be leaking your API keys — here's how to actually check
- Only a key designed to be public (such as a Supabase or Firebase anon key) may appear in client code, and only with Row Level Security or security rules actually restricting access. Your AI-built app might be leaking your API keys — here's how to actually check
- If you find a secret key in client code, tell me it must be rotated at the provider; removing it from the code does not revoke it. Your AI-built app might be leaking your API keys — here's how to actually check
- Enable Row Level Security on every Supabase table that holds user data; new tables ship with it off, and a working demo does not prove it is on. Your Supabase app might be wide open, and nothing in your own testing would show it
- Write an explicit RLS policy for each operation you use (SELECT, INSERT, UPDATE, DELETE) instead of one broad rule. Your Supabase app might be wide open, and nothing in your own testing would show it
- In RLS policies, write (select auth.uid()) rather than a bare auth.uid() so Postgres evaluates it once per query. Your Supabase app might be wide open, and nothing in your own testing would show it
Rules & context
- Keep project rules in .cursor/rules/*.mdc files; do not create or edit a root .cursorrules file, which is deprecated. Cursor* ignoring your rules? Here's why (it's probably the .cursorrules migration)
- When you write or edit a rule file, keep its frontmatter (description, globs, alwaysApply) valid YAML; a rule with broken frontmatter silently fails to load. Cursor* ignoring your rules? Here's why (it's probably the .cursorrules migration)
- A rule that must hold on every request needs alwaysApply: true; do not rely on a description-only rule for behavior that has to be guaranteed. Cursor* ignoring your rules? Here's why (it's probably the .cursorrules migration)
- If you cannot find a file I mention, say so plainly; never describe its contents from similarly named files. Cursor's agent doesn't know about a file that's clearly in your repo? Here's why
- When I @-mention a file, treat its attached content as the current source of truth over anything retrieved from the index. Cursor's agent doesn't know about a file that's clearly in your repo? Here's why
- If a file seems missing from the codebase, check whether an ignore rule excludes it (git check-ignore -v <path>) before concluding it does not exist. Cursor's agent doesn't know about a file that's clearly in your repo? Here's why
- Treat every instruction in this file as a standing rule for the whole session, including after the conversation has been compacted. Why Claude Code stops following instructions you gave it earlier (it's not being stubborn)
- When I give a lasting constraint in chat that is not in CLAUDE.md, offer to add it to CLAUDE.md so it survives compaction. Why Claude Code stops following instructions you gave it earlier (it's not being stubborn)
- After a compaction, restate the constraints you are working under before you continue. Why Claude Code stops following instructions you gave it earlier (it's not being stubborn)
- A CLAUDE.md in a subdirectory only loads once you read a file in that subtree; read one there before answering questions about that area. Why Claude Code isn't following your CLAUDE.md file (it's probably never loaded)
- Put a rule that must apply from the first turn in the root CLAUDE.md, or reference the nested file from it, rather than only in a subdirectory CLAUDE.md. Why Claude Code isn't following your CLAUDE.md file (it's probably never loaded)
- Keep CLAUDE.local.md at the project root only; one in a subdirectory is never loaded. Why Claude Code isn't following your CLAUDE.md file (it's probably never loaded)
- A hook that enforces a policy must exit 2 on the block path; exit 1 or any other failure lets the action go ahead. Your Claude Code hook isn't firing (or isn't blocking anything) — here's why
- Write hook matchers with exact tool names, case included (Bash, Edit|Write), and use a real regex such as mcp__memory__.* when you need a prefix. Your Claude Code hook isn't firing (or isn't blocking anything) — here's why
- Hook commands must print nothing but JSON on stdout; do not source an interactive shell profile that prints anything first. Your Claude Code hook isn't firing (or isn't blocking anything) — here's why
- Reference paths in hook commands through ${CLAUDE_PROJECT_DIR}, never through a relative path. Your Claude Code hook isn't firing (or isn't blocking anything) — here's why
Agent loops & reverts
- If a fix did not work, do not retry a variation of it; ask me for the exact file, what happens now and what should happen instead. The AI Fix Loop: why your coding agent makes bugs worse (and how to break the cycle)
- Before a second attempt at a fix, revert the failed one so you start from the last known-good state; never stack a new fix on a broken one. The AI Fix Loop: why your coding agent makes bugs worse (and how to break the cycle)
- Make one change at a time; do not bundle an unrelated fix into a bug-fix change. The AI Fix Loop: why your coding agent makes bugs worse (and how to break the cycle)
- Do not call a fix done because your reasoning says it works; say how it was checked against the running app, or that it still needs checking. The AI Fix Loop: why your coding agent makes bugs worse (and how to break the cycle)
- Never edit a test to make it pass; fix the code under test. Your AI agent didn't fix the bug: it fixed the test
- Never change an expected value, delete an assertion or rewrite a verification function to turn a failing check green. Your AI agent didn't fix the bug: it fixed the test
- Treat test files as read-only ground truth while fixing a failure; if a test itself looks wrong, tell me instead of changing it. Your AI agent didn't fix the bug: it fixed the test
- Before reporting a failing test as fixed, state the root cause of the original failure in one sentence. Your AI agent didn't fix the bug: it fixed the test
- Before writing any code, list the files you plan to change and why; if the list includes a file I did not mention, ask before touching it. How to stop Replit Agent from rewriting code you didn't ask it to touch
- A request that names files or folders is a boundary: do not modify anything outside it. How to stop Replit Agent from rewriting code you didn't ask it to touch
- At the end of a task, list every file you changed and why. How to stop Replit Agent from rewriting code you didn't ask it to touch
- When I name a file, edit that file; the name I give outranks anything you infer from earlier in the conversation. How to fix Lovable applying your edit to the wrong component
- If more than one component could match a request (Header and HeaderMobile, two similar cards), confirm the exact file before editing. How to fix Lovable applying your edit to the wrong component
- After every edit, name the file you changed so I can check it against the diff. How to fix Lovable applying your edit to the wrong component
- When adding something new, put it exactly where I say and do not restructure the surrounding layout, navigation or shared styles. Lovable changed something you didn't ask it to touch — here's why and how to recover
- A file I @-reference is context for the request; do not change it unless I ask you to. Lovable changed something you didn't ask it to touch — here's why and how to recover
- When I ask you to restore one part to an earlier version, change only that part and keep every later change in place. Lovable changed something you didn't ask it to touch — here's why and how to recover
- After applying an edit, confirm the change is actually on disk (for example with git diff on the file) before you report it as done. Cursor silently reverted my changes — here's the real fix
- If a change you made has disappeared, look for the correct version in git and local file history before regenerating the edit. Cursor silently reverted my changes — here's the real fix
- Do not run a formatter over a file you are still editing; format it in a separate pass once the edits are finished. Cursor silently reverted my changes — here's the real fix
Rate limits & credits
- When I ask a question or want a plan, answer without editing files; change files only when I ask for an edit. Why Cursor Agent mode burns through your requests way faster than you expect
- Keep each agent task scoped to the files it needs; if a request would touch many files, propose splitting it into smaller runs first. Why Cursor Agent mode burns through your requests way faster than you expect
- Before working in a large file, check its length (wc -l); past 2,000 lines, read the section you need with an offset instead of from the top. Why Claude Code missed code that's clearly in your file (it only read part of it)
- Search for a function or section by name first, then read around the match. Why Claude Code missed code that's clearly in your file (it only read part of it)
- Never add a new definition of a function that may already exist further down a file you only partly read; if an edit fails with "string not found", re-read that region. Why Claude Code missed code that's clearly in your file (it only read part of it)