Comienza por aquí — Configuración esencial para Clauderetoma cualquier proyecto en un mensaje, deja de pagar por el chat de ayer y monta el workspace y el hub que lo sostienen

01 el punto de partida

Qué es y por qué existe

Claude Code ya tiene memoria propia (CLAUDE.md y su carpeta de memoria), pero está pensada para reglas estables: cómo te gusta el código, qué stack usas. No está pensada para el estado cambiante de un proyecto: qué hiciste el martes, qué decidiste el miércoles, qué falta para el viernes. Eso es lo que resuelve STATE.md.

02 antes de instalar nada

Lo que Claude Code ya trae y por qué no alcanza

Claude Code guarda cada conversación en disco y te da varias formas de volver a ella. Conviene conocerlas porque el sistema de esta guía no las sustituye: las usa donde sirven y las evita donde cobran de más.

El detalle que importa: si reabres una conversación grande después de más o menos una hora, Claude Code te ofrece retomarla desde un resumen o completa. Ninguna de las dos es gratis: la caché ya expiró y la primera petición reprocesa todo el historial. Por eso el estado vive en un archivo de unas cuantas líneas y no en el transcript de 600 mil tokens.

03 el dato que lo justifica

Lo que cuesta no cerrar

Antes de escribir el sistema medí dos semanas de uso real. El resultado fue lo que decidió el diseño del comando de cierre:

• 14 conversaciones que se estiraron más de 48 horas se llevaron el 83% del consumo semanal, con solo 2 a 7 horas de trabajo real cada una.
• Retomar una conversación tras una pausa larga obliga a regrabar el contexto completo en caché: más de mil regrabaciones en el periodo, un 25% del ciclo.
• Una conversación de 620 mil tokens retomada al día siguiente cuesta alrededor de 1.5 millones de unidades antes de leer la primera palabra nueva.

La conclusión fue incómoda pero simple: guardar el estado no sirve de nada si después sigues escribiendo en el mismo chat. Por eso /cerrar-sesion no solo guarda: termina su respuesta con un bloque que te dice, literal, que cierres la conversación.

04 el archivo

El formato de STATE.md

El formato es fijo a propósito. Si cada sesión se escribe igual, el comando de inicio siempre sabe dónde buscar 'lo hecho', 'pendientes' y 'próximo paso'. Este es el bloque que se prepende en cada cierre:

## Última sesión — 2026-08-27 — Buscador del Lab con filtros

**Lab en producción con buscador, filtros por tipo y nivel y la primera guía publicada.**

### Lo hecho hoy
- Motor de búsqueda client-side sobre título, resumen, tags y herramientas
- Plantilla de guía con índice lateral, bloques de comando y FAQ
- Primera guía publicada: inicio y cierre de sesión

### Decisiones tomadas
- Guías como archivos TypeScript tipados, no markdown: la plantilla es fija y así el editor valida cada bloque

### Bugs conocidos
- El contador de resultados no se anuncia a lectores de pantalla (pendiente aria-live)

### Pendientes — orden de prioridad

#### 🔴 P0 — Bloqueante
- Publicar sitemap con las guías nuevas

#### 🟡 P1 — Esta semana
- Segunda y tercera guía

#### 🟢 P2 — Post-launch
- Negociación de contenido markdown para agentes

### Próximo paso para retomar
Escribir la guía del MCP de GHL con la plantilla ya validada.

---

Tres reglas que hacen que funcione: la sesión nueva siempre va arriba (lo primero que se lee es lo más reciente); los pendientes llevan prioridad explícita (P0 bloqueante, P1 esta semana, P2 después); y el 'próximo paso' es una sola frase accionable, no una lista.

05 para no confundirlas

Tres memorias que se parecen y no son la misma

Cuando la gente instala este sistema, la duda que más se repite es si STATE.md choca con la memoria que Claude Code ya lleva solo. No choca, pero hay que tener claro quién escribe cada una, dónde vive y si viaja con el repo:

