Claude Skills vs Cursor Rules: ¿cuál usar?

Si programas con IA en 2026, seguramente has terminado con instrucciones repartidas en dos sitios: una carpeta .cursor/rules que lee Cursor, y un directorio de skills que lee Claude. Resuelven el mismo problema, enseñarle a tu IA cómo funciona tu proyecto para que dejes de repetirte, y lo resuelven de forma lo bastante distinta como para que elegir mal te cueste tokens, dolores de cabeza de sincronización, o ambas cosas.

Llevamos SkillProof, donde instalamos y probamos skills de Claude en una máquina limpia antes de listarlas. Eso nos da un punto de vista concreto sobre esta comparación: hemos convertido docenas de archivos de reglas en skills durante nuestras pruebas, y hemos visto fallar a ambos formatos de maneras que su documentación no menciona.

Resumen: Las reglas de Cursor son más simples y viven más cerca de tu editor. Las skills de Claude son más capaces y viajan contigo entre herramientas. Las reglas ganan cuando la instrucción debe aplicarse siempre a cada archivo que cumpla un patrón. Las skills ganan cuando la instrucción es condicional, incluye archivos de apoyo, o necesita funcionar fuera de un solo IDE. La mayoría de desarrolladores que usan ambas herramientas deberían mantener las convenciones del proyecto en un archivo compartido y meter todo lo condicional en skills.

	Reglas de Cursor	Skills de Claude
Alcance	Por proyecto (.cursor/rules/) o por usuario (ajustes)	Global (~/.claude/skills/) o por proyecto (.claude/skills/)
Activación	Patrones glob, siempre activas, o coincidencia de descripción	Coincidencia de descripción, decidida por el modelo
Contenido	Instrucciones planas	Instrucciones más scripts, plantillas, archivos de referencia
Portabilidad	Solo Cursor	Claude Code, Claude Desktop, claude.ai, el Agent SDK
Coste de contexto	Texto completo de la regla al adjuntarse; las reglas siempre activas viajan en cada petición	~100 tokens de metadatos hasta activarse, luego el cuerpo
Ecosistema	Grande; miles de .cursorrules compartidos en GitHub	Más pequeño pero creciendo; incluye el conjunto oficial de Anthropic
Cultura de testing	Prácticamente ninguna	Casi ninguna; nosotros probamos las nuestras

Ahora el detalle, porque la tabla esconde las partes interesantes.

Qué son en realidad las reglas de Cursor

Cursor tiene dos generaciones de la misma idea. El archivo .cursorrules original va en la raíz de tu proyecto: un único archivo de texto plano con instrucciones que se inyectan en cada petición de IA en ese repo. Está obsoleto pero sigue funcionando, y buena parte de los ejemplos públicos todavía lo usan.

El sistema actual es un directorio .cursor/rules/ con archivos .mdc, cada uno con frontmatter que controla cuándo se aplica. Cuatro modos: Always (cada petición), Auto Attached (se activa cuando hay en contexto un archivo que cumple un glob, así que globs: *.tsx se adjunta solo durante trabajo en React), Agent Requested (el modelo lee la descripción y decide), y Manual (solo cuando la mencionas con @). Cursor también lee AGENTS.md, algo que importa más adelante en este artículo. También hay reglas a nivel de usuario, configurables en los ajustes de Cursor, que se aplican en todos los proyectos.

Si eso te suena parecido al sistema de activación de una skill, en parte lo es. Las reglas Agent Requested se activan por descripción exactamente igual que las skills. La diferencia está en lo que pasa después de la activación, y ahí llegaremos.

Dónde ganan las reglas de verdad

Probamos skills de Claude para vivir, así que esperarías que defendiéramos las skills en todo. No lo haremos, porque las reglas tienen fortalezas reales.

Las reglas siempre activas son más fáciles de razonar. Una regla con alwaysApply: true está en el contexto de cada petición, punto. No hay activación que falle, ni descripción que se equivoque, ni sesión de "por qué no se activó". Cuando probamos skills, el fallo de activación es uno de los dos defectos más comunes que encontramos. Las reglas en modo always o glob estructuralmente no pueden tener ese defecto. Para un pequeño conjunto de leyes duras del proyecto ("nunca toques los archivos generados en src/gen/"), una regla tonta siempre activa gana a una condicional ingeniosa.

