MemoryLake
Volver a todos los artículos
Tutorial31 de agosto de 2026·12 min de lectura

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

La documentación de reglas de Cline tiene una tabla de formatos que reconoce, y una fila parece resolver toda esta migración: Cursor Rules, ubicación .cursorrules, descripción "Automatically detected."

Lea esa ubicación dos veces. .cursorrules es el formato antiguo de Cursor. La documentación actual de reglas de Cursor no lo menciona en ningún lado; las Project Rules "viven en .cursor/rules como archivos .mdc", y la página enfatiza que "Las reglas del proyecto deben usar la extensión .mdc". La documentación de Cline, por su parte, nunca menciona .cursor/rules ni .mdc en absoluto.

Así que la fila que parece hacer que esto sea gratuito apunta a un archivo que la mayoría de las instalaciones de Cursor de 2026 no tienen. El verdadero puente existe, solo que es diferente, y llegar a él es una conversión en lugar de una detección.

Una nota sobre por qué la gente se lo pregunta esta semana: OpenAI ha propuesto una fecha de cierre del 12 de noviembre de 2026 para los modelos que suministra a Cursor, y Cline documenta dos formas de acceder directamente a los modelos de OpenAI: una clave API o "OpenAI Codex (Subscription OAuth)". Eso es contexto, no el tema principal. Si debería mudarse o no es una pregunta aparte, y esta guía asume que ya la ha respondido.

Dos artículos relacionados cubren terreno cercano: el viaje inverso se encuentra en cómo migrar de Cline a Cursor, y la mitad correspondiente al formato de archivo por sí sola está en cómo migrar su CLAUDE.md a AGENTS.md.

Qué se transfiere realmente

AGENTS.md: el verdadero puente, leído por ambos. Cursor admite AGENTS.md "en la raíz del proyecto y en los subdirectorios", combinando archivos anidados con sus padres para que "las instrucciones más específicas tengan prioridad". La tabla de reglas admitidas de Cline enumera AGENTS.md y ~/.agents/AGENTS.md como un "Formato estándar para compatibilidad entre herramientas". Si sus reglas ya están en AGENTS.md, ya tiene la mayor parte del camino hecho y puede ejecutar ambas herramientas contra el mismo archivo mientras se decide.

Skills: a través de exactamente un directorio compartido. Cursor carga skills desde .agents/skills/, .cursor/skills/, ~/.agents/skills/ y ~/.cursor/skills/, además de una lista de compatibilidad: "Por compatibilidad, Cursor también carga skills desde los directorios de Claude y Codex: .claude/skills/, .codex/skills/, ~/.claude/skills/ y ~/.codex/skills/". Cline lee las skills del proyecto desde .cline/skills/, .clinerules/skills/ y .claude/skills/. Compare las dos listas y verá que hay un directorio en ambas: .claude/skills/, que no pertenece a ninguna de las dos herramientas. Coloque sus skills allí y ambas las leerán. La estructura de SKILL.md es la misma en ambos lados, por lo que se trata de un traslado, no de una reescritura.

Sus modelos, incluidos los de OpenAI, si es por eso que está aquí. Cline documenta dos rutas de OpenAI: una clave API introducida en la configuración y "OpenAI Codex (Subscription OAuth)" donde usted "Inicia sesión con OpenAI y completa el OAuth del navegador", sin "necesidad de introducir una clave API" y donde "los modelos disponibles dependen de su plan de OpenAI". Vale la pena compararlo con la propia página de Cursor para traer su propia clave, que limita OpenAI a "Modelos de chat estándar, sin razonamiento" y señala que "Las claves API personalizadas solo funcionan con modelos de chat".

