Instalación rápida: un Claude estructurado

El mapa: cómo es un Claude estructurado

Recién instalado, Claude Code es un amnésico brillante. Cada sesión empieza de cero: sin memoria de tus proyectos, sin conocimiento de tus reglas, sin lecciones acumuladas. Todo lo que le enseñaste ayer desaparece esta mañana. Este módulo soluciona eso. Es una guía práctica de montaje: al final, tendrás un Claude estructurado, uno que recuerda, sigue tus reglas, mejora con el tiempo y se mantiene solo. Calcula alrededor de una hora de configuración.

Un Claude estructurado se compone de siete elementos, cada uno cubierto por una lección de este módulo:

• El motor: Claude Code en sí, instalado y con sesión iniciada (próxima lección).
• La constitución: un archivo global CLAUDE.md con tus reglas absolutas, cargado al inicio de cada sesión.
• La memoria: una carpeta de notas Markdown que Claude lee y escribe entre sesiones, abierta en Obsidian para que puedas ver y navegar ese mismo conocimiento como un grafo.
• El transporte: la carpeta de memoria versionada con git, de modo que tu cerebro queda respaldado y sincronizado entre máquinas (incluido un teléfono).
• Los reflejos: hooks, pequeños scripts que se ejecutan automáticamente en eventos del ciclo de vida (inicio de sesión, fin de sesión, después de cada turno) y mantienen la memoria sincronizada sin que tengas que pensarlo.
• Las capacidades: skills, paquetes de experiencia instalables. Instalaremos dos colecciones acreditadas, ECC (everything-claude-code) y superpowers, y aprenderemos a seleccionar en vez de acumular.
• El pulso: tareas programadas que ejecutan una consolidación nocturna y semanal, para que la estructura se mantenga sola incluso mientras duermes.

Por qué molestarse. Porque el valor de un asistente solo se acumula si su conocimiento también lo hace. Un Claude sin estructurar te resuelve el mismo problema dos veces y comete el mismo error dos veces. Un Claude estructurado anota la lección la primera vez, la enlaza con lecciones relacionadas y la recupera en el contexto correcto el mes siguiente. La diferencia tras tres meses de uso diario no es sutil: todo este curso se construyó con (y es en gran parte producto de) exactamente la configuración que estás a punto de instalar.

Este módulo es deliberadamente autónomo. Se solapa con los módulos de profundización sobre cómo extender Claude Code y sobre el segundo cerebro: esos explican el por qué y los detalles internos; este te da el camino ordenado, listo para copiar y pegar. Si un paso te intriga, sigue el enlace a la lección completa. Si solo quieres una configuración funcional hoy mismo, sigue los comandos en orden y vuelve a la teoría más tarde.

Un principio antes de empezar: la estructura vive en archivos, no en el chat. Todo lo que instalamos a continuación es texto plano en tu disco: reglas en Markdown, notas en Markdown, configuración en JSON, scripts pequeños. Nada queda encerrado en una base de datos propietaria, todo es versionable, inspeccionable y portable. Eso es lo que hace duradera esta configuración a través de las versiones de Claude: los archivos sobreviven aunque la herramienta cambie.

Instalar Claude Code e iniciar sesión

Primer componente: el motor. La vía recomendada por Anthropic desde 2026 es el instalador nativo, un binario autocontenido que se actualiza solo y no depende de Node.js en tiempo de ejecución:

• macOS / Linux / WSL: curl -fsSL https://claude.ai/install.sh | bash
• Windows (PowerShell): irm https://claude.ai/install.ps1 | iex

Los gestores de paquetes también funcionan si los prefieres (brew install --cask claude-code, winget install Anthropic.ClaudeCode, o npm install -g @anthropic-ai/claude-code), con una salvedad: las instalaciones vía brew y winget no se autoactualizan, y la vía npm requiere Node.js 22 o superior desde la v2.1.198. En Windows nativo, instala también Git for Windows: le da a Claude Code una herramienta Bash adecuada en lugar de recurrir a PowerShell para todo.

