Reglas

Las reglas proporcionan instrucciones a nivel de sistema al Agent. Agrupan instrucciones, scripts y otros elementos, lo que facilita gestionar y compartir flujos de trabajo en todo el equipo.

Cursor admite cuatro tipos de reglas:

Cómo funcionan las reglas

Los modelos de lenguaje de gran tamaño no conservan memoria entre respuestas. Las reglas proporcionan contexto persistente y reutilizable a nivel de prompt.

Cuando se aplican, el contenido de las reglas se incluye al inicio del contexto del modelo. Esto le da a la IA una guía coherente para generar código, interpretar ediciones o ayudar con los flujos de trabajo.

Reglas del proyecto

Las reglas del proyecto se encuentran en .cursor/rules como archivos .mdc y están bajo control de versiones. Se aplican mediante patrones de ruta, se invocan manualmente o se incluyen según su relevancia.

Usa las reglas del proyecto para:

• Codificar conocimiento específico del dominio sobre tu base de código
• Automatizar flujos de trabajo o plantillas específicos del proyecto
• Estandarizar decisiones de estilo o arquitectura

Estructura del archivo de reglas

Cada regla es un archivo .mdc al que puedes poner el nombre que quieras. Las reglas del proyecto deben usar la extensión .mdc. El sistema de reglas ignora cualquier archivo .md simple en .cursor/rules porque no tiene frontmatter para especificar description, globs y alwaysApply. Si prefieres usar markdown simple, usa AGENTS.md en su lugar.

.cursor/rules/  react-patterns.mdc       # Reconocido como una regla de proyecto  api-guidelines.md        # Ignorado (extensión incorrecta)  frontend/                # Organiza las reglas en carpetas    components.mdc

Anatomía de una regla

Cada regla es un archivo Markdown con metadatos de frontmatter y contenido. Controla cómo se aplican las reglas desde el menú desplegable de tipo, que modifica las propiedades description, globs, alwaysApply.

Internamente, los tres campos de frontmatter interactúan para determinar cuándo se incluye una regla:

---alwaysApply: true---- Todos los archivos fuente deben incluir el encabezado de derechos de autor de la empresa- Cuando no estés seguro sobre los detalles de implementación, lee los archivos  fuente relevantes antes de proponer cambios- Nunca modifiques los archivos generados en los directorios `dist/` o `build/`

---globs: src/components/**/*.tsxalwaysApply: false---- Use named exports, not default exports- Co-locate styles in a module CSS file next to the component- Keep components under 200 lines. Extract subcomponents into the same  directory when a file grows beyond that- Prefer composition over prop drilling. Pass children or render props  instead of threading data through multiple layers

---description: RPC service conventions and patterns for the backendalwaysApply: false---- Define cada servicio en su propio archivo bajo `src/services/`- Siempre valida las entradas en el límite del servicio antes de pasar los datos  a las funciones internas- Devuelve objetos de error estructurados con un campo `code` y `message`,  nunca lances cadenas de texto sin procesar- Agrega un archivo de referencia `@service-template.ts` al crear un nuevo  servicio para el código base estándar

---alwaysApply: false---- Toda migración de base de datos debe tener las funciones `up` y `down`  para que pueda revertirse por completo- Nunca modifiques el tipo de una columna en el lugar. Añade una nueva columna, rellena los datos,  y luego elimina la antigua en una migración separada- Haz referencia a la plantilla para la estructura de archivos esperada@migration-template.sql

Ejemplos de patrones glob

Usa globs para limitar una regla a archivos o directorios específicos. Separa varios patrones con comas.

Crear una regla

Hay dos formas de crear reglas:

• /create-rule en el chat: Escribe /create-rule en Agent y describe lo que quieres hacer. Agent genera el archivo de regla con el frontmatter adecuado y lo guarda en .cursor/rules.
• Desde Personalizar: Abre personalizar en la barra lateral, ve a Reglas y haz clic en Añadir regla. Esto crea un nuevo archivo de regla en .cursor/rules. Desde Personalizar puedes ver todas las reglas y su estado.

Mejores prácticas

Las buenas reglas son concretas, aplicables y bien delimitadas.

• Mantén las reglas con menos de 500 líneas
• Divide las reglas grandes en varias reglas componibles
• Proporciona ejemplos concretos o archivos de referencia
• Evita las indicaciones vagas. Escribe las reglas como documentación interna clara
• Reutiliza reglas cuando repitas indicaciones en el chat
• Haz referencia a archivos en lugar de copiar su contenido; así las reglas se mantienen breves y no quedan obsoletas a medida que el código cambia

Qué evitar en las reglas

• Copiar guías de estilo completas: Usa un linter en su lugar. Agent ya conoce las convenciones de estilo comunes.
• Documentar todos los comandos posibles: Agent conoce herramientas comunes como npm, git y pytest.
• Agregar instrucciones para casos límite que rara vez aplican: Mantén las reglas enfocadas en patrones que uses con frecuencia.
• Duplicar lo que ya existe en tu base de código: Señala ejemplos canónicos en lugar de copiar código.

Haz commit de tus reglas en git para que todo tu equipo se beneficie. Cuando veas que Agent comete un error, actualiza la regla. Incluso puedes etiquetar a @cursor en un issue o PR de GitHub para que Agent actualice la regla por ti.

Formato del archivo de reglas

Cada regla es un archivo Markdown con metadatos de frontmatter y contenido. Los metadatos de frontmatter se utilizan para controlar cómo se aplica la regla. El contenido es la propia regla.

---description: "Esta regla establece estándares para componentes frontend y validación de API"alwaysApply: false---...rest of the rule content

Si alwaysApply es true, la regla se aplicará en cada sesión de chat. De lo contrario, la descripción de la regla se presentará a Cursor Agent, que decidirá si debe aplicarse.

Ejemplos