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

El contenido de las reglas se transfiere textualmente. Ambas herramientas toman instrucciones en Markdown plano y las colocan frente al modelo. Cursor describe el mecanismo claramente: "Los modelos de lenguaje grandes no retienen memoria entre completados. Las reglas proporcionan un contexto persistente y reutilizable a nivel de prompt", y "cuando se aplican, el contenido de las reglas se incluye al inicio del contexto del modelo". El enfoque de opencode es casi idéntico: un archivo AGENTS.md que contiene "instrucciones que se incluirán en el contexto del LLM para personalizar su comportamiento para tu proyecto específico", y su documentación incluso dice que el concepto "es similar a las reglas de Cursor".

Un archivo AGENTS.md en la raíz se transfiere sin trabajo adicional. Si ya estabas usando la opción AGENTS.md de Cursor —que Cursor posiciona como una "alternativa simple a .cursor/rules"— opencode lo lee directamente. Las reglas en la raíz del proyecto en opencode "solo se aplican cuando estás trabajando en este directorio o en sus subdirectorios".

Tus archivos de reglas .mdc se transfieren como archivos, una vez que el glob es correcto. El array de instructions de opencode acepta rutas de archivos y patrones glob, por lo que los archivos pueden quedarse exactamente donde están en .cursor/rules/. Estás apuntando a ellos, no moviéndolos. Eso es genuinamente mejor que reescribir, y es la razón para hacer esta migración de esta manera en lugar de unificar todo en un solo archivo.

El frontmatter no se transfiere. Esta es la pérdida más crítica. Los cuatro tipos de reglas de Cursor son Always Apply, Apply Intelligently ("cuando el Agent decide que es relevante según la descripción"), Apply to Specific Files ("cuando el archivo coincide con un patrón especificado") y Apply Manually ("cuando se menciona con @ en el chat"). Esos provienen de la interacción de tres campos de frontmatter: con alwaysApply: false y globs proporcionados, una regla se "auto-adjunta cuando un archivo coincidente está en contexto"; con alwaysApply: false y una description pero sin globs, "el Agent lee la descripción e incorpora la regla cuando es relevante"; sin ninguno de los dos, se "incluye solo cuando mencionas la regla con @ en el chat".

opencode no tiene un equivalente documentado para nada de eso. Su documentación establece que "todos los archivos de instrucciones se combinan con tus archivos AGENTS.md". Una regla que antes solo aparecía cuando tocabas src/components/** ahora aparece en cada solicitud, al igual que la que tenías configurada como manual porque era una lista de verificación de migración que rara vez se necesitaba. Nada falla de forma ruidosa. Tu prompt simplemente se vuelve mucho más grande y mucho menos enfocado, que es el modo de fallo que describimos en why agents ignore your instruction files.

Las referencias @file dentro de las reglas no se transfieren. Las reglas de Cursor pueden hacer referencia a otros archivos en línea; una regla que termina con @migration-template.sql incorpora esa plantilla. La documentación de opencode es directa: "opencode no analiza automáticamente las referencias a archivos en AGENTS.md". Las dos soluciones alternativas admitidas son listar tú mismo los archivos referenciados en instructions, o escribir texto explícito indicándole al agente que los lea.

Las reglas de equipo (Team Rules) no se transfieren. Las reglas de equipo de Cursor se gestionan desde el panel de control de Cursor en los planes Team y Enterprise, "tienen prioridad" sobre otros tipos de reglas y se pueden marcar para que "no se puedan desactivar en Customize". Esa es una superficie de control organizativo, no un archivo. Lo que sea que digan esas reglas debe reexpresarse como archivos confirmados en el repositorio, lo que también significa que deja de ser aplicable de la misma manera.

Lo que Cursor tiene y opencode no, y viceversa. El mecanismo de persistencia documentado de Cursor son las reglas en sus cuatro formas; una búsqueda en el índice de documentación de Cursor no arroja resultados para un almacenamiento de memoria que se escriba a sí mismo, por lo que la afirmación precisa es que no hay un equivalente documentado para ello. Los mecanismos documentados de opencode son los archivos AGENTS.md, el array de instructions y el comando /init. Ninguna de las dos herramientas documenta un almacenamiento que acumule lo que aprendiste mientras trabajabas, que es la tercera categoría a la que esta guía sigue volviendo.

Step 1: Fix the glob, then run /init on top of it

Comienza con el array de instructions en el archivo opencode.json de tu proyecto. El ejemplo documentado utiliza .md; tus reglas son .mdc, y Cursor admite subdirectorios como .cursor/rules/frontend/components.mdc. Por lo tanto, el patrón que deseas es .cursor/rules/**/*.mdc, que también captura carpetas de reglas anidadas. Mantén .md en la lista también si tienes algún documento en Markdown plano allí que Cursor estaba ignorando pero que realmente quieres que opencode lea; un caso inusual pero real, ya que Cursor descarta esos archivos y opencode no lo hará.

