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

Tus reglas se transfieren como texto y no como comportamiento. La documentación de Cline describe que las reglas del espacio de trabajo van en .clinerules/ en la raíz del proyecto, y que Cline procesa "todos los archivos .md y .txt dentro de .clinerules/, combinándolos en un conjunto unificado de reglas". Las reglas globales viven en ~/Documents/Cline/Rules en macOS y Linux, y las reglas del espacio de trabajo tienen prioridad cuando hay conflictos.

El modelo de Cursor es de una naturaleza distinta. Las reglas del proyecto son archivos .mdc en .cursor/rules, bajo control de versiones, y tres campos de frontmatter (alwaysApply, description, globs) deciden cuándo entra cada una en contexto. Su documentación es explícita al señalar que el sistema de reglas ignora los archivos .md ordinarios en esa carpeta porque carecen de esos campos, y que el Markdown simple pertenece a AGENTS.md en su lugar.

Ten en cuenta específicamente el caso de .txt: Cline lee reglas .txt, y el sistema de reglas de Cursor no tiene espacio para ellas en absoluto. Esas desaparecen sin previo aviso.

La semántica de activación casi coincide, pero la estructura no. Las reglas condicionales de Cline "se activan solo cuando tus archivos actuales coinciden con su alcance definido", y —la frase que más importa para la conversión— "Las reglas sin frontmatter siempre están activas".

Así que una carpeta .clinerules/ típica es un montón de archivos siempre activos combinados. Eso es efectivamente un gran bloque de instrucciones siempre encendido. Conviértelo uno a uno en archivos .mdc con alwaysApply: true y habrás reproducido fielmente el bloque, en una herramienta cuya propia guía es mantener las reglas por debajo de las 500 líneas. Fiel, pero incorrecto.

Memory Bank se transfiere como archivos y pierde su mecanismo. Esta es la parte importante. El Memory Bank de Cline está documentado como "un sistema de documentación estructurado que ayuda a Cline a mantener el contexto entre sesiones", lo que convierte a Cline "de un asistente sin estado en un socio de desarrollo persistente". Prescribe seis archivos principales: projectbrief.md, productContext.md, activeContext.md, systemPatterns.md, techContext.md y progress.md.

Lee la premisa sobre la que está construido, expresada en primera persona en la propia documentación de Cline: "mi memoria se restablece por completo entre sesiones. Esto no es una limitación, es lo que me impulsa a mantener una documentación perfecta". Y la regla de funcionamiento: "Después de cada restablecimiento, dependo POR COMPLETO de mi Memory Bank para comprender el proyecto y continuar el trabajo de manera efectiva".

Eso funciona porque Cline está programado para leer todo eso al inicio de cada tarea. Cursor no tiene una convención equivalente. Copia la carpeta y los documentos estarán allí, actualizados pero sin leer.

Lo que Cursor te ofrece en su lugar. Cuatro tipos de reglas según su documentación: reglas de proyecto en .cursor/rules acotadas a la base de código y bajo control de versiones, reglas de usuario que se aplican a todo tu entorno de Cursor, reglas de equipo gestionadas en el panel de control en los planes Team y Enterprise, y AGENTS.md como una alternativa de Markdown simple a .cursor/rules. Las reglas se anteponen al contexto del modelo. Y Cursor expone la realidad subyacente con tanta claridad como Cline: "Los modelos de lenguaje grandes no retienen memoria entre completados. Las reglas proporcionan un contexto persistente y reutilizable a nivel de prompt".

Ambas herramientas coinciden en que no hay memoria. Difieren en lo que se supone que debes hacer al respecto: Cline dice que mantengas la documentación religiosamente, Cursor dice que configures las reglas con precisión. La migración es entre esas dos filosofías, no entre dos formatos de archivo.

Paso 1: Divide el bloque unificado antes de convertir nada

No conviertas archivo por archivo. Lee el contenido combinado de .clinerules/ como un solo documento —que es como lo trataba Cline— y reestructúralo según cuándo debe aplicarse cada parte:

• Siempre, en cada completado: las dos o tres restricciones que harían que una respuesta fuera incorrecta. Encabezados de derechos de autor, "nunca edites archivos generados", la regla arquitectónica estricta.
• Solo al tocar ciertos archivos: cualquier cosa que mencione un directorio, un lenguaje o una capa. Esto suele ser la mayor parte.
• Solo cuando el modelo lo considere relevante: convenciones de dominio que no se asignan a una ruta.
• Solo cuando lo solicites: listas de verificación largas, procedimientos de lanzamiento, protocolos de revisión.

Luego escribe un archivo .mdc por grupo en .cursor/rules y configura el frontmatter para que coincida:

