Reglas de Cursor: configuración y ejemplos para TypeScript

El beneficio es tener menos que corregir durante las revisiones. Como cálculo ilustrativo, cuatro desarrolladores que hacen tres correcciones de cinco minutos cada semana dedican 60 minutos a repetir convenciones. No es una promesa de ahorro. Cuenta qué correcciones dejan de hacer falta después de configurar las reglas y resta el tiempo que dedicas a mantenerlas. El costo de la suscripción es otro tema; lo tratamos en precios de Cursor.

Dónde guardar las reglas de Cursor

Las decisiones de código compartidas deben estar junto al código. Las preferencias personales de respuesta deben seguir siendo personales.

Las instrucciones de un AGENTS.md situado en un subdirectorio se aplican a ese directorio y a los que contiene, junto con las instrucciones de los niveles superiores; las más específicas tienen prioridad. Para las reglas de equipo, proyecto y usuario, el orden de prioridad documentado en caso de conflicto es Team → Project → User. Referencia de reglas de Cursor

Para un equipo pequeño, suelo recomendar las reglas de proyecto. Una instrucción como «usa nuestros componentes de formulario existentes» pertenece al repositorio. «Sé breve en la respuesta final» es una preferencia tuya. Separar estas decisiones evita que una preferencia personal se convierta por accidente en una norma del equipo.

Cuándo se incorpora cada regla al contexto

El frontmatter, el pequeño bloque de configuración que precede al texto de una regla, determina cuándo se incorpora al contexto.

Cuando la selección queda en manos del agente, este elige la regla a partir de su descripción. Un glob es un patrón de rutas de archivos. Comportamiento y sintaxis de incorporación al contexto

Piensa en este mecanismo como la entrega de una orden de trabajo al puesto adecuado. Por muy bien redactada que esté una instrucción, no sirve de nada si la tarea nunca la recibe. Aplica la base de seguridad a todas las tareas, lleva las pautas de estilo a los archivos correspondientes y deja la selección a criterio del agente cuando la pertinencia de una regla dependa de la tarea.

Tres reglas listas para copiar en una aplicación web con TypeScript

Crea los siguientes archivos en tu repositorio. Son convenciones de trabajo propuestas que usan los campos de frontmatter y la sintaxis de patrones de la referencia de Cursor. Las instrucciones son un punto de partida que puedes adaptar, no estándares de programación exigidos por Cursor.

Estilo: aplica la regla a los archivos TypeScript

Guárdala como .cursor/rules/style.mdc:

---
globs: src/**/*.ts, src/**/*.tsx
alwaysApply: false
---

- Follow the nearest existing module's naming and import conventions.
- Prefer named exports unless the framework requires a default export.
- Reuse existing UI components and utilities before adding alternatives.
- Keep formatting in the repository's formatter and linter configuration.

Este ejemplo supone que el código de la aplicación está en src/; ajusta las rutas a tu repositorio. Se centra a propósito en decisiones que un formateador no puede resolver, como saber si la aplicación ya tiene un botón adecuado o una función auxiliar para fechas. Cambia la preferencia de exportación si tu equipo ha tomado otra decisión. Una regla debe describir tu repositorio, no rediseñarlo sin que te des cuenta.

Pruebas: describe qué tareas las necesitan

Guárdala como .cursor/rules/tests.mdc:

---
description: Testing requirements when adding features, fixing bugs, or changing TypeScript behavior
alwaysApply: false
---

- Cover changed behavior with a focused regression test.
- Use the existing test runner, fixtures, and file naming conventions.
- Read package.json for the relevant test script; do not invent a command.
- Report the command and actual result, or explain why tests were not run.

El objetivo es obtener una prueba útil y un resultado veraz. La corrección de un error debe dejar evidencia de que la prueba cubre el fallo original. Una refactorización debe conservar el comportamiento pertinente. Ninguna de las dos necesita otro framework de pruebas ni un informe que confunda «prueba escrita» con «prueba superada».

Cuando quieras pedir expresamente esta lista de comprobación, incluye @tests en tu solicitud. Si el equipo la quiere en todas las tareas, cambia el modo a Always Apply. Trátalo como una decisión deliberada sobre la forma de trabajar; con la descripción por sí sola, la selección queda en manos del agente.

Seguridad: mantén breve la base común

Guárdala como .cursor/rules/security.mdc:

---
alwaysApply: true
---

- Never put secrets in source code, test fixtures, or application logs.
- Use existing server-side authentication and authorization helpers.
- Validate untrusted input at server boundaries with the existing schemas.
- Do not remove permission checks to make a feature or test pass.

Sustituye «funciones auxiliares existentes» por las rutas reales de los módulos del repositorio cuando las conozcas. La base común debe resultar comprensible durante una tarea habitual de desarrollo. «Hazlo seguro» aporta poco que revisar; «conserva la comprobación de autorización» establece un requisito concreto.

Este archivo contiene instrucciones; no constituye una barrera de seguridad. Sigue exigiendo comprobaciones de acceso en el código y revisando los cambios sensibles. La propia documentación de Cursor advierte que las indicaciones para la IA no deben ser el único control de seguridad. Guía de reglas de equipo

