Cómo migrar de Zed a Cursor sin perder el contexto (2026)

Tus habilidades, sin ningún cambio. Las instrucciones de Zed para instalar una habilidad son "copiar la carpeta de la habilidad en ~/.agents/skills/ para uso global, o en la carpeta .agents/skills/ de tu proyecto para uso local del proyecto". Cursor carga habilidades desde .agents/skills/, .cursor/skills/, ~/.agents/skills/ y ~/.cursor/skills/. Las rutas de .agents/ son idénticas, ambas usan una carpeta que contiene un SKILL.md y ambas adoptaron el mismo estándar abierto. Si tus habilidades viven en .agents/skills/, funcionarán en Cursor en el momento en que abras el repositorio.

Cursor va más allá en cuanto a compatibilidad: "también carga habilidades desde los directorios de Claude y Codex: .claude/skills/, .codex/skills/, ~/.claude/skills/ y ~/.codex/skills/ ".

El contenido de tus instrucciones, una vez que establezcas qué archivo lo contenía. El texto se mueve. En qué archivo estaba y qué archivo estaba leyendo Zed son dos preguntas diferentes.

Instrucciones personales, como User Rules. Las instrucciones personales de Zed viven en ~/.config/zed/AGENTS.md (en Windows, bajo %APPDATA%\Zed\). El equivalente de Cursor son las User Rules, "Globales para tu entorno de Cursor".

Lo que no se transfiere: el mecanismo de 'el primer acierto gana'. Zed elige un archivo. Las Project Rules de Cursor son condicionales: cada archivo .mdc decide su propio comportamiento de carga a través del frontmatter. Eso significa más control y más cosas que configurar correctamente.

Tampoco se transfiere: cualquier suposición sobre agentes externos. Zed ejecuta agentes externos sobre ACP (Claude, Codex, OpenCode, Copilot, Cursor y otros) e hilos de terminal (Terminal Threads) que ejecutan una CLI directamente. La documentación de Zed es cuidadosa en este punto: "Los agentes externos y los hilos de terminal pueden leer sus propios archivos de instrucciones nativos directamente. No asumas que el cargador de instrucciones de Zed controla esos agentes". Si tu configuración de Zed se apoyaba en agentes externos, parte del comportamiento de tu contexto nunca fue de Zed para empezar.

Y la verdad honesta: ninguna de las dos herramientas documenta una capa de memoria. El índice de documentación de Zed no tiene página de memoria, y el de Cursor tampoco. Ambas son herramientas de instrucciones y habilidades por diseño, y Cursor establece la premisa subyacente directamente: "Los modelos de lenguaje grandes no retienen memoria entre completados. Las reglas proporcionan un contexto persistente y reutilizable a nivel de prompt". Esa es una descripción precisa de lo que son las reglas y una declaración clara de lo que no son. Nada en esta migración cambia eso: te estás moviendo entre dos herramientas que esperan que tú proporciones la continuidad.

Paso 1: Averigua qué archivo ha estado leyendo realmente Zed

Recorre la lista en orden — .rules, .cursorrules, .windsurfrules, .clinerules, .github/copilot-instructions.md, AGENT.md, AGENTS.md, CLAUDE.md, GEMINI.md — y detente en el primer archivo que exista en tu repositorio. Ese es tu archivo real de instrucciones del proyecto. Todo lo que esté por debajo de él ha estado inerte.

Hay dos resultados comunes y vale la pena detectar ambos antes de migrar:

Un archivo heredado obsoleto está ganando. Un .cursorrules o .windsurfrules dejado por una herramienta anterior tiene prioridad sobre AGENTS.md. Nota la ironía para esta migración en particular: .cursorrules no aparece en absoluto en la documentación actual de Cursor; los cuatro tipos de reglas de Cursor son Project Rules en .cursor/rules, User Rules, Team Rules y AGENTS.md. Un .cursorrules obsoleto ha sido el archivo que dirigía a Zed mientras era el archivo que Cursor ya había dejado atrás.

Tu archivo mantenido nunca se estaba cargando. Si AGENTS.md no es la primera coincidencia, las reglas que pensabas que estaban vigentes no lo estaban. Lee el archivo que estaba ganando; es posible que algo de lo que asumías que funcionaba nunca se haya probado.

Comprueba también la precedencia entre lo personal y lo del proyecto: "Las instrucciones del proyecto anulan las AGENTS.md personales cuando entran en conflicto". Si un comportamiento te sorprendió en un repositorio pero no en otro, esa suele ser la razón.