Luego ejecuta claude en una terminal. En el primer arranque se abre un navegador para el inicio de sesión OAuth. Funcionan dos tipos de cuenta, y la distinción importa para tu bolsillo:

• Una suscripción Claude (Pro, Max, Team, Enterprise): el uso queda cubierto por la cuota mensual fija, dentro de los límites de velocidad del plan. El plan gratuito de claude.ai no incluye Claude Code.
• Una cuenta de Claude Console (API): facturación por consumo, por token. Adecuada para equipos con presupuesto de API, peligrosa para un uso personal, porque un día intenso de trabajo agéntico puede costar más que un mes entero de suscripción.

Para una configuración personal estructurada, la vía de suscripción es casi siempre la correcta. Cuidado con una trampa: si la variable de entorno ANTHROPIC_API_KEY está definida, puede tener prioridad sobre tu suscripción y facturarte por token en silencio. Si tienes una clave antigua olvidada en tu perfil de shell, elimínala o limítala a los proyectos que realmente la necesiten.

Verifica la instalación con claude --version, y luego, desde dentro de una sesión, ejecuta /doctor (alias /checkup). Doctor es una skill de diagnóstico integrada que revisa el estado de tu instalación, problemas de PATH, archivos de configuración ilegibles, hooks lentos, e incluso señala skills o servidores MCP sin usar que te consumen contexto de balde. Ejecútalo ahora para confirmar una base limpia, y recuerda que existe: es lo primero que debes correr cuando tu configuración empiece a fallar tras las personalizaciones que vamos a añadir.

Dónde vive todo de aquí en adelante: el directorio ~/.claude/ es tu hogar de Claude. ~/.claude/CLAUDE.md contendrá tus reglas globales (próxima lección), ~/.claude/settings.json tu configuración y hooks, ~/.claude/skills/ tus skills instaladas, y ~/.claude/projects/ los datos por proyecto, incluida la memoria. Cada componente de este módulo es un archivo en algún lugar de este árbol, o referenciado desde él.

Extras opcionales, útiles de conocer pero no bloqueantes: las extensiones de IDE (VS Code, JetBrains) integran el mismo motor en tu editor; las apps de escritorio y web ofrecen sesiones de Claude Code fuera de la terminal; y sí, Claude Code corre de forma nativa en un teléfono Android vía Termux, algo que se vuelve realmente útil una vez que tu memoria está sincronizada por git. El módulo de segundo cerebro tiene una lección dedicada a esa configuración de bolsillo.

Tu CLAUDE.md global: una constitución, no una novela

Segundo componente: la constitución. El archivo ~/.claude/CLAUDE.md se inyecta en cada sesión, en todos los proyectos, con la prioridad de instrucción más fuerte que el harness otorga al contenido del usuario. Es el archivo con mayor apalancamiento de toda tu configuración: una línea aquí cambia el comportamiento de todas las sesiones futuras. Ese apalancamiento funciona en ambos sentidos, así que el archivo debe curarse sin piedad.

Una estructura probada en batalla, refinada durante meses en la configuración del autor del curso:

• Reglas absolutas primero. Los innegociables, expresados como órdenes, justo al principio: prohibiciones de formato, reglas de seguridad (archivar, nunca borrar), cómo se manejan los secretos (variables de entorno, nunca pegados en el chat), y dónde termina la autonomía de Claude (para el autor: los costes externos de pago, las decisiones de seguridad y las decisiones de producto van al humano; todo lo técnico es decisión de Claude).
• Arranque de sesión. Qué debe hacer Claude al comienzo de cada sesión: qué índice de memoria leer, cómo enrutar hacia el contexto de proyecto correcto cuando nombras uno.
• Punteros, no contenido. Una línea por protocolo recurrente, apuntando al archivo que lo posee (una skill, una nota de memoria). El protocolo detallado vive en un único lugar; CLAUDE.md solo enruta hacia él.

