Un archivo, unas directrices, y Claude hace el resto — cómo estructuré 500 correos sin esfuerzo

En el artículo anterior, describí un sistema de contextos estructurados para trabajar con un LLM en temas complejos. Carpetas, archivos de misión, manifiestos de carga, notas atómicas enlazadas entre sí. El modelo es potente. Pero no es fácil de entender, y menos aún de poner en marcha cuando se parte de cero.

Y sobre todo — no llegué ahí a la primera. Este sistema es el resultado de 40 días de pruebas, errores, versiones descartadas y reconstruidas. Nadie compra un Ferrari como primer coche. Aquí pasa lo mismo: hay que conducir primero, entender cómo funciona, y solo entonces subir en complejidad.

Este artículo cuenta cómo empecé. No con un framework. Con un archivo.

El problema: 500 correos y cero visión de conjunto

Como miembro del consejo de mi comunidad de propietarios, recibo muchos correos. Del administrador, de propietarios, de inquilinos. A veces un tema nuevo, a veces la enésima respuesta a un hilo que dura meses.

El volumen no es el verdadero problema. El verdadero problema es que cada persona que responde a un hilo lleva el contexto en la cabeza — es ella quien ha seguido el tema desde el principio. Yo, cuando abro un correo nuevo, tengo que remontar toda la cadena, encontrar quién dijo qué, entender en qué punto estamos. Para una obra que dura seis meses, es un trabajo considerable. Multiplícalo por quince temas en paralelo, y entiendes por qué busqué otra solución.

Decidí delegar en Claude la estructuración de esa información entrante. Recupera los correos automáticamente, los asocia a su hilo y los agrega. La recuperación automática de correos es pura técnica — no hablaré de eso aquí. Lo que me interesa es lo que viene después: cómo construí, paso a paso, un sistema de memoria que funciona.

Paso 1 — Un archivo, una frase

Al principio, era un simple archivo context.md con una directriz vaga:

"Agrega la información y divide en temáticas."

Y funcionaba. Claude recibía los correos, los clasificaba por tema, mantenía un resumen por temática. Para un primer intento, ya era útil.

Paso 2 — El problema de la pérdida de información

Luego vi que perdía información. Cuando una obra terminaba, por ejemplo, Claude actualizaba la agregación: "obra terminada, recepción conforme". Bien. Pero el historial desaparecía. ¿Cuándo había empezado la obra? ¿Cuándo se retrasó? ¿Cuándo se firmó un anexo? Todo eso quedaba borrado por la última actualización.

Necesitaba las dos cosas: la información final y el historial.

La solución fue pedirle a Claude que mantuviera, además de la agregación, un registro cronológico. Si empieza una obra, es una línea. Si se retrasa, es otra línea. Si un anexo afecta a la obra, es otra línea más. En la agregación se ve el estado actual: "obra iniciada en enero, terminada en junio, conforme". En el registro se ve cada etapa, cada evento, en orden.

Dos vistas del mismo tema. Una para entender rápido, otra para remontar el hilo.

Paso 3 — Las directrices de negocio

Luego quise dar reglas de tratamiento más precisas. No reglas genéricas — directrices específicas a mi contexto.

Por ejemplo: cuando se cita a una persona por su apellido, encontrar el nombre correspondiente. Parece trivial, salvo cuando dos proveedores comparten el mismo apellido. En ese caso, la directriz precisa: usar el sentido del correo para desambiguar.

Otro caso: algunas personas son llamadas a veces por su apellido de soltera, a veces por su apellido de casada. Sin directriz, Claude crea dos entradas distintas para la misma persona. Con la directriz, sabe que es la misma.

Otro ejemplo: separar los pequeños deudores (menos de 100 euros) de los grandes deudores. No es la misma gestión, no es el mismo seguimiento, no es el mismo nivel de atención.

Estas directrices no son reglas universales. Son específicas a mi contexto. Y precisamente por eso son potentes: codifican un conocimiento que solo yo poseo, y que Claude aplica después de forma sistemática, sin olvidar, sin cansarse.

Paso 4 — El muro de las 1.000 líneas

