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

Tus archivos de dirección, con un cambio de nombre y cuatro líneas de frontmatter. Este es el núcleo de la migración, y la asignación es limpia:

Ambos lados funcionan de la misma manera por debajo. El modo auto de Kiro "utiliza la descripción para decidir cuándo es relevante el archivo de dirección". El equivalente de Cursor: "la descripción de la regla se presentará al Cursor Agent para decidir si debe aplicarse". Los archivos manual de Kiro se invocan con #nombre-del-archivo-de-direccion; los de Cursor se mencionan con @. Cambia el nombre de cada archivo a .mdc, añade el frontmatter correspondiente y tendrás el mismo comportamiento que tenías.

Tus archivos de base, como reglas siempre activas. Los archivos product.md, tech.md y structure.md de Kiro se "incluyen en cada interacción por defecto". Esos se convierten en reglas con alwaysApply: true. Sin embargo, léelos antes de convertirlos: la propia guía de dirección de Kiro advierte contra la duplicación de lo que el código base ya establece, y la documentación de reglas de Cursor ofrece el mismo consejo. Un archivo structure.md que es principalmente un listado de directorios vale la pena depurarlo, no portarlo; las razones de esto se encuentran en cómo hacer que Cursor recuerde la estructura de archivos de tu proyecto.

Tu AGENTS.md, sin cambios. Ambas herramientas lo admiten. Kiro lo carga desde la raíz del espacio de trabajo, desde ~/.kiro/steering/ y desde subdirectorios, señalando que "los archivos AGENTS.md no admiten modos de inclusión y siempre se incluyen". Cursor "admite AGENTS.md en la raíz del proyecto y subdirectorios" y lo recomienda explícitamente como la alternativa en markdown simple a las reglas .mdc. Si la mayor parte de tu dirección ya estaba siempre activa de todos modos, AGENTS.md es el destino con menor fricción.

Tus Skills, como un movimiento de directorio o sin movimiento alguno. Cursor lee .agents/skills/, .cursor/skills/, ~/.agents/skills/ y ~/.cursor/skills/, además de —"Por compatibilidad"— .claude/skills/, .codex/skills/, ~/.claude/skills/ y ~/.codex/skills/. Ambas herramientas se basan en el mismo estándar abierto de Agent Skills, por lo que los archivos SKILL.md se trasladan tal cual. Una diferencia de comportamiento: una skill de Cursor invocada con / "se adjunta a un mensaje", y mantenerla activa durante toda una sesión requiere ejecutarla como un Custom Mode con Option+Enter.

Tus especificaciones (specs), como archivos pero no como un flujo de trabajo. Las especificaciones de Kiro viven en .kiro/specs/<nombre>/ como requirements.md (o bugfix.md), design.md y tasks.md. Son markdown en tu repositorio, por lo que sobreviven al traslado y siguen siendo legibles. Lo que no sobrevive es el flujo de trabajo de tres fases que las rodea: la progresión de requisitos-diseño-tareas con aprobaciones intermedias y estado de tareas en tiempo real.

El equivalente más cercano en Cursor es el Plan Mode, y no es poca cosa: "crea planes de implementación detallados antes de escribir cualquier código", puedes "revisar y editar el plan a través del chat o de archivos markdown", y puedes revertir y volver a ejecutar desde un plan refinado. Pero ten en cuenta a dónde va el artefacto: "Los planes se guardan por defecto en tu directorio de inicio. Haz clic en 'Save to workspace' para moverlo a tu espacio de trabajo para referencia futura, compartir con el equipo y documentación". Una especificación de Kiro estaba en el repositorio por defecto. Un plan de Cursor está en tu directorio de inicio por defecto. Esa diferencia predeterminada es la diferencia entre un artefacto de equipo y uno personal.

Nada más se transfiere, y la razón es arquitectónica. Kiro mantiene tres superficies de memoria. El índice de documentación de Cursor no tiene ninguna página de memoria.