Una nota sobre la terminología para que no busques algo que ha sido renombrado. La documentación de Zed indica que "Las reglas han sido reemplazadas por habilidades e instrucciones" (Skills and Instructions), donde las reglas reutilizables bajo demanda se convierten en Skills, las reglas siempre activas se convierten en el AGENTS.md personal y los archivos .rules del proyecto se conservan por compatibilidad. Si seguiste una guía de Zed más antigua, los conceptos siguen existiendo bajo nombres diferentes.

Paso 2: Reconstruye un archivo siempre activo como reglas que se carguen cuando deban

Las Project Rules de Cursor viven en .cursor/rules como archivos .mdc, y la extensión no es opcional. La documentación es explícita: "Las reglas del proyecto deben usar la extensión .mdc. 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".

Así que tienes dos opciones de destino, y la más simple suele ser la correcta: si tus instrucciones de Zed eran un único archivo siempre activo y quieres que sigan siendo así, colócalas en AGENTS.md, que Cursor documenta como una "Alternativa simple a .cursor/rules". Listo.

Si deseas la carga condicional que Zed no podía hacer, realiza la traducción en su lugar. Los cuatro tipos de reglas de Cursor se corresponden claramente con las secciones que el AGENTS.md de la mayoría de la gente ha ido desarrollando:

La interacción está documentada como una tabla y se comporta exactamente como se lee: alwaysApply: true significa que se ignoran los globs y la descripción; alwaysApply: false con globs se acopla automáticamente cuando un archivo coincidente está en contexto; false con una descripción permite al agente traerlo cuando sea relevante; y false sin ninguno de los dos significa que la regla se carga solo cuando la mencionas con @.

El tipo Apply Intelligently es el que hay que escribir con cuidado. La descripción es lo que lee el agente para decidir la relevancia, por lo que "Convenciones de servicio RPC y patrones para el backend" se gana su lugar y "reglas varias" no.

Notas prácticas: /create-rule en Agent genera el archivo con el frontmatter correcto, que es la forma más rápida de evitar por completo la trampa del .md. Las reglas se pueden organizar en carpetas dentro de .cursor/rules. Los directorios .cursor/skills/ anidados se limitan automáticamente a los archivos dentro de ese directorio, por lo que un monorepositorio puede colocar las habilidades junto al paquete al que pertenecen. Y una advertencia si usas la ejecución remota o en la nube de Cursor: Cursor "no copia tus carpetas locales ~/.cursor/skills/ y ~/.agents/skills/ a los Cloud Agents", sesiones SSH remotas o trabajadores autogestionados; las habilidades de proyecto del repositorio viajan, las personales no.

Esto completa la migración de archivos. Lo que no completa es nada que nunca haya estado en un archivo.

Ambas herramientas manejan bien las instrucciones y ninguna pretende hacer más. El propio enfoque de Cursor es el más honesto: las reglas "proporcionan un contexto persistente y reutilizable a nivel de prompt" y el contenido de las reglas "se incluye al principio del contexto del modelo".

Al principio del contexto, en cada solicitud relevante. Esa restricción es lo que hace que un archivo de reglas sea el contenedor equivocado para toda una categoría de conocimiento. Por qué existe una convención, qué enfoque ya intentaste y rechazaste, la restricción que hace que la solución obvia sea incorrecta, la fecha límite que explica el atajo... nada de eso es una instrucción. Ponerlo en AGENTS.md hace que el archivo sea más largo y el agente no sea más obediente, y después de una migración en la que acabas de descubrir que un archivo que mantenías ni siquiera se estaba cargando, el atractivo de un archivo de instrucciones más corto debería ser obvio.

Eso es lo que almacena MemoryLake: el conocimiento duradero de tu proyecto en una capa que tus herramientas consultan, para que las reglas sigan siendo cortas y el razonamiento permanezca disponible en cualquier editor en el que te encuentres este año. La configuración consta de tres pasos.

Paso 1: Crea una clave API

Inicia sesión y crea una clave API. Una sola credencial para todas las herramientas que conectes.

Paso 2: Sube tus primeras memorias

Entradas cortas, una afirmación cada una. La mejor fuente es el archivo de instrucciones que estabas a punto de alargar:

La razón de cada regla. "Los componentes se mantienen por debajo de las 200 líneas porque las herramientas de revisión truncan los diffs más grandes". La regla va en un archivo .mdc; esto va aquí, y es lo que evita que la regla se descarte el próximo trimestre.

Enfoques ya rechazados en este repositorio. La categoría que no aparece en ningún archivo de reglas ni en ningún mensaje de commit, y que se vuelve a proponer en cada nueva sesión.

Hechos del entorno que nadie anuncia. El límite de velocidad no documentado, la dependencia de orden entre dos trabajos, la prueba que solo falla en CI.

