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

El mapa de modos de activación, y vale la pena anotar la correspondencia. Augment admite tres tipos de reglas: Always, donde "los contenidos se incluirán en cada prompt del usuario"; Auto, donde el "Agent detectará y adjuntará automáticamente las reglas basándose en un campo de descripción"; y Manual, que "debe etiquetarse mediante @ adjuntando el archivo de reglas manualmente."

Cursor expresa los mismos tres estados mediante la interacción de tres campos de frontmatter. alwaysApply: true significa "Siempre incluido. Se ignoran los globs y la descripción". 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, la regla se "incluye solo cuando mencionas la regla con @ en el chat".

Así que Always se asigna a alwaysApply: true, Auto se asigna a alwaysApply: false más una descripción, y Manual se asigna a alwaysApply: false sin nada más. La CLI de Augment nombra los dos primeros en el frontmatter como always_apply y agent_requested, lo que hace que la correspondencia sea aún más clara.

Cursor añade un modo que Augment no tiene. Con alwaysApply: false y globs proporcionados, una regla de Cursor se "adjunta automáticamente cuando un archivo coincidente está en contexto". El agent_requested de Augment depende de que el modelo lea una descripción y decida; el modo glob de Cursor es una coincidencia de patrones determinista. Si tienes reglas de Augment que solo importan para archivos TypeScript y has estado describiendo eso en prosa para beneficio del agente, esto es una mejora: codifícalo como un glob y deja de cruzar los dedos.

La extensión del archivo es la trampa. Documentación de Cursor: "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". Las reglas de Augment son .md. Cópialas sin cambios y se quedarán en el directorio correcto, se verán bien y no harán nada. No hay ningún error.

El anidamiento de directorios funciona de manera diferente, a favor de Cursor. Augment es explícito sobre un límite: "Solo los archivos AGENTS.md y CLAUDE.md se descubren jerárquicamente. Los archivos en .augment/rules/ solo se cargan desde la raíz del espacio de trabajo". Cursor permite directorios de reglas anidados, por lo que una regla puede vivir junto al código que gobierna. Si habías estado aplanando todo en un solo directorio raíz porque Augment lo requería, puedes dejar de hacerlo.

Las reglas de usuario se transfieren, pero pierden su configurabilidad. Augment almacena las reglas de usuario en ~/.augment/rules/, y la documentación es firme sobre su comportamiento: "Las reglas de usuario siempre se tratan como always_apply y no admiten otros tipos de frontmatter. La configuración de frontmatter solo afecta a las reglas del espacio de trabajo". Las User Rules de Cursor son "globales para tu entorno de Cursor" y las utiliza el Agent. Mismo rol, misma carga incondicional, por lo que esta mitad es una copia directa.

AGENTS.md se transfiere tal cual. Ambas herramientas lo leen. Augment descubre AGENTS.md y CLAUDE.md jerárquicamente a través de subdirectorios; Cursor "admite AGENTS.md en la raíz del proyecto y en los subdirectorios" y lo describe como una "alternativa simple a .cursor/rules", markdown simple "sin metadatos ni configuraciones complejas". Si una parte de tu configuración de Augment ya está en AGENTS.md, esa parte no requiere trabajo.

Las reglas a nivel de equipo cambian de modelo por completo. Las Team Rules de Cursor son "reglas para todo el equipo gestionadas desde el panel de control", disponibles en los planes Team y Enterprise, y se comportan de manera diferente a cualquier cosa en una carpeta de reglas: "Las Team Rules son texto libre. No utilizan la estructura de carpetas de las Project Rules". Admiten globs, se pueden marcar como Enforce this rule para que la regla "sea obligatoria para todos los miembros del equipo y no se pueda desactivar en Customize", y se sitúan en la parte superior de la cadena de precedencia: "Team Rules → Project Rules → User Rules", donde "todas las reglas aplicables se fusionan; las fuentes anteriores tienen prioridad cuando hay conflicto de directrices".

Esa es una adición genuinamente útil, y es el destino correcto para las reglas del espacio de trabajo de Augment de las que dependía todo tu equipo.

La memoria de Cosmos Experts no tiene equivalente, y esta es la verdadera pérdida. Los Experts de Augment tienen una capa de memoria que "almacena conocimiento acotado en el sistema de archivos virtual (VFS) compartido, de modo que las sesiones futuras puedan aplicar preferencias, convenciones y lecciones establecidas sin depender de la conversación actual". La memoria de un Expert "pertenece a su equipo y está separada por un alcance adecuado para el flujo de trabajo", y está activada por defecto: "La memoria está habilitada para todos los Template Experts".

