Cursor Rules for Vibe Coders: A Starter Set for Keys and Database Access

You built something in Lovable or Bolt. Now you've opened the code in Cursor, and the agent can change any file. Rules are how you tell it what not to do. This page gives you five starter rules in plain English. For exact syntax, Cursor's rules docs (opens in a new tab) are the reference. We link to them throughout.

These are starter rules. We have not watched them run in a live Cursor session.

What Cursor rules are, in 60 seconds

AI models don't remember anything between replies. Rules fix that. When a rule applies, Cursor puts its text at the start of the model's context, so the agent gets the same guidance every time (Cursor docs (opens in a new tab)).

Cursor has four kinds:

• Project Rules live in .cursor/rules in your repo.
• User Rules apply across all your Cursor work.
• Team Rules are set from a dashboard on Team and Enterprise plans.
• AGENTS.md is a plain markdown file of instructions.

.mdc vs AGENTS.md: which to use

Project rules must be .mdc files. Cursor's docs say a plain .md file inside .cursor/rules is ignored, because it has no frontmatter.

If you'd rather write plain markdown, use AGENTS.md at the root of your project. Cursor also reads AGENTS.md in subfolders and applies it when the agent works in that folder (source (opens in a new tab)).

Start with .mdc if you want a rule to load only for certain files. Start with AGENTS.md if you just want one list of instructions.

How a rule decides when to load

Three frontmatter fields control it (Cursor docs (opens in a new tab)):

• alwaysApply: true means every chat gets it.
• globs with a file pattern means it loads when a matching file is in context.
• description alone lets the agent decide when it's relevant.
• None of these means it loads only when you @-mention it.

The 5 starter rules every vibe-coded app needs

1. No secrets in browser code. Private keys must stay on the server. In a Vite app, Lovable's docs say anything starting with VITE_ gets built into the code visitors download (Lovable docs (opens in a new tab)).
2. Keep the Supabase service-role key on the server. Lovable's docs say code using the service role bypasses row-level security, so that code must check permissions itself (Lovable docs (opens in a new tab)). That key should never sit in a VITE_ variable or a client file.
3. Don't loosen database access rules. Row-level security (RLS) decides which rows each user can see. The agent should never turn it off to make an error go away.
4. Small changes only. One change per request, so you can read the diff.
5. No silent deletes. Explain every change. The agent says what it changed and why, and asks before deleting files or data.

Copy-paste examples

Save this as .cursor/rules/no-leaks.mdc:

---
description: Secrets, API keys, Supabase keys and database access rules
alwaysApply: true
---
- Never put a private API key, token or password in client code or in a VITE_ variable.
- The Supabase service-role key is server-only. Never import it in browser code.
- Server code that uses the service role must check the user's permission itself.
- Never disable row-level security or add a policy that lets everyone read or write. If a query fails because of RLS, stop and tell me.

Save this as .cursor/rules/safe-edits.mdc:

---
alwaysApply: true
---
- Make one small change per request.
- Never delete files, tables or data without asking me first.
- After each change, list the files you touched and explain why in plain words.

What to cut from big rule collections

Cursor's docs suggest keeping each rule under 500 lines, splitting large rules, and skipping things the agent already knows, like whole style guides or common commands. Their advice: start simple, and add a rule when you see the agent make the same mistake again.

Common mistakes

• Saving a rule as .md in .cursor/rules. It gets ignored.
• Expecting @file in a rule to paste the file in. Cursor says the agent reads the file when it needs it, and the contents are not inlined.
• Treating rules as your security. Cursor's docs say AI guidance "should not be your only security control." Still check your keys and database rules yourself.

FAQ

Can I make rules without writing files? Yes. Type /create-rule in chat and describe it, or add one from Customize → Rules (source (opens in a new tab)).

Which wins if rules conflict? Team Rules, then Project Rules, then User Rules.

Are these rules tested? No. They are starters. Read them and edit them for your app.

Get the full starter kit

The MODEL Vibe Coding Kit is one script you run in a repo that already works. It adds shared coding-agent rules for Claude Code, Cursor and Windsurf, setup for five stacks (Next.js + Supabase, Vite + React, FastAPI, Expo, Node + Express), and a pre-deploy security checklist. It won't overwrite your files unless you pass --force. Its rules have not yet been watched in a live session, and the kit page says so part by part. It's $29 in early access, with a full refund within 14 days if it doesn't work for you.