Cómo migrar de Cursor a Amazon Q Developer sin perder el contexto (2026)

Comience con lo que documenta cada herramienta, porque la brecha no está donde la mayoría de la gente espera.

La documentación de reglas de Cursor es explícita sobre para qué sirven las reglas y por qué existen:

"Los modelos de lenguaje grandes no retienen la memoria entre completados. Las reglas proporcionan un contexto persistente y reutilizable a nivel de prompt."

Las reglas se inyectan como contexto: "Cuando se aplican, el contenido de la regla se incluye al principio del contexto del modelo". Cada regla de proyecto es un archivo .mdc con frontmatter, y los campos del frontmatter determinan uno de los cuatro tipos de aplicación: Always Apply (Aplicar siempre), Apply Intelligently (Aplicar de forma inteligente) ("Cuando el Agente decide que es relevante según la descripción"), Apply to Specific Files (Aplicar a archivos específicos) a través de un patrón glob, y Apply Manually (Aplicar manualmente) mediante una mención con @. Cursor también documenta una cadena de precedencia: "Las reglas se aplican en este orden: Team Rules → Project Rules → User Rules (Reglas de equipo → Reglas de proyecto → Reglas de usuario). Todas las reglas aplicables se fusionan; las fuentes anteriores tienen precedencia cuando hay conflicto de directrices".

Las reglas de proyecto de Amazon Q Developer viven en una carpeta y son Markdown plano:

"Las reglas de proyecto se definen en archivos Markdown en la carpeta {{project-root}}/.amazonq/rules del proyecto."

Y se aplican sin una condición declarada:

"Una vez que haya creado las reglas de su proyecto, Amazon Q las usará automáticamente como contexto cada vez que un desarrollador chatee con Amazon Q dentro de su proyecto, y se asegurará de cumplirlas al generar respuestas."

La superficie de control es el botón Rules (Reglas) en el panel de chat, que enumera sus reglas y le permite activar o desactivar cada una para la sesión actual: "Las reglas con una marca de verificación están activas y se aplicarán a su conversación". La misma carpeta .amazonq/rules está documentada para Amazon Q Developer en GitLab y GitHub, por lo que la capa no es exclusiva del IDE.

Así que la transferencia se ve así. El contenido de la regla se transfiere limpiamente: es prosa en un archivo Markdown en ambos lados. La condicionalidad de la regla no. Los cuatro tipos de aplicación de Cursor se reducen a un solo comportamiento documentado más una casilla de verificación por sesión. Nada en la documentación de reglas de proyecto de Amazon Q describe un campo de frontmatter para coincidencia de glob, recuperación basada en descripción o invocación manual con @.

Hay una segunda cosa que no se transfiere, y es en la que vale la pena planificar. Amazon Q tiene su propia capa de contexto generada, y aterriza dentro de la misma carpeta a la que está a punto de migrar.

Dos pasos. El primero es mecánico y el segundo es el que la gente suele saltarse.

Paso 1: Eliminar el frontmatter e integrar la condición en la prosa

Cursor es estricto con la extensión del archivo: "Cada regla es un archivo .mdc al que puede poner el nombre que desee. Las reglas de proyecto deben usar la extensión .mdc. El sistema de reglas ignora un archivo .md plano en .cursor/rules porque no tiene frontmatter para especificar description, globs y alwaysApply ".

Amazon Q es igualmente claro en la otra dirección: el archivo de regla "debe ser un archivo Markdown" en .amazonq/rules, y la documentación muestra prosa plana sin frontmatter.

La trampa del valor literal está justo aquí. Si copia .cursor/rules/api.mdc a .amazonq/rules/api.md sin cambios, arrastrará tres líneas de YAML (description, globs, alwaysApply) a un archivo cuyo lector no tiene un uso documentado para ellas. Amazon Q no se quejará. Tratará el frontmatter como parte del texto de la regla, y la condicionalidad que expresaban esos campos simplemente dejará de existir.

Así que haga esto en su lugar, regla por regla:

Para una regla que era Always Apply, elimine el frontmatter y continúe. Esta es una migración limpia; era incondicional en Cursor y es incondicional en Amazon Q.