Lo que no se transfiere: el frontmatter de .mdc como lenguaje de alcance. Este es el verdadero trabajo. Los cuatro tipos de reglas de Cursor se basan en tres campos de frontmatter, y su documentación detalla la interacción: alwaysApply: true significa "Siempre incluido. Se ignoran los globs y la descripción"; false con globs significa "Se adjunta automáticamente cuando un archivo coincidente está en contexto"; false con una description significa que el "Agente lee la descripción e incorpora la regla cuando es relevante"; false sin ninguno de los dos significa "Incluido solo cuando se menciona la regla con @ en el chat". Cline no tiene metadatos equivalentes. "Procesa todos los archivos .md y .txt dentro de .clinerules/, combinándolos en un conjunto unificado de reglas". Todo está dentro o fuera, con un interruptor manual por archivo.

También desaparece: las Team Rules como imposición. Las Team Rules de Cursor se crean en un panel de control, siguen una precedencia documentada de "Team Rules → Project Rules → User Rules" y se pueden marcar para que la regla sea "obligatoria para todos los miembros del equipo y no se pueda desactivar en Personalizar". El modelo de Cline es el opuesto por diseño: "Todos los tipos de reglas detectados aparecen en el panel de Reglas, donde se pueden activar o desactivar individualmente". Cada regla es conmutable por la persona que la usa. Eso es una pérdida real para un equipo que dependía de la imposición, y ningún archivo la transfiere.

Y desaparece: la sincronización remota de reglas. Cursor puede importar reglas desde un repositorio de GitHub en .cursor/rules/imported/<repoName> y "hacer pull y sincronizarlas". El equivalente de Cline es que .clinerules/ está en su repositorio, lo que cubre la misma necesidad para un solo proyecto y no para reglas compartidas entre muchos.

La migración manual

Paso 1: Inventaríe sus reglas según cómo se activan, no según el archivo en el que viven

Abra .cursor/rules y clasifique cada archivo .mdc por su frontmatter, porque eso es lo único que determina dónde debe terminar. Cuatro grupos.

alwaysApply: true. Estas son sus reglas siempre activas y se trasladan directamente. Colóquelas en AGENTS.md si desea que ambas herramientas lean el mismo archivo, o en .clinerules/ si se va a comprometer con Cline. Ambas opciones funcionan; la primera mantiene abiertas sus opciones.

globs definidos. Estos no tienen un equivalente directo. Las reglas de Cline no se adjuntan condicionalmente por patrón de archivo, por lo que una regla que solo se aplicaba a src/components/**/*.tsx se convierte en una regla siempre activa (pagando el costo de contexto en cada tarea) o en una regla conmutable que activa cuando trabaja en esa área. Elija por regla; no haga una conversión generalizada.

description definida, alwaysApply: false. Estas tienen un mejor destino de lo que esperaría, y no es el sistema de reglas. Cursor describe que este tipo se aplica "Cuando el Agente decide que es relevante en función de la descripción". Las skills de Cline funcionan de la misma manera: "Cuando envía un mensaje, Cline ve una lista de skills disponibles con sus descripciones. Si su solicitud coincide con la descripción de una skill, Cline la activa utilizando la herramienta use_skill, que carga las instrucciones completas desde SKILL.md". Mismo mecanismo, diferente nombre. Una regla activada por descripción se convierte en una skill de manera más fiel que en un archivo de reglas.

Ningún campo definido. Estas eran solo para mención con @. En Cline se convierten en archivos de reglas que se dejan desactivados, o en skills que invoca explícitamente. Ambas opciones son válidas; el interruptor es más cercano al original.

No elimine los archivos .mdc mientras hace esto. Son el único registro de qué estaba asignado a qué.

Paso 2: Ubique los archivos, conecte los modelos y vigile el costo de contexto

Cree .clinerules/ en la raíz del proyecto y mantenga un solo tema por archivo; este es el propio consejo de Cline, y aquí importa más porque la conmutación es su única herramienta de alcance: "Divida las reglas por tema... Esto facilita activar o desactivar reglas específicas".

Tres cosas que debe hacer bien.