El principio del puntero merece énfasis, porque es donde la mayoría de las configuraciones se pudren. Si pegas un protocolo completo en CLAUDE.md y en una skill y en una nota de memoria, las tres copias se distancian en cuestión de semanas y Claude sigue la que leyó por último. La regla: CLAUDE.md es un enrutador. El detalle vive en la skill o nota a la que apunta, y se actualiza solo allí. Esto también mantiene el archivo pequeño, lo cual importa por partida doble: cada byte se carga en el contexto de cada sesión, y una constitución corta es una que Claude realmente sigue. Menos de 5 KB es un buen objetivo; si el tuyo supera los 10 KB, casi con seguridad ha absorbido contenido que pertenece a una skill.

Un esqueleto mínimo para empezar:

# Rules (absolute)
- Never delete: archive to _ARCHIVES/ instead.
- Secrets never in chat: set env vars, verify by length, never echo.
- Technical decisions: decide and execute. Escalate only paid costs,
  security, and product decisions.
- Update the memory after every delivered batch of work.

# Session start
- Read the memory index. When I name a project, load its memory notes
  before acting.

# Protocols (pointers)
- Memory sync protocol: see the sync-memory note.
- New project: attach the code-graph tool, reuse existing patterns first.

Tres detalles operativos. Primero, los cambios se aplican en la siguiente sesión, no en la actual: CLAUDE.md se lee una vez al arrancar, así que prueba tus ediciones abriendo una sesión nueva. Segundo, mantén un archivo de versiones anteriores (una copia fechada en una carpeta de archivo) antes de cualquier reescritura: tu constitución es exactamente el tipo de archivo que algún día querrás revertir. Tercero, si trabajas en Windows con scripts de PowerShell que tocan tus archivos, considera mantener el archivo en ASCII puro: evita toda una clase de corrupción de codificación cuando las herramientas lo reescriben.

Los archivos CLAUDE.md a nivel de proyecto (en la raíz de cada repositorio) se apilan sobre el global y llevan hechos específicos del proyecto: comandos de build, notas de arquitectura, convenciones. Se aplican los mismos principios: corto, imperativo, punteros antes que prosa. El archivo global lleva quién eres y cómo trabajas; el archivo de proyecto lleva qué es este código base.

Conecta Obsidian a la memoria de Claude

Tercer componente: la memoria, y la ventana hacia ella. Claude Code guarda la memoria como notas Markdown planas en una carpeta por proyecto, bajo ~/.claude/projects/<project-slug>/memory/, con un archivo índice, MEMORY.md, que se carga en el contexto al inicio de cada sesión. Esa carpeta es el cerebro. Obsidian es la herramienta gratuita que convierte esa misma carpeta en algo navegable para un humano: backlinks, búsqueda de texto completo y una vista de grafo donde tu conocimiento se hace visible.

El truco de configuración que hace que todo funcione es engañosamente simple: abre la propia carpeta de memoria como tu vault de Obsidian. No una copia, no una exportación, la carpeta misma. Descarga Obsidian desde obsidian.md (gratis, sin necesidad de cuenta; en Windows, winget install Obsidian.Obsidian), elige "Open folder as vault" y apúntalo al directorio de memoria. A partir de ahí hay una única fuente de verdad: lo que ves y editas en Obsidian es exactamente lo que Claude carga y escribe. Sin sincronización, porque no hay nada que sincronizar.

Dentro del vault, tres convenciones mantienen sano el cerebro a medida que crece de diez notas a varios cientos:

• Notas atómicas. Un hecho por nota, con un encabezado frontmatter que lleva un name, una description de una línea (usada para la relevancia en el recall) y un type: ¿es sobre el usuario, una pieza de feedback sobre cómo trabajar, el estado de un proyecto o una referencia externa? Una nota con dos ideas es una nota que no puedes enlazar con precisión.
• Wikilinks por todas partes. Cada nota enlaza a sus notas relacionadas con enlaces [[nombre-de-nota]]. Enlaza con generosidad: el valor del grafo está en las conexiones. Un enlace a una nota que aún no existe no es un error, es una señal de algo que vale la pena escribir.
• Mapas de contenido. Un puñado de notas hub (una convención habitual les pone el prefijo _MOC_) que agrupan enlaces por tema: proyectos, feedbacks, referencias. Más el índice MEMORY.md: una línea por nota con su gancho. La regla de hierro: ninguna nota huérfana. Toda nota nueva recibe una línea en el índice y un enlace desde el hub correspondiente, o nunca se recuperará.