Funcionaba bien. Mi context.md organizaba correctamente mi conocimiento. Pero empezaba a crecer. 500 líneas, luego 800, luego más de 1.000.

El problema no es solo la legibilidad para mí. Es la ventana de contexto del LLM. Cuanto más grande es el archivo, más tiene que cargar Claude en cada sesión. Y como expliqué en el artículo anterior, un LLM pierde precisión sobre la información enterrada en medio de un documento largo. Mi archivo único empezaba a jugar en mi contra.

Paso 5 — Separar las directrices del contexto

Primera solución: extraer las directrices en un archivo separado.

Las directrices — cómo tratar los nombres, cómo separar los deudores, cómo gestionar los duplicados — no son información sobre la comunidad. Son reglas de tratamiento. Mezclarlas con el contexto es mezclar la receta con los ingredientes.

Un archivo directives.md por un lado. El context.md por otro. Mejor.

Pero context.md seguía creciendo.

Paso 6 — Dividir el contexto por temática

La verdadera solución fue pedirle a Claude que dividiera mi context.md en tantos archivos como temáticas había. Las obras en un archivo. Las finanzas en otro. Los proveedores en un tercero. Y así sucesivamente.

Y para que se orientara: un readme.md que lista todos los archivos, con una descripción breve de cada temática.

La primera división no me convenció del todo. Es normal: le había pedido que dividiera sin darle directrices precisas sobre cómo hacerlo, así que lo hizo como le pareció. Y a veces su visión de la división no coincidía con la mía. Tenía un archivo de varios miles de líneas — yo no lo veía necesariamente igual que él.

Con un poco de conversación, y unas directrices reforzadas sobre la división, llegamos a algo que me satisfacía. Los archivos están bien divididos. Y sobre todo: Claude ahora solo lee y escribe en los archivos que necesita. Sin más archivo monolítico cargado entero en cada sesión. La ventana de contexto ya no se dispara.

Paso 7 — Externalizar el vocabulario

Último refinamiento: tenemos mucho vocabulario técnico en el contexto de la comunidad. Nombres técnicos, acrónimos (DPAE…), términos jurídicos. En lugar de dejarlos dispersos en cada archivo temático, le pedí que lo centralizara todo en un glossary.md.

El modelo final — simple y robusto

Y listo. Sin ir hacia un sistema de memoria complejo — sin manifiesto de carga, sin notas atómicas, sin memoria episódica — tengo un modelo que cubre ampliamente mi necesidad:

directives.md       — reglas de tratamiento
glossary.md         — vocabulario técnico
readme.md           — índice de temáticas
themes/
  residence.md
  travaux.md
  finances.md
  prestataires.md
  ...               — un archivo por temática

Cuatro conceptos. Un archivo de reglas, un glosario, un índice y archivos temáticos. Eso es todo.

Para dar una idea concreta, aquí está el readme.md real de mi contexto de comunidad de propietarios, tal como existe hoy — 15 archivos temáticos:

Este directorio era antes un único archivo monolítico de más de 1.000 líneas. Se descompuso en 14 archivos temáticos en una sola sesión, y luego debiteurs.md se extrajo de acteurs.md el mismo día — porque la gestión de los deudores merecía su propio espacio.

Lo que cambia en el día a día

La ganancia es enorme.

Para alguien que lleva un tema desde hace seis meses — el administrador que gestiona una obra, el proveedor que responde sobre un presupuesto — el contexto está en su cabeza. Sabe en qué punto estamos porque ha vivido cada etapa.

Yo, cuando llego a un correo, no tengo ese lujo. Tengo que remontar la cadena, releer los intercambios anteriores, reconstituir el estado del tema. Con 15 temas en paralelo y hilos que se extienden durante meses, es un trabajo enorme.

Con el sistema en marcha, todo está agregado. Sé que hay un correo nuevo. Pero sobre todo, sé cuáles son las evoluciones, cómo ha cambiado un dato, en qué punto estamos. Tengo el historial. Tengo la lista de personas contactadas. Tengo la lista de proveedores con sus ámbitos y sus importes. Toda esa información está organizada y es estable. La lista de proveedores no cambia con cada correo — se enriquece progresivamente.