Cuidado con la factura de tokens. Cline incluye esto como una advertencia: "Las reglas consumen tokens de contexto. Evite explicaciones largas o pegar guías de estilo completas. Mantenga las reglas concisas y enlace a documentación externa cuando se necesite una referencia detallada". En Cursor, una regla con glob no le costaba nada hasta que un archivo coincidente estaba en contexto. Convierta varias de esas en siempre activas y habrá trasladado silenciosamente ese costo a cada tarea.

Sepa dónde viven las reglas globales y quién gana. El directorio de reglas globales de Cline es ~/Documents/Cline/Rules en macOS y Linux y Documents\Cline\Rules en Windows, y también lee ~/.agents/AGENTS.md. Cuando ambos existen, "Las reglas del espacio de trabajo tienen prioridad cuando entran en conflicto con las reglas globales", la misma dirección que el orden de proyecto sobre usuario de Cursor, por lo que sus instintos se transfieren.

Cuidado con una inversión en la capa de skills. Cline establece que "Cuando una skill global y una skill de proyecto tienen el mismo nombre, la skill global tiene prioridad". Eso es lo contrario de cómo se resuelven las reglas, y lo contrario de la mayoría de las herramientas. Si mantiene una skill personal y una skill de proyecto con el mismo nombre, gana la personal.

Luego configure su proveedor (clave API o Codex OAuth bajo OpenAI en la configuración de Cline) y vuelva a agregar sus servidores MCP, que no se transfieren desde ningún editor.

Eso cubre la mitad escrita. Lo que queda es el razonamiento detrás de ello, y ninguna de las dos herramientas tiene un lugar para eso.

La mejor manera: ponga el razonamiento en un lugar que ningún editor posea

La respuesta de Cline a la persistencia es Memory Bank, y vale la pena entenderlo precisamente porque es honesto sobre lo que es. Seis archivos markdown en su repositorio (projectbrief.md, productContext.md, activeContext.md, systemPatterns.md, techContext.md, progress.md) más un archivo de reglas que le indica a Cline que los lea. Las instrucciones con las que se envía abren con una línea que vale la pena citar por completo: "Soy Cline, un ingeniero de software experto con una característica única: 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".

Esa es una metodología de documentación, y una buena. También está limitada a un código base: seis archivos que describen el estado de un proyecto, actualizados al pedirle a Cline que "actualice el memory bank". Las cosas que no encajan son las que nunca tuvieron que ver con el código: por qué existe un estándar, qué intentó y rechazó su equipo, a quién preguntar, qué fecha límite se movió.

MemoryLake es una capa de memoria que se encuentra fuera de cualquier herramienta individual, de modo que ese material sobreviva a esta migración y a la siguiente. La configuración consta de tres pasos.

Paso 1: Cree una clave API

Inicie sesión y cree una clave API. Una sola credencial para todas las herramientas que conecte.

Creación de una clave API de MemoryLake al migrar de Cursor a Cline
Creación de una clave API de MemoryLake al migrar de Cursor a Cline

Paso 2: Suba sus primeras memorias

Entradas cortas, una afirmación cada una. Su material de origen es lo que no pudo encajar en el frontmatter:

Traslado de conocimientos de referencia fuera de los archivos de reglas a entradas de MemoryLake
Traslado de conocimientos de referencia fuera de los archivos de reglas a entradas de MemoryLake

Por qué cada regla siempre activa está siempre activa. Acaba de tomar una decisión de criterio sobre cada regla con glob que convirtió. Registre la decisión y el motivo, o la tomará de nuevo de manera diferente en tres meses.

Qué protegían las Team Rules obligatorias. La imposición no sobrevive al traslado. El motivo por el que existía sí debería.

Correcciones que perduraron. El enfoque que el equipo intentó y abandonó. Ningún formato de reglas en ninguno de los lados tiene un campo para esto.

Contexto de trabajo que no es código. Propiedad, áreas congeladas, prioridades actuales, el manual de procedimientos (runbook). El archivo activeContext.md de Memory Bank cubre parte de esto para un repositorio; esto lo cubre para todos ellos.

Paso 3: Conecte su IA y agentes