Una sutileza estructural si trabajas en varios proyectos: Claude mantiene una carpeta de memoria separada por directorio de trabajo, así que el conocimiento se fragmenta entre almacenes. La solución en la configuración del autor son los enlaces del sistema de archivos (junctions en Windows, symlinks en otros sistemas): las carpetas de memoria por proyecto se montan como subcarpetas (por ejemplo _projets/<nombre>) dentro del vault único de la carpeta home. Obsidian ve un único cerebro unificado; cada almacén de proyecto permanece físicamente donde Claude lo espera; editar a través del punto de montaje edita el almacén real. Un vault, muchos almacenes, cero copias.

Dos detalles de confort que vale la pena copiar: colorear el grafo por tipo de nota (grupos de grafo de Obsidian: un color para las notas project_, otro para feedback_, otro para reference_), así la forma de tu conocimiento se lee de un vistazo; y mantener el material voluminoso y regenerable (registros de conversaciones exportadas, grafos de código generados) excluido del filtro principal del grafo para que no ahogue la señal.

Eso es todo el truco. No hace falta rebuscar en un mercado de plugins ni pagar por sincronización: una carpeta, abierta por dos programas, cada uno viendo lo que el otro escribe. Las lecciones a fondo anteriores en el módulo del segundo cerebro cubren la mecánica del recall y la disciplina de escritura de notas; la siguiente lección hace que este cerebro sea duradero y portátil con git.

Versiona tu cerebro con git

Cuarto componente: el transporte. Tu bóveda de memoria es ahora el directorio más valioso de tu máquina, y vive en una carpeta oculta que ninguna herramienta de respaldo tiene en cuenta. La solución es la misma que usa el código: convertir la bóveda en un repositorio git con un remoto privado. Ganas historial (cada cambio de nota es un commit que puedes inspeccionar y revertir), respaldo (el remoto sobrevive a tu disco) y sincronización (el mismo cerebro en tu escritorio, tu portátil e incluso tu teléfono).

Antes del primer push, audita en busca de secretos. Este paso no es opcional. Meses de notas de trabajo acumulan exactamente aquello que nunca debe llegar a un remoto: tokens pegados durante una depuración, contraseñas citadas en resúmenes de sesión. Recorre la bóveda buscando los patrones clásicos (sk_live, ghp_, AKIA, cadenas hexadecimales largas, las palabras password y token) y censura los hallazgos reemplazando el valor por un marcador antes de hacer commit. El primer escaneo del autor sobre una bóveda madura encontró una contraseña de administrador de producción alojada en una nota de sesión; asume que la tuya tiene algo equivalente.

Después, delimita qué viaja. Un buen .gitignore por defecto excluye lo voluminoso, lo regenerable o lo arriesgado:

• Registros de conversaciones exportadas (pueden contener cualquier cosa que hayas pegado alguna vez, incluidos secretos),
• Artefactos generados como los grafos de código (regenerables desde la fuente),
• Carpetas de archivo y ficheros de estado del espacio de trabajo de Obsidian.

Las notas atómicas, el índice, las notas carrefour: eso es el cerebro, y eso sí viaja.

El protocolo diario son dos hábitos: pull al inicio de cualquier sesión que vaya a tocar la memoria, commit y push después de cada actualización de memoria, con un mensaje que nombre el tema. Si eso suena a una disciplina que vas a olvidar, tienes razón, por eso la próxima lección automatiza ambos extremos con hooks. Ante conflictos, aplica la regla específica de memoria: nunca sobrescribir, conservar ambas versiones en la nota y señalar la contradicción para revisarla. Un cerebro se fusiona por acumulación, no a la fuerza con un force-push.