Comprueba la configuración con un cambio real

Elige una tarea pequeña que antes obligara a repetir correcciones. Un cambio en la validación de un formulario es un buen candidato: afecta a un componente, modifica un comportamiento y recibe datos del usuario.

1. Anota el resultado esperado. Identifica el componente existente que se debe reutilizar, el comportamiento que hay que probar y el punto de validación que se debe conservar.
2. Guarda los tres archivos y comprueba su estado. Cursor muestra las reglas en Customize → Rules; también puedes usar /create-rule en Agent. Cómo crear una regla
3. Pide el cambio con los archivos pertinentes en el contexto. Haz una solicitud realista. Si repites todas las reglas en la propia tarea, no podrás saber si la configuración ayudó.
4. Revisa el diff y las comprobaciones indicadas. Busca la convención aplicada en el código, no una afirmación de que se siguieron las reglas. Si la lista de pruebas es importante para este ensayo, pide @tests expresamente.
5. Incluye las reglas útiles en el commit del cambio. Dale al equipo un punto de partida que pueda revisar. Aclara una frase vaga antes de añadir otro archivo.

Si no se respeta una convención, distingue entre dos fallos: la regla no llegó a la tarea, o llegó pero la instrucción no fue eficaz. El primero exige corregir cómo se incorpora al contexto. El segundo pide una instrucción más clara, un ejemplo o una comprobación automatizada.

Qué convenciones merece la pena conservar

Empieza por los errores repetidos que más le cuestan a tu equipo. Estos son algunos usos prácticos, ordenados por la carga de revisión que podrían evitar.

No conviertas estos ejemplos en una obligación de crear cinco archivos más. Si un problema no se ha presentado, déjalo fuera. Si una máquina puede comprobar el requisito con precisión, prioriza esa comprobación. Una regla útil cubre lo que falta entre la solicitud de la tarea y las herramientas que ya tiene el repositorio.

¿Qué pasa con el antiguo archivo .cursorrules?

Usa .cursor/rules/*.mdc para la configuración de proyecto que documenta Cursor actualmente. A fecha del 11 de octubre de 2026, la página de reglas no menciona .cursorrules, por lo que no confirma si el archivo antiguo sigue funcionando. Referencia actual

Si un repositorio todavía conserva ese archivo, recomiendo trasladar sus instrucciones útiles a reglas de proyecto con un propósito concreto, tomando los tres archivos anteriores como punto de partida. Elige cuándo se activa cada una y comprueba una tarea real antes de retirar la copia antigua. No conserves convenciones obsoletas solo porque ya estaban escritas.

Qué tienen en común con CLAUDE.md y AGENTS.md

La idea compartida es mantener unas instrucciones permanentes para el proyecto: Claude Code cuenta con CLAUDE.md, y Codex lee los acuerdos de trabajo de AGENTS.md. La opción de Markdown simple de Cursor responde a esa misma necesidad básica, mientras que sus archivos .mdc permiten elegir cómo se incorporan las reglas al contexto. Mantén coherentes las convenciones de fondo, pero configura de forma deliberada cómo las carga cada herramienta: copiar el texto no equivale a copiar la configuración. En equipos que usan varios agentes, asigna a una persona la responsabilidad de las convenciones compartidas para que los archivos no acaben dando instrucciones contradictorias.

Dos pequeñas herramientas que podrías crear después

Un verificador de reglas del repositorio es la oportunidad más sólida para quien lidera un equipo de ingeniería: comprobar extensiones de archivo, campos de frontmatter reconocidos y patrones que no coinciden con ningún archivo bajo control de versiones. Su versión mínima útil sería un informe local que se ejecute durante la revisión. La señal de demanda es modesta: en la investigación de este artículo, DataForSEO devolvió 140 búsquedas mensuales estimadas de «cursor rules examples». Es interés en un tema relacionado, no evidencia de que alguien vaya a pagar. La limitación es clara: una regla con una estructura válida puede seguir dando malas indicaciones. Definición de la métrica

Un paquete para revisar las convenciones del equipo podría ayudar a quien mantiene varios repositorios. Convierte los comentarios de revisión recurrentes y los ejemplos aprobados en una propuesta de cambios a las reglas, con una persona asignada para revisar cada cambio. DataForSEO devolvió 70 búsquedas mensuales estimadas de «cursor team rules». Empieza como utilidad interna; las reglas de equipo nativas ya se ocupan de la distribución, así que otro panel para almacenar reglas es una propuesta de producto poco sólida. El trabajo útil consiste en decidir qué merece convertirse en una instrucción permanente. Definición de la métrica

Preguntas habituales al configurar las reglas

La próxima semana, elige una corrección recurrente, concreta la regla correspondiente y pruébala en el siguiente pull request habitual. Si todavía estás evaluando el producto, lee el análisis de Cursor o las mejores alternativas a Cursor.

Si quieres integrar todo esto en el flujo de desarrollo de un equipo, ese trabajo encaja en sistemas de IA para producción.