• De la memoria automática solo se cargan las primeras 200 líneas (o 25 KB) del índice; el resto lo lee Claude bajo demanda. No es un lugar para pendientes ordenados.
• La memoria automática es por repositorio y se comparte entre todos los worktrees del mismo repo, pero no entre computadoras. STATE.md sí llega a la otra máquina porque va en el push.
• Los subagentes no ven la memoria automática de la conversación principal ni la conversación. Si un subagente necesita saber en qué va el proyecto, pásale la ruta de STATE.md en el prompt.
• Un CLAUDE.md largo reduce la obediencia a sus propias reglas. Si un dato cambia cada semana, no es de CLAUDE.md: es de STATE.md.

06 comando 1

/iniciar-sesion, paso a paso

Los slash-commands propios de Claude Code son archivos markdown en ~/.claude/commands/ (globales) o en .claude/commands/ del proyecto. El nombre del archivo es el nombre del comando. Crea el archivo y pega el contenido:

mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/davidiriza-lab/sesiones-claude-code/main/commands/iniciar-sesion.md -o ~/.claude/commands/iniciar-sesion.md && curl -fsSL https://raw.githubusercontent.com/davidiriza-lab/sesiones-claude-code/main/commands/cerrar-sesion.md -o ~/.claude/commands/cerrar-sesion.md

mkdir -p ~/.claude/commands && touch ~/.claude/commands/iniciar-sesion.md

---
description: Carga el contexto de un proyecto (lee STATE.md) para retomar donde se dejó. Acepta el nombre del proyecto como argumento o lista los disponibles.
---

# /iniciar-sesion [proyecto]

## Paso 0 — Exigir conversación limpia
Este comando reconstruye el contexto DESDE STATE.md. Si esta conversación ya trae
trabajo previo (otro tema, otro proyecto, una sesión ya cerrada), NO cargues nada.
Responde solo esto y espera:

  ⛔ Esta conversación ya viene cargada.
  Escribe /clear y vuelve a lanzar /iniciar-sesion [proyecto].

Si el usuario responde que quiere continuar aquí, hazlo sin insistir.

## Paso 1 — Resolver el proyecto
- Con argumento: busca la carpeta en ~/proyectos/[argumento]; acepta coincidencia parcial;
  si hay ambigüedad muestra opciones.
- Sin argumento: si el directorio actual está dentro de ~/proyectos/, úsalo.
  Si no, lista las carpetas de ~/proyectos/ numeradas y pregunta cuál.

## Paso 2 — Cargar contexto
1. Lee STATE.md y extrae la sección "Última sesión" (la primera del archivo).
2. Complementa con git: últimos 3 commits y archivos con cambios sin commitear.
3. Revisa trabajo externo: `git fetch origin --quiet` y lee `git status -sb`.
   - behind N con copia local limpia → `git pull --ff-only` y resume qué llegó (por tema).
   - behind N con cambios propios → NO hagas pull; repórtalo en "Antes de empezar".
   - ahead N → hay commits sin subir; repórtalo.
4. Health check (reporta SOLO si algo falla):
   - package.json sin node_modules → "instalar deps con npm install"
   - .env.example sin .env.local → "faltan variables de entorno locales"
   - .next/ más viejo que el último commit → "build cache viejo"
   - requirements.txt sin venv → "instalar deps de Python"
5. Presenta el resumen con ESTE formato:

**Proyecto:** [nombre]
**Última sesión:** [fecha del STATE.md, o "primera sesión"]
**Cambios externos traídos:** [solo si hubo pull]
**Lo hecho:** [2-3 bullets de la última sesión]
**Pendientes:** 🔴 P0 / 🟡 P1 / 🟢 P2
**Próximo paso:** [frase exacta del campo "Próximo paso para retomar"]
**⚠️ Antes de empezar:** [solo si el health check detectó algo]
**¿Por dónde empezamos?**

6. Si no existe STATE.md, créalo con el encabezado y una "Sesión 1" vacía,
   y pregunta qué estamos construyendo.

