Cursor rules are Markdown files with an .mdc extension, kept in .cursor/rules in your repository. Each one starts with frontmatter, a short block of settings between two --- lines. Those settings decide when Cursor adds the rule to its agent’s context. A rule can load in every request, when a matching file is in context, when the agent judges it relevant or only when you mention it.

For a set of coding standards, keep one short rule that always applies and holds a one-line version of every standard. Put the detail in rules that attach by file pattern, so the testing detail arrives with the test files. The Prickles Cursor pack works this way from release 3.0.0, and its rules for TypeScript, JavaScript, Python, Java and PHP are the examples below.

Cursor keeps adding to how rules load. Skills arrived in version 2.4 in January 2026, according to Cursor’s changelog. Every Cursor behaviour below was checked against Cursor’s own documentation on 12 October 2026, so treat that date as part of the answer.

Where Cursor rules files go

Cursor’s Rules docs (2026) describe four kinds of instructions. Project rules are the ones you commit with your code:

Kind Where it lives What it covers
Project rules .cursor/rules/*.mdc in the repository That repository, for everyone who clones it
User rules Customize, then Rules Every project you open
Team rules Cursor’s dashboard on Team and Enterprise plans Every project in the team
AGENTS.md Any folder, from the repository root down That folder and the folders below it

When team, project and user rules conflict, team rules win over project rules and project rules win over user rules. The Cursor CLI reads the same rules as the editor, according to Using Agent in CLI (2026).

Subfolders of .cursor/rules work, but Cursor’s help page on rules (2026) advises a flat folder with descriptive file names. The same page says the old single .cursorrules file at the root “is legacy and will be deprecated”. To move off it, paste its contents into a new rule, set the type to Always Apply and delete the old file.

To create a rule, type /create-rule in Agent and describe what you want, or open Customize, go to Rules and click Add Rule.

Four rule types set by .mdc frontmatter and globs

Cursor’s type dropdown sets three frontmatter fields: alwaysApply, globs and description. A glob is a file pattern such as **/*.ts, where ** matches any number of folders. Cursor’s Rules docs set out how the fields combine:

Rule type Frontmatter When Cursor includes it
Always Apply alwaysApply: true In every chat. Globs and description are ignored
Apply to Specific Files alwaysApply: false and globs When a matching file is in context
Apply Intelligently alwaysApply: false and description, with no globs When the agent reads the description and judges it relevant
Apply Manually alwaysApply: false and neither Only when you @-mention the rule in chat

Cursor’s docs don’t say what happens when a rule has both globs and a description. Their table covers each field on its own, so a rule that sets both relies on undocumented behaviour.

Separate several patterns in globs with commas. Cursor’s own example puts a space after the comma, but a 2025 forum report found that the space stopped the patterns matching anything. Writing them with no space works either way. The Prickles packs do that.

A rule can also point to another file. Cursor’s docs say a mention such as @migration-template.sql “tells Agent where to look”. The agent then reads the file with its tools when it needs the content. The file isn’t inlined into the prompt, in the editor, the CLI or Cloud Agents.

Put anything that must always be in context directly in the rule body.

— Cursor, Rules, 2026

What each kind of rule costs in tokens

Cursor’s Rules docs say that “rule contents are included at the start of the model context” once a rule applies. An Always Apply rule applies to every chat. That context is paid for in tokens, the chunks of text a model reads and is billed by. Cursor’s Models & Pricing page (2026) prices each model’s input and output per million tokens. So every line of an always-on rule is part of the input to every request.

Other rule types put less in every request, and each brings a different risk:

Rule type In every request What can go wrong
Always Apply Every line of the rule Every line is sent with every request
Globs Nothing until a matching file is in context Until then the rule is missing, such as before a first new file
Description Its description An agent may not pick the rule
Manual Nothing It loads only when you mention it

A Cursor staff member put the risk with description rules on record in September 2025. On the Cursor forum, they explained that the model is sent every rule’s description and chooses which rules to read. That step, the reply said, can mean “the model fails to correctly read or follow the rules when you’d expect it to”.

A pointer to a file has the same weakness when nothing else mentions it. Wenhao Yang, Runzhi He and Minghui Zhou tested how coding agents follow repositories’ contribution rules in 2026. When nothing pointed the agents to a repository’s policy file, they opened it in 12 of 347 runs. Of the 248 violations, 242 happened without the file ever being opened.

That’s the case for keeping a one-line version of every standard always on, and for naming the file to read and the moment to read it. AI3 Working Context argues for keeping the always-on part short. The article on AI token cost covers the other side of the bill, the code itself.