Y cuando me hago una pregunta — "¿qué proveedor hizo el último presupuesto para las canalones?", "¿en qué punto está el expediente de tal deudor?" — basta con preguntársela a Claude. Si tienes 300, 400, 500 correos y tienes que encontrar la respuesta a ese tipo de pregunta rebuscando en tu bandeja de entrada, es un infierno.

¿Por dónde empezar?

Si quieres intentarlo, recomendaría usar Claude CoWork cuando no se viene del desarrollo. Es más sencillo, no hay que desplegar toda una herramienta de desarrollo. Solo dos cosas que hacer:

1. Crear un archivo context.md
2. Dar 2-3 directrices en la conversación: "voy a darte información, la agregas, historias si hay varias etapas para esa información, y lo pones todo en el context.md"

Y luego empiezas a hablar con Claude. Le das información, ves cómo la organiza, ajustas. El objetivo de la primera vez es solo aprender. No construir el sistema perfecto. Aprender cómo funciona, cómo reacciona la IA, qué hace bien y qué hace mal.

Por mi parte, pasé directamente a Claude Code porque vengo del desarrollo. Para mí era más sencillo, es más potente. Pero la elección de la herramienta no es lo más importante — lo que cuenta es el método.

El coste de entrada

¿Cuánto tiempo me ha llevado? Partiendo de cero, sin conocer nunca Claude, llevo unos 40 días para llegar al sistema actual (más un montón de otras cosas de las que habrá que hablar: seguimiento de la competencia, este blog también está gestionado íntegramente por Claude, gestión de la documentación de soporte, agente de análisis de datos…). Pero tengo una ventaja: antes de ser product manager, fui desarrollador. Eso ayuda para la parte de herramientas. Para la parte del método — cómo estructurar la información, qué directrices dar — está al alcance de cualquiera.

La cuestión de la confianza

Claro que Claude comete errores. Pero un humano también los comete.

Lo que hay que ver es que evidentemente no confiaríamos la gestión de documentos bancarios a una IA. Hay ámbitos donde no podemos permitirnos el error. Pero para estructurar correos de una comunidad de propietarios, si de vez en cuando Claude asocia mal una información, no es grave. La ganancia de tiempo es tan importante que algunas aproximaciones son un precio aceptable.

Y sobre todo, siempre tengo una salida: mi bandeja de entrada. Todos los correos brutos se conservan en el repositorio — una copia de todos los emails brutos en el proyecto Claude. Puedo en cualquier momento hacer una búsqueda directamente sobre los correos originales a través de Claude Code, sin pasar por la información agregada. El sistema estructurado es un acelerador, no un sustituto. La fuente de verdad sigue siendo accesible.

De lo personal a lo profesional

Apliqué exactamente el mismo enfoque para mi trabajo de PM. Al principio era realmente artesanal — un archivo de contexto, un skill, conversaciones en la consola sin saber muy bien cómo funcionaba. Y luego aprendí. Me lancé, cometí muchos errores.

Descarté la primera versión de lo que había hecho. La segunda, pensaba descartarla también diciéndome "será mucho mejor, pero al menos aprenderé cosas". Y luego la segunda la conservé — todavía funciona. Y fui iterando sobre ella para llegar a una tercera versión, la que describo en el artículo anterior.

Haz evolucionar, no saltes etapas

Estoy en la tercera versión de mi sistema. Acabo de convertir los últimos elementos de la V2 hacia la V3. Y quizás algún día tendré una V4, aún más compleja, pero que aporte aún más valor.

Pero hay que ser pragmático. Se hace una evolución de versión porque las necesidades son crecientes — no solo porque apetezca. De lo contrario, es sobreingeniería.

El camino es: un archivo → unas directrices → un desglose → un glosario → un sistema. Cada paso responde a un problema concreto. No se pasa al siguiente hasta que el anterior ya no es suficiente. Y en cada paso, se tiene algo que funciona.

Empieza con un archivo. Ya verás cuándo hay que dividirlo.

Para saber más

El PM como arquitecto del Contexto Añadir una memoria de sesión como en OpenClaw