# Cursor rules for vibe coding: free .mdc starter set (2026) > Five copy-paste .cursor/rules/*.mdc files (core, frontend, testing, security, new-feature) with the current frontmatter format and all four Cursor rule types explained. Source: https://agentpromptsatoz.com/guides/cursor-rules/ · License: free to use and adapt · Publisher: Agent Prompts A to Z ## How Cursor rules work - Project rules are .mdc files in .cursor/rules/ (plain .md there is ignored). The single .cursorrules file is legacy. - Frontmatter fields: description, globs (comma-separated), alwaysApply. - Always Apply: alwaysApply: true. Apply to Specific Files: globs + alwaysApply: false. Apply Intelligently: description only. Apply Manually: neither; @-mention the rule. ## The starter set ### .cursor/rules/00-core.mdc (Always Apply) ````markdown --- description: Core working agreement for every chat in this repo alwaysApply: true --- # How to work in this project - Stack: {{e.g. Next.js 15 + TypeScript + Supabase}}. Package manager: {{pnpm}}. Never switch it. - Before any change bigger than a one-line fix, write a numbered plan (max 7 steps) and wait for my OK. - Do one step at a time. After each step, run {{pnpm lint && pnpm test}} and fix what breaks before moving on. - Touch only the files the step needs. Don't reformat or rename unrelated code. - Don't add a dependency without asking. Prefer what's already in package.json. - If something is unclear, ask one short question instead of guessing. - Never edit: {{.env*, generated/, applied migrations, lockfiles by hand}}. # Definition of done Before saying a task is done, list each claim (builds, tests pass, bug fixed) and mark it VERIFIED with the exact command and its real output, FAILED, or NOT RUN. Never skip, delete, or weaken a test to make it pass. ```` ### .cursor/rules/frontend.mdc (Apply to Specific Files) ````markdown --- globs: src/app/**/*.tsx, src/components/**/*.tsx alwaysApply: false --- - Reuse existing components in {{src/components/ui/}} before creating new ones. Search first. - Named exports only. One component per file, under ~200 lines; split if it grows. - Style with {{Tailwind}} classes only. No inline style objects, no new CSS files. - Every async UI state needs loading, empty, and error states. - Every form input has a label. Buttons and links must be usable by keyboard. - Don't fetch data in client components if a server component or existing hook can do it. ```` ### .cursor/rules/testing.mdc (Apply to Specific Files) ````markdown --- globs: **/*.test.ts, **/*.test.tsx, tests/** alwaysApply: false --- - Run a single test file with {{pnpm test path/to/file}}; run the full suite before saying done. - When fixing a bug, first write a test that fails because of the bug, then fix the code. - Never use .skip, .only, or delete an assertion to make a suite pass. If a test is wrong, say why and ask. - Test behavior a user would notice, not private implementation details. - Mock network calls at the boundary ({{msw / fetch mock}}), never the code under test. ```` ### .cursor/rules/security.mdc (Apply Intelligently) ````markdown --- description: Use when touching auth, API routes, database queries, env vars, payments, or user input alwaysApply: false --- - Secrets come from environment variables only. Never hard-code keys, never print them, never commit .env. - Every API route checks the user is signed in and allowed to touch that record (no trusting IDs from the client). - Validate all input at the boundary with {{zod}} before using it. - Use parameterized queries or the ORM; never build SQL with string concatenation. - {{Supabase}}: never expose the service-role key to the browser; keep row-level security on. - If a change weakens auth or validation, stop and tell me instead of doing it. ```` ### .cursor/rules/new-feature.mdc (Apply Manually (@new-feature)) ````markdown --- alwaysApply: false --- When I mention @new-feature, follow this workflow: 1. Restate the feature in 2-3 sentences and list what's out of scope. 2. List the files you expect to create or change, and why. 3. Write the numbered plan. Wait for my OK. 4. Build one step at a time, running lint and tests after each. 5. Finish with a short handoff: what changed, how to try it, what's left, and the Definition of done ledger. ```` ## Tips - Start with only 00-core.mdc. Add scoped rules when you see a repeated mistake, not before. - Replace every {{placeholder}} with your real stack and commands. Agents follow commands literally. - Keep always-on rules lean; move anything file-specific into a globs rule so it only loads when needed. - Reference files instead of pasting them: 'follow @src/lib/api-template.ts' keeps rules short and never stale. - Check .cursor/rules/ into git so every teammate and every cloud agent gets the same rules. ## FAQ **Where do Cursor rules go in 2026?** Project rules live in .cursor/rules/ in your repo as .mdc files (subfolders work too). Each file has a small YAML frontmatter block with description, globs, and alwaysApply. A plain .md file in that folder is ignored by the rules system, so use the .mdc extension. If you'd rather use plain markdown, put the same text in AGENTS.md in the project root, which Cursor also reads. **Is .cursorrules still supported?** The single .cursorrules file in the project root is legacy. Cursor's docs say it still works for now but will be deprecated, and recommend moving to .cursor/rules/. To migrate, copy its contents into a new rule like 00-core.mdc with alwaysApply: true (that matches the old behavior), then delete .cursorrules. If both exist, .mdc rules win where they overlap. **What are the four Cursor rule types?** Always Apply (alwaysApply: true) is added to every chat. Apply to Specific Files (globs set, alwaysApply: false) attaches when a matching file is in context. Apply Intelligently (description set, no globs) lets the agent decide from the description. Apply Manually (no description, no globs) is only used when you @-mention the rule, for example @new-feature. **How do I write globs in a .mdc rule?** Put them on one globs: line, comma-separated, for example globs: src/**/*.tsx, tests/**. ** matches any number of folders and * matches one name segment. If alwaysApply is true, globs and description are ignored. **How long should Cursor rules be?** Short and specific. Cursor recommends keeping each rule under 500 lines and splitting big ones into focused files. In practice, a core rule of 15-25 lines plus a few scoped rules beats one giant file, because every always-on line is sent with every request. **Do Cursor rules affect Tab autocomplete?** No. Rules apply to Agent (chat). They don't change Cursor Tab, and User Rules aren't applied to Inline Edit (Cmd/Ctrl+K). **What's the fastest way to improve my rules?** Whenever the agent makes the same mistake twice, add one line to the relevant rule that would have prevented it. You can also type /create-rule in Agent chat and describe what you want; it writes the .mdc file with the right frontmatter. ## Go further (premium) [App Builder Agent Pack](https://payhip.com/b/EuRgw) ($19): six tested Cursor rules files, CLAUDE.md, AGENTS.md and a plan-then-build workflow. Or [all 5 premium packs](https://payhip.com/b/J8eUb) for $29.