Sobre el formato del archivo: Claude Code fusionó los comandos con las skills. Un archivo en ~/.claude/commands/nombre.md y una carpeta en ~/.claude/skills/nombre/SKILL.md producen el mismo /nombre y aceptan el mismo frontmatter. Los archivos de commands siguen funcionando; si algún día quieres adjuntar scripts o plantillas al comando, muévelo a skills. Dos campos de frontmatter que valen la pena aquí: argument-hint: [proyecto] para que el autocompletado te recuerde el argumento, y disable-model-invocation: true en el comando de cierre, para que solo lo dispares tú y Claude no decida cerrar por su cuenta.

07 comando 2

/cerrar-sesion, paso a paso

touch ~/.claude/commands/cerrar-sesion.md

---
description: Cierra la sesión guardando el resumen en STATE.md del proyecto activo, hace commit y push, y termina la conversación.
---

# /cerrar-sesion

1. Detecta el proyecto activo: el git root del directorio actual (o el directorio si no hay git).

2. Genera el resumen de la sesión y PREPÉNDELO en STATE.md (después del encabezado,
   antes de las sesiones anteriores) con esta estructura exacta:

   ## Última sesión — YYYY-MM-DD — [título corto del foco]
   **[Una frase en negrita con el logro principal o el estado al cerrar.]**
   ### Lo hecho hoy            (bullets concretos: qué archivo, qué endpoint, qué componente)
   ### Decisiones tomadas      (con su razón; omitir si no hubo)
   ### Bugs conocidos          (con workaround si existe; omitir si no hay)
   ### Pendientes — orden de prioridad
   #### 🔴 P0 — Bloqueante
   #### 🟡 P1 — Esta semana
   #### 🟢 P2 — Post-launch
   ### Próximo paso para retomar
   [Una frase que diga exactamente por dónde arrancar la próxima vez.]
   ---

3. Si STATE.md no existe, créalo con este encabezado antes del resumen:
   # STATE.md — [nombre del proyecto]
   > Bookmark técnico de continuidad. Léelo al inicio de cada sesión y actualízalo al cierre.
   ---

4. Commit: `git add STATE.md && git commit -m "chore: cerrar sesión YYYY-MM-DD"`

5. Push con conciliación:
   - `git fetch origin --quiet` y lee `git status -sb`.
   - Sin "behind" → `git push`.
   - Con "behind" → `git pull --rebase`; si no hay conflictos, push y menciona en una línea
     qué llegó de fuera. Si hay conflictos, `git rebase --abort`, NO fuerces nada,
     reporta los archivos y deja la conciliación para la próxima sesión.
   - Sin remote o push fallido → avisa en una línea y continúa. Nunca abortes el cierre por esto.

6. Confirma: fecha, foco de la sesión y el próximo paso guardado.

7. CIERRE REAL — no es opcional. Termina SIEMPRE tu respuesta con este bloque, literal
   y como último elemento:

   ───────────────────────────────
   ⛔ CIERRA ESTA CONVERSACIÓN AHORA
   El STATE.md ya está guardado y commiteado. Todo lo de hoy está a salvo.
   →  Escribe /clear (o abre un chat nuevo)
   Mañana: /iniciar-sesion [proyecto] reconstruye todo desde STATE.md.
   Seguir escribiendo aquí arrastra el contexto de hoy y lo cobra otra vez.
   ───────────────────────────────

8. Si el usuario sigue escribiendo en esta conversación después del cierre, recuérdaselo
   en UNA línea antes de responder. Una vez por mensaje, sin bloquear. Si pide continuar
   aquí explícitamente, deja de avisar.

Fíjate en el paso 5: el cierre nunca se aborta por un problema de git. Si el push falla, se avisa en una línea y se sigue. El estado ya está en el archivo; subirlo es deseable, no bloqueante.

08 el día a día

Cómo se ve un día con el sistema

