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

La documentación de las reglas de Cursor es precisa sobre el requisito de formato, y la precisión es el punto clave:

"Las reglas del proyecto viven en .cursor/rules como archivos .mdc y están bajo control de versiones. Se acotan mediante patrones de ruta, se invocan manualmente o se incluyen según su relevancia."

"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."

Tres campos de frontmatter contienen toda la condicionalidad. La documentación detalla la bifurcación clave:

"Si alwaysApply es true, la regla se aplicará a cada sesión de chat. De lo contrario, la descripción de la regla se presentará al Cursor Agent para decidir si debe aplicarse."

Además de globs para acotar una regla a los archivos que coincidan, y una recomendación de "mantener las reglas por debajo de las 500 líneas".

Vale la pena detenerse en ese requisito de extensión, porque es la razón más común por la que la gente llega a una migración ya frustrada. Una regla guardada como .md en ese directorio no es una regla rota; no es una regla en absoluto, y nada te lo advierte. La mitad de los informes de que Cursor olvida las reglas del proyecto se remontan a un archivo que el sistema de reglas nunca detectó.

Ahora Roo Code. Las reglas del espacio de trabajo van en .roo/rules/, que la documentación define como el método preferido, con un único archivo .roorules en la raíz del espacio de trabajo como alternativa (fallback). Las reglas globales van en ~/.roo/rules/, y esa ubicación "es fija y no se puede personalizar". El orden de carga está documentado claramente: primero las reglas globales, luego las reglas del proyecto y "si hay un conflicto, las reglas del espacio de trabajo tienen prioridad".

La ruta global fija tiene una consecuencia práctica para los equipos: es una ubicación en el directorio de inicio, por lo que es por máquina y está fuera del control de versiones. Cualquier cosa que pongas allí existe en una sola laptop, que es la misma asimetría detrás de que Cursor olvide la configuración entre máquinas. Coloca las reglas relevantes para el equipo en el directorio del espacio de trabajo, no en el global.

Y luego, la frase que cambia tu plan:

"Roo Code lee los archivos de forma recursiva (incluyendo subdirectorios), añadiendo su contenido al prompt del sistema en orden alfabético según el nombre del archivo."

Recursivamente, añadiendo, alfabético, por nombre de archivo. No hay alwaysApply porque se aplica todo lo que está en el directorio. No hay globs porque nada está acotado a nivel de archivo. No hay description para que el modelo la evalúe, porque no se le está pidiendo al modelo que decida.

Así que esto es lo que se transfiere y lo que no. La prosa de cada regla se transfiere sin cambios; es markdown en ambos casos. La estructura de directorios se transfiere, ya que Roo Code también lee subdirectorios. Lo que se evapora son los tres campos de frontmatter, y con ellos toda la distinción entre una regla que se aplica siempre y una regla que se aplica a src/api/**/*.ts.

De esto se derivan dos consecuencias, y la segunda suele sorprender a la gente.

Primero, tu consumo de contexto aumenta. Cada regla que escribiste como condicional (el largo archivo de convenciones de base de datos acotado a las migraciones, el archivo de patrones de React acotado a .tsx) ahora está en el prompt del sistema en cada solicitud, incluidas aquellas sobre tu script de compilación.

Segundo, contradicciones que nunca se cruzaron ahora lo hacen. Una regla que decía "preferir componentes de servidor" acotada a tu directorio app y una regla que decía "todos estos son componentes de cliente" acotada a una carpeta heredada (legacy) nunca estuvieron juntas en el contexto bajo Cursor. Bajo una adición plana sí lo están, y cuál queda más abajo en el prompt se decide por qué nombre de archivo se ordena después. Este es el mecanismo detrás de informes como que Roo Code olvida el contexto del proyecto: las reglas están presentes y no están de acuerdo.

Roo Code sí tiene un mecanismo de condicionalidad. Solo que está en otro lugar.

Paso 1: Reexpresar el alcance de globs como modos

