Cómo configurar el Memory Bank de Cline y mantenerlo actualizado (Paso a paso, 2026)

Es documentación, y la documentación decae

El bloque de instrucciones personalizadas que impulsa Memory Bank está escrito en primera persona, y vale la pena leerlo literalmente: "Soy Cline, un ingeniero de software experto con una característica única: mi memoria se restablece por completo entre sesiones. Esto no es una limitación; es lo que me impulsa a mantener una documentación perfecta. Después de cada restablecimiento, dependo TOTALMENTE de mi Memory Bank para comprender el proyecto y continuar el trabajo de manera efectiva".

Todo se deriva de esa frase. Cline no está recordando; está leyendo. Si el archivo dice que el proyecto usa REST y cambiaste a GraphQL hace tres semanas, Cline no está confundido: está en lo correcto sobre un archivo que está equivocado.

Uno de los seis archivos cambia mucho más rápido que el resto

La estructura principal consta de seis archivos en una jerarquía deliberada: projectbrief.md como "Documento fundacional que da forma a todos los demás archivos", luego productContext.md, systemPatterns.md y techContext.md construyendo sobre él, alimentando a activeContext.md y progress.md.

Esos seis no envejecen al mismo ritmo. projectbrief.md puede ser correcto durante un año. activeContext.md cubre "Enfoque actual, cambios recientes, próximos pasos" y, según la documentación, "se actualiza con mayor frecuencia".

Esa asimetría es todo el problema de mantenimiento. El archivo con más probabilidades de estar desactualizado es también en el que Cline se apoya más al inicio de una tarea, porque es el que describe lo que estabas haciendo ayer.

Actualizar es un comando que alguien debe recordar ejecutar

Cline te ofrece tres comandos: "initialize memory bank" para crear la estructura, "update memory bank" para activar "una revisión y actualización completa de la documentación", y "follow your custom instructions" para que Cline lea el banco y continúe donde lo dejaste.

La documentación enumera cuatro condiciones que deberían activar una actualización: "Descubrir nuevos patrones de proyecto", "Después de implementar cambios significativos", "Cuando el usuario lo solicite con update memory bank (DEBE revisar TODOS los archivos)" y "Cuando el contexto necesite aclaración".

Tres de esas cuatro dependen de que un humano se dé cuenta. Eso no es una crítica al diseño (es lo que es una metodología de documentación), pero sí te indica dónde debes poner tu esfuerzo.

Inicializarlo una vez y no volver a tocarlo. El patrón más común, y funciona durante aproximadamente dos semanas. Luego, el banco describe una versión del proyecto que ya no existe, y como Cline lo lee con total confianza, un contexto incorrecto es peor que no tener contexto.

Ejecutar "update memory bank" solo cuando algo se rompe. Para entonces, la actualización es una reescritura completa en lugar de un incremento, y las reescrituras completas se posponen.

Poner todo en activeContext.md. Es el archivo que la gente abre más a menudo, por lo que acumula notas de arquitectura, decisiones sobre el stack tecnológico y preguntas abiertas hasta que deja de ser un resumen del enfoque actual. La jerarquía existe precisamente para evitar esto.

Tratar Memory Bank como un sustituto de la autocompactación. Estas son herramientas diferentes. La documentación sugiere la división directamente: "También puedes dejar que Auto Compact se encargue de la gestión rutinaria del contexto y reservar el 'update memory bank' manual para puntos de control importantes".

Asumir que un archivo .md en la carpeta correcta es suficiente. Memory Bank necesita que el bloque de instrucciones esté activo. Cópialo en un archivo de reglas de Cline como .clinerules/memory-bank.md, o en tus instrucciones personalizadas globales; de lo contrario, los archivos son solo archivos, lo cual es una versión de por qué los agentes ignoran tus archivos de instrucciones.

Configurarlo en una máquina y asumir que el equipo lo tiene. Si el bloque de instrucciones reside en tus instrucciones personalizadas globales en lugar de en el repositorio, tus colegas no tienen Memory Bank en absoluto: tienen una carpeta de archivos markdown que el agente de nadie tiene instrucciones de leer. El síntoma es confuso: el banco parece mantenido porque tú lo mantienes, pero parece no hacer nada para todos los demás.