Añade los archivos a los que tus reglas de Cursor solían hacer referencia con @, ya que esas referencias ya no se seguirán. Si tenías una regla que apuntaba a @migration-template.sql, la plantilla debe estar en instructions o nombrarse explícitamente en el texto.

Luego ejecuta /init. Este es el paso que la gente se salta, y es el que da resultados. El comando /init de opencode "escanea los archivos importantes en tu repositorio, puede hacer un par de preguntas específicas cuando el código base no puede responderlas, y luego crea o actualiza AGENTS.md con una guía concisa específica del proyecto", y considera explícitamente "referencias a fuentes de instrucciones existentes como las reglas de Cursor o Copilot". Crucialmente, ejecutarlo no es destructivo: "Si ya tienes un AGENTS.md, /init lo mejorará en su lugar en vez de reemplazarlo a ciegas". Ejecutarlo después de configurar instructions significa que puede ver lo que ya tienes en lugar de reinventarlo.

Una regla de precedencia que debes conocer antes de crear cualquier cosa: opencode resuelve "archivos locales subiendo desde el directorio actual (AGENTS.md, CLAUDE.md)" y un archivo global en ~/.config/opencode/AGENTS.md, y "el primer archivo coincidente gana en cada categoría. Por ejemplo, si tienes tanto AGENTS.md como CLAUDE.md, solo se utiliza AGENTS.md". Si tu repositorio ha estado funcionando con un CLAUDE.md, crear un AGENTS.md lo desactivará. El mismo patrón se aplica globalmente: ~/.config/opencode/AGENTS.md tiene prioridad sobre ~/.claude/CLAUDE.md.

Step 2: Decide what each unconditional rule now costs

Ahora revisa los archivos .mdc a los que acabas de apuntar y lee solo su frontmatter. Clasifícalos en tres grupos.

Las reglas con alwaysApply: true son gratuitas. Eran incondicionales en Cursor y son incondicionales en opencode. No hay nada que hacer.

Las reglas con globs estaban limitadas a tipos de archivos o directorios. En opencode, ahora siempre están activas. Para una regla corta —cinco líneas de convenciones de TypeScript— eso está bien, y unificarla es la decisión correcta. Para una regla larga, tienes dos opciones honestas: recortarla a la parte por la que vale la pena pagar en cada solicitud, o dejarla fuera de instructions y cargarla deliberadamente cuando estés trabajando en esa área. No hay una tercera opción que preserve la condicionalidad, y fingir lo contrario es la forma en que los archivos de instrucciones triplican silenciosamente su tamaño.

Las reglas con una description y sin globs son el grupo más interesante, porque Cursor usaba la descripción como una señal de recuperación: el comportamiento de "el Agent lee la descripción e incorpora la regla cuando es relevante". Ese mecanismo no tiene cabida en opencode. Lo que puedes preservar es la intención: mantén el texto de la descripción como la primera línea de la regla para que un humano que escanee el prompt combinado pueda ver para qué sirve, y considera si la regla es realmente una regla o un hecho que aprendiste. Con bastante frecuencia es esto último, lo que significa que pertenece a la siguiente sección en lugar de estar en instructions.

Las reglas sin ninguno de los dos campos eran manuales, solo para mención con @. Suelen ser listas de verificación y plantillas. Déjalas fuera de instructions por completo y haz referencia a ellas por su ruta cuando las necesites. La documentación de opencode sugiere exactamente este patrón para archivos externos: enseña al agente a leer un archivo cuando se aplique una condición, en lugar de cargarlo por adelantado.

Vale la pena aplicar los consejos de mejores prácticas de Cursor mientras haces esto: "Mantén las reglas por debajo de las 500 líneas", "divide las reglas grandes en múltiples reglas combinables" y "haz referencia a archivos en lugar de copiar su contenido; esto mantiene las reglas cortas y evita que se queden obsoletas a medida que cambia el código". Las tres cosas importan más en opencode que en Cursor, porque no hay una capa condicional que absorba tus excesos. Si prefieres no perder la condicionalidad en absoluto, migrating Cursor rules to Codex cubre un destino cuyo alcance funciona de manera diferente, y migrating Cursor to Claude Code cubre otro.

Clasificar los grupos de frontmatter suele revelar algo incómodo: una parte significativa del contenido de tu .cursor/rules no son reglas. Es historia. "No uses el endpoint por lotes para la conciliación, se agota el tiempo de espera con más de diez mil filas". "Los tokens de autenticación son generados por el servicio heredado hasta el primer trimestre, así que no agregues alcances aquí". Esos son hechos que alguien aprendió de la manera difícil, archivados en el único lugar duradero que ofrecía la herramienta.

Las reglas son el contenedor equivocado para ellos, en ambas herramientas. Cursor lo dice por sí mismo: las reglas son "contexto persistente y reutilizable a nivel de prompt", que se vuelve a enviar cada vez. Un hecho que aprendiste en julio no es una configuración a nivel de prompt; es conocimiento, se acumula sin límites y se descubre en lugar de crearse.

