Cursor Rules Examples: 6 .mdc Rules That Stop Common AI Coding Mistakes
The short answer
Cursor project rules are .mdc files in a .cursor/rules folder in your repo. Each one starts with a short frontmatter block (description, globs, and alwaysApply) followed by plain markdown instructions. Cursor adds a rule to the Agent's context always, only when you work on files matching its globs, or when the Agent decides the description is relevant. Good rules are short, specific, and target the mistakes the Agent actually keeps making.
How the three settings work
The frontmatter decides when a rule loads, which matters because every loaded rule costs context.
- alwaysApply: true loads the rule in every Agent chat. Keep this for one short core workflow rule.
- globs (for example **/*.tsx) loads the rule only when matching files are involved.
- description alone lets the Agent pull the rule in when the task matches, which suits on-demand jobs like writing tests or commits.
Example 1: A core workflow rule (always on)
Set alwaysApply to true and keep it to a few lines: read the relevant files before editing, never guess an import path or API, make the smallest change that solves the task, and run the type checker or tests before saying you're done. This one rule removes a surprising share of broken edits.
Example 2: TypeScript (scoped to .ts and .tsx)
Use globs of **/*.ts and **/*.tsx. Tell the Agent not to use any, to prefer unknown with narrowing, to keep exported functions explicitly typed, and to fix type errors instead of silencing them with ts-ignore.
Example 3: Next.js App Router
Scope it to your app folder. Tell the Agent that components are server components by default, to put "use client" only on the small interactive leaf that needs it rather than on a whole page, and to fetch data on the server instead of in useEffect.
Example 4: API route security (on demand)
Give it a description such as "Use when creating or editing API routes or server actions." Tell the Agent to check authentication and authorization on every route, validate input, never trust IDs from the client without checking ownership, and never return secrets or stack traces.
Example 5: Testing (on demand)
Describe it as applying when writing or fixing tests. The key line is that the Agent must never weaken or delete an assertion to make a failing test pass; it should fix the code or explain why the test is wrong.
Example 6: Commit messages (on demand)
Describe it as applying when the user asks for a commit message. Ask for a short imperative subject line under about 70 characters, a blank line, then a body explaining why the change was made.
Rules vs .cursorrules vs AGENTS.md
The older single .cursorrules file at the repo root still works in many setups, but .cursor/rules is the current approach because each rule can be scoped. AGENTS.md is a plain markdown alternative that several coding agents read; it is simple but loads as one block. Many teams use a short AGENTS.md plus scoped .mdc rules.
Skip the setup
The Cursor Rules Pack on ShipReadyAgents has 10 tested .mdc rules (core workflow, TypeScript, Next.js App Router, React, Python, Tailwind, testing, API security, git commits and Supabase) with an installer that backs up anything it would replace. If you also use Claude Code, the Claude Code Skills Pack covers the same habits as skills.
Related
- Template: Cursor Rules Pack
- Template: Claude Code Skills Pack
- Template: PR Code Review Agent
- Tool: Cursor
- Tool: Claude Code
FAQ
Where do Cursor rules go?
In a .cursor/rules folder at the root of your project, one .mdc file per rule. Commit the folder so your whole team gets the same rules.
Do Cursor rules apply to Tab autocomplete?
No. Rules are added to the Agent (chat) context, not to Tab completions.
How many rules should I have?
As few as solve real problems. One short always-on rule plus a handful of scoped or on-demand rules keeps context small and the Agent focused.
Agent Drop: the weekly newsletter
One new agent template, one tool worth using, three links. Free, weekly.