Escribir el banco para el modelo en lugar de para la siguiente persona. Los archivos son markdown simple en tu repositorio, lo que significa que un humano los leerá durante la revisión de código y la incorporación (onboarding). Las entradas escritas como listas de palabras clave concisas son más baratas de producir y mucho más difíciles de verificar para cualquiera de las dos audiencias un mes después.

La configuración consta de tres pasos, y el tercero es la parte que la mayoría de las guías omiten.

Paso 1: Instalar las instrucciones y luego inicializar

Copia el bloque de instrucciones personalizadas de Memory Bank de la documentación de Cline en un archivo de reglas de Cline (el ejemplo que da la documentación es .clinerules/memory-bank.md) y luego pídele a Cline que ejecute "initialize memory bank".

Elige la ubicación deliberadamente. Las preguntas frecuentes de Cline lo plantean como un equilibrio: "Las instrucciones personalizadas se aplican globalmente en todos los proyectos. Un archivo de reglas de Cline es específico del proyecto y se almacena en tu repositorio, lo que facilita compartirlo con colaboradores". Para cualquier proyecto con más de una persona, la versión del repositorio gana, porque una instrucción global que solo tú tienes produce un Memory Bank que solo tú mantienes.

Hay una tercera opción que vale la pena conocer: las reglas condicionales pueden "activar las instrucciones de Memory Bank solo cuando se trabaja con archivos de memory-bank/". Útil si la versión siempre activa está saturando tu contexto.

Deja que Cline cree la estructura inicial en lugar de escribir a mano los seis archivos. La documentación recomienda comenzar con un resumen básico del proyecto (project brief) y dejar que la estructura evolucione, y Cline puebla la jerarquía de manera más consistente que una persona completando plantillas.

Paso 2: Dividir los seis archivos según la rapidez con la que cambian y actualizar con ese ritmo

Escribe, una sola vez, quién actualiza qué y cuándo. Una versión que funciona:

• projectbrief.md y productContext.md — se revisan en los hitos, no en las sesiones.
• systemPatterns.md y techContext.md — se actualizan cuando una decisión arquitectónica o de dependencia cambia realmente, en el mismo commit que el cambio.
• activeContext.md — se actualiza al final de cada sesión de trabajo. La documentación es explícita: "cambia con mayor frecuencia; actualízalo después de cada sesión".
• progress.md — se revisa al reanudar el trabajo, ya que "realiza un seguimiento de los hitos".

Luego, utiliza el flujo de trabajo de la ventana de contexto que describe la documentación, ya que también sirve como ritual de mantenimiento. Cuando tu ventana de contexto se llene: pídele a Cline "update memory bank" para documentar el estado actual, inicia una nueva conversación y luego pídele a Cline "follow your custom instructions". Obtienes una ventana limpia y un banco actualizado con las mismas tres acciones, lo cual es mucho más confiable que un recordatorio en el calendario.

Una advertencia sobre la actualización completa: "update memory bank" significa que Cline "DEBE revisar TODOS los archivos". Eso es minucioso y no es gratuito; en un banco grande, es una pasada sustancial. Resérvalo para los puntos de control y deja que el recorte rutinario ocurra a través de Auto Compact, exactamente como sugieren las preguntas frecuentes.

Paso 3: Mantener los hechos que sobreviven al repositorio en otro lugar

Aquí está el límite del diseño. Memory Bank está acotado a un directorio de proyecto y diseñado en torno a una base de código. Eso es correcto para systemPatterns.md e incorrecto para una gran categoría de cosas que tu agente también necesita.

Detalles específicos del cliente y del dominio. Preferencias sobre cómo quieres que se haga el trabajo, que son válidas en cada repositorio que tocas. Decisiones cuyo razonamiento importa más que el resultado. Cualquier cosa compartida con un compañero de equipo que esté usando una herramienta diferente.