La recompensa que sorprende a la gente: el teléfono. Claude Code corre de forma nativa en Android dentro de Termux, y en cuanto tu bóveda es un repositorio git, el teléfono la clona y la monta como su propia memoria de sesión (un enlace simbólico desde ~/.claude/projects/<slug>/memory del teléfono hasta el clon). El Claude de escritorio y el Claude de bolsillo leen y escriben entonces el mismo cerebro, separados por un commit. Una lección dedicada en el módulo de segundo cerebro de este curso recorre esa configuración de bolsillo, trampas incluidas.

Una advertencia para cerrar: un repositorio privado es privado para la cuenta que lo aloja. Trata el remoto de la bóveda con el mismo cuidado que una exportación de gestor de contraseñas: autenticación fuerte en la cuenta, nada de compartir el repositorio a la ligera, y recuerda que censurar antes del commit vale más que borrar después del push, porque el historial de git recuerda lo que subiste incluso después de eliminarlo.

Los hooks que mantienen viva la estructura

Quinto componente: los reflejos. Todo lo instalado hasta ahora depende de hábitos: hacer pull antes de trabajar, actualizar la memoria después de cada lote, hacer push al terminar. Los hábitos se degradan. Los hooks son el mecanismo de Claude Code para convertirlos en automatización: comandos de shell que el propio harness ejecuta en eventos del ciclo de vida. Se configuran en ~/.claude/settings.json (a nivel de usuario) o en el .claude/settings.json de un proyecto, y a mediados de 2026 hay alrededor de treinta eventos disponibles, desde SessionStart y SessionEnd hasta Stop (fin de cada turno del asistente), PreToolUse, PostToolUse y más.

Para una configuración estructurada, dos hooks concentran la mayor parte del valor:

• SessionStart trae el cerebro. Un script que ejecuta git pull --ff-only sobre el vault, con un timeout corto, y que nunca bloquea la sesión si la red falla. Cada sesión arranca con la memoria más reciente, de forma automática.
• SessionEnd (o Stop) lo envía. La imagen especular: hace commit y push de los cambios de memoria al cerrar la sesión, para que nada de lo aprendido quede varado en una sola máquina.

La forma en settings.json:

{
  "hooks": {
    "SessionStart": [{ "hooks": [{ "type": "command",
      "command": "bash ~/.claude/hooks/pull-brain.sh" }] }],
    "SessionEnd": [{ "hooks": [{ "type": "command",
      "command": "bash ~/.claude/hooks/push-brain.sh" }] }]
  }
}

Un patrón más avanzado, tomado de la configuración del autor, resuelve un vacío real: no existe un evento nativo de "sesión inactiva", pero aun así quieres que la memoria se sincronice cuando te alejas a mitad de sesión. La solución es una arquitectura en dos etapas. Etapa uno, un hook global de Stop: después de cada turno del asistente, un script diminuto registra la sesión (id, ruta de la transcripción, directorio de trabajo) en un archivo de pendientes, con un costo de milisegundos. Etapa dos, una tarea programada cada 15 minutos: revisa las sesiones pendientes y, para cualquiera cuya transcripción no haya cambiado en 30 minutos, ejecuta Claude en modo headless contra esa misma sesión (claude -p --resume <session-id> "sync memory...") para que el propio modelo escriba en el vault las lecciones de esa sesión. Las sesiones inactivas guardan su memoria sin que nadie toque el teclado.

La automatización que llama a Claude desde una cadena de hooks necesita guardas anti-bucle, y vale la pena interiorizarlas aunque no copies nada más: las ejecuciones headless fijan una variable de entorno marcadora para que el hook Stop ignore sus propios turnos (de lo contrario, cada sincronización genera registros que generan nuevas sincronizaciones); un archivo de sello registra qué estado ya se sincronizó para que la misma sesión inactiva nunca se procese dos veces; un lock evita ejecuciones solapadas; y unos topes limitan el daño (como máximo dos sincronizaciones por pasada, con timeout duro en cada una). Cualquier hook que pueda disparar aquello que lo disparó a él debe llevar este tipo de guarda.