Las seis capas de Kiro Crew no tienen destino. Crew conserva preferences.md y projects.md (ambos reemplazados por completo por un consolidador cada 30 mensajes), un directorio history/ con degradación escalonada, un almacén semántico SQLite, un almacén episódico con búsqueda vectorial y un almacén de lecciones para correcciones aprendidas. Cada capa tiene un límite de caracteres y su propia regla de degradación: el historial se reduce a "Primera entrada por día + recuento" a los 14 días, deja de cargarse a los 181 y se "elimina del disco" a los 365. Las lecciones están limitadas a 50 entradas y marcadas para que "lo explícito del usuario siempre gane". Es un sistema de memoria real, y Cursor no tiene ningún contenedor para recibirlo.

La memoria aprendida de Kiro Web tampoco se transfiere. Se construye a partir de tus comentarios en las pull requests —"Solo tus comentarios, como el usuario que creó la tarea, influyen en lo que aprende el agente"— y tu control sobre ella se limita a las eliminaciones.

Un snapshot de Crew es una copia de seguridad, no una exportación. kirocrew snapshot produce un único archivo tarball que cubre memoria, espacio de trabajo, crons, configuración, skills y notificaciones. Es la forma correcta de moverse entre máquinas, y Kiro lo documenta exactamente así. Pero solo Kiro lo lee, por lo que es una copia de seguridad de lo que estás dejando, no un archivo de importación para lo que estás adoptando. Trátalo con cuidado: Kiro advierte que "Los snapshots contienen datos confidenciales (claves de seguridad utilizadas para la integridad del registro de auditoría)".

Paso 1: Toma un snapshot y luego lee las capas que estás a punto de perder

Ejecuta kirocrew snapshot ~/migrate antes de cualquier otra cosa. Incluso si Cursor no puede leerlo, querrás tener la copia; y la tarea diaria integrada de Crew solo "conserva los últimos 7 snapshots", así que no asumas que el de ayer todavía está ahí.

Luego lee, en lugar de copiar. Abre ~/.kiro/crew/workspace/memory/preferences.md y projects.md. Debido a que esos dos archivos son "reemplazados por completo por el consolidador cada 30 mensajes, no son de solo adición", representan una instantánea actual del modelo que Crew tiene de ti, no un registro. Lo que sea que esté en ellos es lo que Crew cree que importa en este momento, lo que los convierte en una lectura corta y de una señal inusualmente alta.

Luego mira tus lecciones: las correcciones aprendidas, limitadas a 50. Estas son las cosas que le dijiste a Crew que hiciera siempre, o que corregiste para que hiciera. Nada en tu repositorio las implica, por lo que nada en Cursor las reconstruirá.

También verifica tu dirección global en ~/.kiro/steering/. Kiro resuelve los conflictos priorizando la dirección del espacio de trabajo sobre la global. El orden de Cursor es "Team Rules → Project Rules → User Rules", donde "las fuentes anteriores tienen prioridad cuando las pautas entran en conflicto". El proyecto sigue superando a lo personal, por lo que esa mitad del comportamiento sobrevive; pero si usas las Team Rules de Cursor, una nueva capa ahora supera a ambas.

Paso 2: Convierte la dirección a .mdc y elige qué se queda como texto simple

Para cada archivo en .kiro/steering/, lee su frontmatter, busca la fila en la tabla anterior y escribe el equivalente de Cursor. Un archivo fileMatch se convierte en un valor de globs; un archivo auto conserva su description y descarta el name; un archivo siempre activo se convierte en alwaysApply: true y no necesita ninguno de los dos.

Dos conversiones que vale la pena hacer a mano en lugar de mecánicamente:

Las referencias a archivos dejan de funcionar. La dirección de Kiro puede incrustar archivos en tiempo real con #[[file:api/openapi.yaml]], por lo que el texto de dirección se mantenía actualizado a medida que cambiaba el archivo. Las reglas de Cursor no tienen una directiva equivalente. O bien incluyes el contenido en línea —y aceptas que se desactualizará— o haces referencia a la ruta en prosa y dejas que el agente la lea.

