Cómo organizo mi workspace de Claude para manejar 12 proyectos sin confundirme (ni gastar tokens de más)

El problema: Claude no recuerda entre sesiones

Esto es fundamental entenderlo. Claude no tiene memoria entre conversaciones. Cada vez que abres una sesión nueva, empieza desde cero.

Lo que sí persiste entre sesiones es lo que tú le das al inicio: el archivo CLAUDE.md. Claude Code (la versión terminal) lo lee automáticamente en el directorio donde lo abres, subiendo por la jerarquía de carpetas. Si está bien estructurado, Claude ya sabe quién eres, en qué proyecto estás y cómo trabajar — sin que tengas que explicarlo cada vez.

El problema es que yo tenía un CLAUDE.md de 597 líneas que se cargaba completo en cada sesión, sin importar si iba a hacer SEO, escribir un email o revisar un servidor. Eso son aproximadamente 5,000 tokens de contexto fijo en cada turno de conversación.

En una sesión larga de 40 turnos: 200,000 tokens extra de arrastre. Innecesarios.

Lo que encontré cuando auditué mi directorio

Antes de construir la solución, hice una auditoría completa de mi workspace de agencia. Esto es lo que encontré:

Duplicación activa. Había iniciado una migración de archivos que quedó a medias. El mismo contenido existía en dos rutas distintas, sin que ninguna fuera claramente la fuente de verdad.

Dos CLAUDE.md con información contradictoria. El principal tenía la paleta de colores correcta y actualizada. Una copia en una subcarpeta tenía la paleta anterior, ya descontinuada. Si abría Claude desde esa subcarpeta, generaba código con colores que ya no uso.

Proyectos sin contexto propio. Cada cliente tenía su carpeta de trabajo, pero ningún archivo le decía a Claude quién era ese cliente. Cada sesión nueva empezaba re-explicando lo mismo: nombre del negocio, colores, tono.

Sin tablero de estado. No existía ningún archivo que dijera qué proyectos estaban activos, pausados o pendientes de deploy. Esa información vivía solo en mi cabeza.

La solución: arquitectura de tres capas

Lo que construí se basa en una idea simple: el directorio desde donde abres Claude determina el contexto que recibe.

Capa 1 — Identidad global (siempre activa). Un CLAUDE.md en el directorio home, de 30 líneas máximo: quién soy, la agencia, el workspace principal. Se carga en cualquier sesión, en cualquier directorio.

Capa 2 — Sistema de agencia (carga base mínima). El CLAUDE.md principal, reducido de 597 a 80 líneas. Solo lo que se necesita en toda sesión: identidad, colores vigentes, reglas inamovibles, CTA, tipografía, prioridades de desarrollo y un mapa de dónde está cada cosa. Lo que no está ahí — el SVG completo de un botón, reglas detalladas de WordPress, la escala tipográfica extendida — vive en archivos de skills que se cargan on-demand cuando realmente se necesitan.

Capa 3 — Contexto por proyecto (carga automática al abrir desde esa carpeta). Cada proyecto tiene su propio CLAUDE.md de máximo 30 líneas: cliente, marca, estado actual, stack técnico. Al abrir Claude desde la carpeta de ese proyecto, recibe automáticamente el CLAUDE.md raíz más el del proyecto — contexto enfocado, sin ruido de los otros 11 proyectos.

El tablero de estado maestro

Uno de los cambios con más impacto inmediato fue crear un STATUS.md centralizado: tablas simples por categoría (clientes, marcas propias, audiovisual, libros) con estado y próxima acción de cada proyecto.

Al inicio de cualquier sesión general, basta con pedirle a Claude que lea ese archivo. En dos segundos tiene el panorama completo — no tengo que explicar en qué va cada proyecto.

Cómo se usa en la práctica

# Trabajo en un cliente:
cd proyectos/clientes/nombre-cliente
claude
# Claude ya sabe: quién soy, la agencia, el cliente, el estado

# Necesito una landing page:
"Lee _system/skills/landing-premium.md antes de empezar"
# Carga el protocolo específico on-demand

# Revisión general del ecosistema:
cd ~/AI/DigitalGlowAgency
claude
"Lee _system/STATUS.md"
# Panorama completo en segundos

Cada terminal que abro está naturalmente aislada al proyecto de esa carpeta. No hay contaminación de contexto entre clientes.

El componente financiero: trackear tiempo y tokens

Uso un script propio que al terminar una sesión calcula cuántos tokens se usaron y cuánto costaron, combinado con el tiempo real de trabajo. El resultado: un registro con fecha, cliente, tipo de trabajo, tokens, costo en USD, duración en horas y precio sugerido.

Con eso puedo calcular el costo real de cada tipo de trabajo. Un sitio web completo puede costar $2.40 USD en tokens pero 8 horas de trabajo. Una automatización puede costar $0.80 USD en tokens pero 4 horas. Eso cambia cómo cotizo.

Lo que también apliqué: MarkItDown para documentos

MarkItDown es una librería de Microsoft que convierte PDFs, Word, Excel y HTML a Markdown limpio. Cuando un cliente me manda un brief en PDF, o descargo un reporte de Google Ads, en lugar de subir el PDF completo (8,000-12,000 tokens), primero lo convierto a Markdown — el resultado es un archivo de ~800 tokens que Claude lee en milisegundos y que se puede versionar. Cualquier documento que Claude necesite leer más de una vez pasa por este proceso antes de almacenarse.

Los números reales

Tokens base por sesión: de ~5,000 a ~700. Tokens extra en una sesión larga de 40 turnos: de ~200,000 a ~28,000. Tiempo re-explicando contexto: de 5-10 minutos por sesión a cero. Riesgo de confundir proyectos: de alto (12 proyectos, un solo CLAUDE.md) a prácticamente nulo.

El ahorro de tokens en dinero no es enorme — unos pocos dólares al mes. Lo que sí cambia es la velocidad operativa y la eliminación de errores por contexto equivocado.

Tres principios detrás de esto

El directorio como contexto. No le explicas a Claude en qué proyecto estás — se lo dice el directorio desde donde abres la sesión.

Carga mínima, expansión on-demand. El contexto base es mínimo. Skills, templates y design system completo se cargan solo cuando la tarea los requiere.

El estado vive en el repositorio. No en tu cabeza, no en conversaciones pasadas. En archivos Markdown que cualquier sesión nueva puede leer al arrancar.