MemoryLake es donde va esa mitad. Se sitúa fuera de ambas herramientas, contiene lo que tu equipo estableció en lugar de cómo trabaja tu equipo, y es accesible a través de MCP o una API por cualquier cliente en el que te encuentres hoy. El efecto práctico en esta migración es que el array de instructions se mantiene lo suficientemente corto como para que perder la condicionalidad no duela.

Step 1: Create an API key

Genera una clave y realiza tu primera solicitud en unos treinta segundos. Una sola clave cubre todas las superficies, que es el objetivo: el conocimiento no debe pertenecer a un editor.

Step 2: Upload your first memories

Arrastra los documentos, imágenes y archivos que ya contienen las decisiones establecidas de tu proyecto, además de los archivos de reglas que acabas de identificar como historia en lugar de convención. Comienza con aquello que estás cansado de volver a explicar.

Step 3: Connect your AI & agents

Dale acceso a Claude, Codex, OpenClaw y otros agentes a través de MCP o la API. En una sesión de opencode, eso significa que los hechos establecidos se pueden recuperar bajo demanda en lugar de ocupar permanentemente tu prompt de instrucciones combinado.

El array de instructions se mantiene pequeño, que es lo que hace que la pérdida de condicionalidad sea tolerable. La capa condicional de Cursor existía porque los directorios de reglas crecen; si el crecimiento va a otra parte, el array plano funciona perfectamente bien.

Las reglas de equipo (Team Rules) dejan de ser un obstáculo para la migración. El contenido organizativo que vivía en el panel de Cursor se divide claramente: las convenciones aplicables se convierten en archivos confirmados en el repositorio, y las decisiones establecidas se convierten en memorias que el agente de cada compañero de equipo lee, independientemente de la herramienta o del nivel de plan.

Cambiar de herramienta de nuevo se vuelve económico. El array de instructions de opencode y el frontmatter .mdc de Cursor son formatos específicos de cada herramienta. Un almacenamiento accesible a través de MCP no lo es, lo que significa que el próximo movimiento será un cambio de configuración en lugar de una auditoría de conocimiento.

Y la molestia específica que empuja a la gente a escribir reglas en primer lugar —ser corregido sobre lo mismo dos veces, o volver a enseñar al agente where things live in the repository— se aborda en la capa correcta. Eso nunca fue un problema de reglas. Era un problema de memoria que se intentaba resolver con un prompt.

Verifica que el glob haya coincidido con algo. Después de configurar instructions, pídele a opencode que resuma la guía que cargó. Si tus reglas de Cursor no aparecen, la extensión es lo primero que debes verificar.

Ejecuta /init después de la configuración, no antes. Mejora un archivo AGENTS.md existente en su lugar, así que deja que vea tu configuración real.

Mantén un solo hogar de instrucciones por directorio. AGENTS.md anula a CLAUDE.md en el mismo lugar, así que elige uno y elimina el otro en lugar de dejar un archivo muerto que parezca activo.

Ten cuidado con las URL de instrucciones remotas. opencode puede cargar instrucciones desde una URL, y "las instrucciones remotas se recuperan con un tiempo de espera de 5 segundos". Eso hace posible un archivo de reglas de equipo compartido, pero también hace que tu sesión dependa de que el servidor esté activo.

No recrees referencias @ pegando contenido. Añade el archivo a instructions o nómbralo en el texto. Pegar contenido es precisamente lo que desaconseja la propia guía de Cursor, ya que la copia se queda obsoleta.

Saca el historial antes de unificar. Unificar reglas condicionales solo es seguro si las reglas son realmente convenciones. Cualquier cosa que parezca una historia de batallas pertenece a una capa de memoria.

El resumen honesto de esta migración es que el array de instructions de opencode es una idea realmente buena —reutilizar los archivos de reglas que ya escribiste es mejor que reescribirlos— con dos vacíos documentados sobre los que el ejemplo publicado no te advierte. Uno es trivial una vez que lo ves: el glob tiene que ser .mdc, no .md, porque Cursor ignora el Markdown plano en .cursor/rules y, por lo tanto, tus reglas son todas .mdc. El otro es estructural: instructions combina todo lo que recibe, por lo que la distinción de Cursor entre Always / Intelligently / By-File / Manual se reduce a estar siempre activo.

Ambos son manejables, y el segundo principalmente porque gran parte de lo que llenaba tu directorio de reglas nunca debió haber sido una regla. Apunta el glob correctamente, ejecuta /init encima, clasifica el frontmatter en gratuito, costoso y bajo demanda, y mueve el historial acumulado a una capa que ninguna de las dos herramientas tenga que poseer. Lo que queda es un archivo de instrucciones corto que dice cómo trabajar en este repositorio, que es para lo único que un sistema de reglas sirvió alguna vez.