1. Abres Claude Code en un chat limpio y escribes /iniciar-sesion nombre-del-proyecto.
2. Lees el resumen: lo hecho, pendientes por prioridad, próximo paso y, si aplica, qué llegó de fuera o qué hay que instalar.
3. Trabajas normal. Todo lo que decidas o descubras, el comando de cierre lo va a capturar de la conversación.
4. Al terminar escribes /cerrar-sesion. Revisas que el resumen sea fiel (dos segundos) y ves el bloque de cierre.
5. Escribes /clear. Mañana repites desde el paso 1 con cero contexto arrastrado.

El único hábito nuevo es el paso 5. Todo lo demás lo hacen los comandos.

09 cuando no trabajas solo

Dos máquinas, dos personas o dos asistentes

El sistema asume que el repo puede cambiar fuera de tu sesión: desde otra computadora tuya, desde un colaborador, o desde otro asistente de IA que trabaje el mismo proyecto. Tres reglas lo mantienen sano:

• Al arrancar, siempre fetch. Si hay commits nuevos y tu copia está limpia, se traen solos y el resumen te dice qué llegó. Si tu copia tiene cambios propios, no se hace pull automático: se te avisa y decides.
• Al cerrar, siempre rebase antes de push. Si hay conflicto, se aborta el rebase y se reporta. Nunca un push forzado.
• Cada asistente escribe solo en su bitácora. Si además de Claude usas otro asistente, dale su propio archivo de estado (por ejemplo OTRO_STATE.md) y pon en ambos comandos la regla de leerlo como contexto secundario y nunca escribirlo.

10 dónde vive cada cosa

Una carpeta por proyecto, y el hub aparte

El sistema da por hecho algo que conviene decir en voz alta: cada proyecto es una carpeta propia, con su propio repo de git y su propio STATE.md. Ni subcarpetas dentro de un repo grande, ni proyectos metidos dentro de la carpeta desde la que arranca Claude. Yo lo aprendí al revés. En abril mis proyectos vivían dentro del hub, en Claude_Dashboard/proyectos/productos/ y /flujos/, todos bajo el mismo repo. En mayo los saqué a ~/proyectos/, uno por carpeta, y ahí siguen.

• /cerrar-sesion escribe en el STATE.md del git root. Si el proyecto no tiene .git propio, el git root es el hub, y la sesión del proyecto cae en el archivo equivocado, mezclada con todo lo demás. Al día siguiente /iniciar-sesion no encuentra nada que leer.
• Un repo dentro de otro repo confunde a git: el de afuera lo trata como carpeta rara o como submódulo, y cada push del hub arrastra o ignora el de adentro según cómo se hizo el add.
• El health check busca package.json, node_modules y .env.local en la raíz del proyecto. Con carpetas anidadas revisa la carpeta equivocada y te avisa de cosas que no faltan.
• GitHub y Vercel esperan un repo por proyecto. Un monorepo casero de veinte landings es una fábrica de builds rotos y de variables de entorno cruzadas.
• Las capturas, PDFs y videos que se acumulan trabajando terminan dentro del repo de código. A mí me pasó hasta con el hub: dejó de subir por archivos de más de 100 MB. Ese material vive fuera, en una carpeta por proyecto dentro de Descargas.

~/
├── Claude_Dashboard/        el hub: un repo, sin código de proyectos
│   ├── STATE.md             sesiones que no son de ningún proyecto
│   ├── STACK.md             registro global de lo instalado y conectado
│   └── docs/  VOZ.md  ...
├── proyectos/               una carpeta = un repo = un STATE.md
│   ├── sitio-web/
│   ├── landing-cliente-x/
│   ├── crm-interno/
│   └── ...
└── Workspace/               vistas por organización, hechas solo de symlinks
    ├── 🔵 Personal/
    ├── 🟠 Empresa/
    └── 🟣 Cliente grande/

11 en un mensaje

Protocolo de proyecto nuevo

/iniciar-sesion tiene un tercer camino además de leer STATE.md o listar los proyectos: cuando la carpeta no existe, o existe sin STATE.md, entra en protocolo de proyecto nuevo. Hace una sola pregunta y de la respuesta infiere ruta, cuenta de GitHub, stack, base de datos y despliegue.

