Home › Rules › Cursor rules examples

Cursor rules examples: 10 copy-paste .mdc rules for beginners

Checked against Cursor's Rules docs on Oct 19, 2026. Sources below.

• Formats
• Cursor

Short answer: a Cursor project rule is a .mdc file in .cursor/rules/ with a few lines of frontmatter that decide when it loads. Below are 10 examples covering all four rule types. Copy the ones that fit your project, save each as its own file, and delete the rest.

The 4 rule types (pick one per file)

The file must end in .mdc. A plain .md file in .cursor/rules is ignored. Separate several globs with commas.

The examples

1. Always on: how to work (Always Apply)

---
description: How to work in this project
alwaysApply: true
---

- Do one task per request. If I ask for several, list them and do only the first.
- Before writing code, give a 3-line plan: what changes, which files, how I'll test it.
- Make the smallest change that works. Don't refactor code I didn't mention.
- Ask before adding a dependency, deleting files or touching more than 3 files.
- Never say something works unless you ran it.

Why: The habits every project needs. Keep this one short, since it loads in every chat.

2. Always on: explain like I'm new (Always Apply)

---
description: Explain changes for a beginner
alwaysApply: true
---

- I'm new to coding. After each change, explain what you did in 2-3 plain sentences.
- Give me the exact commands to run, one per line, and what I should see.

Why: Turns every change into a mini lesson, and you never have to guess what to type next.

3. React components (Apply to Specific Files)

---
globs: src/components/**/*.tsx
alwaysApply: false
---

- One component per file, named export, file name matches the component.
- Keep components under 200 lines; move pieces into the same folder when they grow.
- Reuse existing components from src/components/ui before making new ones.

Why: Loads only when a component file is in the chat, so it never clutters other work.

4. API routes: validate everything (Apply to Specific Files)

---
globs: app/api/**/*.ts, src/api/**/*.ts
alwaysApply: false
---

- Validate every request body with zod before using it.
- Check the logged-in user on the server in every route. Never trust an id sent by the browser.
- Return errors as { error: string } with the right status code. Never return stack traces.

Why: The most common AI-code security bug is a route that trusts whatever the browser sends.

5. Supabase migrations (Apply to Specific Files)

---
globs: supabase/**/*.sql
alwaysApply: false
---

- Turn on Row Level Security for every new table, with explicit policies.
- Ask before dropping or renaming a column or table, and say what data would be lost.
- One change per migration file, with a clear name.

Why: Database changes are the hardest to undo. This rule makes the AI slow down only there.

6. Python scripts (Apply to Specific Files)

---
globs: **/*.py
alwaysApply: false
---

- Use the project's virtual environment (.venv). Add new packages to requirements.txt and tell me.
- Scripts that move, rename or delete files must support --dry-run and default to it.
- Read settings from environment variables, never hardcode keys.

Why: Dry run by default saves you from a script that "helpfully" renames 500 files.

7. Tests (Apply to Specific Files)

---
globs: **/*.test.ts, **/*.test.tsx, tests/**/*.py
alwaysApply: false
---

- Test behavior a user would notice, not private details.
- Never delete or weaken a failing test to make it pass. Tell me why it fails.

Why: AI agents sometimes "fix" a failing test by deleting it. This blocks that.

8. Apply intelligently: database changes (Apply Intelligently)

---
description: Use when adding, changing or removing database tables, columns or queries
alwaysApply: false
---

- List the exact schema changes and wait for my OK before writing them.
- Every query that returns user data filters by the logged-in user.

Why: No globs: Agent reads the description and pulls the rule in when the task is about the database, whatever file it's in.

9. Apply intelligently: secrets and keys (Apply Intelligently)

---
description: Use when working with API keys, tokens, passwords, .env files or environment variables
alwaysApply: false
---

- Secrets go in .env, which must be listed in .gitignore. Never print, hardcode or commit them.
- Anything with a NEXT_PUBLIC_, VITE_ or EXPO_PUBLIC_ prefix ends up in the browser. Never put a secret there.

Why: The prefixes are the trap: those variables are bundled into the code every visitor downloads.

10. Manual: pre-launch checklist (Apply Manually)

---
alwaysApply: false
---

Before I launch, check and report (don't fix yet):
1. Every table has row-level security.
2. No secrets in front-end code or in git history.
3. Every API route checks the user.
4. Prices come from the server.
5. Error pages don't show stack traces.

Why: No description and no globs means it loads only when you type @release in chat. Perfect for a checklist you run once.

Cursor rules best practices (from Cursor's docs)

• Keep each rule under 500 lines, and split big ones into several small rules.
• Be specific. Write rules like clear internal docs, with concrete examples.
• Point to files instead of pasting them. Mention @component-template.tsx and Agent reads it when needed. Note: the file isn't pasted into the prompt, so anything that must always be there goes in the rule itself.
• Don't copy whole style guides (use a linter) or list every command (Agent knows npm, git and pytest).
• Start simple. Add a rule only when you see Agent make the same mistake repeatedly.
• Let Cursor write it: type /create-rule in chat and describe what you want.

Common questions

Is .cursorrules deprecated?

Cursor's current Rules docs only describe .cursor/rules/*.mdc, User Rules, Team Rules and AGENTS.md. The old single .cursorrules file isn't mentioned any more, so treat it as legacy: move its contents into a core.mdc like example 1, or into AGENTS.md.

Why isn't my rule applying?

Cursor's FAQ: check the rule type. An "Apply Intelligently" rule needs a description; a file-scoped rule needs a glob that actually matches the file in the chat. A rule with neither only loads when you @-mention it.

Cursor rules or AGENTS.md?

Cursor reads both. AGENTS.md is one plain file that other tools read too; .mdc rules let you load things only when relevant. Full comparison: Cursor rules vs AGENTS.md.

Do rules affect Tab autocomplete?

No. Per Cursor's docs, rules don't affect Cursor Tab, and User Rules aren't used by Inline Edit (Cmd/Ctrl+K).

Want a full set for your project type? Every page in the rules library includes a core.mdc plus a glob-scoped project rule, or generate a Cursor rule.

Related

• Cursor rules vs AGENTS.md (which to use)
• Cursor rules vs skills (when to use a SKILL.md instead)
• CLAUDE.md examples and best practices
• Rules file formats explained
• Supabase app rules (full AGENTS.md + .mdc set)
• Next.js SaaS MVP rules

Sources

• Cursor docs: Rules
• AGENTS.md: the open format

Checked Oct 19, 2026. These tools change often; if something here no longer matches, tell us at [email protected].