Cómo hacer que Cursor recuerde la estructura de archivos de tu proyecto (2026)

Parte de tu árbol está excluida de la indexación a propósito

Esto es lo primero que debes verificar y lo que sorprende a la gente, porque nada lo anuncia.

Cursor respeta tus archivos de ignorados. De la documentación: "Cursor respeta automáticamente tus patrones de .gitignore. Los archivos ignorados por git también son ignorados por la indexación de Cursor". Además de eso, .cursorignore añade "exclusiones adicionales más allá de lo que cubre .gitignore", y Cursor "ya ignora los archivos .env, .git/ y los archivos de bloqueo de forma predeterminada".

La consecuencia es contundente: "Los archivos ignorados están bloqueados para la indexación y para Agent". Por lo tanto, si tu cliente de API generado, tu SDK de terceros o un directorio de salida de compilación está en el gitignore (y normalmente lo está), Agent no puede ver esa parte de la estructura en absoluto. No está olvidando dónde viven esos archivos. Nunca se le han mostrado.

Hay un matiz aquí que explica un comportamiento genuinamente confuso. "Los comandos de terminal y las herramientas MCP se ejecutan fuera de los controles de acceso a archivos de Cursor, por lo que aún pueden leer archivos ignorados". De modo que el mismo Agent puede saber que un directorio existe después de ejecutar ls, y luego ser incapaz de encontrar nada en él a través de la búsqueda. Esa inconsistencia se interpreta exactamente como olvido.

No hay un mapa almacenado: la estructura se redescubre cada vez

La guía de Cursor sobre las menciones @ es más reveladora de lo que parece. Úsalas "cuando sepas qué archivos son relevantes", y: "Si no estás seguro de qué archivos importan, omítelo; Agent encuentra los archivos relevantes a través de su propia búsqueda".

Ese es el diseño. Agent localiza lo que necesita por solicitud en lugar de mantener un mapa del proyecto entre mensajes. Nada sobre el diseño persiste entre turnos a menos que una regla lo coloque allí o lo adjuntes. Y Cursor es directo sobre por qué persiste algo en absoluto: "Los modelos de lenguaje grandes no retienen memoria entre completados. Las reglas proporcionan un contexto persistente y reutilizable a nivel de prompt".

Así que "recordar mi estructura de archivos" no es una configuración de memoria que no hayas podido encontrar. Es una cuestión de qué has hecho persistente y cómo.

La regla que escribiste sobre la estructura no se está cargando

Si escribiste una regla de ubicación y se está ignorando, casi siempre se debe a una de estas cuatro cosas, y las preguntas frecuentes de Cursor nombran las dos primeras: "Verifica el tipo de regla. Para Apply Intelligently, asegúrate de que se defina una descripción. Para Apply to Specific Files, asegúrate de que el patrón de archivo coincida con los archivos referenciados".

Vale la pena interiorizar la tabla de frontmatter, porque una regla sin campos establecidos no es una regla rota, es una regla manual. Con alwaysApply: true está "Siempre incluida. Se ignoran los globs y la descripción". Con alwaysApply: false y globs, se "Adjunta automáticamente cuando un archivo coincidente está en contexto". Con una descripción y sin globs, "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".

Luego, la trampa de la extensión: "Un archivo .md simple en .cursor/rules es ignorado por el sistema de reglas porque no tiene frontmatter para especificar description, globs y alwaysApply. Si prefieres markdown simple, usa AGENTS.md en su lugar".

Y finalmente, la ubicación. Las reglas aterrizan en el .cursor/rules de la carpeta que tienes abierta. Si abres un subdirectorio de un monorepo como tu proyecto, tu regla estará limitada a ese subdirectorio.

Un árbol pegado es incorrecto en una semana

Incluso cuando se carga, se deteriora. Un listado de directorios es lo que más rápido se queda obsoleto en un archivo siempre activo, y un árbol desactualizado es peor que no tener ninguno: apunta activamente a Agent hacia rutas que se han movido. Esto es exactamente a lo que se refiere Cursor con que las reglas "se vuelven obsoletas a medida que cambia el código", y es por eso que el consejo es hacer referencia en lugar de copiar.

Pegar la salida de tree -L 3 en una regla siempre activa. Se carga, es precisa durante unos días y luego comienza a desviar la atención. El contenido de las reglas "se incluye al inicio del contexto del modelo", por lo que también estás pagando por ello en cada mensaje.