¿Qué estamos construyendo?

1. Landing de cliente    → ~/Clientes/[cliente]/[nombre] · org de la empresa · Next.js · Supabase · Vercel
2. Landing o embudo propio → ~/proyectos/[nombre] · cuenta personal · Next.js · Supabase · Vercel
3. SaaS o app propia     → ~/proyectos/[nombre] · cuenta personal · Next.js · Supabase · Vercel
4. Dashboard interno     → ~/proyectos/[nombre] · cuenta personal · Next.js + Supabase · acceso con contraseña
5. Script o herramienta  → ~/proyectos/[nombre] · cuenta personal · sin DB · sin deploy
6. Otro                  → pregunta solo lo que no pueda inferir

Si es de cliente, pide además el nombre del cliente para la carpeta.

Lo que hace con esa respuesta, sin más preguntas

1. Crea la carpeta en la ruta que corresponde al tipo.
2. git init dentro de la carpeta.
3. Crea el repo privado en GitHub con gh repo create, en la cuenta personal o en la de la empresa. Si no queda claro por el tipo, esa es la única pregunta extra.
4. Conecta el remote.
5. Escribe STATE.md con tipo, stack, repo, deploy y base de datos, y una Sesión 1 que dice 'proyecto creado desde cero'.
6. Si es de cliente, deja un CLAUDE.md mínimo en la carpeta del cliente con el nombre del proyecto y el repo.
7. Anota el proyecto en el STACK.md del hub.
8. git add, commit 'init: [nombre]' y push -u origin main.

# [nombre-proyecto]

**Tipo:** [landing de cliente / landing propia / SaaS / dashboard / script]
**Stack:** [Next.js + Supabase / Node.js / ...]
**Repo:** [URL del repo recién creado]
**Deploy:** [Vercel / sin deploy]
**DB:** [Supabase / ninguna]

---

## Sesión 1 — [fecha]

**Lo hecho:**
- Proyecto creado desde cero

**Pendientes:**
🔴 P0: definir primer paso real

**Próximo paso para retomar:** definir estructura inicial

Lo que evita es la pregunta de '¿esto está en GitHub?' tres semanas después. Cuando hice inventario por primera vez tenía diez proyectos sin repo. Desde que el protocolo existe, ninguno arranca sin remote, y el resumen de la primera sesión ya tiene el formato que el comando de inicio va a leer mañana.

12 para no perderse

Vistas por organización: symlinks y un workspace de VS Code

Sesenta carpetas planas en ~/proyectos/ se vuelven ilegibles. Y agruparlas en subcarpetas por cliente rompe la ruta plana que los comandos esperan (~/proyectos/[nombre]). Lo que hago: la carpeta real no se mueve nunca; encima hay una capa de vistas hechas solo de enlaces simbólicos.

• ~/Workspace/ tiene una carpeta por organización: personal, empresa, el cliente grande, utilidades.
• Dentro, cada proyecto es un symlink al directorio real de ~/proyectos/, con un nombre corto y, si quieres, un emoji. 'synergy-axis' en el disco se ve como '🛰️ Synergy Axis' en la vista.
• git no ve los symlinks: los repos siguen viviendo en ~/proyectos/. Mover, renombrar o borrar una vista no toca ningún repo.
• Un mismo proyecto puede aparecer en dos vistas si sirve a dos organizaciones.

mkdir -p ~/Workspace/"🟠 Empresa"
ln -s ~/proyectos/landing-cliente-x ~/Workspace/"🟠 Empresa"/"Landing Cliente X"

Sobre las vistas va un workspace multi-raíz de VS Code: un archivo .code-workspace que abre el hub y las vistas en una sola ventana, con nombre propio para cada raíz y ajustes que aplican a todas. Con files.exclude escondes node_modules, .git y .next de todos los proyectos a la vez.