• Siempre → alwaysApply: true (se ignoran los globs y la descripción)
• Acotado a archivos → globs: src/api/**/*.ts con alwaysApply: false
• Seleccionado por el modelo → una buena description: y sin globs
• Manual → ninguno de los dos, e invócalo con @nombre-de-regla en el chat

Dos trampas mientras haces esto. La extensión debe ser .mdc; un archivo .md en .cursor/rules se ignora por completo, sin ningún error. Y tus reglas globales de Cline (~/Documents/Cline/Rules) son personales, no del proyecto, por lo que pertenecen a las Reglas de Usuario de Cursor en Customize, no al repositorio. Si tu equipo comparte estándares, las reglas de equipo gestionadas desde el panel de control son la capa superior en los planes Team y Enterprise.

Haz las eliminaciones aquí también. Una migración es el único momento en que alguien lee cada regla con ojos nuevos; de lo contrario, la regla escrita para un servicio que diste de baja se obedecerá indefinidamente.

Paso 2: Decide qué pasa con el Memory Bank

Tienes tres opciones, y elegir deliberadamente importa más que cuál elijas.

Opción A: consérvalo y apunta Cursor hacia él. Escribe una regla .mdc, alwaysApply: true, que le indique al agente que lea memory-bank/activeContext.md y memory-bank/progress.md antes de comenzar a trabajar, y que los actualice cuando termine. Esta es la reproducción más cercana al comportamiento de Cline. El costo es real: estás agregando una instrucción siempre activa más las lecturas de archivos que desencadena, en cada sesión.

Opción B: integra las partes duraderas en las reglas y conserva el resto como documentos. systemPatterns.md y techContext.md son principalmente arquitectura estable y datos del stack; esos se convierten en reglas de proyecto o en un AGENTS.md. projectbrief.md y productContext.md son documentos de orientación que un humano lee una vez; déjalos como documentos del repositorio. activeContext.md y progress.md son el estado de la sesión, y aquí es donde debes ser honesto: nada en Cursor los mantiene por ti, por lo que o los actualizas a mano o se deteriorarán hasta convertirse en una descripción errónea pero confiada de dónde se encuentra el proyecto.

Opción C: retira el formato y conserva el contenido. La estructura de seis archivos existe porque Cline necesitaba un lugar fijo donde mirar después de cada restablecimiento. Si ya no estás ejecutando Cline, la estructura es solo un andamiaje; lo que importa es que las decisiones, la arquitectura y las restricciones que contiene permanezcan en algún lugar recuperable.

Elijas lo que elijas, no te quedes sin hacer nada en silencio. Un activeContext.md desactualizado en el repositorio es peor que no tener ningún Memory Bank, porque la próxima persona —o el próximo agente que se tope con él— lo creerá.

Un elemento de inventario más antes de cerrar la configuración antigua: cualquier cosa que Cline haya aprendido y que nunca hayas escrito en el Memory Bank. Pregúntale, en una sesión, qué sabe sobre las peculiaridades del proyecto y sobre qué advertiría a un nuevo desarrollador. Pega las respuestas en algún lugar. Esa es la única parte de esta migración que tiene una fecha límite.

Fíjate en lo que el Memory Bank de Cline hizo bien, porque es la razón por la que a la gente le encanta: trata el conocimiento como un artefacto de primera clase en lugar de como un efecto secundario de chatear. Su debilidad es dónde vive ese artefacto y quién lo mantiene: seis archivos en un repositorio, actualizados por la convención de una herramienta, invisibles para cualquier otro asistente que utilices.

Así que conserva el instinto y cambia la dirección. Las reglas se quedan en el repositorio, en el formato de Cursor, pequeñas. El conocimiento detrás de ellas —decisiones, arquitectura, incidentes, contratos— va a un almacén que cualquier herramienta puede leer y escribir.

MemoryLake es una capa de memoria para eso: un almacén único donde viven tus documentos, decisiones y conocimiento del proyecto, legible directamente desde herramientas compatibles con MCP como Claude y Codex, y desde ChatGPT a través de la API. La idea del Memory Bank, menos el requisito de que la convención de un agente sea lo que lo mantenga vivo.

Paso 1: Crea una clave API

Genera una clave y realiza tu primera solicitud en unos 30 segundos. Guárdala en tu entorno o en un gestor de secretos en lugar de pegarla en un chat.

Paso 2: Sube tus primeras memorias

Arrastra los documentos, imágenes y archivos que tu Memory Bank estaba reemplazando: systemPatterns.md y techContext.md tal como están, las decisiones de arquitectura con sus motivos, los informes de incidentes, los contratos de API, las restricciones que has acumulado. Sube las fuentes en lugar de una versión condensada; condensar es lo que hace que se pierda la razón detrás de una regla.

Paso 3: Conecta tu IA y agentes