Notas operativas. Los hooks se cargan al inicio de la sesión: las sesiones ya abiertas cuando editas settings.json no adquieren el hook nuevo hasta que se relanzan. Mantén los hooks rápidos y no bloqueantes: un hook SessionStart lento retrasa cada sesión que vayas a abrir en el futuro (el chequeo de /doctor señala los hooks lentos exactamente por esta razón). Registra los fallos en un lugar visible en vez de fallar de forma ruidosa: los scripts del autor añaden una línea a una nota de alertas en el vault, que aparece en Obsidian, donde un humano realmente la ve. Y trata los hooks como código: se ejecutan sin supervisión y con tus permisos, así que versiónalos junto con el vault.

Skills: instala ECC y superpowers, cura sin piedad

Sexto componente: las capacidades. Las skills son carpetas de instrucciones (un SKILL.md más scripts opcionales) que enseñan a Claude un flujo de trabajo, y el ecosistema a su alrededor ha madurado hasta convertirse en colecciones reales que puedes instalar en minutos. Dos merecen instalarse desde el primer día de una configuración estructurada, y una disciplina evita que se vuelvan contraproducentes.

ECC (everything-claude-code) es la colección curada más grande, obra de Affaan Mustafa, con licencia MIT. Ten en cuenta que el repositorio cambió de nombre en 2026: la dirección canónica ahora es github.com/affaan-m/ECC (la URL antigua de everything-claude-code redirige). Con fecha de julio de 2026 incluye 278 skills, 67 agentes, 34 reglas y un conjunto de automatizaciones por hooks, cubriendo orquestación de agentes, patrones de frontend, testing, flujos de git, análisis de seguridad y mucho más. Instálala como plugin:

/plugin marketplace add https://github.com/affaan-m/ECC
/plugin install ecc@ecc

superpowers, de Jesse Vincent, es la otra pieza clave: no es un montón de capacidades sino una disciplina de proceso. Instala skills de flujo de trabajo que imponen buenos hábitos de ingeniería: brainstorming antes de construir, depuración sistemática antes de parchear, desarrollo guiado por pruebas, verificación antes de dar algo por terminado. Vive en el marketplace oficial de plugins de Anthropic, así que la instalación es un único comando, sin necesidad de añadir el marketplace:

/plugin install superpowers@claude-plugins-official

Su regla central merece adoptarse tal cual: si una skill podría aplicar a la tarea en curso, invócala antes de actuar. Las skills que tienes pero nunca invocas son peso muerto.

Ahora la disciplina: cura, no acumules. Es tentador instalar las 278 skills de ECC. Resiste esa tentación. El nombre y la descripción de cada skill instalada participan en el emparejamiento de skills; cientos de ellas irrelevantes contaminan ese emparejamiento y sobrecargan el contexto. Cuando el autor de este curso integró ECC, se quedó con 67 skills de las 271 que tenía entonces el repositorio: las categorías de orquestación de agentes, frontend, ingeniería, QA y contenido que encajaban con su stack real, y descartó deliberadamente categorías completas (trading de criptomonedas, sanidad HIPAA, cinco stacks de backend que nunca toca). Instala lo que corresponda al trabajo que realmente haces; siempre puedes añadir una skill el día que la necesites. El chequeo /doctor ahora incluso señala las skills sin usar como coste de contexto, lo que indica cuán real es el problema.