Las listas de recursos de agentes personalizados no tienen contraparte. Si configuraste agentes personalizados en Kiro, recuerda que "los archivos de dirección no se incluyen automáticamente" para ellos y tenías que listarlos explícitamente, a menudo como {"resources": ["file://.kiro/steering/**/*.md"]}. Cursor aplica las reglas según su frontmatter independientemente del modo, por lo que esas listas explícitas de recursos no tienen nada en qué convertirse; verifica si algún agente se estaba ejecutando deliberadamente sin dirección, porque esa intención no se trasladará.

Si la mayor parte de tu dirección era siempre activa y simple, la recomendación honesta es omitir .mdc para esos archivos por completo y colocar el contenido en AGENTS.md. La documentación de Cursor sugiere exactamente esto para "proyectos que necesitan instrucciones simples y legibles sin la sobrecarga de reglas estructuradas". Reserva .mdc para los archivos que realmente necesitan globs o descripciones.

Una última nota si estás trasladando a un equipo: la dirección de equipo de Kiro se distribuía enviando archivos a las máquinas "a través de soluciones MDM o políticas de grupo". Las Team Rules de Cursor se gestionan desde el panel de control en los planes Team y Enterprise, se aplican "en todos los repositorios y proyectos de ese equipo" y se pueden marcar como "Enforce this rule" para que los miembros no puedan desactivarlas. Ese es un mejor mecanismo, pero es texto libre —las Team Rules "no utilizan la estructura de carpetas de las Project Rules"— por lo que un directorio de archivos de dirección tiene que aplanarse.

Observa cómo las dos mitades de esta migración se comportaron de manera diferente. Todo lo que escribiste se trasladó: la dirección se convirtió en reglas, AGENTS.md se quedó donde estaba, las skills no necesitaron cambios, las especificaciones siguieron siendo legibles. Todo lo que la herramienta aprendió no se trasladó en absoluto.

Esa división no es un problema de Kiro o de Cursor. Kiro construyó un elaborado sistema de memoria aprendida y lo mantiene bajo ~/.kiro/. Cursor tomó una decisión deliberada diferente: el contexto duradero vive en archivos de reglas y skills controlados por versiones, razón por la cual sus reglas son revisables y su documentación no tiene página de memoria. Ambos son diseños coherentes. Ninguno es un buen lugar para tener la única copia de por qué rechazaste un enfoque.

Eso es lo que MemoryLake contiene: el conocimiento duradero de tu proyecto en una capa que tus herramientas consultan, para que la mitad aprendida deje de ser una propiedad del editor que casualmente abriste. La configuración consta de tres pasos.

Paso 1: Crea una clave API

Inicia sesión y crea una clave API. Una sola credencial para todas las herramientas que conectes.

Paso 2: Sube tus primeras memorias

Entradas cortas, una afirmación cada una. Escribe estas directamente a partir de la lectura del Paso 1:

Tus lecciones, una por entrada. Las correcciones aprendidas limitadas a 50 en Crew. Estas son las líneas de mayor valor que posees y las menos recuperables.

Lo que dicen actualmente preferences.md y projects.md. Son una instantánea en tiempo real, por lo que son cortas. Divídelas en afirmaciones en lugar de pegar el archivo completo.

Decisiones con la razón adjunta. "Ponemos en cola las escrituras porque la réplica se retrasa bajo carga". Una regla establece la política; solo la razón evita que vuelva a surgir la alternativa.

Enfoques ya rechazados en este código base. La categoría que no aparece en ningún archivo de dirección, ninguna regla y ningún mensaje de commit.

Paso 3: Conecta tu IA y agentes

Conecta lo que uses. Se puede acceder a MemoryLake a través de MCP y de una API, y tanto Kiro como Cursor admiten servidores MCP, por lo que puedes ejecutarlos en paralelo durante la transición sin mantener dos copias del mismo razonamiento, y otros asistentes leerán la misma memoria a través de la API.