Nada de eso pertenece a seis archivos markdown en un solo repositorio, y forzarlo allí es lo que hace que un Memory Bank se vuelva sobrecargado y obsoleto al mismo tiempo. Una capa de memoria fuera del repositorio contiene la mitad que abarca varios proyectos, mientras que Memory Bank sigue haciendo aquello para lo que es genuinamente bueno. 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. Te pertenece a ti en lugar de a un repositorio, lo que permite que el mismo conocimiento te siga entre proyectos en lugar de tener que restablecerse en cada nuevo Memory Bank.

Paso 2: Subir tus primeras memorias

Comienza con lo que has tenido la tentación de pegar en activeContext.md que nunca tuvo que ver con el enfoque actual: preferencias permanentes, glosario del dominio, detalles del cliente, decisiones y las razones detrás de ellas. Luego, añade las cosas que ya has vuelto a explicar en un segundo repositorio.

Paso 3: Conectar tu IA y agentes

Apunta Cline al almacén. La mitad específica del repositorio se queda en Memory Bank, donde tu equipo puede revisarla en un pull request; la mitad duradera deja de tener que escribirse de nuevo en cada nuevo proyecto.

El primer cambio es que activeContext.md se vuelve más pequeño y, por lo tanto, se mantiene preciso. Un archivo que solo contiene el enfoque actual es un archivo que honestamente puedes actualizar en treinta segundos al final de una sesión. Un archivo que se ha convertido en un vertedero de conocimiento general es uno que omitirás.

El segundo es que comenzar un nuevo repositorio deja de ser un lienzo en blanco. Hoy en día, un nuevo proyecto significa un nuevo Memory Bank sin nada en él, y pasas la primera semana restableciendo preferencias que Cline ya aprendió dos veces. Con la mitad duradera almacenada fuera, solo los archivos específicos del proyecto son nuevos.

El tercero es que un compañero de equipo que use una herramienta diferente ya no queda aislado. Memory Bank es una convención de Cline; un colega en otro agente no puede leerlo como memoria, solo como documentación. Si la mitad de tu equipo ha cambiado (por ejemplo, después de una migración de Cursor a Cline), la capa compartida es lo que mantiene a ambas partes trabajando a partir de los mismos hechos.

• Coloca el bloque de instrucciones en el repositorio, no en la configuración global, para cualquier proyecto con más de una persona.
• Actualiza activeContext.md al final de cada sesión. Es el único archivo con una cadencia por sesión, y es el que Cline lee con mayor atención.
• Vincula las actualizaciones arquitectónicas al commit que cambia la arquitectura. systemPatterns.md nunca debería actualizarse como una tarea separada.
• Usa el ritual de llenado como tu activador de actualización. Actualización, nueva conversación, "follow your custom instructions". Mantenimiento gratuito asociado a algo que ya haces.
• Reserva las ejecuciones completas de "update memory bank" para los puntos de control. Revisa cada archivo; deja que Auto Compact se encargue de la gestión rutinaria del contexto.
• Añade archivos bajo memory-bank/ cuando un tema lo merezca, tal como lo permite la documentación para características complejas, especificaciones de integración o estrategias de prueba, en lugar de hacer crecer un solo archivo indefinidamente.
• Mantén fuera el conocimiento que abarca varios proyectos. Si un hecho fuera igualmente cierto en tu próximo repositorio, Memory Bank es el lugar equivocado para él.
• Lee el banco tú mismo una vez al mes. Es markdown simple en tu repositorio, lo cual es su mayor ventaja, y significa que la obsolescencia es visible para un humano, si un humano mira. Auditar lo que tu IA recuerda se aplica aquí tanto como a cualquier almacén oculto.

Memory Bank es uno de los diseños más honestos en este espacio. No pretende que el modelo recuerde nada; dice que la memoria se restablece y la documentación es lo que sobrevive. Esa honestidad es exactamente por lo que funciona y exactamente por lo que decae: un sistema construido sobre documentación hereda el modo de fallo de la documentación.

Configúralo en el repositorio, divide los seis archivos según la rapidez con la que cambian, asocia las actualizaciones a algo que ya haces y mantén el conocimiento que sobrevive a este repositorio en algún lugar que también le sobreviva.