Dale acceso a la memoria a Claude, Codex, OpenClaw y otros agentes de IA a través de MCP o la API. Las herramientas que hablan MCP leen el mismo almacén directamente, por lo que el conocimiento llega a cualquier agente que estés usando este mes, en lugar de a aquel cuya convención de carpetas adoptaste el año pasado.

La primera diferencia es que tus reglas siempre activas pueden ser tres reglas. La presión para hacer que todo se aplique siempre proviene de no tener otro lugar donde poner el contexto; con la recuperación disponible, alwaysApply: true se reserva para lo que haría que una respuesta fuera incorrecta.

La segunda es que activeContext.md deja de ser una mentira a punto de ocurrir. El estado que nadie mantiene se deteriora; el estado en un almacén en el que los agentes escriben a medida que trabajan se mantiene actualizado, y las partes que son genuinamente estables —decisiones, arquitectura— no necesitan mantenimiento alguno.

La tercera es que el conocimiento deja de tener la forma de la herramienta. Un Memory Bank es una convención de Cline, .cursor/rules es una convención de Cursor, CLAUDE.md es una convención de Claude Code. El material dentro de los tres es el mismo material, razón por la cual cambiar de editor sigue costando un fin de semana hasta que vive fuera de ellos.

Y se integra con lo que Cursor hace de forma nativa. Las reglas siguen proporcionando contexto a nivel de prompt exactamente como está documentado, las reglas de equipo siguen distribuyendo estándares, y ninguna de las dos tiene que albergar el historial de tu proyecto, que es lo que hace que las reglas de Cursor parezcan que se olvidan constantemente cuando en realidad son simplemente cortas por diseño.

Reestructura las reglas por activación, nunca archivo por archivo

Cline combinaba todo; Cursor evalúa cada archivo en sus propios términos. Una copia uno a uno pierde la condicionalidad o hace que todo esté siempre activo. Dedica una hora a reestructurar: es la diferencia entre reglas que se activan cuando son relevantes y un bloque que diluye cada prompt.

Verifica la extensión antes de depurar nada

.mdc o no existe. El sistema de reglas ignora los archivos .md en .cursor/rules, y los archivos .txt no tienen cabida en absoluto. Si Cursor "no sigue tus reglas" justo después de una migración, comprueba esto primero.

Coloca las reglas personales en las Reglas de Usuario, los estándares de equipo en las reglas de equipo

La carpeta de reglas globales de Cline es una capa personal; el repositorio no lo es. Las Reglas de Usuario de Cursor cubren tus hábitos en todos los proyectos, y las reglas de equipo gestionadas desde el panel de control cubren los estándares de la organización en los planes Team y Enterprise. Mezclar las tres en las reglas del proyecto es la forma en que todos heredan las preferencias personales de alguien.

Decide el destino del Memory Bank el primer día

Consérvalo con una regla siempre activa, intégralo en reglas y documentos, o retira el formato y mueve el contenido. Las tres opciones son defendibles. Dejar seis archivos sin mantenimiento en el repositorio no lo es, porque todo su valor radicaba en estar actualizados.

Pregúntale al antiguo agente qué sabe antes de dejar de usarlo

Cualquier cosa que no esté escrita en el Memory Bank existe solo en las sesiones que estás a punto de abandonar. Diez minutos preguntándole a Cline sobre qué advertiría a un nuevo desarrollador es el seguro más barato en todo este proceso.

No esperes que las reglas sirvan para obligar al cumplimiento

Cursor lo dice directamente: las reglas proporcionan un contexto persistente y reutilizable a nivel de prompt. El contexto es influencia. El formateo, los archivos protegidos, las importaciones prohibidas y la política de commits pertenecen a los formateadores, linters y CI; y luego el archivo de reglas puede explicar por qué existen.

De Cline a Cursor son dos migraciones bajo un mismo abrigo. La parte de las reglas necesita reestructuración en lugar de copia, porque Cline combina cada archivo .md y .txt en .clinerules/ en un único conjunto unificado, mientras que Cursor decide el destino de cada archivo .mdc a partir de su frontmatter —y un archivo .md simple en .cursor/rules se ignora sin ningún error—. La parte de Memory Bank es la que se rompe silenciosamente: seis archivos markdown que llegan intactos y pierden la convención que hacía que Cline los leyera después de cada restablecimiento.

Ambas herramientas te dicen la verdad sobre el problema subyacente. Cline dice que su memoria se restablece por completo entre sesiones, por lo que insiste en la documentación. Cursor dice que los modelos no retienen memoria entre completados, por lo que insiste en las reglas. Tómate en serio el instinto del Memory Bank, mantén las reglas pequeñas y acotadas, y coloca el conocimiento en sí en un almacén que ninguna de las dos herramientas posea. Así, la próxima migración será un cambio de configuración en lugar de una excavación.