Para una regla que era Apply to Specific Files, elimine el frontmatter y escriba el alcance en la primera frase de la regla misma. Una regla cuyo glob era **/*.test.ts se convierte en una regla que comienza con una frase que nombra los archivos de prueba como su sujeto. Está convirtiendo una condición impuesta por la máquina en una declarada, y vale la pena ser honesto en que esto es una pérdida de precisión: el modelo ahora decide la relevancia a partir de su redacción en lugar de una ruta coincidente.

Para una regla que era Apply Intelligently, el campo description era la señal de recuperación. Intégrelo en la línea de apertura, porque ahora tiene que hacer su trabajo como prosa ordinaria en lugar de como metadatos.

Para una regla que era Apply Manually, decida si realmente la quiere siempre activa. Algunas de estas existen precisamente porque no deberían activarse de forma predeterminada. Esas son las candidatas a quedar completamente fuera de .amazonq/rules y mantenerse en algún lugar donde pueda invocarlas deliberadamente.

El propio consejo de redacción de Cursor sobrevive al traslado y vale la pena llevarlo consigo: mantenga las reglas por debajo de las 500 líneas y "Haga referencia a los archivos en lugar de copiar su contenido; esto mantiene las reglas cortas y evita que queden obsoletas a medida que cambia el código".

Si ha realizado una traducción de reglas antes, la estructura le resultará familiar: mover las reglas de Cursor a un AGENTS.md de Codex plantea la misma cuestión de frontmatter con un formato de destino diferente.

Paso 2: Mantener las reglas creadas fuera de la ruta de regeneración

Amazon Q puede generar un banco de memoria para un proyecto, y aquí es donde la migración se vuelve delicada:

"Amazon Q puede generar automáticamente archivos de banco de memoria que proporcionan un índice rápido de la estructura de su proyecto, el stack tecnológico y la información del producto. Esta función analiza archivos clave en su proyecto para crear archivos de resumen que ayudan a Amazon Q a comprender su base de código sin tener que analizar todo el proyecto cada vez que hace una pregunta."

Se producen cuatro archivos (product.md, structure.md, tech.md y guidelines.md) y se escriben en una subcarpeta memory-bank bajo .amazonq/rules. Ese es el mismo árbol de carpetas en el que acaba de migrar sus reglas de Cursor.

La ruta de actualización no es una edición. Es una reconstrucción:

"Si su proyecto cambia, puede hacer que Amazon Q genere nuevos archivos de banco de memoria para actualizar su contexto. Para hacerlo, elija el botón Rules (Reglas) y luego seleccione Regenerate Memory Bank (Regenerar banco de memoria)."

Se derivan dos consecuencias. Primero, cualquier cosa que un compañero de equipo escriba a mano dentro de memory-bank/ se encuentra en la ruta de la próxima regeneración. Segundo, y más importante: debido a que esos cuatro archivos se producen analizando su código, solo pueden contener lo que su código ya dice. La razón por la que mantuvo una regla que decía "no use el otro cliente HTTP" no está en el código: el otro cliente no está allí. La regeneración no puede producir esa frase, y nunca lo hará.

Vale la pena contrastar esto con el otro banco de memoria conocido en este espacio. El banco de memoria de Cline es un conjunto de archivos que se le indica al agente que lea y actualice a medida que avanza el trabajo, por lo que su contenido es lo que el agente haya registrado sobre el estado del proyecto. El banco de memoria de Amazon Q tiene el mismo nombre y el origen opuesto: se genera a partir del repositorio. Ninguno es mejor; son respuestas a preguntas diferentes, y asumir que uno se comporta como el otro es la forma en que los equipos pierden contenido.

Así que mantenga las dos capas físicamente separadas. Sus reglas migradas van directamente en .amazonq/rules/ como archivos individuales. Deje que se genere la subcarpeta memory-bank y trátela como un resultado derivado. Si desea dar forma a lo que produce la generación, Amazon Q documenta la forma admitida de hacerlo: una regla en .amazonq/rules que describa el formato que desea, lo cual es una propiedad excelente: la capa generada es guiada por la capa creada, no al revés.

Todo lo anterior es un trabajo de traducción, y lo volverá a hacer la próxima vez que cambie de herramienta. La parte que le sigue costando no es el formato del archivo, sino que el razonamiento detrás de cada regla nunca se almacenó en ningún lugar excepto dentro de un archivo específico de la herramienta.

MemoryLake le da a ese razonamiento un hogar fuera de ambos productos y lo sirve a cualquier agente que lo solicite, a través de MCP o la API. Cursor conserva sus reglas y Amazon Q conserva su banco de memoria exactamente como están; esto se sitúa junto a ellos y contiene la capa que ninguno de los dos está diseñado para almacenar: lo que decidió, lo que rechazó y por qué.

Paso 1: Crear una clave de API

Genere una clave y realice su primera solicitud en unos treinta segundos. Haga esto antes de comenzar a reescribir los archivos de reglas, para tener un lugar donde colocar el razonamiento a medida que avanza.

Paso 2: Subir sus primeras memorias

A medida que trabaje en cada archivo .mdc en el Paso 1 anterior, se encontrará reconstruyendo por qué existe la regla. Capture eso a medida que avanza: la convención, la alternativa que rechazó y el incidente o la restricción detrás de ella. Agregue también los documentos de respaldo, diagramas y archivos.

Paso 3: Conectar su IA y agentes

Dé acceso a Claude, Codex, OpenClaw y Amazon Q a través de MCP o la API. Un agente que puede consultar la capa de decisión responde a "por qué esta es la convención aquí" con la razón adjunta, en lugar de simplemente repetirle la regla.

El cambio inmediato es que la condicionalidad que perdió en el Paso 1 deja de importar tanto. Una regla con alcance de glob existía en parte para mantener las directrices irrelevantes fuera de la ventana de contexto. Cuando el razonamiento vive en un almacén que el agente consulta bajo demanda, .amazonq/rules puede mantenerse genuinamente corto (solo los comandos permanentes) y la cola larga se recupera cuando es relevante en lugar de cargarse solo porque podría serlo.

El segundo cambio aparece en la primera Regenerate Memory Bank (Regeneración del banco de memoria). No perderá nada, porque las cosas que valía la pena conservar nunca estuvieron en los archivos generados.

El tercero es que una migración parcial deja de ser un problema. Muchos equipos ejecutan Cursor y Amazon Q en paralelo durante meses, en diferentes repositorios o en diferentes mitades de un equipo. Dos carpetas de reglas en dos formatos se desvincularán. Una capa de decisión que leen ambos agentes no lo hará.

El cuarto llega en la próxima migración. Los archivos de reglas se vuelven a traducir. El razonamiento no, porque nunca estuvo en un archivo de reglas.

Migre una regla a la vez y lea cada una. Una copia por lotes es el modo de fallo aquí, porque conserva un frontmatter que no significa nada en el otro lado y descarta silenciosamente condiciones que lo significaban todo.

Nunca escriba a mano dentro de memory-bank/. Es un resultado generado. Coloque sus archivos directamente en .amazonq/rules/.

Declare el alcance explícitamente en las reglas que solían tener globs. Comience la regla con los archivos o directorios a los que se aplica. Ha convertido una condición impuesta en una declarada; haga que la declaración sea ineludible.

Use una regla para dar forma a la generación. Amazon Q admite la personalización de la salida del banco de memoria a través de una regla de proyecto. Esa es la costura documentada entre las capas creadas y generadas; úsela en lugar de editar archivos generados.

No asuma que fijar elementos (pinning) lo cubre. La fijación de contexto está documentada como disponible solo en el IDE de VS Code, y los elementos fijados se aplican solo a la pestaña de chat actual; una nueva pestaña comienza de cero. Es una comodidad por conversación, no una capa de proyecto duradera.

Escriba el porqué, una vez, en algún lugar que ninguna de las dos herramientas posea. Esta es la única parte del trabajo que no se repite.

La migración de Cursor a Amazon Q Developer es fácil de subestimar porque ambos lados usan Markdown en una carpeta de proyecto. El contenido se traslada. La condicionalidad no: los cuatro tipos de aplicación documentados de Cursor no tienen homólogos documentados en las reglas de proyecto de Amazon Q, y los cuatro campos en su frontmatter .mdc se convierten en texto inerte si los copia.

La segunda cosa que hay que hacer bien es la disciplina de carpetas. El banco de memoria de Amazon Q se genera en una subcarpeta del mismo árbol .amazonq/rules, y se reconstruye en lugar de editarse. Es un índice realmente útil de lo que contiene su base de código, y precisamente por esa razón no puede contener las decisiones que su base de código no contiene.

Realice la traducción con cuidado, mantenga el contenido creado y el generado en lugares separados, y coloque el razonamiento en algún lugar que sobreviva al próximo cambio de herramienta. Así, esta será la última vez que haga esta traducción en particular desde cero.