{
  "folders": [
    { "name": "⚡ Hub",          "path": "Claude_Dashboard" },
    { "name": "🔵 Personal",     "path": "Workspace/🔵 Personal" },
    { "name": "🟠 Empresa",      "path": "Workspace/🟠 Empresa" },
    { "name": "🟣 Cliente grande", "path": "Workspace/🟣 Cliente grande" },
    { "name": "⚙️ Utilidades",   "path": "Workspace/⚙️ Utilidades" }
  ],
  "settings": {
    "explorer.sortOrder": "default",
    "files.exclude": {
      "**/node_modules": true,
      "**/.git": true,
      "**/.DS_Store": true,
      "**/.next": true,
      "**/venv": true,
      "**/__pycache__": true,
      "**/*.tsbuildinfo": true
    }
  }
}

• El hub va primero en la lista de carpetas. La extensión de Claude Code para VS Code arranca con esa raíz como directorio principal, que es justo lo que el sistema quiere.
• En un workspace multi-raíz el directorio de trabajo de Claude sigue a la carpeta del archivo que tienes abierto. Lo veo en mis sesiones: abro un archivo del sitio y el directorio principal salta del hub al proyecto; vuelvo a un archivo del hub y regresa. Como /cerrar-sesion detecta el proyecto por el git root del directorio actual, antes de cerrar conviene tener abierto un archivo del proyecto correcto, o pedir el cierre nombrando el proyecto.
• Si renombras una carpeta real, el symlink queda roto. Regenera la vista con el script; no muevas la carpeta a la vista.

13 el centro

El Dashboard: el hub desde donde arranca todo

Todas mis sesiones de Claude Code arrancan desde la misma carpeta, Claude_Dashboard, y desde ahí saltan al proyecto con /iniciar-sesion. No es costumbre: hay razones técnicas.

Qué vive en el hub

Qué no vive en el hub

• Código de proyectos. Cada uno en ~/proyectos/ con su repo.
• Imágenes, videos, PDFs y material de clientes. Van a Descargas en una carpeta por proyecto, o a la carpeta del cliente. Si entran al repo del hub, tarde o temprano un archivo grande te bloquea el push.
• Secretos. Las credenciales viven en el .env.local de cada proyecto o en un repo aparte cifrado con git-crypt; nunca en STATE.md ni en STACK.md.

La memoria y la configuración también se respaldan

La memoria automática vive fuera de cualquier repo. Para no perderla, cada tanto se copia a ~/.claude/memory/, que es un repo privado junto con el CLAUDE.md global, los comandos y las skills. Y el hub guarda un MIGRACION_MAC.md con qué repos clonar, qué credenciales restaurar y qué verificar. Cambiar de máquina se vuelve seguir una lista, no reconstruir de memoria.

14 de cero

Instalar todo de cero: pídeselo a Claude

Si vienes sin nada, no hace falta seguir las secciones anteriores a mano. En el repo hay un INSTALAR.md escrito para que lo lea Claude Code: pega el encargo de abajo, Claude te hace una sola pregunta y deja instalado lo que elijas. No pide tokens, no instala dependencias y no sobrescribe ningún archivo tuyo sin preguntar.

Lee https://raw.githubusercontent.com/davidiriza-lab/sesiones-claude-code/main/INSTALAR.md y sigue sus instrucciones al pie de la letra. Antes de tocar nada, hazme la pregunta de qué quiero instalar y espera mi respuesta.

• Si ya tienes un ~/.claude/CLAUDE.md, no lo reemplaza: pregunta si agrega las reglas al final del tuyo.
• Si ya tienes ~/.claude/settings.json, guarda una copia .bak, fusiona additionalDirectories con lo que ya había y valida que el resultado siga siendo JSON.
• Al terminar imprime qué quedó hecho, qué saltó y por qué, y los tres pasos siguientes: reiniciar Claude Code, abrir el workspace en VS Code y correr /iniciar-sesion con tu primer proyecto.

15 la trampa nueva

Worktrees y la app de escritorio