Conecte lo que use. Se puede acceder a MemoryLake a través de MCP y de una API, y Cline admite servidores MCP, por lo que la misma memoria está disponible en Cline de inmediato. Cursor, Claude Code, Codex y OpenClaw se conectan de la misma manera, lo que significa que puede mantener ambos editores abiertos durante la transición sin tener que mantener dos copias de lo que sabe.

Conexión de Cline, Cursor y otros agentes a una capa de memoria compartida
Conexión de Cline, Cursor y otros agentes a una capa de memoria compartida

Tres límites honestos. Esto no convierte sus archivos .mdc: el mapeo del frontmatter en el Paso 1 es manual, y debería serlo, porque implica tomar decisiones. No restablece la imposición; una capa de memoria no puede hacer que una regla no se pueda desactivar en el panel de Reglas de Cline. Y la memoria es contexto, no imposición: la documentación de Cursor señala lo mismo sobre sus propias reglas obligatorias: "La guía de IA no debería ser su único control de seguridad".

Qué cambia esto en la práctica

El alcance de las reglas se convierte en una decisión explícita. Cursor lo decidía a partir del frontmatter. Cline le obliga a elegir por archivo, una vez, abiertamente.

Las reglas activadas por descripción terminan en un lugar real. Al convertirse en skills en lugar de meterse a la fuerza en un archivo siempre activo, mantienen el comportamiento que realmente deseaba.

Las skills dejan de pertenecer a un editor. Un directorio que ambas herramientas leen, por lo que cambiar de editor no es una migración de skills.

El razonamiento deja de vivir en una ventana de chat. Que es la única razón por la que algo de esto sobrevive al próximo cambio de herramienta.

Buenas prácticas para pasar de Cursor a Cline

Convierta por modo de activación, no por archivo. El frontmatter es la especificación. Los nombres de archivo no le dicen nada.

Use AGENTS.md para reglas siempre activas mientras se decide. Ambas herramientas lo leen, por lo que nada queda varado si cambia de opinión.

Envíe las reglas activadas por descripción a las skills. La activación de skills de Cline coincide más estrechamente con el comportamiento "Apply Intelligently" de Cursor que cualquier archivo de reglas.

Coloque las skills en .claude/skills/ si desea usar ambos editores. Es el único directorio en ambas listas de compatibilidad.

Audite lo que hizo siempre activo. Cada regla con glob convertida ahora cuesta contexto en cada tarea, y Cline advierte exactamente sobre esto.

Escriba para qué servía la imposición. Es la única propiedad que no sobrevive, y generalmente existía por una razón que alguien todavía puede nombrar.

Conserve los archivos .mdc hasta que se asiente el polvo. Documentan el alcance que está a punto de volver a implementar.

No confunda Memory Bank con la memoria entre proyectos. Describe el estado de un código base; la distinción más amplia se encuentra en por qué el contexto largo no es memoria.

Conclusión

La migración que Cline parece ofrecer de forma gratuita no es la que necesita. Su tabla de reglas detecta .cursorrules, un formato que la documentación actual de Cursor ya no menciona, mientras que el formato que realmente tiene (un directorio .cursor/rules lleno de archivos .mdc) no aparece en ninguna parte de la documentación de Cline. El puente que sí existe es AGENTS.md, que ambas herramientas leen, además de .claude/skills/, el único directorio de skills que aparece en ambas listas de compatibilidad.

Lo que le cuesta tiempo es el frontmatter. Los tres campos de Cursor producen cuatro comportamientos de activación, y las reglas de Cline son de todo o nada con un interruptor manual. Clasifique por alwaysApply, globs y description antes de copiar nada: las reglas siempre activas se trasladan directamente, las reglas con glob se convierten en una decisión por regla sobre el costo de contexto, las reglas activadas por descripción se convierten mejor en skills y las reglas de mención con @ se convierten en interruptores. La imposición de las Team Rules no se convierte en absoluto.