El alcance por glob es preciso. globs: **/*.sql significa que tus convenciones SQL se adjuntan durante el trabajo con SQL y nunca en otro caso. El mapeo de tipo de archivo a instrucción es mecánico y predecible. Las skills se aproximan a esto con la redacción de la descripción ("usar al escribir SQL"), que funciona bien en la práctica pero es una decisión de criterio del modelo en vez de una coincidencia de patrón.

Viven donde escribes. Las reglas se integran con el autocompletado Tab de Cursor, las ediciones en línea y el modo agente sin ninguna configuración. Nada que instalar, ninguna convención de directorios que aprender más allá de soltar archivos en una carpeta.

El ecosistema es enorme. Busca .cursorrules en GitHub y encontrarás miles de archivos que cubren casi cualquier framework. La calidad varía muchísimo, pero la cobertura no.

Lo que hacen las skills que las reglas no pueden

Si el formato te resulta nuevo, nuestra guía completa de skills de Claude cubre la anatomía. Aquí va la parte relevante para la comparación.

Activación condicional con una economía real detrás. Una skill se carga por etapas. Al arrancar, Claude lee solo el nombre y la descripción de cada skill, unos 100 tokens. El cuerpo se carga cuando la descripción coincide con tu petición. Los archivos de referencia se cargan más tarde todavía, y solo si hace falta. Cincuenta skills instaladas están inactivas por unos pocos miles de tokens en total. Cincuenta reglas siempre activas serían una catástrofe de contexto, por eso Cursor limita y avisa sobre la longitud de las reglas. La divulgación progresiva significa que una skill puede ser enorme sin ser cara, y eso cambia lo que te puedes permitir escribir.

Archivos incluidos. Una skill es una carpeta, no un archivo. La skill docx de Anthropic incluye scripts de Python que construyen documentos Word. La skill skill-creator incluye plantillas y un arnés de evaluación. Una skill de revisión de código puede llevar una rúbrica de severidad como archivo de referencia separado que se carga solo durante las revisiones. Las reglas son texto que describe lo que el modelo debería hacer. Las skills pueden incluir la herramienta para hacerlo, y el modelo ejecuta el script en vez de improvisar el resultado.

Portabilidad. Una skill que escribes para Claude Code también funciona en Claude Desktop, en claude.ai, y en cualquier cosa construida sobre el Agent SDK. Tus convenciones de git te siguen de la terminal al chat y a un agente personalizado. Una regla de Cursor funciona en Cursor. Si alguna vez cambias de editor, o usas Claude para trabajo que no es de editor como escribir o analizar datos, el formato de skill es el que sobrevive al cambio. Este es el argumento más fuerte a favor de las skills como alternativa a las reglas de Cursor: escribes las instrucciones una vez y no quedan atadas a un solo producto.

Las skills pueden actuar, no solo aconsejar. Como Claude Code ejecuta comandos, una skill puede decir "ejecuta este script y pega la salida" en vez de "así es como uno podría formatear el resultado". La diferencia entre describir un comportamiento y entregarlo es la misma diferencia entre una guía de estilo y un linter.

Lo que hacen las reglas que las skills no pueden

Dos cosas, y no son pequeñas.

Contexto nativo del IDE. Las reglas participan en todo lo que hace Cursor: autocompletados mientras escribes, ediciones en línea con Cmd+K, el panel de agente. Las skills operan donde opera Claude, que hoy significa la CLI, la app de escritorio y la web, no dentro del editor de otra empresa. Si todo tu uso de IA ocurre en la tecla Tab de Cursor, las skills no te alcanzan ahí.

Aplicación por glob. No existe un equivalente en skills de "adjunta estas instrucciones siempre que haya un archivo .proto en contexto". El modelo decide a partir de descripciones, y aunque es bueno en esto, no es una garantía. Para instrucciones que deben correlacionar con el tipo de archivo en vez de con el tipo de tarea, las reglas con alcance por glob son el mecanismo mejor, sin discusión.

La ruta de migración, en ambos sentidos

Convertir un archivo .cursorrules en una skill

Toma un archivo de reglas típico:

You are an expert React and TypeScript developer.

- Functional components with hooks only, no classes
- Named exports, never default exports
- Tailwind for styling, no inline style objects
- All API calls go through src/lib/api.ts
- Tests in Vitest, colocated as *.test.tsx

La conversión consiste sobre todo en añadir una activación y estructura:

---
name: react-conventions
description: React/TypeScript conventions for this repo. Use when
  writing or reviewing components, hooks, styles, API calls, or
  frontend tests.
---

## Components
- Functional components with hooks. No class components.
- Named exports only. No default exports.

## Styling
- Tailwind utility classes. Never inline style objects.

## Data access
- Every API call goes through `src/lib/api.ts`. Do not call
  fetch directly from a component.

## Tests
- Vitest, colocated next to the component as `*.test.tsx`.

Suéltalo en .claude/skills/react-conventions/SKILL.md y se activará en el trabajo de frontend de ese repo. Cambiaron tres cosas y cada una importa. La línea de persona ("You are an expert...") desaparece porque no hace nada; el modelo no mejora en React porque le digan que es un experto. La descripción ahora enumera actividades concretas, porque ese campo es la activación y las descripciones vagas son la razón número uno por la que las skills se quedan inertes. Y las viñetas ganaron encabezados, ya que el cuerpo de una skill debe poder hojearse rápido en el momento de la carga. Nuestra guía para escribir skills cubre a fondo la parte de redactar la descripción; es el paso que la gente estropea.

Ya que estás, pregúntate si alguna viñeta debería convertirse en un archivo. Si tu archivo de reglas describe un formato de respuesta de API, pon un ejemplo real de respuesta en reference.json junto al SKILL.md y apunta hacia él. Esa opción simplemente no existe en el formato de reglas.

En la otra dirección

Convertir una skill en una regla de Cursor significa aplanarla. Toma el cuerpo de tu SKILL.md, quita el frontmatter, y guárdalo como .cursor/rules/react-conventions.mdc con un frontmatter nuevo:

---
description: React/TypeScript conventions for this repo
globs: src/**/*.tsx,src/**/*.ts
alwaysApply: false
---

