Qué se transfiere realmente
Comencemos con lo que realmente es un Memory Bank, porque la documentación es más clara al respecto de lo que la mayoría de la gente cree.
"Memory Bank is a documentation methodology that transforms Cline from a stateless assistant into a persistent development partner. Through structured markdown files, Cline can 'remember' your project details across sessions."
Nota la palabra metodología. Las instrucciones de configuración lo confirman: copias un bloque de instrucciones personalizadas y las "añades a un archivo de reglas de Cline, como .clinerules/memory-bank.md." No hay un interruptor de encendido. La función es una convención de prompts que vive en un archivo de reglas, más una carpeta de documentos que la convención le indica al agente que lea. Si configuraste el tuyo siguiendo la configuración del Memory Bank de Cline, el archivo de reglas en el que pegaste ese bloque es la parte que estás a punto de perder, no la carpeta.
La carpeta en sí es común y corriente:
"Memory Bank files are regular markdown files in your project that both you and Cline can access. They're organized hierarchically to build a complete picture of your project."
Seis archivos, cada uno con una tarea: projectbrief.md como documento base, productContext.md para el porqué de la existencia del proyecto, activeContext.md para el enfoque actual y los cambios recientes, systemPatterns.md para la arquitectura y los patrones de diseño, techContext.md para el stack tecnológico y las restricciones, y progress.md para lo que funciona y lo que queda por hacer. Lo manejas con frases; la documentación menciona "follow your custom instructions" para que Cline lea el banco y continúe donde lo dejaste, y "update memory bank" para activar "una revisión y actualización completa de la documentación".
Así que la migración se divide claramente en dos. Los documentos se transfieren perfectamente: son archivos markdown en tu repositorio y siguen siendo markdown en tu repositorio. El mecanismo no se transfiere en absoluto, y aquí te explicamos por qué.
La documentación de Zencoder describe el contexto como algo que se ensambla por mensaje a partir de cinco fuentes: el análisis del espacio de trabajo de la estructura de archivos y dependencias de tu proyecto, el archivo actualmente abierto en tu editor, las habilidades coincidentes (skills), cualquier elemento que adjuntes con menciones @ y el contexto que el agente recopila con sus propias herramientas durante la ejecución. Esa es la lista completa de cómo llega el contexto, y ninguna de las cinco fuentes es un archivo de instrucciones del repositorio que esté siempre cargado.
La superficie duradera y controlada por versiones que Zencoder sí tiene son las habilidades (skills):
"Skills are stored asSKILL.mdfiles in.agents/skills/and are version-controlled with your repo."
Las lee desde tres ubicaciones: <workspace>/.agents/skills/ para las habilidades del proyecto, <user-home>/.agents/skills/ para las de nivel de usuario, y <workspace>/.claude/skills/ que la documentación etiqueta como "habilidades compatibles con Claude". La ruta heredada .zencoder/skills/ se describe como "obsoleta pero aún compatible".
Y ahora, la frase que define tu plan de migración:
"Skills are automatically selected by the agent based on task context. Manual skill selection is not currently supported."
Una habilidad se carga cuando el agente decide que su description coincide con lo que estás haciendo. La documentación es directa al señalar que la descripción es la que hace el trabajo: es "lo que hace la habilidad; el agente usa esto para decidir cuándo cargarla", y la recomendación es "escribirla como una condición de activación clara".
Junta las dos mitades. El Memory Bank de Cline depende de una instrucción que se ejecuta incondicionalmente al inicio de cada tarea. La superficie equivalente de Zencoder se activa al coincidir con una descripción, y no hay una anulación manual para forzarla. Copiar memory-bank/ en un proyecto de Zencoder te da seis archivos que nada ni nadie está obligado a abrir.
Para completar la verificación inversa: la documentación de Zencoder describe habilidades, ensamblaje de contexto por mensaje y búsqueda en múltiples repositorios. No describe un almacén de memoria conversacional que acumule hechos a lo largo de las sesiones. Su propio consejo apunta en la dirección opuesta: "Los chats largos y con múltiples temas acumulan contexto obsoleto. Inicia un nuevo chat para cada tarea distinta para que el contexto del agente se mantenga limpio". Ese es un buen consejo, y significa que cada tarea comienza desde el repositorio más lo que el agente decida cargar.
La migración manual
Step 1: Split the bank into procedures and standing facts
Abre los seis archivos y vuelve a clasificar su contenido por su forma en lugar de por su nombre de archivo, porque el destino tiene un solo contenedor y tiene forma de procedimiento.
Cualquier cosa que se lea como una secuencia (cómo realizar un lanzamiento, cómo agregar una migración, cómo funciona la lista de verificación de revisión) es una habilidad candidata. Tiene una condición de activación de forma natural ("usa esto al agregar una migración de base de datos"), por lo que una descripción puede coincidir con ella de manera confiable y funcionará bien.
Cualquier cosa que se lea como un hecho permanente pertenece al grupo difícil. systemPatterns.md describiendo por qué el bus de eventos tiene la forma que tiene, techContext.md enumerando la restricción que descarta una biblioteca obvia, projectbrief.md explicando para qué sirve realmente el producto... nada de eso tiene una condición de activación, porque es relevante para casi todas las tareas y específico para ninguna. Escribir una descripción que coincida con "siempre" es exactamente para lo que el mecanismo no está diseñado.
Luego están activeContext.md y progress.md, que no son ninguna de las dos cosas. Son un registro continuo de cómo están las cosas. Esos dos son la razón por la que el Memory Bank se sentía como memoria en lugar de documentación, y son los dos que no tienen ningún destino en absoluto; esta es la brecha detrás de quejas como que Cline olvide el historial de tareas, excepto que ahora la pérdida es estructural en lugar de un problema de la ventana de contexto.
Step 2: Write the procedure skills, and write their descriptions carefully
Crea una carpeta por procedimiento bajo .agents/skills/, cada una con un archivo SKILL.md que contenga un name y una description. Dedica tu esfuerzo a la descripción, porque es todo el mecanismo de activación. "API helper skill" no coincidirá; "use this skill when the user asks to create or modify API endpoints" sí lo hará.
Vale la pena conocer dos campos. paths acepta patrones glob para delimitar una habilidad a archivos específicos, lo que te acerca más a la carga condicional que las descripciones por sí solas. Y disable-model-invocation, establecido en true, evita que el agente seleccione automáticamente una habilidad, lo cual, dado que la selección manual no es compatible, efectivamente deja esa habilidad fuera de juego. Úsalo deliberadamente o no lo uses en absoluto.
Si tu equipo también utiliza herramientas basadas en Claude, ten en cuenta que Zencoder también lee <workspace>/.claude/skills/. Una sola carpeta puede servir para ambos en lugar de mantener dos copias.
Lo que no debes hacer es meter los hechos permanentes en una habilidad con una descripción vaga y cruzar los dedos. Así es como terminas en el modo de fallo descrito en por qué las habilidades de los agentes no son memoria: un documento que técnicamente está presente pero que nunca se carga cuando realmente importa.
La mejor manera: Una capa que no espera a ser emparejada
El grupo que no pudiste ubicar es el más valioso. Razones de arquitectura, alternativas rechazadas, la restricción que explica un módulo extraño, el estado actual del proyecto... ese es el contenido que hacía que valiera la pena mantener tu Memory Bank, y el modelo de activación de Zencoder no le ofrece ningún disparador confiable.
MemoryLake mantiene esa capa fuera del editor y responde preguntas al respecto a través de MCP o la API. El agente no tiene que adivinar a partir de una descripción si el contenido es relevante: simplemente pregunta cuando surge una duda. Tus habilidades de procedimiento se quedan en .agents/skills/, donde Zencoder las carga por coincidencia de tareas, y los hechos permanentes siguen estando disponibles para responder preguntas, independientemente de lo que el agente haya decidido cargar en ese turno.
Step 1: Create an API key
Genera una clave y realiza tu primera solicitud en unos treinta segundos. Haz esto antes del Paso 1 anterior, para que tengas un lugar donde colocar cada hecho a medida que clasificas los seis archivos.

