Qué se transfiere realmente
Qué transmite la sincronización de Git
La documentación de Lovable comienza desde donde vive tu código: "Cuando construyes con Lovable, el código de tu proyecto se almacena y gestiona dentro de la plataforma Lovable". La sincronización de Git vincula el proyecto a un repositorio de tu propiedad y, después de eso, "los cambios que realizas en Lovable se confirman en tu repositorio, y las confirmaciones enviadas a la rama sincronizada vuelven a aparecer en tu proyecto de Lovable".
Eso hace que la parte del código sea sencilla. Cualquier asistente de programación funciona con él: "Lovable recibe las confirmaciones que envías a la rama sincronizada independientemente de qué herramienta las haya realizado, por lo que se admite cualquier IDE o asistente de programación que funcione con Git". En los planes de pago también puedes descargar la base de código sin conectar Git.
Algunos límites definen cómo lo configuras:
- Una rama a la vez. Lovable edita y sincroniza únicamente la rama sincronizada. Las confirmaciones en otras ramas no aparecen en Lovable hasta que las fusiones.
- Solo exportación. La documentación de Lovable dice: "No puedes importar un repositorio existente a Lovable". Conectarse siempre crea un nuevo repositorio.
- Sin datos, sin secretos. El repositorio contiene el código de tu proyecto, "incluidos los archivos de migración de la base de datos que definen su estructura, pero nunca los datos dentro de tu base de datos". Y "los secretos que almacenas en Lovable se quedan fuera del repositorio".
Qué se queda en Lovable
Knowledge es lo principal. Lovable lo describe como la forma de "proporcionar instrucciones y contexto persistentes al agente de Lovable", y viene en dos niveles. El Knowledge del espacio de trabajo contiene reglas compartidas, como estándares de codificación y convenciones de nomenclatura. El Knowledge del proyecto contiene lo que es específico de una aplicación, como su propósito, esquema de base de datos, decisiones de arquitectura y términos de dominio. Cada uno admite hasta 10,000 caracteres.
Knowledge es un campo de configuración, no un archivo en tu repositorio. La guía de Lovable sobre la sincronización de Git señala esto indirectamente: "Lovable trata el código que escribiste de la misma manera que el código que generó, y puede cambiar cualquiera de los dos en una solicitud posterior". Su consejo es colocar las restricciones que deben mantenerse en todas las solicitudes en el Knowledge del proyecto y mantener pruebas para el comportamiento del que dependes. Es un buen consejo dentro de Lovable, y significa que las restricciones que más importan son exactamente las que no estarán en tu clon.
Las skills son lo segundo. Las skills del espacio de trabajo son guías de juego (playbooks) con nombre para tareas recurrentes, y se cargan bajo demanda en lugar de estar siempre activas. Viven en la configuración del espacio de trabajo, no en el repositorio.
El chat del proyecto es lo tercero. La documentación de la sincronización de Git cubre el código, no la conversación que lo produjo. Las decisiones tomadas allí solo llegan al repositorio si alguien las escribe.
Qué lee Claude Code en su lugar
Claude Code lee archivos de instrucciones al comienzo de cada sesión. El principal es CLAUDE.md. También puede leer AGENTS.md, con una condición que importa para esta migración: "Por defecto, Claude lee AGENTS.md solo cuando no tienes un CLAUDE.md en tu directorio de trabajo o por encima de él". Nuestra guía sobre el comportamiento por defecto de AGENTS.md en Claude Code cubre los archivos que cuentan para esa verificación. Anthropic señala que "Leer AGENTS.md directamente requiere Claude Code v2.1.277 o posterior".
Las skills se transfieren de manera más directa. "Las skills de Claude Code siguen el estándar abierto Agent Skills, que funciona en múltiples herramientas de IA". Una skill de proyecto vive en .claude/skills/<nombre-de-la-skill>/SKILL.md, y el consejo de Anthropic para las skills de proyecto es "Confirmarla (commit) para que tu equipo también la reciba".
Claude Code también mantiene la memoria automática (auto memory), notas que el propio Claude escribe basándose en tus correcciones y preferencias. Esas notas provienen de tus sesiones de Claude Code, por lo que nada de lo que aprendió el chat de Lovable estará en ellas hasta que lo escribas.
Donde ambos se encuentran: el servidor MCP de Lovable
Lovable ejecuta un servidor MCP al que se conectan clientes externos, y Claude Code es uno de los clientes que Lovable documenta. "El servidor MCP de Lovable está disponible en todos los planes". Es lo opuesto a los conectores de chat de Lovable: en lugar de que Lovable acceda a tus herramientas, tus herramientas acceden a Lovable.
Para una migración, la parte útil son las herramientas de lectura. La lista documentada incluye get_workspace_knowledge y get_project_knowledge, que devuelven el texto de Knowledge; list_workspace_skills y get_workspace_skill, que devuelven una skill "incluyendo su contenido completo"; list_messages, descrito como "Listar mensajes recientes en un proyecto, del más nuevo al más antiguo"; y list_edits y read_file para el historial y los archivos del proyecto.
Eso significa que Claude Code puede leer tu Knowledge y tus skills directamente en lugar de que tengas que copiarlos a mano. Esto viene con dos advertencias. Las herramientas de escritura para Knowledge reemplazan en lugar de añadir. La descripción de set_project_knowledge termina con "Reemplaza el contenido existente por completo", por lo que si todavía estás usando Lovable, no dejes que un agente vuelva a escribir en Knowledge a la ligera. Y list_messages devuelve mensajes recientes, por lo que es una forma de revisar las últimas decisiones, no un archivo de todo el chat.
Cosas a verificar antes de comenzar
Espacios de trabajo Enterprise. El acceso MCP de terceros está "deshabilitado por defecto en los espacios de trabajo Enterprise". Un propietario o administrador debe habilitarlo primero.
Alcance y costo. Lovable advierte que la conexión "no está restringida a un solo proyecto" y que "las llamadas a herramientas utilizan créditos reales y editan proyectos reales". Sus preguntas frecuentes dicen que los créditos se aplican a create_project y send_message y que otras herramientas son gratuitas, por lo que leer Knowledge y skills no debería gastar créditos. Enviar mensajes al agente de Lovable sí lo hará.
Quién puede ver qué. "Solo los propietarios y administradores del espacio de trabajo pueden gestionar el Knowledge del espacio de trabajo". Las skills personalizadas pueden ser descargadas por editores y niveles superiores. Para las skills integradas de Lovable, sus preguntas frecuentes dicen: "Solo se pueden descargar las skills que hayas agregado al espacio de trabajo". Si no eres administrador, pídele a uno el Knowledge del espacio de trabajo actual.
Las reglas de tu organización. Knowledge a menudo incluye referencias internas, y el chat del proyecto puede incluir detalles del cliente. Verifica qué está permitido antes de moverlo a una nueva herramienta o archivo.
La migración manual
Paso 1: Sincroniza el código, luego extrae el Knowledge y las skills de Lovable
Conecta el proyecto a un repositorio en la configuración del proyecto (Project settings), bajo Git, y deja que termine cualquier edición de Lovable en curso. La tarjeta de estado de sincronización te indica cuándo Lovable y tu proveedor están en la misma confirmación. Clona el repositorio y trabaja en una rama de características (feature branch), para que la rama sincronizada de Lovable se mantenga limpia.
A continuación, extrae el contexto. Conecta Claude Code al servidor MCP de Lovable siguiendo los pasos de configuración en la documentación de Lovable. Luego, pídele a Claude Code que lea el Knowledge del proyecto y el Knowledge del espacio de trabajo y guarde cada uno en un archivo temporal (scratch file). Lee ambos tú mismo antes de usarlos. El Knowledge escrito hace meses a menudo contiene reglas que ya has cambiado. Si prefieres no conectar MCP, copia el texto a mano desde la configuración del proyecto, bajo Knowledge.
Para las skills, Lovable te permite descargar una skill personalizada como un archivo zip desde la configuración del espacio de trabajo, bajo Skills. Lovable dice que sus skills "usan la misma estructura SKILL.md que Claude de Anthropic y cualquier otra herramienta que siga la convención Agent Skills", por lo que no necesitan conversión.
Por último, revisa el chat reciente. Pídele a Claude Code que enumere los mensajes recientes del proyecto a través de MCP, o desplázate por el chat tú mismo, y escribe las decisiones que nunca llegaron a Knowledge: por qué se eligió una biblioteca, qué se probó y se descartó, qué comportamiento no debe cambiar. Ponle fecha a cada una.
Paso 2: Escribe un archivo de instrucciones que ambas herramientas lean y mueve las skills al repositorio
Las dos herramientas leen archivos diferentes por defecto. Las preguntas frecuentes de Knowledge de Lovable dicen que "los archivos AGENTS.md a nivel de raíz siempre son leídos por el agente de Lovable independientemente de la duración de la sesión", y que los archivos de instrucciones como CLAUDE.md también pueden guiarlo. Claude Code lee AGENTS.md solo cuando no hay un CLAUDE.md.
Por lo tanto, si vas a seguir usando Lovable junto con Claude Code, coloca las reglas compartidas en un archivo AGENTS.md en la raíz. Ambas herramientas lo leen. Si necesitas instrucciones específicas para Claude, el patrón documentado de Anthropic es mantener AGENTS.md "como el único archivo que comparten todas las herramientas colocando una importación @AGENTS.md en un CLAUDE.md junto a él". Mantén ese CLAUDE.md corto, porque Lovable también podría leerlo.
Luego, traduce cada parte del contexto de Lovable:
- El Knowledge del proyecto se convierte en
AGENTS.md. Reescríbelo como reglas cortas y directas. La guía de Anthropic es "apuntar a menos de 200 líneas por archivo CLAUDE.md", y la misma disciplina ayuda aquí. - El Knowledge del espacio de trabajo se convierte en reglas compartidas. Coloca las reglas que se aplican a cada proyecto en el
AGENTS.mdde cada repositorio, o mantén tus reglas personales en las instrucciones de Claude Code a nivel de usuario. - Las decisiones del chat se convierten en un archivo de decisiones. Un solo archivo, entradas con fecha, de la más nueva a la más antigua. Enlázalo desde
AGENTS.md. - Las skills se mueven a
.claude/skills/. Descomprime cada skill descargada en su propia carpeta y confírmala (commit).
Lovable también publica una skill que enseña a los clientes cómo manejar su servidor MCP, y su documentación sugiere .claude/skills/lovable-mcp/SKILL.md como la ubicación para Claude Code. Agrégala solo si planeas seguir construyendo en Lovable desde Claude Code.
Inicia una sesión de Claude Code y confirma qué se cargó. Con solo un AGENTS.md, una sesión interactiva muestra una línea que dice que no se encontró ningún CLAUDE.md y que se cargó AGENTS.md. Con un CLAUDE.md, ejecuta /context y verifica que aparezca bajo archivos de memoria (Memory files). Luego, pídele a Claude que resuma las reglas que cargó. Si falta algo, corrige el archivo, no el chat.
Si ya te has mudado antes desde otro constructor basado en navegador, nuestra guía para migrar de Replit a Claude Code sigue el mismo patrón.
La mejor manera: Mantén las decisiones del proyecto en un solo lugar que ambas herramientas puedan usar
La migración manual convierte el Knowledge y el chat de Lovable en archivos que Claude Code lee. El archivo de decisiones es la parte más valiosa. También es la parte con más probabilidades de desactualizarse, porque tanto Lovable como Claude Code seguirán trabajando en el mismo código.
MemoryLake es una capa de memoria para mantener esas decisiones en una sola lista que tú mantienes, disponible para Claude Code y los demás asistentes que utilices.
Tú mismo escribes las entradas, con tus propias palabras. No se lee, escribe ni elimina nada de tu Knowledge de Lovable, tus skills de espacio de trabajo, tu memoria de Claude Code ni del almacenamiento de ningún proveedor. Verifica la política de tu organización antes de copiar detalles del proyecto en cualquier lugar.
Paso 1: Crea una clave API
Inicia sesión y genera una clave desde el panel de control. La clave pertenece a tu espacio de trabajo de MemoryLake, independiente de tus cuentas de Lovable y Anthropic.
Paso 2: Sube tus primeras memorias
Comienza con las decisiones que anotaste en el Paso 1 de la migración manual. Una decisión por entrada, con fecha y el motivo.
Paso 3: Conecta tu IA y agentes
Conecta Claude Code y los demás asistentes que utilices. Las mismas decisiones estarán disponibles en cada herramienta que conectes, en lugar de vivir en la configuración de una sola herramienta.
Qué cambia esto en la práctica
La primera diferencia es que el contexto de Lovable se convierte en algo que puedes leer y revisar. Knowledge se encontraba en un campo de configuración. Ahora es un archivo en tu repositorio, con control de versiones junto con tu código.
La segunda es menos retrocesos. Lovable puede cambiar el código que escribiste en una solicitud posterior. Cuando la restricción vive en un archivo AGENTS.md raíz que ambas herramientas leen, está frente a Lovable y Claude Code por igual.
La tercera es que las skills siguen funcionando. Debido a que ambas herramientas usan la misma estructura SKILL.md, un flujo de trabajo que tu espacio de trabajo perfeccionó en Lovable se ejecuta en Claude Code sin necesidad de reescribirlo. Sin embargo, las skills conllevan procedimientos, no decisiones, razón por la cual las skills no sustituyen a la memoria y el archivo de decisiones sigue siendo importante.
La cuarta es menos explicaciones repetidas. Una sesión que comienza con el archivo de instrucciones correcto no requiere que vuelvas a explicar el proyecto, la situación que cubre nuestra guía sobre cómo Claude Code olvida el contexto del proyecto.
Buenas prácticas para pasar de Lovable a Claude Code
Mantén a Lovable en su propia rama. Trabaja en una rama de características y fusiónala en la rama sincronizada.
No reescribas el historial sincronizado. La documentación de Lovable dice que no se debe hacer force-push, rebase o squash de las confirmaciones que ya están en la rama sincronizada.
Lee el Knowledge antes de copiarlo. Las reglas antiguas a menudo son reglas incorrectas.
Usa un solo AGENTS.md en la raíz. Ambas herramientas lo leen.
Trata las escrituras de MCP con cuidado. Las escrituras en Knowledge reemplazan todo el campo.
Confirma (commit) las skills en el repositorio. Ahí es donde Claude Code encuentra las skills del proyecto.
Escribe las decisiones del chat. El chat no viaja con el código, como explica nuestra guía sobre cómo Lovable olvida el contexto del proyecto.
Conclusión
Pasar de Lovable a Claude Code es fácil para el código y deliberado para el contexto. La sincronización de Git te brinda un repositorio en el que Claude Code puede trabajar. El Knowledge, las skills y el chat de Lovable se quedan en Lovable a menos que los extraigas.
El servidor MCP de Lovable facilita esto. Claude Code puede leer el Knowledge del proyecto y del espacio de trabajo, las skills personalizadas y los mensajes recientes directamente, siempre que trates las herramientas de escritura con cuidado. Las skills se mueven tal como están, porque ambas herramientas usan la misma estructura SKILL.md.
Coloca las reglas compartidas en un archivo AGENTS.md a nivel de raíz, agrega un CLAUDE.md corto que lo importe si necesitas instrucciones específicas para Claude, y mantén un archivo de decisiones con fecha. Ese es el contexto que de otro modo tendrías que reconstruir una corrección a la vez.