Y la capa debajo de todo esto (por qué existen estas reglas, qué se intentó y se rechazó, quién es dueño de qué) nunca estuvo en el formato de ninguna de las dos herramientas. El Memory Bank de Cline es honesto acerca de restablecerse por completo entre sesiones, que es exactamente la razón por la que el razonamiento pertenece a un lugar que ningún editor posee. Si el síntoma que lo trajo aquí fue que las reglas no se aplicaban silenciosamente, ambos lados de esa historia se cubren en por qué Cursor olvida las reglas de su proyecto y por qué Cline olvida el contexto de su proyecto.

Preguntas frecuentes

¿Lee Cline mis archivos .cursor/rules automáticamente?

No. La tabla de reglas admitidas de Cline enumera .clinerules/, .cursorrules, .windsurfrules y AGENTS.md, y .cursorrules es el formato heredado de un solo archivo de Cursor, no el directorio .cursor/rules. La documentación actual de Cursor establece que las Project Rules "viven en .cursor/rules como archivos .mdc" y no menciona .cursorrules en absoluto. La documentación de Cline no menciona .cursor/rules ni .mdc. Planifique hacer una conversión.

¿Cuál es el camino honesto más rápido para mis reglas?

Coloque todo lo que era alwaysApply: true en AGENTS.md en la raíz del proyecto. Cursor admite AGENTS.md en la raíz y en los subdirectorios; Cline enumera AGENTS.md y ~/.agents/AGENTS.md como un estándar para múltiples herramientas. Ese único archivo hace que ambos editores sigan sus estándares principales desde el primer día, y luego puede migrar las reglas con alcance de manera deliberada.

¿Es necesario reescribir mis skills?

No, pero es posible que deba trasladarlas. Ambas herramientas utilizan una carpeta que contiene un SKILL.md. Cursor carga skills desde .agents/skills/, .cursor/skills/, ~/.agents/skills/, ~/.cursor/skills/ y, "por compatibilidad", desde .claude/skills/, .codex/skills/ y sus equivalentes a nivel de usuario. Cline lee .cline/skills/, .clinerules/skills/ y .claude/skills/. La coincidencia es .claude/skills/, por lo que ese es el directorio que debe usar si desea que ambas herramientas lean una sola copia.

¿Puedo seguir usando modelos de OpenAI en Cline?

Cline documenta dos rutas bajo su proveedor de OpenAI: una clave API pegada en la configuración y "OpenAI Codex (Subscription OAuth)", donde inicia sesión con su cuenta de OpenAI y "no se requiere introducir una clave API", y donde "los modelos disponibles dependen de su plan de OpenAI". Ambas pasan por su propia cuenta de OpenAI. Esa es una disposición diferente a la de un modelo suministrado a un editor bajo un contrato de proveedor, que es de lo que trata el aviso del 12 de noviembre de OpenAI.

¿Qué pasa con mis Team Rules?

Dejan de ser obligatorias. Cursor documenta las Team Rules como gestionadas desde el panel de control, aplicadas con la precedencia "Team Rules → Project Rules → User Rules", y opcionalmente marcadas para que sean "obligatorias para todos los miembros del equipo y no se puedan desactivar en Personalizar". El diseño de Cline consiste en interruptores por archivo en el panel de Reglas, conmutables individualmente. Puede copiar el contenido en .clinerules/ o AGENTS.md; no puede copiar la propiedad que impedía que alguien las desactivara.

¿Es el Memory Bank de Cline un reemplazo para las reglas de Cursor?

No, y no intenta serlo. Memory Bank son seis archivos markdown que describen el estado de un proyecto, activados por un archivo de reglas que le indica a Cline que los lea, y sus instrucciones de fábrica describen una memoria que "se restablece por completo entre sesiones". Las reglas son lo que usted requiere; Memory Bank es lo que el proyecto es actualmente. Mantener los dos separados es el punto, una distinción que se cubre en por qué los agentes ignoran sus archivos de instrucciones y, para Cline específicamente, en las mejores configuraciones de memoria para Cline.