Las skills de terceros que provienen de fuentes que no son de renombre merecen una comprobación más: una auditoría antes de instalar. Una skill se ejecuta con los permisos completos de tu agente. El protocolo de verificación, tratado en profundidad en la lección del módulo de seguridad sobre auditar skills de terceros: clónala en una carpeta de cuarentena sin ejecutar nada, lee cada script, busca patrones peligrosos (llamadas a eval y exec, llamadas de red, bloques en base64, comandos destructivos, frases de inyección de prompts como "ignora las instrucciones anteriores"), y luego copia solo la carpeta auditada a ~/.claude/skills/, nunca un paquete completo sin auditar. Más allá de los marketplaces, para descubrir skills: la skill find-skills busca en el ecosistema abierto, y directorios como skills.sh clasifican las skills según instalaciones reales.

Después de instalar, reinicia la sesión (o ejecuta /reload-plugins) y pon a prueba una skill de principio a fin: pide una tarea que la skill cubra y confirma que Claude anuncia que la está usando. Si no se activa, la causa habitual es un desajuste de descripción: la descripción de la skill no contiene las palabras que tú usas de forma natural. Eso se puede arreglar (editando la descripción), y saber comprobarlo te pone por delante de la mayoría de los usuarios.

El latido: tareas programadas, el sueño (dream) nocturno, statusline

Séptimo componente: el latido. Los hooks reaccionan a las sesiones; las tareas programadas actúan cuando no hay ninguna sesión en marcha. Esta capa es lo que hace que la estructura sea autosuficiente: la consolidación, la actualización y las auditorías ocurren cada noche y cada semana, hayas aparecido ese día o no. En Windows el programador es el Programador de tareas (schtasks o el módulo ScheduledTasks de PowerShell); en macOS y Linux, cron o launchd. Cada tarea es un pequeño script más un horario.

El ritmo en la configuración del autor, a modo de plantilla:

• Por la tarde, las conversaciones fluyen hacia el cerebro. Una tarea diaria exporta las sesiones recientes de Claude a Markdown dentro del vault (el paquete pip claude-conversation-extractor hace esto) y actualiza los grafos de conocimiento derivados. Las conversaciones pasadas se convierten en material consultable en vez de historial perdido. Una precaución aprendida a pulso: pasar las exportaciones por un script de redacción de secretos antes de que nada las indexe, porque las transcripciones en bruto contienen todo lo que alguna vez se pegó ahí.
• Por la noche, el sueño (dream). Una tarea diaria de consolidación (el autor la ejecuta a las 21:00, después de la exportación) lanza Claude en modo headless con una skill dedicada: releer las conversaciones y la memoria recientes, extraer hechos duraderos en notas bien formadas, fusionar duplicados, tejer wikilinks, mantener el índice limpio. Hay dos reglas de seguridad integradas: una copia de seguridad fechada de las notas antes de cada ejecución, y archivar, nunca borrar: una nota contradicha recibe un aviso de obsolescencia y se traslada a una carpeta de archivo en vez de desaparecer. El nombre no es casual: Anthropic anticipó exactamente esta idea como "el sueño", agentes que consolidan la memoria entre sesiones; una versión autoalojada son apenas unas cuantas decenas de líneas de prompt.
• Cada 15 minutos, el idle-sync de la lección de los hooks, que atrapa las sesiones que abandonaste a medio pensamiento.
• Semanalmente, el lint del vault. Una tarea que recorre el vault en busca de wikilinks rotos, notas huérfanas, entradas de índice muertas y notas demasiado grandes. La entropía se acumula en cualquier sistema enlazado; una pasada semanal mantiene el grafo honesto.

Una convención mantiene unida esta capa: las alertas aterrizan en el vault. Cada tarea añade sus fallos y hallazgos a una única nota de alertas en la raíz del vault. Los logs viven junto a los scripts para fines forenses, pero la nota es lo que ve un humano, porque aparece en Obsidian, donde ya miras. Una automatización de la que nunca sabes nada es una automatización en la que no puedes confiar; una automatización que te manda correos es una automatización que aprendes a ignorar. Una nota en el cerebro es el camino intermedio.

