Cursor Rules vs Agent Skills: I Tested Both. Here's When Each One Actually Works.

Source: Dev.to

Short answer

Rules are not deprecated. They do different things. Here’s what I found.

The setup

I created identical instructions in both formats and ran them through Cursor’s agent to see how each one behaves.

As a rule (.cursor/rules/jsdoc.mdc with alwaysApply: true)

---
description: "JSDoc rules"
alwaysApply: true
---
Always add JSDoc comments to exported functions.

As a skill (.cursor/skills/jsdoc/SKILL.md)

# JSDoc Skill
Always add JSDoc comments to exported functions.

Test 1 – Does each one work on a relevant task?

Prompt: “Create a utility function that formats dates”

• Rule: Added full JSDoc with @param and @returns. Followed the instruction.
• Skill: Same result – full JSDoc, followed the instruction.

When the task matches what the instruction is about, both rules and skills work fine.

Test 2 – Does each one load on an unrelated task?

I gave each setup a marker instruction (// RULE-LOADED or // SKILL-LOADED) and asked Cursor to write a Python “Hello, World!” script—nothing to do with JSDoc or JavaScript.

• Rule (alwaysApply: true): The marker comment appeared in the Python file. The rule loaded even though the task was unrelated.
• Skill: No marker. The skill did not load at all.

Core behavioral difference: Rules with alwaysApply: true are injected into every prompt regardless of relevance. Skills only load when the agent decides the task is relevant.

Test 3 – Cross‑tool discovery

Cursor’s docs say it auto‑discovers skills from .claude/skills/ and .codex/skills/ for cross‑tool compatibility. I placed a skill in .claude/skills/test/SKILL.md with a marker instruction and ran a relevant task.

The skill did not load. Cursor didn’t find it. This may be a CLI vs. GUI difference, or it may only work with .cursor/skills/. In any case, the claim that “put it in .claude/skills/ and every tool finds it” didn’t hold up in my testing.

When to use which

Use rules when:

• You want something enforced on every task (coding style, naming conventions, framework patterns).
• You need it to apply even when the task seems unrelated (e.g., “preserve comments” during a refactor).
• You want predictable, always‑on behavior.

Use skills when:

• You have procedural, multi‑step workflows (e.g., “here’s how to deploy to staging”).
• You want the instruction to load only when relevant (saves context‑window space).
• You’re building something portable across tools (once cross‑tool discovery works reliably).

The migration question

Cursor has a /migrate-to-skills command mentioned in its docs. I wasn’t able to test it through the CLI (it appears to be GUI‑only). The v2.4 changelog positions skills as complementary to rules: “Compared to always‑on, declarative rules, skills are better for dynamic context discovery and procedural how‑to instructions.”

That framing matches what I tested. Rules and skills aren’t competing; they handle different use cases.

What this means for your .cursor/rules/ files

• If you have .mdc rules with alwaysApply: true for things like coding style, error‑handling patterns, or framework conventions, keep using them. They work, they’re reliable, and they load every time.
• If you’re building multi‑step workflows or deployment procedures, skills are the better fit. They keep the context window clean by only loading when needed.

Don’t migrate everything to skills because someone said rules are deprecated. They’re not.

Links

• 77 free .mdc rules – a starting point.
• cursor‑lint – validates your rules and can auto‑generate them from your stack (npx cursor-lint --generate).
• Agent Skills spec – the open standard.
• Cursor docs on rules and skills.