Cursor Rules: always apply, globs y agents.md

Cuando ya tienes tu PRD y tus especificaciones técnicas listas, el siguiente paso es aprender a crear Cursor Rules para definir las limitantes con las que cada agente va a trabajar. Este contenido es para desarrolladores que usan Cursor con agentes de IA y quieren que humanos y modelos implementen con criterios consistentes.

Sin reglas claras, un agente puede proponerte una arquitectura que no encaja con tu proyecto. Las reglas funcionan como un contrato de ingeniería: le dicen al agente cómo escribir el código, cuándo aplicar cada convención y qué límites respetar. Y aquí viene lo interesante: no todas las reglas se cargan igual ni en el mismo momento.

Qué son las Cursor Rules y para qué sirven

Las reglas son el contrato de ingeniería de tu proyecto. Le indican tanto a los agentes como a los humanos cómo implementar con criterios consistentes, evitando que cada quien programe a su manera.

Un detalle clave del prompt inicial: pedir que las reglas sean fáciles de leer para agentes y humanos. Eso importa porque más adelante tú mismo vas a revisarlas y validarlas.

En el ejemplo trabajado con el modelo Opus, se apunta el agente a la carpeta completa de specs en lugar de un archivo específico, para que lea todo el contexto. Luego se pide generar un archivo de regla por cada categoría del stack:

• Reglas de TypeScript, React, Vitest y la lógica de evaluación de los flags.
• Estilos para el CSS.
• Reglas de arquitectura transversales al proyecto.

Cada regla necesita un scope correcto, y ahí está la parte que muchos pasan por alto.

¿Qué es una Cursor Rule? Es un archivo que define las convenciones y límites con los que un agente de IA debe implementar código en tu proyecto. Vive dentro de la carpeta .cursor/rules y garantiza consistencia entre agentes y humanos.

Cuáles son los cuatro tipos de reglas en Cursor

La documentación oficial de Cursor define cuatro niveles distintos de reglas, cada uno con su alcance [03:22].

• Reglas por proyecto: las que construye tu agente dentro de .cursor/rules.
• Reglas por usuario: instaladas en tu máquina y aplican a todos tus proyectos.
• Reglas a nivel de team: cuando tu organización paga Cursor y define reglas para todo el equipo.
• El agents.md: el archivo de entrada que los modelos LLM cargan primero en el contexto.

Un apunte útil: cuando usas Cloud Code ese archivo se llama cloud.md, mientras que para otros modelos de lenguaje se usa agents.md.

Por qué se usa .mdc en vez de Markdown plano

Cada regla se guarda en un archivo .mdc dentro de .cursor/rules. La razón es simple: el formato .mdc agrega un formatter que te permite añadir reglas custom mediante un encabezado, algo imposible en un Markdown plano [05:03].

Ese encabezado controla tres parámetros que deciden cuándo se carga la regla en tu conversación.

Cómo funciona el always apply y los globs

El comportamiento de cada regla depende de la combinación de tres valores: always apply, la descripción y los globs. Piensa en los globs como un regex que indica en qué archivos se aplica la regla o en cuáles no.

Estas son las combinaciones posibles:

1. always apply en true: la regla siempre se agrega al contexto de tu conversación.
2. always apply en false con globs: se adjunta automáticamente cuando abres un archivo que coincide con esa ruta.
3. always apply en false, con descripción y sin globs: el agente lee la descripción y carga la regla solo cuando hace match con lo que ejecuta.
4. always apply en false, sin descripción ni globs: solo se incluye cuando la mencionas con el arroba.

¿Cuándo debo usar always apply true? Cuando la regla es transversal, como la arquitectura o TypeScript. Así se carga en cada prompt y evitas que el agente proponga soluciones que no encajan con tu proyecto.

En la propuesta generada, la regla de arquitectura quedó con always apply true y sin globs, algo que tiene mucho sentido: quieres esa regla siempre visible. En cambio, la regla de componentes React quedó con always apply false y globs limitados a archivos TypeScript o TSX, para no cargarla cuando trabajas en documentación.

Cómo validar las reglas que genera el agente

Una buena práctica es pedirle al agente que muestre qué globs va a asignar antes de generar los archivos, para que tú los valides. Tu tarea es leer cada regla y confirmar si realmente encaja con lo que quieres.

Al revisar la regla de frontend, aparecen los tres elementos esperados:

• Una descripción: convenciones de componentes React y frontend solo para apps web.
• Unos globs: aplica solo en archivos TS y TSX.
• El always apply en false: se carga únicamente al trabajar esos archivos.

Hay un límite técnico importante: Cursor recomienda que cada regla tenga menos de 500 líneas [07:14]. La regla de frontend del ejemplo tiene 35 líneas, así que pasa la validación sin problema.

Qué debe contener el agents.md y qué no

El último paso antes de cerrar es crear el agents.md, y este sí es Markdown plano en la raíz del proyecto. A diferencia de las reglas modulares, este documento es el punto de entrada que cualquier agente lee primero [08:26].

Por eso debe ser conciso. Se carga en todas las conversaciones y en cada subagente, así que solo debe aportar lo esencial:

• Una descripción corta del producto, por ejemplo un dashboard de feature flags.
• El stack que se usa.
• La estructura del monorepo.

La clave es no repetir el detalle que ya vive en cada regla, sino remitirse a ellas. En el ejemplo, el agente incluyó comandos, flujo de trabajo y reglas del proyecto, pero conviene quitarlos: los comandos ya viven en el package.json y las reglas ya están referenciadas dentro del system prompt de Cursor. Cargar eso solo haría el archivo más extenso de lo necesario.

¿Cuál es la diferencia entre agents.md y las cursor rules? El agents.md es el punto de entrada conciso que todo agente lee primero, con contexto general y stack. Las cursor rules contienen el detalle específico de cada convención y se cargan según su scope.

El reto ahora es tuyo: escribe las reglas de tu proyecto y dirige a cada subagente para que escriba el código como a ti te gusta. ¿Cómo estás organizando tus reglas entre el agents.md y los archivos .mdc? Cuéntalo en los comentarios.