Claude Code skills vs Cursor rules

The file format

A Claude Code skill is a single SKILL.md file with YAML frontmatter (name, description, optional license, version, tags), followed by markdown instructions the model reads when it judges the skill relevant. Skills are loaded by the harness on demand — Claude Code only pulls a skill into context when the description matches the task.

---
name: code-review
description: Reviews diffs for correctness, security, and readability before merge.
license: MIT
---

# Code review

When asked to review a diff:

1. Read the full diff before commenting on any chunk.
2. Flag any logic that loses an error path.
3. ...

A Cursor rule is either a single .cursorrules file at the repo root (project-wide, always-on), or a set of .mdc files in .cursor/rules/ (scoped, attached when their globs match). .mdc adds frontmatter for description, globs, and alwaysApply.

Scope and activation

The biggest practical difference is how each tool decides when a rule applies.

• Claude Code skills activate by description matching. The model reads the one-line description and decides if the skill is relevant. Good when the trigger is intent-based ("review this PR", "write tests for X").
• Cursor rules activate by file globs (or always-on for .cursorrules). Good when the rule is anchored to file types — "any time you edit *.tsx, prefer server components."

Both can carry the same content. But a description-triggered skill works better for "do this when asked", while a glob-triggered rule works better for "always do this in this kind of file."

Install paths

• Claude Code → .claude/skills/<slug>/SKILL.md
• Cursor (project rules) → .cursor/rules/<slug>.mdc
• Cursor (legacy, always-on) → .cursorrules at repo root
• Codex CLI → .codex/skills/<slug>/SKILL.md

With the skills-hub CLI, the same source manifest writes to the right path for each target — pass --target cursor and you get an .mdc file with the right frontmatter; pass --target claude-code and you get a SKILL.md.

When to use which

Three rules of thumb, after watching teams adopt both:

1. Use a skill when the trigger is "the user asks for X." Code review, deploy checklist, writing an ADR, generating tests for a service — these are intent-driven. The agent should pull the skill when relevant and ignore it otherwise. Example: code-review-and-quality.
2. Use a rule when the trigger is "we always do X in this kind of file." Glob-scoped conventions: server components for app/**/*.tsx, Prisma select (not include) for **/*.repository.ts. The rule is about shape, not intent.
3. Use both when the workflow spans editor and agent. Security and OWASP knowledge belongs in both — you want it as a cursor rule when editing handlers, and as a skill when the agent does an audit. Install once with two targets:

   npx @skills-hub-ai/cli install common-owasp \
     --target claude-code,cursor

Skills that work well in both

• common-owasp — security mindset, scoped to handlers and route files in Cursor.
• test-driven-development — intent-driven for "write a test for X", glob-driven for **/*.test.ts.
• frontend-ui-engineering — UI conventions belong as a Cursor rule on **/*.tsx.
• documentation-and-adrs — intent-driven skill (ask for an ADR), with a Cursor rule on docs/adr/**.
• shipping-and-launch — pure skill territory; deploys are intent-driven, not file-shaped.
• security-and-hardening — both. Hardening checklist on demand, plus glob-scoped reminders for auth code.

One source of truth, two targets

Don't fork your knowledge. Author the skill once as SKILL.md, register it on skills-hub.ai, and install with --target per consumer. The CLI handles the format translation, generates a glob list when emitting .mdc, and pins both copies in .skills.json so your team stays in sync regardless of which editor they prefer.

Keep going

• Install Claude skills in 30 seconds
• Building your first AI coding skill
• Cursor rules registry
• Claude skills registry