Cómo clasificar qué Cursor Rules deberían convertirse en Skills y cuáles deberían quedarse (Guía 2026)

Se superponen en la superficie porque ambos pueden ser seleccionados por el agente basándose en una descripción.

Por el lado de las reglas, Cursor documenta cuatro modos de aplicación: Always Apply ("Aplicar a cada sesión de chat"), Apply Intelligently ("Cuando el Agente decide que es relevante según la descripción"), Apply to Specific Files ("Cuando el archivo coincide con un patrón especificado") y Apply Manually ("Cuando se menciona con @ en el chat"). La mecánica subyacente se expresa de forma aún más sencilla: "Si alwaysApply es true, la regla se aplicará a cada sesión de chat. De lo contrario, la descripción de la regla se presentará al Cursor Agent para que decida si debe aplicarse".

Por el lado de las skills, la historia de selección suena casi idéntica: "Cuando Cursor se inicia, descubre automáticamente las skills de los directorios de skills y las pone a disposición del Agente. Al agente se le presentan las skills disponibles y decide cuándo son relevantes según el contexto". El campo de frontmatter que lo impulsa se describe de la misma manera: description es "Utilizado por el agente para determinar la relevancia".

Así que ambos pueden seleccionarse por descripción y ambos pueden limitarse a archivos específicos. Las skills aceptan un campo paths donde, "Cuando se establece, la skill solo se muestra cuando el agente trabaja con archivos que coinciden", lo cual es la misma idea que los globs de una regla. Las skills también se pueden bloquear para que no se invoquen automáticamente: disable-model-invocation, "Cuando es true, la skill solo se incluye cuando se invoca explícitamente a través de /skill-name. El agente no la aplicará automáticamente según el contexto".

Donde realmente difieren es en lo que cada uno puede contener y cuándo se lee.

Una regla es texto que va en el prompt. Vale la pena citar cómo plantea Cursor la razón de ser de las reglas, porque nombra el problema subyacente: "Los modelos de lenguaje grandes no retienen memoria entre completados. Las reglas proporcionan un contexto persistente y reutilizable a nivel de prompt".

Una skill es un paquete. "Una skill es un paquete portable y con control de versiones que enseña a los agentes cómo realizar tareas específicas de un dominio. Las skills pueden incluir scripts, plantillas y referencias sobre las cuales los agentes pueden actuar utilizando sus herramientas". Y no es específico de Cursor: "Las skills funcionan en cualquier agente que admita el estándar Agent Skills".

Esa última frase es la parte que cambia la decisión. Uno de estos formatos se va contigo y el otro es una construcción propia de Cursor. La portabilidad también es la razón por la que la misma pregunta sigue reapareciendo cada vez que los equipos se mueven entre agentes, como al migrar reglas de Cursor a Codex.

Ejecutar el convertidor en todo. El comando existe, por lo que parece una decisión que Cursor ya ha tomado por ti. Convierte reglas dinámicas y comandos de barra elegibles; la palabra tiene un peso real, y una convención de aplicación constante no es un procedimiento de varios pasos esperando a ser empaquetado.

Mantener todo como reglas porque ya funcionan. Es defendible, pero tiene un costo que la documentación menciona: las reglas van al contexto del modelo al inicio. Las mejores prácticas de Cursor desaconsejan el exceso de volumen: "Mantén las reglas por debajo de las 500 líneas", "Divide las reglas grandes en múltiples reglas componibles" y "Haz referencia a archivos en lugar de copiar su contenido; esto mantiene las reglas cortas y evita que queden obsoletas a medida que cambia el código".

Colocar un archivo Markdown simple en el directorio de reglas. Este es el error con la documentación más clara, y Cursor ahora lo detalla: "Las reglas del proyecto deben usar la extensión .mdc. El sistema de reglas ignora un archivo .md simple en .cursor/rules porque no tiene frontmatter para especificar la descripción, los globs y alwaysApply". La documentación también ofrece la alternativa: "Si prefieres markdown simple, usa AGENTS.md en su lugar". Consolidar todo en ese archivo es una decisión propia, y la analizamos en mover un CLAUDE.md a AGENTS.md.

Asumir que las skills de tu directorio de inicio viajan con tu trabajo. En su mayoría no lo hacen, y Cursor establece el límite: "Cursor no copia ~/.agents/skills/ ni las skills locales no sincronizadas a Cloud Agents, sesiones SSH remotas de Agents Window o workers autohospedados". La documentación ofrece la solución para uno de esos casos: "En workers autohospedados, usa skills de proyecto desde el repositorio o integra las skills en la imagen del worker".