Toque final, la statusline: Claude Code renderiza una barra de estado personalizada canalizando el JSON de la sesión (modelo, uso de contexto, costo, estado del límite de tasa) hacia un comando que configuras bajo statusLine en settings.json. Un pequeño script convierte eso en un panel en vivo: porcentaje de contexto, barras de cuota, costo de la sesión. Una trampa documentada en la máquina del autor: refreshInterval está en milisegundos. Puesto en 1, generaba un proceso intérprete nuevo unas 28 veces por segundo y congelaba visiblemente la terminal; 1000 (un tick por segundo) es un valor sensato. Cuando tu terminal tartamudee misteriosamente, revisa primero ese número.

Con el latido instalado, da un paso atrás y mira lo que construiste a lo largo de este módulo: reglas que se cargan solas, memoria que se escribe sola, sincronización que ocurre sin ti, skills que se disparan con sus propios gatillos, y mantenimiento que se ejecuta mientras duermes. La última lección comprime todo esto en una lista de verificación que puedes volver a ejecutar en cualquier máquina nueva.

La checklist de una hora

Todo lo de este módulo, comprimido en el manual de operaciones que puedes repetir en cualquier máquina nueva. Los tiempos son estimaciones honestas para alguien que lo hace por segunda vez; la primera vez, duplícalos y disfruta del paisaje.

Fase 1: motor (10 min)

• Instalador nativo para tu sistema operativo, luego claude --version.
• Inicia sesión con la cuenta de suscripción; busca cualquier ANTHROPIC_API_KEY perdida.
• /doctor: línea base limpia confirmada.

Fase 2: constitución (10 min)

• ~/.claude/CLAUDE.md: reglas absolutas primero, rutina de inicio de sesión, solo punteros.
• Una sesión nueva recita tus reglas correctamente.

Fase 3: memoria y Obsidian (10 min)

• Instala Obsidian, abre la carpeta de memoria viva como bóveda.
• Primera nota atómica con frontmatter; línea en MEMORY.md; wikilink desde un hub.
• Una sesión nueva recuerda el dato de la nota sin que se lo pidas.

Fase 4: transporte git (10 min)

• .gitignore para conversaciones, grafos generados, archivos.
• Escaneo de secretos, redacción y SOLO DESPUÉS el primer push a un remoto privado.
• Editar, confirmar, subir: el historial funciona.

Fase 5: hooks (10 min)

• Hook de SessionStart que trae el cerebro (ff-only, con tiempo límite, exit 0 siempre).
• Ruta de SessionEnd o Stop para subir cambios, con protecciones anti bucle si algo invoca a Claude.
• Una sesión nueva demuestra que el pull se disparó; /doctor confirma que no hay hooks lentos.

Fase 6: skills (10 min)

• /plugin install superpowers@claude-plugins-official.
• Marketplace de ECC agregado, instalado y luego podado a tu propio stack.
• Una skill se activa a partir de una tarea formulada con tus propias palabras.

Fase 7: latido (10 min, más una noche para verificar)

• Exportación diaria de conversaciones con redacción de secretos; dream nocturno con copia de seguridad y política de archivar nunca borrar; lint semanal de la bóveda.
• Nota de alertas en la raíz de la bóveda como único canal de reporte.
• Statusline configurada, refreshInterval en 1000 ms.

La mentalidad de verificación importa más que la lista: cada fase termina con una prueba, no con una sensación. Una sesión nueva que recita las reglas, una nota recordada sin que se le pida, un hook que se disparó de forma demostrable, una skill que se activó sin nombrarla. Si no puedes mostrar la prueba, la fase no está terminada, digan lo que digan los archivos de configuración.

Adónde ir desde aquí: el módulo de extensión para servidores MCP y escritura de tus propias skills, el módulo de segundo cerebro para la mecánica del recuerdo y la instalación de bolsillo en Android, el módulo de orquestación para cuando un solo Claude deja de ser suficiente, y el módulo de seguridad antes de que tus hooks y skills se multipliquen. La estructura que acabas de construir es la base sobre la que se apoyan todos esos módulos. Mantenla con el hábito que supera a cualquier herramienta de este curso: cuando aprendas algo duradero, escríbelo en el cerebro antes de cerrar la sesión.