Tres límites honestos. MemoryLake no puede leer un snapshot de Crew, importar la memoria aprendida de Kiro Web ni escribir tus archivos .mdc; esos son los formatos de Kiro y la superficie de dirección de Cursor. Solo contiene lo que tú o tus agentes introducen en él, por lo que el Paso 2 es manual. Y las reglas son contexto en lugar de una configuración forzada; cualquier cosa que deba cumplirse siempre pertenece a las Team Rules de Cursor con la opción de cumplimiento activada, no a una capa de memoria.

La conversión de dirección se convierte en una búsqueda, no en un juicio de valor. Cuatro modos, cuatro tipos de reglas, una tabla.

Dejan de ocurrir operaciones silenciosas que no hacen nada. Un archivo .md simple en .cursor/rules se ignora. Ahora lo sabes antes de enviarlo.

Las especificaciones siguen siendo legibles, y tú decides sobre el flujo de trabajo. Los archivos sobreviven; las fases de aprobación no.

Los planes necesitan guardarse deliberadamente. Los planes de Cursor se guardan por defecto en tu directorio de inicio, por lo que "Save to workspace" es el paso que lo convierte en un artefacto de equipo.

Las skills dejan de ser específicas de una herramienta. El mismo SKILL.md se ejecuta en Kiro, Cursor, Claude Code y Codex.

La degradación deja de ser una sorpresa. El historial de Crew perdía detalles a los 14 días y se eliminaba a los 365; un comportamiento que vale la pena comprender en sus propios términos, como en lo que mostró un árbol de memoria con puntuación de retención.

Toma un snapshot antes de comenzar y mantén el archivo tarball fuera de las unidades compartidas. Kiro advierte que los snapshots contienen claves confidenciales.

Lee preferences.md, projects.md y tus lecciones. Los archivos reemplazados por completo son cortos por diseño. No hay excusa para pasarlos por alto.

Cambia el nombre a .mdc y añade frontmatter, o mueve el contenido a AGENTS.md. Esas son las únicas dos opciones que realmente se cargan.

Prefiere AGENTS.md para cualquier cosa que sea simple y esté siempre activa. Cursor lo recomienda y funciona en ambas herramientas durante la transición.

Convierte las referencias #[[file:…]] de manera deliberada. Incluirlas en línea las desactualiza; las referencias en prosa las mantienen activas.

Depura structure.md en lugar de portarlo. Ambos proveedores desaconsejan volver a describir el código base.

Aplana la dirección de equipo antes de tocar las Team Rules. Son texto libre, no una estructura de carpetas.

Mantén el razonamiento fuera de las reglas siempre activas. Cada herramienta limita lo que transporta y el razonamiento es lo primero que se recorta; el problema general en lo que realmente leen los agentes de programación.

La migración de Kiro a Cursor consta de dos partes con dificultades muy diferentes. La parte escrita es casi mecánica: los cuatro modos de inclusión de dirección se asignan a cuatro tipos de reglas de Cursor, AGENTS.md funciona en ambos, los archivos SKILL.md no necesitan cambios y las especificaciones siguen siendo markdown legible en tu repositorio. La única cosa que te causará problemas es la extensión del archivo: un archivo .md simple en .cursor/rules se ignora por completo, sin ningún error que te lo advierta.

La mitad aprendida no se migra en absoluto. Kiro Crew conserva seis capas de memoria en tu directorio de inicio, cada una con su propio límite y programa de degradación, además de una memoria aprendida independiente en Kiro Web construida a partir de tus comentarios en las PR. El índice de documentación de Cursor no tiene página de memoria, porque su diseño coloca el contexto duradero en reglas y skills controladas por versiones. Un kirocrew snapshot te brinda una copia de seguridad completa que solo Kiro puede leer.

Por lo tanto: toma un snapshot, lee los tres archivos que contienen el modelo actual que Crew tiene de ti, convierte la dirección con la tabla, decide por archivo entre .mdc y AGENTS.md, y coloca las lecciones y los enfoques rechazados en un lugar que ambos editores puedan consultar. Así, el próximo cambio de herramienta será una preferencia en lugar de un evento de amnesia.