Lo que la migración te acaba de enseñar. Si un .cursorrules obsoleto tenía prioridad sobre tu AGENTS.md, escribe qué convenciones, por lo tanto, nunca se aplicaron realmente. Eso es un hecho sobre tu base de código, no una regla.

Paso 3: Conecta tu IA y agentes

Conecta lo que uses. MemoryLake es accesible a través de MCP y de una API, y tanto Zed como Cursor admiten servidores MCP, lo cual es útil durante el período de transición cuando aún no te has cambiado por completo. Los agentes nativos de MCP como Claude Code, Codex y OpenClaw leen la misma memoria, y cualquier otra cosa accede a ella a través de la API.

Tres límites honestos. MemoryLake no escribe tus archivos .mdc, tu AGENTS.md ni tus User Rules; así es como diriges Cursor, y el comportamiento de carga descrito anteriormente es el de Cursor. Solo contiene lo que tú o tus agentes introducen en él, por lo que el Paso 2 es deliberado. Y las reglas son contexto en lugar de configuración forzada: cualquier cosa que deba cumplirse absolutamente siempre necesita una comprobación en CI, no una línea en markdown.

Descubres qué se estaba cargando realmente. El principio de 'el primer acierto gana' significa que la respuesta a menudo no es el archivo que estabas editando.

Las habilidades no cuestan nada de mover. Ambas herramientas leen .agents/skills/.

La carga se vuelve condicional en lugar de todo o nada. Cuatro tipos de reglas reemplazan a un único archivo siempre activo.

La trampa del .md deja de ser un misterio. Una extensión incorrecta en .cursor/rules significa que el archivo no existe.

Los archivos de instrucciones se vuelven más cortos. El razonamiento se traslada fuera, por lo que lo que queda son instrucciones.

El próximo cambio de editor es más barato. El conocimiento duradero ya no está dentro del directorio de configuración de una sola herramienta.

Establece el archivo ganador antes de copiar nada. Zed lee la primera coincidencia en una lista de nueve archivos.

Elimina los archivos de reglas heredados obsoletos después de haberlos leído. Un .cursorrules sobrante tiene prioridad sobre AGENTS.md en Zed y no está documentado en el Cursor actual.

Usa /create-rule en lugar de escribir a mano el frontmatter de .mdc. Genera un frontmatter válido y evita el fallo más común.

Si quieres markdown simple, usa AGENTS.md. Cursor lo documenta como la alternativa simple; no luches contra .cursor/rules.

Escribe descripciones reales en las reglas de Apply Intelligently. La descripción es lo que lee el agente para decidir la relevancia.

Limita el alcance con globs en lugar de un único archivo gigante siempre activo. Cargar todo en cada solicitud es lo que hacía que el archivo de Zed fuera inmanejable.

Mantén las habilidades personales en el repositorio si usas Cloud Agents. El ~/.agents/skills/ local no se copia a los entornos de ejecución remotos.

No esperes que ninguna de las dos herramientas recuerde. Ninguna documenta una capa de memoria; la estructura general se encuentra en lo que los agentes de programación realmente leen.

Esta migración es más fácil que la mayoría y tiene una auténtica sorpresa. La parte fácil son las habilidades: tanto Zed como Cursor cargan desde .agents/skills/ y ~/.agents/skills/, ambos usan una carpeta con un SKILL.md y nada necesita conversión. La sorpresa está en el origen: Zed lee el primer archivo coincidente de una lista de nueve, por lo que el archivo de instrucciones que ha estado dando forma a tu agente podría no ser el que has estado manteniendo, y AGENTS.md se encuentra en el séptimo lugar de ese orden.

Establece qué archivo estaba ganando, léelo correctamente y luego decide cómo debe quedar. Un archivo siempre activo va a AGENTS.md y habrás terminado. Si deseas una carga condicional, tradúcelo a .cursor/rules, recordando que se ignora un .md simple en ese directorio y que /create-rule escribe un frontmatter válido por ti.

Lo que ninguna de las dos herramientas ofrece es un lugar para el razonamiento. Cursor lo dice claramente: las reglas proporcionan un contexto reutilizable a nivel de prompt, cargado al principio del contexto del modelo. Esa es la descripción correcta de un archivo de instrucciones y la razón por la que es el contenedor equivocado para decisiones, enfoques rechazados y restricciones. Mueve las instrucciones a los tipos de reglas correctos, mantenlas cortas y coloca el razonamiento en un lugar que tu próximo editor también pueda leer. Cómo se ve eso específicamente en el lado de Cursor se cubre en cómo llevar el contexto de Cursor a través de las sesiones.