También ejecuta dos modelos distintos según la calidad de la señal. "Simple memory es la opción predeterminada. Escribe comentarios humanos explícitos y de alta calidad directamente en un archivo de conocimiento seleccionado". La alternativa: "Noisy memory utiliza un registro de evidencia más un archivo de conocimiento seleccionado. Combina señales más débiles a lo largo del tiempo y promueve un aprendizaje solo después de que la evidencia sea lo suficientemente sólida". Ambos "exponen la misma vista de conocimiento seleccionado a los lectores".

El mecanismo de persistencia documentado de Cursor son las reglas. Su propio enfoque de para qué sirven las reglas lo dice directamente: "Los modelos de lenguaje grandes no retienen la memoria entre completados. Las reglas proporcionan un contexto persistente y reutilizable a nivel de prompt". No existe un equivalente documentado a un almacén de memoria acotado y propiedad del equipo que se escriba solo a partir de tus comentarios, por lo que los aprendizajes acumulados en tu VFS de Augment son la parte para la que necesitas un plan antes de cambiar, no después.

Paso 1: Convertir los archivos de reglas, la extensión y el frontmatter juntos

Realiza estas dos ediciones en la misma pasada, porque hacer una sin la otra produce un archivo que queda silenciosamente inerte.

Para cada archivo en .augment/rules/, cámbiale el nombre a .mdc y reescribe el frontmatter. Una regla de Augment con type: always_apply se convierte en alwaysApply: true. Una con type: agent_requested se convierte en alwaysApply: false más la description que ya tenía; conserva esa descripción, ya que Cursor la usa de la misma manera que lo hacía Augment. Una regla manual se convierte en alwaysApply: false sin descripción ni globs, y se menciona con @ por su nombre de archivo.

Luego haz una segunda pasada y busca reglas que realmente deberían estar acotadas por globs. Cualquier cosa cuya descripción equivalga a "usar esto al trabajar en archivos X" es candidata para globs en su lugar, lo que convierte una decisión subjetiva en una coincidencia exacta. Este es también el momento de mover las directrices anidadas fuera de la raíz, ya que Cursor permite carpetas de reglas en subdirectorios y Augment no.

Dos comodidades que vale la pena conocer. El comando /create-rule en el chat de Cursor "genera el archivo de reglas con el frontmatter adecuado y lo guarda en .cursor/rules", lo cual es más rápido que escribir a mano el frontmatter para una regla que puedes describir. Y Cursor puede importar reglas desde un repositorio de GitHub: "escaneará todos los archivos .mdc en el repositorio" y los colocará en .cursor/rules/imported/<repoName>, conservando las rutas relativas. Si estás migrando varios repositorios, convertir una vez en un repositorio de reglas compartido e importar es menos trabajo que convertir cada vez.

Copia el contenido de ~/.augment/rules/ en las User Rules de Cursor, y promueve cualquier cosa que el equipo deba seguir a Team Rules, usando Enforce this rule para aquellas que no deban desactivarse individualmente. Lo que no debes hacer es promoverlo todo: "todas las reglas aplicables se fusionan; las fuentes anteriores tienen prioridad cuando hay conflicto de directrices", y una regla de equipo obligatoria grande que contradiga una Project Rule ganará de una manera que nadie a nivel local podrá solucionar.

Paso 2: Lee la memoria de tus Experts antes de perder el acceso a ella

Este paso no tiene herramientas y es el que más importa.

Augment escribe la memoria "como Markdown legible bajo su propio directorio VFS", lo que significa que es legible cuando vas a buscarla. Ve a buscarla. El material valioso es el tipo de cosas que nadie escribe dos veces: preferencias de estilo de código que el Expert aprendió de los comentarios de revisión, convenciones que infirió de correcciones repetidas, las lecciones que un Code Review Memory Expert destiló de meses de comentarios.

Clasifica lo que encuentres en dos montones. Las cosas que parecen una regla — "validar siempre en el límite de la API", "preferir la composición aquí" — se convierten en reglas .mdc o Team Rules, y ya has construido el mecanismo para eso en el Paso 1. Las cosas que parecen un hecho sobre tu proyecto — por qué se tomó una decisión, qué significa un término internamente, qué servicio es dueño de qué — no pertenecen en absoluto a un archivo de reglas. Las reglas son instrucciones; esto es conocimiento, y meterlo en archivos alwaysApply: true es la forma en que un directorio de reglas se convierte en un archivador que consume contexto en cada prompt. Esa distinción es la esencia de what coding agents actually read.

Ten en cuenta también a qué estás renunciando en cuanto a procedimientos, para que puedas reemplazarlo conscientemente. La memoria de Augment te avisa cuando aprende algo: "En las sesiones interactivas, te dice cuándo recuerda algo para que puedas corregirlo o vetarlo". Y cuando el mundo cambia, "marca las discrepancias cuando la evidencia actual entra en conflicto con una regla recordada". Un archivo de reglas no hace ninguna de las dos cosas. Después de la migración, el hábito de revisión tendrá que ser tuyo.