Roo Code acota las reglas por modo, no por ruta de archivo. Junto a .roo/rules/ puedes crear directorios .roo/rules-{modeSlug}/, y los ejemplos documentados incluyen rules-code/ para el modo Code, rules-architect/ para tareas de arquitectura, rules-debug/ para flujos de trabajo de depuración y rules-docs-extractor/ para la extracción de documentación. El mismo patrón existe globalmente bajo ~/.roo/. Dentro de cada nivel, la documentación señala que "las reglas específicas de modo se cargan antes que las reglas generales".

Así que revisa tus archivos .mdc y clasifícalos según lo que sus globs realmente intentaban aproximar. Una regla acotada a archivos de prueba suele ser una regla sobre cómo escribes pruebas, lo cual es una preocupación del modo Code o del modo Debug. Una regla acotada a documentos de arquitectura pertenece a rules-architect/. Una regla que tenía alwaysApply: true va a .roo/rules/ sin cambios, porque eso es lo que significa ese directorio.

Las reglas cuyos globs eran genuinamente sobre rutas en lugar de tipos de trabajo son las que no tienen un hogar claro. En su lugar, escribe esas reglas como condicionales explícitos en la prosa (una frase que indique a qué directorio se aplica la guía), ya que el archivo se cargará de todos modos y el modelo necesita conocer el límite a partir del texto. Es menos confiable que un glob, pero es honesto sobre lo que admite el destino.

Mientras estás aquí, elimina los bloques de frontmatter en lugar de dejarlos en su lugar. Roo Code no analiza un encabezado YAML suelto en la parte superior de un archivo de reglas, por lo que se convierte en contenido: instrucciones para el modelo sobre alwaysApply que no significan nada.

Paso 2: Controlar el orden de adición deliberadamente y vigilar dos trampas

Dado que el contenido se añade en orden alfabético por nombre de archivo, los nombres de archivo ahora representan el orden de carga. Nómbralos de modo que el orden sea intencional: un prefijo numérico en cada archivo hace que la secuencia sea explícita y evita que un cambio de nombre posterior reordene silenciosamente tu prompt del sistema.

Luego, dos comportamientos documentados que debes verificar.

El primero es la trampa del directorio vacío: "Si el directorio .roo/rules/ existe pero está vacío, Roo Code recurrirá al uso del archivo .roorules en su lugar". Por lo tanto, una migración a medias (directorio creado, archivos aún no movidos) reactiva silenciosamente un archivo raíz heredado que quizás hayas olvidado.

El segundo es la prioridad de los archivos heredados de manera más amplia. El orden de carga documentado enumera los archivos heredados en la raíz del espacio de trabajo, .roorules y .clinerules, como "utilizados solo si no se cargó contenido del directorio de reglas genéricas". Que Roo Code lea .clinerules es conveniente si vienes de Cline y confuso si no: un archivo antiguo en tu repositorio no hace nada mientras tu directorio de reglas tenga contenido, y toma el control en el momento en que no lo tiene.

Finalmente, mantén tu AGENTS.md donde está. Cursor lo admite como la alternativa de markdown simple a .mdc, y sigue siendo útil en todo tu entorno tecnológico: migrar las reglas de Cursor a una configuración estilo Windsurf cubre el mismo problema de traducción para un destino diferente, y el hilo común es que la convención abierta es la parte que sobrevive.

El Paso 1 te pidió decidir a qué modo pertenece cada regla, y el Paso 2 te pidió decidir en qué orden se cargan. Ambas decisiones son fáciles cuando sabes por qué existe cada regla y casi imposibles cuando no lo sabes.

"Preferir componentes de servidor" frente a "todos estos son componentes de cliente" es irresoluble como dos imperativos ordenados alfabéticamente. Es trivial una vez que sabes que el segundo describe un directorio que nadie ha migrado todavía y el primero es la dirección vigente. Esa razón no está en ninguna de las dos herramientas, y tampoco estaba en el frontmatter de .mdc.

MemoryLake mantiene esa capa (la decisión, la alternativa que perdió y la razón) fuera de cualquier editor, y la sirve a cualquier agente que la solicite a través de MCP o la API. Tus archivos .roo/rules/ se mantienen cortos e imperativos, cargados exactamente como describe la documentación, y el razonamiento detrás de ellos se puede responder sin necesidad de estar en el prompt del sistema en cada solicitud.

Paso 1: Crear una clave API