- Functional components with hooks. No class components.
- Named exports only. No default exports.
...

Pierdes los archivos incluidos, así que cualquier cosa que fuera un script se convierte en una descripción de lo que hacía el script. Pierdes la divulgación progresiva, así que recorta sin piedad: un cuerpo de skill de 3.000 tokens debería convertirse en una regla de 500 tokens, quedándote solo con lo que los modelos de Cursor realmente necesitan por petición. Mantén el glob ajustado para que la regla no grave trabajo que no le corresponde.

Usar ambas sin duplicarte

Muchos desarrolladores usan Cursor para editar y Claude Code para trabajo de agente en el mismo repo. La trampa es mantener dos copias de las mismas convenciones que se desalinean en menos de un mes.

La solución que nos ha funcionado: elige un hogar canónico por instrucción, según su forma.

Los hechos compartidos del proyecto van en AGENTS.md. Ambas herramientas lo leen. Notas de arquitectura, comandos de build, estructura de directorios, la lista de "nunca toques estos archivos". Un archivo, cero duplicación, y también sirve a los humanos recién llegados.

Las instrucciones con forma de glob se quedan en .cursor/rules. Convenciones por tipo de archivo que deben adjuntarse mecánicamente en el editor.

Las instrucciones con forma de tarea y multiherramienta se convierten en skills. Metodología de depuración, checklists de revisión, procedimientos de lanzamiento, cualquier cosa con un script o una plantilla, cualquier cosa que también quieras disponible en Claude Desktop o en el chat.

Si una instrucción realmente necesita existir en ambos formatos, haz que la regla sea un puntero, no una copia: un .mdc de dos líneas que diga "las convenciones de X viven en .claude/skills/x/SKILL.md; síguelas" mantiene una sola fuente de verdad. Algunos equipos automatizan la conversión en CI en vez de esto, regenerando archivos .mdc a partir de los cuerpos de SKILL.md en cada commit. Es más maquinaria de la que la mayoría de proyectos necesita, pero gana al desajuste silencioso en un equipo grande.

Una cosa de la que te alejaríamos: pegar el mismo documento de 2.000 palabras textualmente en ambos sistemas. En Cursor infla cada petición. En Claude suele ser señal de que el contenido debería dividirse en un núcleo pequeño siempre relevante y un conjunto de skills condicionales. Es el mismo razonamiento que en skills vs MCP: ajusta el mecanismo a la forma del problema en vez de forzar a una herramienta a hacerlo todo.