Step 2: Upload your first memories
Trabaja con el grupo de elementos difíciles de ubicar, archivo por archivo. Decisiones de arquitectura de systemPatterns.md, restricciones de techContext.md, intención del producto de projectbrief.md y productContext.md, y el estado actual de activeContext.md y progress.md. Escribe cada uno como una decisión con su motivo. Los documentos de soporte van en el mismo lugar; convertir los documentos del proyecto en memoria de IA explica cómo hacerlo sin tener que reescribirlo todo.

Step 3: Connect your AI & agents
Dale acceso a Zencoder, Claude, Codex y tus otros agentes a través de MCP o la API. Cada nuevo chat (y el propio consejo de Zencoder es iniciar muchos de ellos) comenzará siendo capaz de responder por qué el proyecto es como es.

Qué cambia esto en la práctica
El primer cambio es que iniciar un chat nuevo deja de costarte nada. Zencoder recomienda un nuevo chat por tarea precisamente porque el contexto obsoleto perjudica, y esa recomendación solo resulta cómoda cuando el conocimiento duradero no está en el chat desde el principio.
El segundo es que tus habilidades mejoran porque se vuelven más específicas. Una vez que los hechos permanentes tienen otro lugar donde vivir, cada habilidad puede ser un único procedimiento con una descripción precisa, que es exactamente la condición bajo la cual funciona la coincidencia de descripciones.
El tercero es que los archivos de registro dejan de ser una pérdida. activeContext.md y progress.md no tenían destino en la nueva herramienta. Al registrarlos como decisiones con fechas, se convierten en lo que un nuevo compañero de equipo lee en lugar de tener que desplazarse por el historial de un chat.
El cuarto es que el próximo movimiento será más fácil que este. La razón por la que esta migración fue complicada es que el mecanismo de Cline era un archivo de reglas y el de Zencoder es una coincidencia de descripción. A una capa que no pertenece a ninguno de los dos no le importa qué mecanismo elija la próxima herramienta; la misma razón por la que el olvido del contexto del proyecto por parte de Cline y sus equivalentes en cualquier otra herramienta tienen la misma solución de fondo.
Buenas prácticas después de mudarse a Zencoder
Trata las descripciones como la característica clave. La descripción de una habilidad es todo su mecanismo de activación. Escríbela como una condición de activación que nombre la situación, no como una etiqueta que nombre el tema.
Un procedimiento por habilidad. Agrupar tres procedimientos no relacionados te dará una descripción que no coincidirá limpiamente con ninguno de ellos.
Ten en cuenta paths para el trabajo delimitado a archivos. La delimitación por glob es lo más cercano a la carga condicional y es más confiable que una descripción amplia.
No configures disable-model-invocation a la ligera. Dado que la selección manual no es compatible, deshabilitar la selección automática elimina la única vía de acceso.
Migra fuera de la ruta de habilidades heredada. La documentación describe .zencoder/skills/ como obsoleta pero compatible, y recomienda .agents/skills/ para mantenerse alineado con el estándar actual.
Comparte una carpeta de habilidades con las herramientas de Claude. Zencoder también lee .claude/skills/, por lo que los equipos que ejecutan ambos no necesitan duplicados.
No esperes que una habilidad se comporte como una regla siempre activa. Si algo debe cumplirse en cada tarea, un contenedor emparejado por tarea es el lugar equivocado para ello.
Conclusión
El Memory Bank de Cline es una carpeta de markdown más un archivo de reglas que hace que el agente la lea. Zencoder controla las versiones de las habilidades en .agents/skills/, las selecciona automáticamente a partir de sus descripciones y actualmente no admite la selección manual; además, sus fuentes de contexto documentadas se ensamblan por mensaje en lugar de cargarse desde un archivo de instrucciones permanente. Por lo tanto, los documentos de tu Memory Bank se migran perfectamente, pero la garantía de que algo los lea, no.
Divide el banco por su forma antes de moverlo. Los procedimientos se convierten en habilidades con descripciones escritas como condiciones de activación, y funcionarán bien. Los hechos permanentes y el estado de ejecución necesitan un hogar que responda preguntas en lugar de esperar a ser emparejados. Haz esa división una vez y el consejo de Zencoder de iniciar un chat nuevo para cada tarea se convertirá en lo que debe ser: una forma de mantener el contexto limpio, no una forma de empezar de cero.