How to split an always-on core from attached rules

  1. Write one rule with alwaysApply: true containing a one-line version of every standard that matters on every task. Cursor’s best practices say to keep rules under 500 lines, so keep this one well under.
  2. Group the lines by subject. Under each group’s heading, name the file that holds the rest as a plain path, and say when to read it, such as before the first edit to a test.
  3. Put each group’s detail in its own rule, with alwaysApply: false and globs for the files it covers.
  4. Leave description out of those rules, because the docs don’t say which setting wins when a rule has both.
  5. Move guidance that belongs to a task rather than a kind of file, such as what to check before calling work done, into a skill with a specific description.
  6. Put anything a tool can check in the linter’s config. Cursor’s docs say to use a linter rather than copy a style guide into a rule, and TA1 Linter as Law makes each check an error.

Step 2 matters because a glob rule isn’t there until a matching file is in context. A rule that tells the agent to read the detail before its first edit of that kind covers the gap, including a test file that doesn’t exist yet.

The Prickles Cursor pack in release 3.0.0

In every request .cursor/rules/prickles.mdc alwaysApply: true, every tenet's rule line When a matching file is in context Foundations source files Architecture source files Style source files Types & Schema source and schemas Testing test files only Patterns source files prickles-<pillar>.mdc with globs When the task needs it, or on /name Process /prickles-process AI Collaboration /prickles-ai Tooling /prickles-tooling .agents/skills/prickles-*/SKILL.md
One always-on entry names every pillar's file. Cursor attaches the six code pillars by file pattern. The agent reads the three task pillars as skills.

Prickles keeps the entry in .cursor/rules/prickles.mdc. It holds the ID, name and rule line of all 50 tenets under nine pillar headings, in 11,063 bytes and 86 lines. Each heading names the pillar’s file and says when to read it:

## Testing (TS1–TS8). Before you write or change a test, read `.cursor/rules/prickles-testing.mdc`.

- **TS1 Living Documentation.** If a behaviour matters, write a test that proves it. The test is the spec. Prose docs are a paraphrase.

A line near the top of the entry makes reading a pillar’s file a precondition, before the first edit of that kind and again after Cursor compacts the agent’s context. Pillars load in two ways:

  • Foundations, Architecture, Style, Types & Schema, Testing and Patterns are rules with alwaysApply: false, globs for your language and no description.
  • Process, AI Collaboration and Tooling belong to tasks rather than files, so they’re skills in .agents/skills.

Nothing is removed from the 2.0 pack. The entry and the pillar files hold every word of every tenet. The pack’s tests rebuild each rule from them byte for byte and check that every frontmatter block parses. The Strict layout keeps 2.0’s arrangement of nine .mdc files with alwaysApply: true, putting 38,610 bytes in every request. Pick either layout in step 3 of the download on the implementation page.

What the split does to a Cursor bill hasn’t been measured. Once the agent has a source file in context, the five pillars matching source files attach too, so a session spent on source code still carries most of the canon. The split is there so the agent has the right detail when it writes each kind of file.

Cursor rules examples for five languages

Every language gets the same entry file. Only the globs on each pillar rule change with the language. The Testing rule shows the differences best, because each language names its test files its own way.

TypeScript

The Testing rule matches .test and .spec files and anything in a __tests__ folder:

---
alwaysApply: false
globs: "**/*.test.ts,**/*.test.tsx,**/*.spec.ts,**/*.spec.tsx,**/__tests__/**,**/*.feature"
---

TypeScript’s other code pillars match .ts, .tsx, .mts and .cts files, plus Vue, Svelte and Astro components.

JavaScript

JavaScript follows the same conventions with its own extensions:

---
alwaysApply: false
globs: "**/*.test.js,**/*.test.jsx,**/*.spec.js,**/*.spec.jsx,**/__tests__/**,**/*.feature"
---

Other code pillars match .js, .jsx, .mjs and .cjs files and the same component files.

Python and pytest

Python’s Testing rule follows pytest’s file names and also matches any tests folder and conftest.py:

---
alwaysApply: false
globs: "**/test_*.py,**/*_test.py,**/tests/**,**/conftest.py,**/*.feature"
---

For other code, the pillars match .py files and .pyi stubs.

Java with Maven or Gradle

Java’s Testing rule matches the src/test folder that Maven and Gradle use, and classes ending in Test, Tests or IT:

---
alwaysApply: false
globs: "**/src/test/**,**/*Test.java,**/*Tests.java,**/*IT.java,**/*.feature"
---

Java’s other code pillars match .java files.

PHP with PHPUnit

A tests folder and classes ending in Test, as PHPUnit projects name them:

---
alwaysApply: false
globs: "**/tests/**,**/*Test.php,**/*.feature"
---

All other PHP pillars match .php files.

Every Testing rule also matches .feature files, which hold Gherkin scenarios, the plain-language test format that Cucumber and Behat read. Types & Schema adds schema files to its language’s source globs: .schema.json, .sql, .prisma, .graphql and .proto.

Cursor rules vs skills

Each skill is a folder holding a SKILL.md file. Cursor’s Agent Skills docs (2026) say it looks in .agents/skills and .cursor/skills in the project and in your home folder, and in .claude/skills and .codex/skills for compatibility. A skill’s frontmatter needs a name that matches the folder and a description. Here’s the Prickles Tooling skill’s frontmatter:

---
name: prickles-tooling
description: "Use before configuring or changing a linter, formatter, type checker, duplication check or CI gate in this repository, and whenever one of them fails. Holds the rest of the Prickles Tooling tenets, TA1 Linter as Law, TA2 Duplication Detection, which bind you exactly as the always-loaded Prickles entry does."
---

Cursor’s agent sees each skill’s name and description and decides when to read the rest. You can also type / and the skill’s name, which attaches it to one message. The Agent Skills specification (2026) puts the up-front cost at about 100 tokens a skill. A skill can take paths, and then Cursor offers it to the agent only while it reads or edits matching files. The agent still decides whether to use it.

Cursor attaches a glob rule itself, while a skill, like an Apply Intelligently rule, waits for the agent to choose it. Jude Gao’s AGENTS.md outperforms skills in our agent evals (Vercel, 2026) found that a skill left to the agent was never invoked in 56% of cases. The post doesn’t name the agent or the model.

What differs Glob rule Skill
Who loads it Cursor, when a matching file is in context Either the agent, when the description fits, or you with /
In every request Nothing until a file matches Its name and description
Suits Standards for a kind of file Steps for a kind of task

Cursor’s 2.4 changelog says skills suit “procedural ‘how-to’ instructions”. In April 2026, a Cursor support engineer advised on the forum that each skill’s description should be specific enough to trigger for the right tasks. The Prickles skills follow both. Each one covers a task, and its description opens with when to use it.

Cursor’s built-in /migrate-to-skills draws the same line. It turns Apply Intelligently rules into skills and leaves Always Apply and glob rules alone, because they have their own triggers.

Prickles keeps the pack’s skills in .agents/skills because other agents read that folder too. The Prickles packs for Codex, Gemini CLI and others write the same skill files there. A second pack replaces a skill rather than adding a copy, so each skill keeps the one home that F3 Don’t Repeat Yourself asks for.

Cursor rules vs AGENTS.md

Cursor reads AGENTS.md at the root and in subfolders, as plain Markdown with no frontmatter. Nested files combine with their parents. Where they differ, the more specific one wins. Cursor’s help page adds that it reads CLAUDE.md the same way and always applies it, whatever its frontmatter says.

So AGENTS.md and CLAUDE.md behave like Always Apply rules, with no way to attach either one to a kind of file. Keep anything conditional in .mdc rules. If the repository holds the same standards in another agent’s AGENTS.md or CLAUDE.md, Cursor sends both copies, so keep each rule in one place. CLAUDE.md vs AGENTS.md covers what every other agent reads.

How to check Cursor loads your rules

  1. Open Customize, then Rules. The entry should show as Always, and each pillar rule with its globs. The three skills are listed under Skills.
  2. Start a new chat and, without letting the agent read or search any file, ask it to quote the rule of TS8 One Concept Per Test word for word. Compare its answer with the entry. The entry has to be in its context already for the quote to match.
  3. Open a test file, ask the agent to add a test to it, and check that the prickles-testing rule is among the context it used.
  4. If no glob rule ever attaches, open the repository folder itself as the workspace. The 2025 forum report found that patterns which worked in a single folder matched nothing in a multi-folder workspace.

These checks come from the pack’s setup guide. The file locations, frontmatter and loading behaviour described here follow Cursor’s documentation as it read on 12 October 2026. The pack’s own tests check every file’s frontmatter, size and pointers. How the layout changes the code Cursor writes hasn’t been measured. The Prickles adherence test covers Claude Code alone. A pilot has run. The full test is scheduled for 17 October 2026.