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.

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:

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.

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.