Cursor Skills vs Rules

Cursor ships a built-in skill called /migrate-to-skills. To do its job it has to decide, mechanically, which of your existing rules are really skills in disguise. Those criteria are the best available answer to this question, and they're published.

The short version: a rule that always applies, or that applies to specific file globs, stays a rule. A rule that the agent decides to apply based on its description was always a skill. A slash command becomes a skill that only you can invoke.

What /migrate-to-skills actually converts

Verbatim from Cursor's documentation:

Dynamic rules: Rules that use the "Apply Intelligently" configuration—rules with alwaysApply: false (or undefined) and no globs patterns defined. These are converted to standard skills.

Slash commands: Both user-level and workspace-level commands are converted to skills with disable-model-invocation: true

Read as a decision table, that gives you this:

The logic underneath is consistent: if something has a deterministic trigger — always, or these files, or you asked for it by name — a rule expresses it fine. The moment the trigger becomes a judgement call about relevance, you're describing a skill, and the skills system is built for that decision in a way the rules system isn't.

That's the converter's behavior. The reading of it in that last paragraph is ours.

The two systems, side by side

Cursor's own summary is worth quoting because it's compact and correct: use rules for "short coding guidelines and constraints"; use skills for a "detailed, repeatable process."

What Cursor does not document

Two gaps matter, and both are being filled with guesswork elsewhere.

There is no documented precedence between a rule and a skill. Cursor documents a precedence chain for rules against other rules — Team → Project → User. It documents nothing about what happens when an always-on rule and an active skill give contradictory instructions. A widely-shared blog post reports that rules won three times out of three in the author's own informal testing. That may well be what happens; it is one person's unreplicated result, not documented behavior, and we're not going to launder it into a fact by repeating it. If a conflict would be expensive for you, don't write one and hope.

There is no documented context budget for skills. Cursor says only that "Skills load resources on demand, keeping context usage efficient." Codex and OpenClaw both publish numbers you can write against; Cursor doesn't. So the usual argument for moving things out of always-on rules — that you're reclaiming a measurable amount of context — is directionally sound here but unquantified.

Where commands fit now

Cursor's help documentation treats this as a three-way split: rules, skills, and commands. That's still how it reads in the UI, but the boundary has moved. /migrate-to-skills converts commands into skills with disable-model-invocation: true, which produces exactly what a command was: something only you can invoke, never the model.

So the third category is now better understood as a setting on a skill than a separate system:

---
name: deploy-production
description: Deploys the current branch to production.
disable-model-invocation: true
---

That's a command. It appears under /, and the agent will never decide to run it on its own. Which is the behavior you want for anything with consequences.

This is not a Cursor quirk, incidentally. Claude Code's documentation states that custom commands "have been merged into skills," and OpenClaw's Claude migration converts .claude/commands/ files into skills with the same disable-model-invocation: true flag. Three ecosystems, independently, landed on the same answer: a command is a skill that doesn't invoke itself.

Deciding, case by case

The pattern: rules carry facts and constraints that hold regardless of the task. Skills carry procedures invoked for a particular kind of work. Where the trigger is a file rather than a phrasing, paths on a skill and globs on a rule are both defensible — pick the rule if it's a short standing constraint, the skill if it's a procedure with steps.

paths and globs are not the same mechanism

Both take glob patterns and both scope by file. They do different jobs:

• A rule's globs injects the rule when matching files are in play. The rule's content is short and lands directly in context.
• A skill's paths surfaces the skill for consideration when the agent is reading or editing matching files. The skill's body still loads only if the agent decides to use it, and it can pull in bundled scripts and references afterwards.

So globs is about inclusion; paths is about eligibility. If what you have is three lines of standing guidance, globs on a rule is simpler. If what you have is a procedure with steps and supporting files, paths on a skill is the one that scales.

The migration, in practice

If you have accumulated rules over a year of using Cursor, the quickest useful thing is to run /migrate-to-skills and read what it proposes rather than deciding from first principles. Its criteria are mechanical and its output is reviewable.

The one judgement it can't make for you: a rule set to "Apply Intelligently" that turns out to be relevant to everything was never really a dynamic rule — it's an always-on constraint that was mislabelled, and it belongs in alwaysApply: true or AGENTS.md. Migration will convert it to a skill because that's what the frontmatter says. Reading the results is still your job.

Caveats

• We have not run Cursor, /migrate-to-skills, or any conflict test. The conversion criteria are quoted from Cursor's documentation; the reasoning built on top of them is our editorial interpretation and is marked as such.
• The claim that rules override skills in conflicts is not documented by Cursor and is not repeated here as fact.
• Rule types, frontmatter fields, and the Team → Project → User chain are documented behavior as of August 2026.

Sources

• Cursor — Agent Skills (official docs) — /migrate-to-skills conversion criteria, paths, disable-model-invocation
• Cursor — Rules (official docs) — rule types, .mdc requirement, precedence chain
• Cursor — Skills (help centre) — Cursor's own rules/skills/commands framing
• Cursor 2.4 changelog — the release that introduced skills
• Claude Code — Skills (official docs) — the parallel commands-merged-into-skills change