Genera una clave y realiza tu primera solicitud en unos treinta segundos. Haz esto antes del Paso 1 anterior, para que tengas un lugar donde registrar cada conflicto a medida que clasificas los archivos.

Paso 2: Sube tus primeras memorias

Para cada regla que conservaste, escribe qué decidió, qué descartó y por qué. Los pares que se contradecían entre sí son las entradas de mayor valor, porque esas son las que volverán a surgir. Los documentos de soporte y los archivos van en el mismo lugar.

Paso 3: Conecta tu IA y agentes

Dale acceso a Roo Code, Claude, Codex y tus otros agentes a través de MCP o la API. Cuando una regla parezca incorrecta, la respuesta a "por qué está esto aquí" llegará con su razonamiento en lugar de como una simple repetición.

El primer cambio es que tu directorio de reglas puede ser pequeño. Una vez que el razonamiento tiene un hogar, cada archivo es un puñado de líneas imperativas, lo que importa mucho más bajo una adición plana de lo que importaba bajo una carga condicional.

El segundo es que la asignación de modos se vuelve decidible. Clasificar una regla en rules-code/ frente a rules-architect/ es un juicio sobre qué tipo de trabajo gobierna, y ese juicio es obvio cuando la regla lleva consigo su propósito y una conjetura cuando no lo hace.

El tercero es que el orden de los nombres de archivo deja de ser crítico para la carga. Seguirás queriendo nombres deliberados, pero ya no dependerás de una casualidad alfabética para resolver un desacuerdo real: el desacuerdo se resolvió una vez, a propósito, y quedó registrado.

El cuarto es que la próxima herramienta será un trabajo más pequeño que este. Cursor puso la condicionalidad en el frontmatter, Roo Code la pone en los modos, y la herramienta que venga después hará otra cosa. Lo que no cambia es el conjunto de decisiones que ha tomado tu proyecto, que es la misma razón por la que lo que realmente leen los agentes de programación es una pregunta más duradera que qué extensión requiere una herramienta determinada.

Asume que todo en .roo/rules/ está siempre activo. No hay un equivalente a alwaysApply porque ese directorio es la capa siempre activa. Cualquier cosa que no quieras en cada solicitud pertenece a un directorio de modo o no debe estar en absoluto.

Usa los directorios de modo como tu herramienta de alcance. rules-code/, rules-architect/, rules-debug/ y sus contrapartes globales son donde vive la condicionalidad ahora.

Haz que los nombres de archivo expresen el orden de carga. El contenido se añade alfabéticamente por nombre de archivo, por lo que un prefijo numérico convierte un orden implícito en uno explícito.

Nunca dejes .roo/rules/ vacío. Un directorio vacío recurre a .roorules, lo que convierte una migración parcialmente terminada en una configuración heredada activa.

Audita si hay archivos .clinerules y .roorules sueltos. Son inertes mientras tu directorio de reglas tenga contenido y autoritarios en el momento en que no lo tenga.

Elimina el frontmatter al convertir. El YAML no analizado se convierte en prosa, y la prosa sobre alwaysApply es ruido que el modelo tiene que leer.

Mantén AGENTS.md en el repositorio. Es la superficie que no cambia entre estas dos herramientas, ni en la siguiente.

Cursor requiere archivos .mdc con frontmatter, y establece que un archivo .md simple en .cursor/rules se ignora porque carece de los campos que especifican description, globs y alwaysApply. Roo Code lee markdown simple de forma recursiva desde .roo/rules/ y lo añade en orden alfabético por nombre de archivo, con directorios específicos de modo como su mecanismo de alcance y una alternativa documentada a .roorules cuando el directorio está vacío. Ambos son diseños razonables. No son el mismo diseño, y renombrar una carpeta convierte silenciosamente cada regla condicional en una incondicional.

La migración que funciona es una remodelación: los globs se convierten en modos, alwaysApply se convierte en el valor predeterminado, los nombres de archivo se convierten en el orden de carga, y las reglas que solo eran compatibles porque nunca se habían cruzado tienen que reconciliarse genuinamente. Esa última parte necesita las razones, no solo las reglas; así que pon las razones en un lugar que ninguna de las dos herramientas posea, y el próximo sistema de reglas que adoptes será una traducción en lugar de una excavación.