Escribir "el proyecto está organizado por características" y detenerse ahí. Cierto pero inútil. No le dice a Agent dónde va un archivo nuevo.

Volver a adjuntar carpetas manualmente en cada chat. Funciona, y es el bucle descrito en cómo dejar de volver a explicar el contexto a la IA.

Dejar de ignorar directorios para que Cursor pueda verlos. Ocasionalmente correcto, a menudo no; la documentación enumera por qué se ignoran las cosas, incluyendo que "Los archivos generados grandes ralentizan la indexación" y "Los secretos y las credenciales están más seguros excluidos del contexto de la IA".

Configurar la regla de estructura en Apply Intelligently. Suena razonable, pero deja la decisión en manos de una descripción que escribiste en cinco segundos. Descripción vaga, no hay regla.

Pedirle a Agent que vuelva a escanear la base de código en cada sesión. Costoso y repetitivo, y el mismo patrón aparece en cómo evitar que Claude Code vuelva a leer tu base de código.

El replanteamiento que hace que esto sea manejable: no quieres que Cursor memorice dónde están los archivos. Quieres que sepa dónde van los nuevos archivos y por qué. Lo primero es derivable y se deteriora. Lo segundo es una convención y se mantiene.

La propia documentación de Cursor lo demuestra sin decirlo explícitamente. Su ejemplo de una regla adjunta automáticamente, limitada a globs: src/components/**/*.tsx, contiene líneas como "Ubicar los estilos en un archivo CSS de módulo junto al componente" y "Mantener los componentes por debajo de las 200 líneas. Extraer los subcomponentes en el mismo directorio cuando un archivo crezca más allá de eso". Esas son reglas de ubicación. No hay ningún árbol en el ejemplo.

Cuatro pasos.

Audita los archivos de ignorados antes de escribir nada. Compara .gitignore y .cursorignore con los directorios en los que Agent sigue equivocándose. Si una carpeta realmente debería ser visible (un directorio de esquemas registrado, un cliente generado que confirmas), esa es una solución de una sola línea que ninguna regla puede sustituir.

Escribe convenciones de ubicación, limitadas con globs. Una regla por área, adjunta por patrón para que se cargue cuando estés trabajando allí. Usa las formas de glob documentadas: src/** para todo lo que esté bajo src/, src/**/*.tsx para componentes, patrones separados por comas como docs/**/*.md, docs/**/*.mdx cuando necesites dos. Di dónde van las cosas y cómo debe llamarse el archivo, no lo que existe actualmente.

Usa AGENTS.md anidados para la delimitación estructural. Coloca uno en cualquier subdirectorio y se "aplicará automáticamente al trabajar con archivos en ese directorio o sus subdirectorios", combinando las instrucciones "con los directorios principales, teniendo prioridad las instrucciones más específicas". Sin frontmatter, sin mantenimiento de globs, y el archivo se encuentra junto al código que describe, por lo que es más probable que se update cuando cambie el diseño.

Adjunta carpetas explícitamente para la consulta específica. Cuando conozcas el área, menciónala con @: "@auth.ts o @src/components/ para incluir archivos o carpetas (escribe / después de seleccionar una carpeta para navegar más profundamente)". Eso es para la solicitud que tienes delante, no un sustituto de la convención.

Eso se encarga de la carga y la delimitación. Lo que nada de esto contiene es la parte que hace que un diseño tenga sentido: por qué el límite está donde está, qué reorganización intentaste y revertiste, el directorio que parece vestigial y no lo es. Las reglas están limitadas a un máximo recomendado de 500 líneas y están destinadas a señalar en lugar de duplicar, por lo que el argumento detrás de una estructura no tiene dónde vivir.

Eso es lo que MemoryLake almacena: el conocimiento duradero de tu proyecto en una capa de la que leen tus herramientas, para que las reglas sigan siendo cortas y el razonamiento permanezca disponible. La configuración consta de tres pasos.

Paso 1: Crea 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

Entradas cortas, una afirmación cada una. Qué escribir específicamente sobre la estructura:

Dónde va cada tipo de elemento nuevo, con el motivo. "Los nuevos controladores de API van en src/api/handlers/, un archivo por ruta, porque el enrutador busca en ese directorio con un glob". Una regla establece la ubicación; el motivo es lo que evita una alternativa plausible el próximo mes.

Límites que parecen arbitrarios y no lo son. El módulo que no puede importar de otro, el directorio que debe permanecer libre de frameworks. Nada en el árbol comunica una restricción.