Escribir más reglas cada vez que el agente se equivoca en algo. La guía de Cursor es deliberadamente más pausada: "Empieza con algo sencillo. Añade reglas solo cuando notes que el Agente comete el mismo error repetidamente". Su lista de lo que se debe evitar es igualmente directa: "Copiar guías de estilo completas: usa un linter en su lugar", "Documentar cada comando posible", "Añadir instrucciones para casos extremos que rara vez se aplican" y "Duplicar lo que ya está en tu base de código". Las reglas que se acumulan tienden a producir la desviación descrita en cuando Cursor olvida las reglas de tu proyecto.

Tratar las skills como la memoria del agente. Son procedimientos empaquetados, no un registro de lo que decidió tu equipo. Esa distinción importa más de lo que parece, y lo explicamos en por qué las skills de los agentes no son memoria.

Una sola pregunta decide casi todos los casos: ¿esto es siempre cierto o es algo que haces?

Paso 1: Clasificar cada elemento en siempre cierto, limitado a archivos o procedimental

Siempre cierto pertenece a una regla con alwaysApply activado. Encabezados de derechos de autor, la instrucción de leer los archivos de origen antes de proponer cambios, directorios que nunca deben editarse... el propio ejemplo de aplicación constante de Cursor es exactamente este tipo de lista. Estos elementos consumen pocos tokens y omitirlos sale caro, y no querrás que el agente decida si son relevantes.

Limitados a archivos pueden ir en cualquier dirección, y el desempate honesto es la portabilidad. Una regla con globs y una skill con paths hacen el mismo trabajo. Si es probable que la convención también sea importante en otro agente, el formato de skill es el que viaja.

Procedimental pertenece a una skill, y aquí es donde el convertidor demuestra su valor. Cualquier cosa con pasos, una plantilla que rellenar, un script que ejecutar o material de referencia adjunto es para lo que se diseñó el formato de skill: puede contener "scripts, plantillas y referencias sobre las cuales los agentes pueden actuar utilizando sus herramientas" y cargarlos solo cuando sea necesario. Forzar eso en una regla significa que todo el procedimiento se queda en tu prompt, independientemente de si la tarea de hoy lo requiere o no.

El propio alcance de repositorio de Cursor es una pista útil sobre la intención: "Las skills en directorios de proyectos anidados se limitan automáticamente a los archivos dentro de ese directorio", por lo que una skill colocada junto al paquete al que se aplica queda limitada sin ninguna configuración. Ese es el mismo principio de localidad de archivos que examinamos en limitar el alcance de las instrucciones a los archivos.

Paso 2: Decidir quién elige cada elemento y establecer el campo correspondiente

Para cada elemento, anota quién debería elegirlo: siempre cargado, seleccionado por el agente, coincidente con archivos o invocado manualmente. Luego, establece el campo correspondiente, porque los valores predeterminados no son los mismos en ambos lados.

Una regla obtiene alwaysApply: true para siempre, una description para selección por el agente, globs para coincidencia de archivos, o ninguno para manual; Cursor señala que sin descripción ni globs, una regla se "incluye solo cuando mencionas la regla con @ en el chat".

Una skill se selecciona por el agente de forma predeterminada, ya que Cursor presenta las skills disponibles y el agente decide su relevancia a partir de la descripción. Para que sea solo manual, establece disable-model-invocation. Para limitarla a archivos, establece paths. Y ten en cuenta el comportamiento de invocación: una skill invocada con una barra diagonal "se adjunta a un mensaje", por lo que una skill que deseas activa durante toda una sesión requiere una configuración diferente a la de una que deseas para un solo turno.

Una regla de nomenclatura que debes respetar: el name de una skill debe contener "solo letras minúsculas, números y guiones" y "debe coincidir con el nombre de la carpeta contenedora".

Paso 3: Escribir por qué existe cada convención, en algún lugar que ninguno de los formatos controle

Tanto las reglas como las skills contienen instrucciones. Ninguno de los dos es un buen lugar para el argumento detrás de la instrucción, y el propio consejo de Cursor es empujar el contenido fuera de estos archivos en lugar de meterlo en ellos: haz referencia a archivos en lugar de copiarlos, señala ejemplos canónicos, mantén las reglas cortas.

Eso deja un vacío. "Nunca alteres un tipo de columna in-situ" es una regla. El porqué (qué migración falló, en qué mes y qué acordó el equipo después) es lo que evita que alguien elimine la regla el próximo trimestre. Colócalo en un lugar que sobreviva a ambos formatos.

Las reglas y las skills responden a cómo debe comportarse el agente. Son un mal hogar para lo que decidió tu equipo y por qué, que es lo que la gente sigue intentando almacenar en ellos. MemoryLake es un almacén en el que escribes esas decisiones a propósito, manteniéndolas separadas de la configuración de cualquier editor y legibles desde cada asistente que conectes. Tú mismo escribes las entradas, con tus propias palabras. No se lee, escribe ni elimina nada de los sistemas de Cursor ni del almacén de ningún otro proveedor; tus reglas, skills y repositorios permanecen completamente bajo sus propios controles.

