Cursor rules for beginners: 5 rules every non-developer should add

Every time you start a new chat in Cursor, the AI starts with no memory of your project's habits. Rules fix that. This guide covers Cursor rules for beginners: what they are, where they go, and five rules worth adding today, even if you have never written a line of code.

What a Cursor rule is

A rule is a short set of instructions that Cursor adds to the start of the AI's context. Think of it as a sticky note the AI reads before it does anything. Cursor's docs put it simply: models don't remember between conversations, so rules give them "persistent, reusable context".

There are four kinds:

• Project rules live in your project, in a folder called .cursor/rules. They travel with the project.
• User rules are your personal preferences, set once in Cursor's settings and used across every project.
• Team rules are for paid team plans, managed from a dashboard.
• AGENTS.md is a plain markdown file in your project's main folder. It's the simplest option.

Where project rules go (and the mistake to avoid)

Project rules are files ending in .mdc inside .cursor/rules. The extension matters: Cursor's docs say a plain .md file in that folder is ignored. If you'd rather use plain markdown, use an AGENTS.md file instead.

The easiest way to create one: type /create-rule in Cursor's chat and describe what you want. Cursor writes the file for you.

The four ways a rule can apply

At the top of each .mdc file is a small header that controls when the rule is used:

For safety rules, use Always Apply. A safety rule that only sometimes applies isn't much of a safety rule.

The 5 rules every non-developer should add

Create one file, for example .cursor/rules/safety.mdc, and paste this in:

---
alwaysApply: true
---

1. Plan first. Before changing code, explain in plain English what you
   will change and which files you will touch. Wait for my "go".
2. Ask before deleting. Never delete files, drop database tables, or run
   rm, git reset --hard, git clean or git push --force unless I say "yes"
   after you explain what will be lost.
3. Protect secrets. Never put API keys or passwords in code, chat, or any
   file that gets committed. Use environment variables and tell me where
   to set them.
4. Small steps. Change one thing at a time. After each step, tell me how
   to check it works before moving on.
5. Explain changes. After every change, summarize what you did in two or
   three plain sentences, with no jargon left unexplained.

Why these five:

1. Plan first catches misunderstandings before they become six changed files.
2. Ask before deleting guards against the one mistake that can't be undone with a click. (If it happens anyway, read how to undo AI changes.)
3. Protect secrets prevents the most expensive beginner mistake: a leaked key.
4. Small steps keeps problems small and easy to trace.
5. Explain changes means you actually understand your own app over time.

Keep rules short

Cursor's own advice: keep rules focused, under 500 lines, and add rules when you notice the AI making the same mistake twice. Don't paste in a huge style guide. A short rule the AI follows beats a long one it skims.

One honest limit: rules guide the AI, they can't force it. Pair them with git save points so any mistake is reversible.

Get these ready-made

Our free starter pack includes 10 starter rules as a ready-made .mdc file for Cursor plus a CLAUDE.md for Claude Code, along with a one-page launch checklist. The Ship-Safe Starter Kit goes further with 9 detailed Cursor rules, a git undo cheat sheet and a pre-deploy security checklist.

Vibe Shipped is independent and not affiliated with Cursor (Anysphere, Inc.). Written with AI assistance and reviewed by a human.