Por qué Cursor empieza de cero y qué se mantiene realmente
Hay cuatro lugares donde puede residir una regla
El conjunto documentado de Cursor:
Project rules (Reglas de proyecto) residen en .cursor/rules como archivos .mdc y están bajo control de versiones. Están "delimitadas mediante patrones de ruta, se invocan manualmente o se incluyen según su relevancia".
User Rules (Reglas de usuario) son "preferencias globales definidas en Customize → Rules que se aplican a todos los proyectos". Las utiliza el Agent (Chat) y son el lugar adecuado para el estilo de comunicación y las convenciones personales.
Team Rules (Reglas de equipo) son "reglas para todo el equipo gestionadas desde el panel de control", disponibles en los planes Team y Enterprise.
AGENTS.md se describe como "instrucciones del Agent en formato markdown. Alternativa sencilla a .cursor/rules". Existe soporte anidado: coloca AGENTS.md en cualquier subdirectorio y se aplicará automáticamente al trabajar con archivos en ese directorio o sus hijos, combinando las instrucciones "con los directorios padres, teniendo prioridad las instrucciones más específicas".
La mayoría de las personas han escrito exactamente una de estas y han asumido que lo cubre todo.
Solo se garantiza la presencia de un tipo de regla
Este es el núcleo del asunto. Los cuatro tipos de reglas de Cursor, según la documentación:
| Tipo de regla | Cuándo se aplica |
|---|---|
| Always Apply | "Se aplica a cada sesión de chat" |
| Apply Intelligently | "Cuando el Agent decide que es relevante según la descripción" |
| Apply to Specific Files | "Cuando el archivo coincide con un patrón especificado" |
| Apply Manually | "Cuando se menciona con @ en el chat" |
Por debajo, tres campos de frontmatter lo deciden. alwaysApply: true significa "Siempre incluido. Se ignoran los globs y la descripción". Con alwaysApply: false y globs proporcionados, la regla se "adjunta automáticamente cuando un archivo coincidente está en contexto". Con una descripción y sin globs, "el Agent lee la descripción e incorpora la regla cuando es relevante". Sin ninguno de los dos, se "incluye solo cuando mencionas la regla con @ en el chat".
Así que una regla que escribiste hace tres semanas sin campos de frontmatter configurados está esperando una mención con @ que nunca has escrito. No se ha perdido. Nunca fue invitada.
La propia respuesta de las preguntas frecuentes de Cursor es el diagnóstico más rápido: "Verifica el tipo de regla. Para Apply Intelligently, asegúrate de definir una descripción. Para Apply to Specific Files, asegúrate de que el patrón de archivo coincida con los archivos referenciados".
Un archivo .md simple en .cursor/rules se ignora silenciosamente
El fallo que más tiempo hace perder, porque nada te lo advierte. Directamente de la documentación: "El sistema de reglas ignora un archivo .md simple en .cursor/rules porque no tiene frontmatter para especificar description, globs y alwaysApply. Si prefieres markdown simple, usa AGENTS.md en su lugar".
Si has estado manteniendo un archivo notes.md dentro de .cursor/rules y preguntándote por qué nada cambiaba, esa es la razón. Cámbiele el nombre a .mdc y añade frontmatter, o mueve el contenido a AGENTS.md.
La regla se cargó, pero lo que referenciaba no
Las reglas son cortas por diseño. La guía de Cursor recomienda mantenerlas por debajo de las 500 líneas, dividir las reglas grandes en otras componibles y, lo que es más importante, "referenciar archivos en lugar de copiar su contenido; esto mantiene las reglas cortas y evita que queden obsoletas a medida que cambia el código". Puedes incorporar un archivo con @nombre_archivo.ts.
Lo que crea una brecha de segundo orden. "Sigue nuestras convenciones de servicio" solo funciona si las convenciones son accesibles. Una regla es un puntero más una dirección; no es el conocimiento en sí. Esa distinción, en todas las herramientas, es por qué los agentes ignoran los archivos de instrucciones que escribiste.
El lugar donde se guardó la regla no siempre es el que crees
Las reglas se registran en git, que es como las comparte un equipo, pero una nueva regla aterriza en el .cursor/rules de la carpeta en la que estás trabajando. Abre una subcarpeta como tu proyecto y tu regla se limitará a esa subcarpeta. Es una comprobación de cinco segundos que te ahorra una tarde entera.
Lo que la gente intenta
Volver a explicar el proyecto al inicio de cada chat. Funciona, permanentemente, con el mismo coste cada vez: el bucle descrito en cómo dejar de volver a explicar el contexto a la IA.
Escribir una regla enorme que siempre esté activa. Se aplica en cada sesión y se incluye al inicio del contexto del modelo en cada mensaje. La propia lista de cosas a evitar de Cursor menciona "copiar guías de estilo completas" (usa un linter en su lugar) y "documentar cada comando posible", ya que el Agent ya conoce npm, git y pytest.
Mantener un único chat abierto para siempre. Pospone el límite en lugar de cruzarlo.
Configurar todo en Apply Intelligently. Suena razonable, pero delega la decisión a una descripción que escribiste en cinco segundos. Si la descripción es vaga, la regla no se aplicará.
Pegar decisiones de arquitectura en una regla. El instinto correcto, pero el contenedor equivocado: las reglas están pensadas para ser cortas y apuntar a cosas. Ese es el caso detrás de por qué Cursor olvida las decisiones arquitectónicas.
Sincronizar reglas entre máquinas a mano. Es común y genera desajustes. La versión de la frontera entre máquinas se cubre en cómo evitar que Cursor olvide entre máquinas.
La solución: tipar tus reglas y luego mantener el razonamiento fuera de ellas
Dos pasos. El primero hace que Cursor cargue lo que escribiste. El segundo le da al conocimiento un hogar que un límite de 500 líneas no puede albergar.
Audita lo que tienes y corrige las extensiones. Abre .cursor/rules. Cualquier archivo que termine en .md está siendo ignorado: conviértelo a .mdc con frontmatter o muévelo a AGENTS.md.
Asigna a cada regla el tipo más específico que siempre sea correcto. Las restricciones universales obtienen alwaysApply: true. Las convenciones específicas de idioma o directorio obtienen globs. La guía situacional obtiene una descripción específica para que el Agent pueda juzgar realmente su relevancia. Los procedimientos que rara vez se necesitan se mantienen manuales y se mencionan con @.
Separa lo global de lo local. El estilo de comunicación y las convenciones personales pertenecen a las User Rules en Customize → Rules. Las convenciones del repositorio pertenecen a las reglas del proyecto o a AGENTS.md, registradas en git para que tu equipo también las reciba.
Usa AGENTS.md anidados en lugar de hacer malabarismos con globs. Un archivo raíz más uno por cada directorio principal te ofrece delimitación sin necesidad de frontmatter, y las instrucciones más específicas tienen prioridad.
Apunta a ejemplos canónicos en lugar de copiarlos. Usa referencias @file. La documentación de Cursor explica claramente la razón: las copias quedan obsoletas a medida que cambia el código.
Eso soluciona la carga. Lo que no puede solucionar es la capa que las reglas excluyen deliberadamente: por qué la arquitectura es como es, qué enfoques ya intentaste y abandonaste, la restricción que hace que una decisión extraña sea correcta. La guía de Cursor es añadir una regla cuando notes que el Agent repite un error, lo cual es un buen consejo y también una admisión de que las reglas capturan conclusiones, no razonamientos.
Eso es lo que contiene MemoryLake: el conocimiento duradero de tu proyecto en una capa de la que leen tus herramientas, de modo que las reglas se mantengan cortas y el razonamiento permanezca disponible. La configuración consta de tres pasos.
Paso 1: Crear una clave de API
Inicia sesión en MemoryLake y crea una clave de API. Una sola credencial para todas las herramientas que conectes.
Paso 2: Sube tus primeras memorias
Escribe entradas cortas (una afirmación cada una) que cubran aquello para lo que un archivo de reglas no tiene el formato adecuado:
Decisiones con su restricción. "Las consultas pasan por la capa de repositorio porque la carga ansiosa (eager loading) del ORM rompió la paginación". Una regla puede establecer la primera mitad. Solo esta versión evita que la sugerencia vuelva a aparecer.
Lo que ya rechazaste. La categoría de mayor valor y la que no existe en ningún lugar del repositorio. Cada nueva sesión vuelve a proponerlo.
Conocimiento entre repositorios. Vocabulario de dominio y estándares que se aplican a varios proyectos. Las reglas de proyecto son por repositorio por diseño; esto no.
Correcciones que has hecho más de una vez. La propia heurística de Cursor para escribir una regla, y el razonamiento detrás de la corrección pertenece aquí, justo al lado.
Paso 3: Conecta tu IA y agentes
Conecta las herramientas que utilizas. MemoryLake es accesible a través de MCP y de una API, por lo que los agentes nativos de MCP (entre ellos Claude Code, Codex y OpenClaw) se conectan apuntando al servidor MCP, mientras que otros asistentes leen la misma memoria a través de la API.
Tres límites honestos. MemoryLake no escribe tus reglas de Cursor y no las reemplaza: las reglas son la forma en que diriges al Agent, y aún debes escribirlas correctamente. Solo contiene lo que tú o tus agentes escriben en él, por lo que el Paso 2 es manual. Y las reglas son contexto a nivel de prompt en lugar de una configuración forzada, lo cual es el enfoque de Cursor, no el nuestro; una capa de memoria no cambia eso.
Qué cambia esto en la práctica
"¿Por qué no siguió la regla?" se convierte en una comprobación de dos segundos. Extensión, luego tipo, luego patrón. Casi siempre es uno de los tres.
Las reglas siempre activas se vuelven cortas. Cuando la sustancia reside en otra parte, el archivo siempre activo vuelve a ser un puñado de restricciones reales en lugar de un documento enviado con cada mensaje.
Un nuevo repositorio no es un comienzo desde cero. Las reglas de proyecto no viajan entre repositorios. El conocimiento guardado fuera de ellas sí.
La incorporación del equipo deja de ser historia oral. Las reglas registradas ofrecen convenciones; la capa de memoria ofrece las razones. Los nuevos integrantes necesitan ambas, y normalmente solo una de ellas está escrita.
Tus otras herramientas ven el mismo contexto. El razonamiento detrás de tu arquitectura es idéntico ya sea que lo lee Cursor, Claude Code o Codex: la estructura que se cubre en qué significa realmente la memoria persistente.
Buenas prácticas para reglas de Cursor que perduran
Usa .mdc en .cursor/rules o usa AGENTS.md. Nunca uses un .md simple dentro del directorio de reglas: se ignora.
Establece el tipo deliberadamente, una vez por regla. No dejes el frontmatter en blanco esperando que funcione. En blanco significa manual.
Escribe descripciones que un extraño pueda enrutar. "Convenciones de servicio RPC y patrones para el backend" es enrutable. "Cosas del backend" no lo es.
Mantén las reglas por debajo de las 500 líneas y divide lo que crezca. Es el propio número de Cursor, y las reglas componibles son más fáciles de reescribir cuando cambia el alcance.
Referencia archivos, no los copies. Las copias quedan obsoletas; las referencias @file no.
Añade reglas de forma reactiva. La documentación lo dice claramente: añade una regla cuando notes que el Agent comete el mismo error repetidamente, y no optimices en exceso antes de conocer tus patrones.
Registra las reglas en git y sigue actualizándolas. Incluso puedes etiquetar a @cursor en un issue o PR de GitHub para que el Agent actualice una regla por ti.
Prefiere AGENTS.md anidados para la delimitación por directorios. Menos frontmatter que mantener y la precedencia es predecible.
Guarda las razones fuera de las reglas. Las reglas son para dar dirección y punteros. El porqué es lo que hace que un agente maneje el caso que no previste, y no cabe en 500 líneas: el problema general descrito en por qué RAG no es memoria.
Conclusión
Cursor es explícito en que los modelos no retienen memoria entre completados y que las Reglas son el mecanismo para un contexto persistente y reutilizable a nivel de prompt. Por lo tanto, mantener el contexto entre sesiones es cuestión de hacer bien cuatro cosas: la extensión del archivo, el tipo de regla, el alcance y dónde se guardó la regla. Corrige eso y la mayoría de los "se le olvidó" desaparecerán.
Lo que queda es la parte que las reglas están diseñadas para no contener. Tienen un límite, están pensadas para apuntar a archivos en lugar de duplicarlos y capturan la conclusión en lugar del argumento. Coloca las decisiones, las restricciones y los enfoques rechazados en una capa que tus herramientas puedan leer, mantén tus reglas cortas y correctamente tipadas, y cada nueva sesión comenzará tanto con la instrucción como con la razón detrás de ella.