Tampoco nadie prueba las reglas

Aquí está la parte de esta comparación que nadie más te va a dar, porque es toda nuestra razón de existir.

Cuando empezamos a probar skills comunitarias de Claude, alrededor de la mitad fallaban al primer intento: activaciones rotas, instrucciones que el modelo no puede seguir, resultados no mejores que la base. Documentamos la taxonomía de fallos en por qué la mitad de las skills de Claude no funcionan. La pregunta incómoda que sigue es si los miles de archivos .cursorrules compartidos en GitHub son mejores.

No lo son, y estructuralmente no pueden serlo. Se aplican los mismos incentivos: las reglas se publican desde el flujo de trabajo de un solo autor, nunca se verifican en una instalación limpia, nunca se miden contra una base sin regla, y reciben estrellas según la calidad del README en vez de los resultados. Cuando hemos desmenuzado archivos de reglas populares, encontramos los mismos defectos por los que penalizamos a las skills. Relleno de persona que consume contexto y no cambia nada. Instrucciones escritas para una versión de modelo dos generaciones atrás. Viñetas contradictorias ("sé conciso" cuarenta líneas después de "explica siempre tu razonamiento en detalle"). Reglas tan largas que desplazan al código que se supone que deben mejorar.

Las reglas esquivan un modo de fallo, ya que una regla siempre activa no puede dejar de activarse. Todos los demás modos de fallo se transfieren directamente. Un documento de convenciones que empeora el resultado es igual de dañino en cualquiera de los dos formatos; el formato solo cambia cómo se entrega.

Así que, sea cual sea el lado de esta comparación en el que caigas, el consejo operativo es idéntico: no instales archivos de instrucciones compartidos por fe. Compara la salida con y sin las instrucciones en una tarea real de tu propio proyecto. Diez minutos de comparación ganan a cualquier contador de estrellas. Para las skills, ya hemos hecho ese trabajo en nuestra colección de código probada, donde entradas como systematic-debugging llevan evidencia de antes/después en vez de promesas. Para las reglas de Cursor, que sepamos, nadie está haciendo ese trabajo en absoluto. Saca tú mismo la conclusión de cuánto vale la mitad de ellas.

Preguntas frecuentes

¿Puede Claude Code leer mi archivo .cursorrules directamente? No de forma automática. Claude Code lee CLAUDE.md, AGENTS.md, y sus directorios de skills, e ignora .cursorrules y .cursor/rules. Puedes pedirle que lea el archivo en una sesión, pero para algo permanente, convierte el contenido en una skill o mueve las partes compartidas a AGENTS.md.

¿Las reglas de Cursor cuestan tokens igual que las skills? Más, en la mayoría de configuraciones. Una regla siempre activa viaja en cada petición a longitud completa. Una skill queda inactiva en unos 100 tokens de metadatos y paga por su cuerpo solo cuando se activa. Las reglas con alcance por glob acortan la diferencia, ya que se adjuntan solo durante trabajo que coincide, pero no existe un equivalente en reglas de cargar material de referencia bajo demanda.

¿Debería convertir todas mis reglas de Cursor en skills? No. Mantén como reglas las convenciones con alcance por glob y por tipo de archivo si trabajas en Cursor; ese mecanismo es genuinamente mejor para ellas. Convierte el material con forma de tarea: flujos de trabajo, checklists, cualquier cosa con plantillas o scripts, cualquier cosa que quieras fuera del editor.

¿Existe un estándar compartido que lean ambas herramientas? AGENTS.md es lo más parecido. Cursor y Claude Code lo leen ambos, junto con una lista creciente de otros agentes. Son instrucciones planas siempre activas sin carga condicional, así que trátalo como el hogar de un pequeño núcleo de hechos del proyecto en vez de un vertedero.

¿Son mejores para un equipo las skills de Claude o las reglas de Cursor? Las skills se registran en git bajo .claude/skills/ y se versionan como código, y las reglas se registran bajo .cursor/rules/ de la misma manera, así que ambas se distribuyen bien. La pregunta del equipo es realmente sobre superficie: si todos viven en Cursor, las reglas los alcanzan sin ninguna configuración. Si el equipo también usa Claude Code, Desktop, o agentes construidos sobre el SDK, las skills son el único formato que cubre todas las superficies, y el patrón de sincronización de arriba evita que los dos se desalineen.