Hay un caso donde el sistema falla en silencio si no lo sabes: los worktrees. Claude Code puede abrir cada sesión en una copia aparte del repo (claude --worktree nombre, o pidiéndoselo en el chat), y la app de escritorio lo hace sola: cada sesión nueva del sidebar es su propio worktree. Esa copia vive en .claude/worktrees/<nombre>/ y trabaja sobre una rama nueva llamada worktree-<nombre>.

• Si corres /cerrar-sesion dentro de un worktree, el commit de STATE.md cae en la rama worktree-<nombre>, no en main. Mañana, desde la copia principal, /iniciar-sesion va a leer un STATE.md viejo.
• Dos sesiones en paralelo son dos copias del mismo STATE.md. La segunda que cierre no ve lo que escribió la primera hasta que alguien fusione las ramas.
• El worktree arranca sin los archivos ignorados por git. Tu .env.local no está ahí, y el health check lo va a marcar. Para que se copie solo, crea un archivo .worktreeinclude en la raíz con la lista de esos archivos.
• Al salir, Claude Code borra el worktree si está limpio; si tiene cambios te pregunta. Si eliges borrar, se va también la rama con el cierre.

.env
.env.local

Mi regla: cierro sesión desde la copia principal, o mergeo la rama del worktree antes de cerrar. Y en el comando de cierre conviene una línea que detecte si el directorio está dentro de .claude/worktrees/ y lo avise en el mensaje final. Agrega .claude/worktrees/ al .gitignore para que no te aparezca como carpeta sin rastrear.

16 dentro del día

Gastar menos ventana mientras trabajas

Cerrar bien resuelve el costo entre días. El costo dentro del día lo resuelven cuatro hábitos que no requieren instalar nada, y una herramienta que sí:

La herramienta es context-mode, un plugin para Claude Code que corre los comandos pesados en un sandbox e indexa los resultados para que Claude busque en ellos en vez de cargarlos completos. Lo instalé y probé su diagnóstico: registra hooks de SessionStart, PreCompact y Stop, más una decena de herramientas MCP. Su autor promete reducciones muy altas de contexto; yo no medí ese número, así que tómalo como promesa del proyecto y no como dato mío. Licencia Elastic 2.0, no MIT: gratis para uso normal, con restricciones si quieres revenderlo como servicio.

/plugin marketplace add mksglu/context-mode
/plugin install context-mode@context-mode

17 para exprimirlo

Ajustes que valen la pena

Hook SessionStart: que el estado llegue solo

Los hooks son scripts que Claude Code ejecuta en momentos fijos, y a diferencia de una instrucción en CLAUDE.md no dependen de que Claude decida obedecer. El de SessionStart tiene una propiedad que aquí es oro: lo que el script imprime se agrega al contexto de Claude. Con esto, el encabezado de STATE.md y el estado de git entran a la conversación antes de tu primer mensaje, sin gastar un turno en leerlos:

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "startup|clear",
        "hooks": [
          {
            "type": "command",
            "command": "cd \"$CLAUDE_PROJECT_DIR\" && [ -f STATE.md ] && { echo '## STATE.md (última sesión)'; sed -n '1,40p' STATE.md; echo; echo '## git'; git status -sb 2>/dev/null | head -5; }"
          }
        ]
      }
    ]
  }
}

• El matcher startup|clear lo dispara al abrir Claude Code y después de cada /clear, que es exactamente cuando arrancas limpio. No lo pongas en resume ni en compact: ahí ya hay contexto.
• No reemplaza a /iniciar-sesion. El hook mete el texto crudo; el comando hace el fetch, el health check y te presenta el resumen con formato. Con el hook, el comando arranca con la mitad del trabajo hecho.
• Si el hook vive en .claude/settings.json del repo, quien clone el proyecto lo hereda. Si prefieres que sea solo tuyo, va en ~/.claude/settings.json.
• Dentro de un worktree, $CLAUDE_PROJECT_DIR sigue apuntando a la copia principal. Si quieres el STATE.md del worktree, lee el campo cwd del JSON que el hook recibe por stdin.