El camino manual anterior convierte las instrucciones limpiamente y transforma el conocimiento acumulado en un archivo de reglas para el que no es adecuado o en un documento que nadie lee. Ese segundo resultado es lo que hace que las migraciones de herramientas se sientan costosas.

La alternativa es separar las dos capas a propósito. Las instrucciones — "ejecutar lint antes de hacer commit", "usar sangría de 2 espacios" — pertenecen a las reglas, acotadas tan estrechamente como la herramienta lo permita. Los hechos sobre tu proyecto pertenecen a un almacén que el agente lee cuando los necesita, no a uno que se carga en cada prompt. Haz eso y la migración se reducirá a la conversión del frontmatter, y la siguiente se reducirá aún más. MemoryLake se configura en tres pasos.

Paso 1: Crear una clave API

Inicia sesión y genera una clave API desde tu panel de control. No está vinculada a un directorio de reglas ni a un espacio de trabajo, por lo que el mismo conocimiento estará disponible ya sea que la solicitud provenga de Cursor, de una CLI o de lo que sea que evalúes el próximo trimestre.

Paso 2: Sube tus primeras memorias

Coloca el segundo montón del Paso 2 anterior: decisiones de arquitectura y sus razones, vocabulario del dominio, las preferencias permanentes que tus Experts de Augment habían aprendido, la propiedad de los servicios, las respuestas que sigues dando en las revisiones.

Deja las instrucciones en .cursor/rules. Este no es, deliberadamente, un lugar para duplicar tu carpeta de reglas.

Paso 3: Conecta tu IA y agentes

Apunta Cursor al almacén. Tus archivos .mdc se mantendrán pequeños y orientados al comportamiento, tu presupuesto de contexto dejará de ser consumido por hechos de fondo, y un compañero de equipo que se una el próximo mes leerá el mismo conocimiento que el agente, la propiedad tratada en sharing one memory across tools.

El primer cambio es que la conversión se vuelve mecánica. Extensión, frontmatter, listo, sin decisiones subjetivas sobre qué convención aprendida merece estar en cada prompt.

El segundo es que el conocimiento del equipo deja de depender de un nivel de plan. Las Team Rules son una función de los planes Team y Enterprise, y son texto libre sin estructura de carpetas. Útiles para la obligatoriedad, pero poco adecuadas para ser tu base de conocimiento.

El tercero es que conservas la capacidad de revisión que te daba Augment. Su memoria te decía cuándo recordaba algo y marcaba contradicciones; un archivo de reglas es silencioso. Un almacén que puedes leer, auditar y corregir restaura ese hábito, que es el objetivo de auditing what your AI remembers.

• Cambiar el nombre a .mdc y reescribir el frontmatter en una sola pasada. Se ignora un archivo .md en .cursor/rules, sin ningún error.
• Conserva tus descripciones de agent_requested. Cursor utiliza description de la misma manera para la inclusión basada en la relevancia.
• Convierte el alcance en prosa en globs. Cursor se adjunta automáticamente en los archivos coincidentes en contexto, lo cual es mejor que describir la condición.
• Desaplana tus reglas. Cursor permite directorios de reglas anidados; Augment cargaba .augment/rules/ solo desde la raíz del espacio de trabajo.
• Mueve AGENTS.md sin tocarlo. Ambas herramientas lo leen en la raíz y en los subdirectorios.
• Reserva las Team Rules para la obligatoriedad. Son de texto libre, compatibles con globs, están en la parte superior de la cadena de precedencia y, opcionalmente, no se pueden desactivar.
• Lee la memoria VFS antes de irte. Es markdown legible y nada lo exportará por ti.
• Reconstruye el hábito de revisión tú mismo. Augment mostraba nuevas memorias para veto y marcaba conflictos; los archivos de reglas no hacen ninguna de las dos cosas.

La mitad de las reglas de esta migración es un cambio de nombre más una reescritura de frontmatter, y el modo acotado por globs y los directorios anidados de Cursor mejoran genuinamente lo que tenías.

La mitad que vale la pena planificar es la memoria de los Experts de Augment. Es un sistema real — acotado al equipo, que se escribe solo, con dos modelos de evidencia y un paso de veto — y la respuesta documentada de Cursor para la persistencia son las reglas, lo cual es un trabajo diferente. Lee esos almacenes antes de cambiar, divide lo que encuentres en instrucciones y hechos, y coloca los hechos en un lugar que no te cobre contexto en cada prompt.