Reorganizaciones que ya rechazaste. La estructura plana que probaste, el utils/ que deliberadamente no tienes. Cada nuevo agente los volverá a proponer, y nada en el repositorio registra esa decisión.

Directorios que están excluidos de la indexación y qué hay en ellos. Si generated/ está en el gitignore, una nota de una línea sobre lo que vive allí y cómo se produce es más útil que dejar de ignorar 40,000 archivos.

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 (como 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. Las convenciones de ubicación que escribiste una vez son las mismas que lee cada agente que trabaja en el repositorio.

Tres límites honestos. MemoryLake no indexa tu base de código y no escribe tus reglas de Cursor: la propia indexación de Cursor encuentra los archivos, y las reglas son cómo diriges a Agent. Solo almacena lo que tú o tus agentes introducen en él, por lo que el Paso 2 es manual. Y esto es contexto en lugar de imposición; si una regla de ubicación realmente debe cumplirse, una regla de linter o una comprobación de CI es la garantía.

"Puso el archivo en el lugar equivocado" se convierte en una comprobación de dos pasos. ¿Está el directorio ignorado? ¿Es correcto el tipo y el patrón de la regla? Casi siempre es una de esas dos cosas.

Tus reglas dejan de necesitar actualizaciones cada vez que agregas una carpeta. Las convenciones sobreviven a las refactorizaciones. Los listados de directorios no.

Los nuevos colaboradores obtienen la misma respuesta que el agente. Una convención de ubicación escrita es documentación de incorporación que, casualmente, también guía a un modelo.

Las exclusiones de indexación dejan de parecer errores. Una vez que sabes que .gitignore elimina archivos del alcance de Agent, los informes de "no puede encontrar nada en dist/" dejan de ser misteriosos.

Las decisiones de diseño sobreviven a la herramienta. El razonamiento es idéntico ya sea que lo lea Cursor, Claude Code o Codex: el concepto cubierto en lo que realmente significa la memoria persistente.

Verifica primero .gitignore y .cursorignore. Los archivos ignorados por git son ignorados por la indexación de Cursor, y ninguna regla puede evitar eso.

Nunca pegues un árbol de directorios en una regla siempre activa. Es derivable, se queda obsoleto en una semana y ambos proveedores lo desaconsejan.

Delimita las reglas estructurales con globs. Una regla sobre componentes debería adjuntarse cuando abres un componente, no en cada mensaje.

Prefiere AGENTS.md anidados para convenciones por directorio. Las instrucciones más específicas tienen prioridad, no hay frontmatter que mantener y el archivo vive junto a lo que describe.

Usa .mdc dentro de .cursor/rules, nunca .md simple. Un archivo .md allí se ignora silenciosamente.

Escribe la convención de nomenclatura, no la lista de archivos. "Un archivo por ruta, nombrado según la ruta" sobrevive a cualquier instantánea de handlers/.

Adjunta carpetas con @ para la tarea en cuestión. La precisión es mejor que esperar que la búsqueda elija el área correcta.

Mantén el razonamiento fuera de las reglas. El porqué de la existencia del límite es lo que permite a un agente manejar el caso que tu convención no anticipó: el problema general detallado en por qué los agentes ignoran los archivos de instrucciones que escribiste.

Cursor no mantiene un mapa de tu proyecto entre mensajes, y no se supone que deba hacerlo: Agent encuentra los archivos relevantes a través de su propia búsqueda cada vez, y las reglas son el mecanismo documentado para cualquier cosa que deba persistir. Por lo tanto, cuando los archivos terminan en el lugar equivocado, hay tres cosas que verificar, en orden: si el directorio está excluido por .gitignore o .cursorignore, si el tipo de regla y el patrón glob realmente hacen que se cargue, y si la regla dice dónde van las cosas o simplemente describe dónde están.

Esta última es la solución de fondo, y es a la que apuntan de forma independiente tanto la documentación de Cursor como la de Claude Code: no gastes contexto siempre activo en contenido que la herramienta puede derivar, y no copies lo que se quedará obsoleto. Escribe las convenciones de ubicación, delimítalas a los directorios que gobiernan y mantén el razonamiento detrás del diseño en algún lugar que cada herramienta pueda consultar. Así, un nuevo archivo irá al lugar correcto porque la convención es legible, no porque una instantánea de tu árbol haya resultado ser precisa todavía.