Paso 1: Crear una clave API

Genera una clave desde el panel de control. Es lo que permite que Cursor, un agente de terminal y un asistente de chat accedan al mismo conjunto de datos sin que cada uno de ellos tenga que llevar su propia copia del razonamiento.

Paso 2: Subir tus primeras memorias

Comienza con las decisiones detrás de las reglas: el enfoque que se descartó y con qué argumentos, el incidente que una convención busca prevenir, la persona a la que preguntar antes de tocar un servicio específico. Un archivo de reglas contiene la instrucción; casi nunca contiene el motivo.

Paso 3: Conectar tu IA y agentes

Apunta tus herramientas a la capa de memoria para que esos datos se carguen al inicio de una sesión en lugar de inferirse de un archivo de configuración. Luego, realiza la prueba que realmente demuestra algo: pídele a un asistente diferente que te devuelva una de las decisiones. Si responde, tu razonamiento habrá dejado de estar ligado al formato de archivo de un solo editor.

El primer cambio es que el convertidor se vuelve seguro de usar, porque sabes con qué alimentarlo. Entran los procedimientos con pasos, scripts o plantillas. Las convenciones de aplicación constante se quedan donde están.

El segundo es que tu prompt se vuelve más pequeño. Todo lo que tiene alwaysApply activado se lee en cada sesión; los procedimientos movidos a skills se cargan bajo demanda. Ese es el beneficio mecánico real, y solo llega si mueves las cosas correctas.

El tercero es que el requisito de .mdc deja de costarle una tarde a cualquiera. El sistema de reglas ignora un archivo .md simple en el directorio de reglas, y Cursor ahora lo dice en el mismo párrafo que la solución.

El cuarto es que las ejecuciones remotas y en la nube dejan de darte sorpresas. Las skills locales no sincronizadas y ~/.agents/skills/ no llegan a Cloud Agents, sesiones SSH remotas ni workers autohospedados, por lo que cualquier cosa de la que dependa una ejecución en la nube pertenece al repositorio.

El quinto es que la portabilidad se convierte en algo que eliges en lugar de algo que descubres. Se describe que las skills funcionan en cualquier agente que admita el estándar; las reglas son una construcción de Cursor. Saber en qué formato está cada parte de tu contexto es la diferencia entre una migración y una reescritura, el mismo problema que otro proveedor documenta desde el otro lado, como en qué archivo de instrucciones de Copilot se lee.

Mantén las listas de aplicación constante cortas y absolutas. Se leen en cada sesión, por lo que cada línea compite con la tarea real.

*Dale a cada descripción un cuándo, no solo un qué.* En ambos lados, la descripción es lo que el agente utiliza para juzgar la relevancia.

Coloca en el repositorio las skills que necesita una ejecución en la nube. Los directorios de skills a nivel de proyecto viajan; está documentado que los locales no sincronizados se quedan en tu máquina.

Una skill por procedimiento, en su propia carpeta. La identidad de la skill proviene de la carpeta que contiene SKILL.md, y las carpetas de categorías superiores son solo organizativas.

Usa el anidamiento en lugar de listas de globs siempre que puedas. Una skill dentro de un directorio de paquete se limita a ese directorio automáticamente.

Respeta las reglas de extensión. .mdc para reglas de proyecto; el Markdown simple pertenece a AGENTS.md en su lugar.

Mantén el razonamiento en otro lugar. Un archivo de reglas que también lleva su propio historial deja de ser corto, y la brevedad es lo que hace que funcione.

Cursor documenta ambos mecanismos claramente; solo que no los pone en la misma página. Las reglas son contexto a nivel de prompt, incluidas al inicio del contexto del modelo, con cuatro modos de aplicación y el requisito estricto de que las reglas del proyecto usen la extensión .mdc. Las skills son paquetes portables y con control de versiones que pueden contener scripts, plantillas y referencias, cargan sus recursos bajo demanda y funcionan en cualquier agente que admita el estándar Agent Skills.

La cuestión de la clasificación es más sencilla de lo que sugiere la comparación de características. Las convenciones que siempre son ciertas se quedan como reglas de aplicación constante, porque no quieres que se juzgue su relevancia. Los procedimientos con pasos y archivos adjuntos se convierten en skills, porque para eso sirve la carga bajo demanda. Las guías limitadas a archivos pueden ser cualquiera de las dos, y la portabilidad es el desempate más sensato.

Vale la pena anotar dos límites en una nota adhesiva: el sistema de reglas ignora un archivo .md simple en .cursor/rules, y las skills locales no sincronizadas no llegan a Cloud Agents, sesiones SSH remotas ni workers autohospedados.

Luego, da el único paso que ninguno de los dos formatos admite. Registra por qué existe cada convención en algún lugar que no sea un archivo de reglas o un paquete de skills, para que la próxima persona que lea la regla también encuentre la razón por la que está ahí.