Tu segundo cerebro no es JARVIS mientras necesites estar sentado enfrente.

Esta página construye un agente personal encima de tus notas, de principio a fin. No es una lista de trucos: es un sistema con cinco capas que se montan una por una, y cada parada deja una capa funcionando antes de pasar a la siguiente.

Antes de tocar nada conviene tener claras tres cosas: qué te queda armado al terminar, cuál de los tres caminos de montaje te toca, y qué temas esta guía no re-explica porque ya viven completos en otra página de la bóveda. Las tres caben aquí.

Qué tienes al final

Al cerrar esta página tienes un agente personal trabajando sobre tus notas. No una carpeta ordenada con Claude Code al lado: un sistema que arranca sabiendo quién eres, carga sus habilidades solo cuando le sirven, le delega lo pesado a un equipo, dispara reflejos que no dependen de que entienda, y se despierta solo a la hora que le dijiste.

Son cinco piezas y se montan en este orden. Ninguna necesita a la siguiente para servirte: si te quedas en la tercera, tienes tres capas andando y no un sistema a medias.

Ese es el destino. Lo que cambia entre una persona y otra es por dónde se entra, y eso es la decisión que sigue.

Los tres caminos, en una línea cada uno

El cerebro de este sistema son archivos de texto en tu disco. Lo que cambia entre un camino y otro es qué le pones encima, y esa decisión se toma una vez.

Cada uno cuesta algo distinto, y hay uno que casi nadie debería elegir de entrada. La comparación completa, con lo que ganas y lo que te cuesta en cada caso, está en la parada de los tres caminos. Si ya sabes cuál es el tuyo, puedes saltártela.

Qué se queda en otras guías

La bóveda ya tiene guías completas de casi todas las piezas que aquí se usan. Esta página no las repite: las usa. La tabla dice de entrada qué tema vive en qué guía y con qué se queda ésta, para que no leas cuarenta minutos buscando algo que está en otro lado.

Dos de esas guías son las que más conviene tener a la mano mientras lees ésta. Si lo que quieres hoy es que algo corra solo y todavía no tienes el vault armado, empieza por las 10 automatizaciones con Claude: ahí se opera una tarea programada de punta a punta, y aquí se da por sabido.

Y si quieres el método general de carpetas y la convención de nombres, la estructura de folders y archivos para Claude lo cubre entero. Esta página se apoya en esa y arma las nueve carpetas de este caso en la parada del esqueleto.

La tercera es de otro tipo: si todavía no sabes si lo que necesitas es una skill, un subagente, un hook o un servidor MCP, Claude Anatomy te ayuda a decidir la pieza antes de escribir el primer archivo.

Y la cuarta llega hasta la parada de los sentidos: prender un conector paso a paso vive en la guía de conectores de Claude; aquí solo se decide cuáles valen la pena y qué sale de tu máquina cuando los prendes.

Con eso ya sabes qué vas a construir y qué no vas a leer aquí. Lo que sigue es el arranque: abrir la terminal, dejar Claude Code instalado y con tu sesión iniciada, y crear la carpeta donde va a vivir todo. Si ya lo tienes andando, sáltatelo y entra directo al esqueleto de las cinco capas.

Una herramienta la abres tú. Le pides algo, te contesta, cierras la ventana y lo que aprendió se va con ella. Un agente no funciona así: abre sabiendo quién eres y hace cosas los días que tú no lo abriste. La diferencia entre los dos no está en el modelo ni en el prompt: está en cuántas capas tiene montadas debajo.

Son cinco, y son las mismas para cualquier agente. Aquí no hay nada de contenido: si el tuyo cotiza, cobra o estudia, el esqueleto no cambia, cambia lo que le metes adentro. Por eso esta sección va antes que cualquier carpeta.

La cuenta que incomoda, antes de seguir: un chatbot con un prompt largo y bien escrito tiene una de las cinco. La memoria, y a medias. Es muchísimo mejor que nada, y también es la razón exacta por la que el lunes se siente amnésico.

Las cinco, una por una

Qué cambia cuando la capa existe

Se montan de abajo hacia arriba, y no se saltan

Las cinco capas no son un menú donde eliges tus favoritas. Son una escalera: cada una supone que la de abajo ya está puesta, y montarlas en desorden es la forma más común de terminar con un sistema aparatoso que no sirve.

• Memoria primero, siempre. Sin ella, todo lo que le montes encima vuelve a empezar de cero cada sesión: la habilidad no sabe para quién escribe y el subagente no sabe qué reglas respetar.
• Habilidades después, y solo cuando ya hiciste la tarea a mano varias veces. Una skill es un procedimiento que ya funciona, escrito para no volver a explicarlo; no es un lugar donde adivinar cómo debería funcionar.
• Equipo cuando la conversación se te empiece a llenar. Si todavía no se te llena, un subagente es una carpeta más que mantener y una indirección más que depurar.
• Sentidos cuando el trabajo de verdad viva afuera. Conectar el correo porque se puede es abrirle una puerta que quizá no necesita, y cada puerta abierta es algo que sale de tu máquina.
• Latido hasta el final. Lo que va a correr solo tiene que ser algo que ya te sale bien a mano, sin que nadie lo esté mirando.

Dónde estás parado ahora mismo

Si ya usas Claude Code para algo, lo más probable es que tengas una capa y media sin habértelo propuesto. Vale la pena saber cuál antes de construir encima. Este prompt no crea ni cambia nada: solo mira y te dice qué hay.

Quiero saber en cuál de las cinco capas de un agente personal está parada esta carpeta. Revísala y dime qué hay y qué falta, capa por capa:

1. MEMORIA — ¿existe un CLAUDE.md en la raíz o en .claude/? ¿Cuántas líneas tiene? ¿Hay algo en .claude/rules/? Si hay rules, dime cuáles tienen frontmatter de rutas y cuáles cargan siempre.
2. HABILIDADES — ¿hay carpetas en .claude/skills/ con su SKILL.md adentro? Enlístalas con la descripción de cada una tal como está escrita.
3. EQUIPO — ¿hay archivos en .claude/agents/? Dime el nombre de cada uno y para qué dice que sirve.
4. SENTIDOS — ¿hay un .mcp.json en el proyecto? Enlista lo que declare.
5. LATIDO — revisa si existe ~/.claude/scheduled-tasks/ y, si existe, dime el nombre y la descripción de cada tarea que haya ahí.

Reglas de esta revisión:
- No crees, edites ni borres ningún archivo. Esto es solo un diagnóstico.
- Si algo no existe, dilo con esas palabras en vez de proponer qué escribirías.
- Cita la ruta exacta de todo lo que encuentres.

Al final, dime cuál es la primera capa que me falta contando desde la memoria hacia arriba, y por qué ésa y no otra.

Una aclaración de territorio antes de seguir. Si lo que traes es la duda de qué pieza construir para un problema suelto —si eso se resuelve con una skill, con un subagente, con un hook o con un servidor MCP—, esa decisión se toma en la guía de anatomía de Claude Code, que compara las piezas una contra otra y te deja elegir una. Aquí no elegimos entre ellas: aquí se arma una sola cosa que las usa todas, y el orden en que se montan es la mitad del trabajo.

Ése es el esqueleto entero: cinco capas, un orden y una regla de costo. Lo que sigue es dónde vive. Y ahí aparece la pregunta que casi nadie hace antes de instalar nada: si el cerebro son archivos y las capas son carpetas, ¿de verdad necesitas Obsidian encima?

La respuesta honesta es no. Claude Code lee archivos markdown de una carpeta de tu disco: leer, escribir, mover y buscar archivos son herramientas que ya trae puestas, sin instalar nada de por medio. Una carpeta, archivos con extensión .md adentro y una sesión abierta ahí es todo lo que el agente necesita para funcionar.

Obsidian no le agrega ni una capacidad a Claude. Te agrega una ventana a ti: el grafo que enseña qué nota se conectó con cuál, la búsqueda instantánea sobre el vault entero, la app de teléfono para capturar en la calle y un atajo de teclado que abre una nota nueva sin que sueltes las manos.

La distinción importa porque decide qué instalas. Si lo que te frena es no ver tus notas, Obsidian resuelve. Si lo que te frena es no capturarlas, Obsidian resuelve. Si esperas que Obsidian haga que Claude entienda mejor tu vault, no va a pasar: el que entiende es Claude, y él abre los mismos archivos con Obsidian corriendo o desinstalado.

Los tres caminos

Y si lo quieres en el teléfono

Obsidian corre en iOS y Android, pero no sincroniza solo: hay que decidir por dónde viajan los archivos. Son cuatro caminos, del más simple al más manual.

El camino que te toca

Ya elegiste la ventana. Falta el mueble: cómo se llaman las carpetas que van adentro y por qué el orden que casi todo el mundo usa, el de por tema, es justo el que le impide a tu agente encontrar nada. Eso es lo que sigue.

Si ya usas Claude Code todos los días, esta parada no te dice nada nuevo: salta a la parada del esqueleto y sigue desde ahí. Lo único que vale la pena que confirmes antes de irte es que abres la sesión parado dentro de la carpeta del vault, y no un nivel más arriba.

Para el resto: ya sabes qué vas a construir y con cuál de los tres caminos. Falta encender la herramienta que lo construye. Aquí no se crea todavía ninguna carpeta del vault; se deja Claude Code instalado, conectado a tu cuenta y parado donde tiene que estar.

Es el único tramo de la página con comandos de terminal. Son cuatro piezas, ninguna cuesta dinero aparte de la suscripción que ya pagas, y en una computadora limpia se hace en quince minutos. La mitad de ese rato es esperar descargas.

Si responde un número de versión seguido de «(Claude Code)», ya está. Si responde que no encuentra el comando, no te adelantes: abajo están los dos tropiezos que lo explican casi siempre.

Nunca le pongas sudo delante a ese comando, por más que un foro te lo sugiera. Ahí es donde nacen los problemas de permisos que después no sabes de dónde salieron. Si te falla por permisos, la página oficial de instalación tiene el arreglo por sistema.

Si ya instalaste por el camino de arriba, este paso no existe para ti. Sigue al login.

La primera vez te pregunta cómo quieres entrar. Eliges entrar con tu cuenta de Claude, se abre el navegador, te conectas con la cuenta de siempre y regresas a la terminal. El login queda guardado: no lo repites cada mañana.

Si algún día quieres cambiar de cuenta, escribes /login dentro de la sesión y el navegador se abre otra vez.

La prueba de que quedó

Con la sesión abierta, pega esto y mándalo. No cambia nada de tu computadora: solo obliga a Claude a decir en voz alta dónde está parado, que es justo el dato que se rompe sin que te des cuenta.

Quiero comprobar tres cosas antes de empezar, sin que modifiques nada de mi computadora.

1) Dime la ruta completa de la carpeta desde la que estás corriendo ahora mismo.
2) Enséñame qué archivos y qué carpetas hay ahí, sin entrar a las subcarpetas.
3) Dime si en esta carpeta existe un archivo CLAUDE.md y si estás leyendo alguno.

Contéstame en español, en cinco líneas como máximo, y no crees, muevas ni borres ningún archivo.

Si contestó las tres, ya tienes con qué trabajar. La respuesta que importa es la primera: esa ruta es donde va a nacer el vault en la parada que sigue.

Si la ruta no es la que querías, sal de la sesión, muévete con cd a la carpeta correcta y vuelve a abrir Claude Code ahí. Es un minuto ahora y es media hora de confusión después.

Y si te dijo que no ve ningún CLAUDE.md, está bien: todavía no existe. Ese archivo se escribe más adelante, y va en la raíz del vault. En una subcarpeta no se autocarga: solo entra cuando Claude lee un archivo de esa carpeta.

Los pasos por sistema operativo —Mac, Windows y Linux— los mantiene al día Anthropic en la página oficial de instalación. Si tu caso se sale de lo de arriba, esa es la que manda. Aquí no se copia su tabla completa a propósito: cambia cada mes y una copia vieja hace más daño que un enlace.

Ya tienes la herramienta encendida, conectada a tu cuenta y parada en la carpeta donde va a nacer el vault. De aquí en adelante todo pasa dentro de esa sesión: la parada que sigue la usa para construir las carpetas, y no vuelves a instalar nada.

Antes de crear una sola carpeta hay que tomar una decisión, y es la única de esta guía que no se deshace barato: cómo se agrupan tus notas. Si la tomas mal, el sistema funciona igual durante tres semanas y después se pudre solo.

Casi todo el mundo agrupa por tema. Es lo que hace un archivero, es lo que hace tu escritorio y es lo que va a proponerte cualquier plantilla que te bajes. Y es exactamente lo que no hay que hacer aquí.

Dos formas de guardar la misma nota

Fíjate en lo que se movió: no cambió qué anotas, cambió quién toma la decisión. Por tema decide tu criterio, que es inconsistente por definición. Por tipo decide la forma de la nota, que es la misma siempre.

El cerebro estaba en el lugar equivocado

La causa es de dónde cuelga el archivo. Claude Code sube por el árbol de directorios desde la carpeta donde lanzaste la sesión, y carga los CLAUDE.md que va encontrando de ahí hacia arriba. Los CLAUDE.md que están en subcarpetas no se cargan al inicio: entran solo cuando Claude lee algún archivo de esa subcarpeta.

La estructura vieja ponía el CLAUDE.md en 05-CLAUDE/. Si tú lanzas la sesión en la raíz del vault, que es lo normal porque ahí está todo, ese archivo queda una carpeta hacia abajo. Resultado: el cerebro del sistema no estaba cargado en la mayoría de las sesiones, y solo aparecía de rebote cuando Claude abría por su cuenta algo de esa carpeta.

El arreglo cabe en una línea: el CLAUDE.md se mueve a la raíz del vault. Desde ahí se carga al inicio de cada sesión, y si la conversación se compacta se vuelve a leer del disco. Está en la documentación oficial de memoria, y es el tipo de detalle que nunca te da un error: solo hace que todo funcione peor sin decirte por qué.

La estructura corregida, completa

JARVIS/
├── CLAUDE.md                 <- en la raíz. Aquí sí se autocarga
├── .gitignore                <- lo que nunca sube al repositorio
├── .claude/                  <- la carpeta que Claude Code ya busca sola
│   ├── skills/               <- las habilidades (parada de las habilidades)
│   ├── agents/               <- el equipo (parada del equipo)
│   ├── rules/                <- reglas por carpeta (parada de la memoria)
│   └── settings.json         <- los reflejos (parada de los reflejos)
├── 00-INBOX/                 <- todo cae aquí primero, sin pensar
├── 01-CAPTURES/              <- lo del inbox, ya clasificado por tipo
│   ├── observations/         <- lo que viste
│   ├── reactions/            <- lo que sentiste
│   ├── patterns/             <- lo que se repite en dos lugares
│   ├── questions/            <- lo que no sabes
│   └── numbers/              <- lo que trae cifra
├── 02-CONNECTIONS/           <- ideas que salieron de cruzar dos notas
├── 03-BRIEFS/                <- la cola de producción
└── 04-PUBLISHED/             <- lo publicado, con sus números pegados

Dos detalles del árbol que valen la pena. El primero ya lo viste: el CLAUDE.md va en la raíz.

El segundo es que 05-CLAUDE/ se retira entera. No porque estuviera mal pensada, sino porque Claude Code ya tiene su carpeta y se llama .claude/. Es la que busca sola para las habilidades, los subagentes, las reglas y la configuración. Tener una carpeta paralela inventada por nosotros significaba que nada de lo que metías ahí se cargaba solo.

Y 05-CLAUDE/context/, que aparecía en el árbol viejo y nunca se explicaba en ninguna parte, simplemente no hace falta. Todo lo que ibas a guardar ahí ya tiene su lugar: lo que siempre aplica va en el CLAUDE.md, lo que aplica solo en una carpeta va en .claude/rules/, y lo que Claude descubre solo se guarda en su propia memoria. Las tres se separan en la parada que sigue.

Qué cae en cada carpeta

El prompt que construye el esqueleto

No hay nada que crear a mano. Abre la terminal en la carpeta donde quieres que viva el vault, lanza Claude Code y pega esto. Crea las carpetas, deja un README corto en cada una explicando qué va ahí y qué no, y escribe el .gitignore.

Los README no son adorno: son lo que va a leer tu agente, y tú a los tres meses, cuando dude si una nota va en observations o en reactions. El .gitignore importa porque este vault va a terminar siendo un repositorio privado de GitHub, que es la condición para que el sistema siga trabajando con la laptop cerrada.

Eres mi asistente de configuración. Vamos a crear el esqueleto de un vault personal llamado JARVIS dentro de la carpeta donde estamos parados. No me pidas que escriba archivos a mano: hazlo tú y al final enséñame el resultado.

1) Crea esta estructura exacta de carpetas:

JARVIS/
├── .claude/skills/
├── .claude/agents/
├── .claude/rules/
├── 00-INBOX/
├── 01-CAPTURES/observations/
├── 01-CAPTURES/reactions/
├── 01-CAPTURES/patterns/
├── 01-CAPTURES/questions/
├── 01-CAPTURES/numbers/
├── 02-CONNECTIONS/
├── 03-BRIEFS/
└── 04-PUBLISHED/

2) En cada carpeta numerada y en cada subcarpeta de 01-CAPTURES, crea un README.md de diez líneas como máximo, escrito en español y hablándome de tú, que diga:
   - qué tipo de nota va en esa carpeta,
   - qué NO va, con el ejemplo del error más fácil de cometer (confundir una observación con una reacción, o meter una captura cruda en 02-CONNECTIONS),
   - un ejemplo de una sola línea de una nota que sí pertenece ahí.

El criterio de todo el sistema es que las carpetas clasifican por TIPO de nota, no por tema. Que cada README lo deje claro en su primera frase.

3) Crea un .gitignore en la raíz que ignore la carpeta de configuración local de Obsidian (.obsidian/), los archivos basura del sistema operativo (.DS_Store, Thumbs.db), CLAUDE.local.md y .claude/settings.local.json. Explícame en dos líneas por qué se ignora cada uno.

4) NO crees todavía el CLAUDE.md, ni habilidades, ni subagentes, ni settings.json. Esos vienen después y necesitan información mía que aún no te he dado.

5) Cuando termines, muéstrame el árbol resultante, dime cuántos archivos creaste, y avísame si algo de lo que pedí ya existía y no lo tocaste.

6) Al final, dime el comando exacto para entrar a la carpeta JARVIS desde donde estoy parado ahora, y recuérdame con esas palabras que de aquí en adelante todas las sesiones de Claude Code se abren desde DENTRO del vault, nunca desde la carpeta de arriba.

Ese último paso no es cortesía. El prompt crea JARVIS como una carpeta dentro de donde estabas parado, así que la sesión que acaba de construirlo sigue viviendo un nivel más arriba del vault.

De aquí en adelante todas las sesiones se abren desde dentro de JARVIS. Eso es lo que hace que el CLAUDE.md de la raíz se cargue solo al arrancar. Si abres la terminal una carpeta más arriba, vuelves a tener el síntoma del principio: contesta genérico y no parece conocer tu vault.

El esqueleto ya está de pie y vacío, que es exactamente como debe estar. Lo que sigue es meterle lo primero que lo convierte en un agente en vez de una carpeta ordenada: la memoria. Son tres, se confunden todo el tiempo, y una de ellas no viaja entre tus máquinas.

Cuando alguien dice que su Claude «ya tiene memoria», puede estar hablando de tres cosas distintas. Se escriben con manos diferentes, se cargan en momentos diferentes y no llegan a los mismos lugares. Confundirlas es el motivo número uno de que un agente personal se sienta amnésico justo cuando más lo necesitas.

Las tres existen en tu carpeta ahora mismo, aunque tú solo hayas escrito una.

Las tres, lado a lado

Las tres de la tabla son nativas: vienen con Claude Code y no se instalan. Si viniste del Camino C de la parada de los tres caminos, claude-mem no es ninguna de las tres ni las reemplaza — es una herramienta aparte que guarda lo que Claude hizo en cada sesión, y se monta encima de esto. La memoria automática de la fila de en medio ya está prendida en tu máquina aunque nunca hayas instalado nada.

Cómo se instala y se opera cada una por dentro, con claude-mem y los archivos por tema, es territorio de la guía de memoria en Claude Code. Aquí importa la pregunta que esa guía no contesta: qué escribir, qué borrar y quién gana cuando dos memorias dicen lo contrario.

Y cuando son varios agentes escribiendo en un mismo cuaderno, la mecánica cambia por completo: eso está en el palacio de memoria para agentes. Lo de esta página es más simple, y por eso funciona: el cuaderno es de uno solo.

Qué recordar y qué no

El error de casi todos los CLAUDE.md es que están llenos de cosas verdaderas que no hacía falta escribir. Verdadero no es lo mismo que útil: cada línea que agregas compite con las demás por atención, y las que se pueden deducir leyendo los archivos se llevan atención sin devolver nada.

La regla práctica es una sola y no falla: si tuviste que corregirle lo mismo dos veces, va al archivo. La primera vez es un caso suelto. La segunda ya es un patrón, y un patrón que no escribes lo vas a corregir una tercera.

La de la izquierda no se puede desobedecer: cualquier texto la cumple. La de la derecha sí, y por eso sirve, porque se nota cuando no se cumplió. Ésa es la prueba para cada línea de tu archivo: si no puedes darte cuenta de que la rompió, no era una regla.

Los dos techos de carga

Escribir mucho no es lo mismo que que se cargue mucho. Hay dos números que deciden cuánto de lo que escribiste llega de verdad a la sesión, y son distintos para cada archivo.

Nada de esto hay que adivinarlo. Dos comandos te dicen qué tienes escrito y qué se cargó de verdad en la sesión que estás corriendo ahora.

Si /context enseña un archivo que tú creías cargado y no aparece, ya encontraste por qué te ignora.

Y si el índice de la memoria automática se pasa del techo, la escritura funciona pero Claude Code devuelve un error pidiéndole a Claude que reescriba el índice, precisamente porque lo que sobra se pierde en la siguiente carga.

La poda: quince minutos, una vez al mes

Nadie te va a avisar. El CLAUDE.md no se rompe cuando envejece: se pone flojo. Le agregaste una regla en marzo por un proyecto que ya cerró, una excepción en mayo por un cliente que ya no está, y una aclaración en junio que contradice la de marzo. Nada de eso da error.

Un CLAUDE.md que creció sin podarse obedece peor que uno de la mitad de largo. La razón es aritmética: cada instrucción que agregas le quita peso a las demás. Veinte reglas que siguen siendo ciertas pesan más, una por una, que sesenta donde la mitad ya no aplica.

Y si dos reglas se contradicen, Claude puede elegir cualquiera de las dos. El conflicto no se resuelve solo, no avisa, y no falla igual siempre: un día hace una cosa y otro día la contraria. Eso es exactamente lo que se siente como «se le olvidó».

La memoria automática se poda igual, pero por otro lado: ábrela con /memory, lee el índice y borra lo que ya no describe cómo trabajas. Como la escribe Claude solo, se acumula rápido; y como se corta a las primeras 200 líneas, lo viejo que dejaste arriba está desplazando lo nuevo sin que nadie te lo diga.

Para lo que tiene que pasar pase lo que pase —que no borre lo ya publicado, que no abra un .env, que no mande nada sin que tú lo veas— hay otra capa que no pide por favor: un hook corre antes de la herramienta y la bloquea, entienda Claude o no. Eso se arma en la parada de los reflejos, los reflejos. Por ahora basta con saber que existe, para que no intentes resolver con una línea de texto algo que necesita un candado.

Reglas que solo aparecen cuando hacen falta

Hay además una forma de escribir memoria que casi nadie usa y que no compite con las tres de arriba, porque no es otra memoria: es una manera de partir la primera. Es la carpeta .claude/rules/, y es lo que salva al CLAUDE.md de crecer sin control. Son archivos .md sueltos y Claude Code los descubre solo, sin que los declares en ningún lado.

Sin frontmatter de rutas cargan siempre, con la misma prioridad que el .claude/CLAUDE.md; o sea, es lo mismo que tener un archivo más largo, solo que ordenado. El ahorro está en la otra versión: con un frontmatter paths, una regla carga únicamente cuando Claude toca un archivo que coincide con esos patrones.

Para un vault eso es justo lo que quieres. Las reglas de cómo se afila una captura no tienen por qué estar cargadas mientras escribes un brief, y las reglas de lo ya publicado, que es lo más delicado que hay, aparecen solo cuando Claude toca esa carpeta. Los tuyos personales van en ~/.claude/rules/ y cargan antes que los del proyecto.

---
paths:
  - "04-PUBLISHED/**/*.md"
---

# Reglas de lo ya publicado

- El texto de una nota publicada no se edita nunca.
- Lo único que se actualiza aquí son las métricas del frontmatter.
- Si te pido un cambio de texto, dime el archivo y espera
  mi confirmación por escrito antes de tocarlo.

Crea el archivo .claude/rules/publicado.md en la raíz de esta carpeta.

Ponle un frontmatter con paths apuntando solo a 04-PUBLISHED/**/*.md, para que estas reglas se carguen únicamente cuando toques archivos de esa carpeta, y no en todas las sesiones.

En el cuerpo escribe estas reglas en una lista, con mis palabras y sin adornos:
- El texto de una nota publicada no se edita nunca.
- Lo único que se actualiza son las métricas del frontmatter.
- Si te pido un cambio de texto, me dices el archivo y esperas mi confirmación por escrito.

Cuando lo tengas, enséñame el archivo completo y dime en una línea cómo compruebo que la regla se está cargando cuando toca, y no antes.

El prompt que te entrevista y escribe el archivo

Lo habitual es partir de una plantilla larga con corchetes para llenar a mano. Sirve, y tiene el problema de todas las plantillas: se llena rápido y en genérico, porque describir «mi voz» en abstracto es difícil, y contestar preguntas concretas no lo es.

Este prompt hace lo contrario. Te entrevista, una pregunta a la vez, y hasta el final escribe el archivo. Las cinco cosas que tiene que sacarte son las mismas de siempre: quién eres, qué es este lugar, cómo suenas, qué no se toca y qué trabajos te hace.

Vas a escribir el CLAUDE.md de esta carpeta, pero antes me vas a entrevistar.

Reglas de la entrevista:
- Una pregunta a la vez. Espera mi respuesta antes de seguir.
- Si contesto algo que no se puede verificar ("tono cercano", "que escriba bien"), no lo aceptes: pídeme un ejemplo concreto, o dos palabras que sí y dos que no.
- No inventes nada que yo no haya dicho. Lo que te falte, apúntalo y pregúntamelo al final en una lista aparte.

Cúbreme estas cinco cosas, en este orden:
1. Identidad. Quién soy, qué hago, para quién, y los dos o tres temas de los que hablo siempre.
2. El lugar. Qué es esta carpeta para mí y qué hacen las tres o cuatro subcarpetas que se comportan distinto a lo que su nombre sugiere. No me preguntes por las que se explican solas.
3. Voz. Cómo sueno cuando escribo. Pregúntame por largo de frase, signos que no uso, cómo abro, cómo cierro, y la lista literal de palabras que odio. Si te puedo pasar tres textos míos, léelos y saca los patrones tú en vez de preguntarme.
4. Reglas duras. Qué NUNCA debes tocar ni hacer sin que yo lo pida.
5. Trabajos. Qué te voy a pedir de forma repetida, con el nombre que yo uso para cada cosa.

Cuando termine la entrevista, escribe el archivo CLAUDE.md en la raíz de esta carpeta con esas cinco secciones, y respeta esto:
- Menos de 200 líneas. Si te pasas, corta primero lo que se puede deducir leyendo mis archivos.
- Cada regla escrita de forma que se note si la rompiste. Nada de buenos deseos.
- Nada de listar carpetas que se entienden por su nombre.
- Ninguna regla que contradiga a otra. Si dos de mis respuestas se pelean, dímelo antes de escribir.

Al final enséñame el archivo y dime en cuántas líneas quedó.

Ya escrito, no confíes en que quedó. Cierra la sesión, abre una nueva y pégale esto antes que cualquier otra cosa.

Lee mi CLAUDE.md completo y dime en un párrafo:
1. Qué entiendes de mí y de este lugar: a quién le hablo, de qué escribo y cómo sueno.
2. Cuál es tu rol exacto aquí adentro, según el archivo.
3. Cuál es la regla que no vas a romper pase lo que pase.

Sé específico. No me digas "es un sistema para tomar notas": dime quién soy, qué construyo y qué me importa. Y si algo del archivo te quedó ambiguo, o se contradice con otra línea, márcalo aparte en una lista para que yo lo arregle.

La respuesta te dice más del archivo que de Claude. Si te devuelve generalidades, no es que no entienda: es que no le diste nada específico que entender. Cuando pase, vuelve al archivo, no al prompt.

La memoria ya sabe quién eres, cómo suenas y qué no se toca. Lo que todavía no sabe es cómo haces las cosas: procesar lo que capturaste, cruzarlo, armar un encargo, escribirlo en tu voz. Eso no cabe en el CLAUDE.md, porque se cargaría entero en cada sesión aunque no lo uses. Va en la capa 2, que solo se enciende cuando hace falta.

La memoria le dice a tu agente quién eres. Las habilidades le dicen qué sabe hacer. Una skill es un procedimiento que tú ya repites a mano —procesar el inbox, cruzar las capturas de la semana, armar un brief— escrito una sola vez en un archivo, para no volver a dictarlo nunca.

Lo que las hace baratas es cuándo se cargan. Al arrancar la sesión, Claude Code solo lee el nombre y la descripción de cada skill. El cuerpo, con su procedimiento completo y su barra de calidad, no entra al contexto hasta que la skill se usa. Puedes tener veinte y pagar por veinte renglones.

Esta sección no te enseña a escribir skills desde cero. Hace otra cosa: migra las cuatro que ya trae este sistema al formato oficial y te enseña las tres trampas que dejan una skill escrita, guardada y muerta.

Si lo que quieres es escribir skills nuevas —cómo se estructura una desde cero, cómo se prueba que dispare y cómo se empaqueta—, eso tiene página propia: el creador de habilidades.

Y si dudas entre guardarlas en tu carpeta personal o en la del proyecto, esa decisión se toma en global o de proyecto. Aquí ya viene tomada: en este sistema van adentro del vault.

Una skill es una carpeta, no un archivo suelto

Lo más común es guardar las habilidades como archivos markdown sueltos en una carpeta, cada uno con un encabezado tipo «Skill: Process Inbox» y una lista de frases disparadoras debajo. Se lee bien y no sirve: eso es un documento. Claude Code no lo carga solo, no aparece en el menú de la barra, y las frases disparadoras de adentro no disparan nada.

Una skill de verdad es una carpeta con un archivo SKILL.md adentro. La carpeta se llama como la skill, el archivo se llama siempre SKILL.md, y arriba del todo va un bloque de frontmatter entre tres guiones. Ese bloque es lo que convierte un documento en algo que Claude Code carga.

tu-vault/
├── CLAUDE.md                     ← en la raíz, no en una subcarpeta
├── .claude/
│   └── skills/
│       ├── process-inbox/
│       │   └── SKILL.md
│       ├── weekly-connections/
│       │   └── SKILL.md
│       ├── generate-brief/
│       │   └── SKILL.md
│       └── write-content/
│           └── SKILL.md
├── 00-INBOX/
├── 01-CAPTURES/
├── 02-CONNECTIONS/
├── 03-BRIEFS/
└── 04-PUBLISHED/

---
name: process-inbox
description: Procesa las capturas crudas de 00-INBOX: las afila a una
  frase, les pone tres tags y las archiva en 01-CAPTURES. Úsala cuando el
  usuario diga «procesa mi inbox» o «afila las capturas de hoy».
---

# Procesar el inbox

1. Lee cada nota en 00-INBOX/.
2. Decide a qué subcarpeta de 01-CAPTURES pertenece.
3. ... el resto del procedimiento, en español normal.

La descripción es el disparador, no el cuerpo

Ésta es la parte que nadie cree hasta que la ve fallar. Al arrancar la sesión, lo único que Claude lee de tu skill es el nombre y la descripción. Con eso, y con nada más, decide si le sirve para lo que le acabas de pedir.

Por eso las frases disparadoras escritas adentro del cuerpo no disparan nada: el cuerpo no se lee hasta que la skill ya fue elegida. Meter ahí las palabras clave es ponerlas del otro lado de la puerta que quieres abrir. Van en la descripción.

La descripción y el campo when_to_use, si lo usas, se cortan juntos a 1.536 caracteres en el listado que Claude ve al arrancar. Es bastante espacio, pero no es infinito: pon el caso de uso principal primero.

• Qué hace la skill, en concreto y con los nombres reales de tus carpetas.
• Cuándo hay que usarla: en qué momento del día, ante qué situación, después de qué otra cosa.
• Con qué palabras se la vas a pedir: las frases exactas que tú dices, tal como las dices.
• Y si hace falta, cuándo NO usarla, para que no se meta donde no la llamaron.

Escríbela pensando en alguien que no ha leído el cuerpo. Literalmente es lo que está pasando.

Las cuatro skills del sistema

Éstas son las cuatro que mueven el flujo completo: capturar, conectar, hacer el brief y escribir. Cada tarjeta de aquí abajo es el archivo SKILL.md entero, con su frontmatter arriba: se copia tal cual y ya queda montada.

Para instalarlas no hace falta que abras el Finder ni que crees carpetas a mano. Copia el bloque, pégaselo a Claude Code adentro del vault y dile: «guarda esto tal cual en .claude/skills/process-inbox/SKILL.md, creando las carpetas que falten». Cuatro veces, una por skill.

---
name: process-inbox
description: Procesa las capturas crudas de 00-INBOX del vault: las afila a una frase, les pone tres tags y las archiva en la subcarpeta correcta de 01-CAPTURES. Úsala cuando el usuario diga «procesa mi inbox», «afila las capturas de hoy» o «limpia el inbox», y también al empezar la sesión de la mañana si 00-INBOX tiene notas sin procesar.
---

# Procesar el inbox

## Proceso
1. Lee cada nota que haya en 00-INBOX/.
2. Para cada nota:
   a. Decide a qué subcarpeta de 01-CAPTURES pertenece: observations, reactions, patterns, questions o numbers.
   b. Afila la nota cruda en una sola frase específica y punzante.
   c. Agrégale exactamente tres tags. Ni más, ni menos.
   d. Mueve la nota afilada a la subcarpeta que le toca.
3. Al terminar, devuelve un reporte con:
   - Total de notas procesadas y a dónde fue cada una.
   - Cualquier patrón que hayas notado entre las capturas de hoy.
   - Una conexión que valga la pena explorar más.
4. Guarda ese mismo reporte, con la fecha arriba, en .claude/ultima-corrida.md,
   sobrescribiendo el anterior. Cuando esta skill corre desde una tarea programada
   no hay nadie leyendo la pantalla, así que si el reporte no queda en un archivo
   se pierde.

## Barra de calidad
Una nota afilada tiene que ser tan específica que alguien de fuera la entienda sin contexto adicional.
Si todavía necesita explicación, no está afilada. Reescríbela.

## Reglas
- No borres el original hasta que la nota afilada esté escrita en su carpeta.
- Si una nota no cabe en ninguna de las cinco subcarpetas, déjala en 00-INBOX y dilo en el reporte.
- Si una categoría se quedó con menos de cinco notas en total, márcalo: significa que estoy capturando de un solo lado.

---
name: weekly-connections
description: Cruza las capturas de los últimos siete días de 01-CAPTURES y escribe las conexiones no obvias como notas nuevas en 02-CONNECTIONS. Úsala cuando el usuario diga «sesión de conexiones», «encuentra las conexiones de esta semana» o «qué se conectó esta semana», y en el ritual del domingo.
---

# Conexiones de la semana

## Proceso
1. Lee todas las notas agregadas a 01-CAPTURES/ en los últimos 7 días.
2. Busca conexiones cruzando TODAS las subcarpetas al mismo tiempo, no dentro de cada una.
3. Una conexión fuerte cumple uno de estos cuatro tipos:
   TIPO A. El mismo principio de fondo apareciendo en dos dominios distintos.
   TIPO B. Contradicción entre dos notas que crea una tensión interesante.
   TIPO C. Patrón que conecta tres o más notas en una idea que todavía no tiene nombre.
   TIPO D. Una pregunta de una nota que otra nota responde por accidente.
4. Para cada conexión fuerte:
   a. Nombra de qué tipo es.
   b. Escribe el puente entre las ideas en una sola frase.
   c. Escribe una entrada posible que use la conexión.
   d. Crea una nota nueva en 02-CONNECTIONS/ que enlace las notas fuente.

## Barra de calidad
Si la conexión es obvia, no califica.
Solo suben las que sorprenderían de verdad a la persona que escribió las notas.
Mínimo tres. Máximo cinco. Calidad sobre cantidad.

## Cierre
Termina diciendo cuál de las conexiones vale más la pena trabajar como brief, y por qué.

---
name: generate-brief
description: Convierte una conexión de 02-CONNECTIONS en un brief listo para escribir, con los cinco campos del sistema: ONE THING, PROOF, READER TRANSFORMATION, tres entradas y tres cierres. Úsala cuando el usuario diga «haz un brief de esto», «genera el brief de [tema]» o «esta conexión ya está para escribirse».
---

# Generar un brief

## Proceso
Escribe un brief con exactamente estos cinco campos.

ONE THING
La única idea sobre la que se construye toda la pieza.
Tiene que caber en una frase. Si no cabe, la idea no está lista.
Si la one thing se siente vaga, dilo y pide que se afile antes de seguir.

PROOF
El ejemplo, el número o el resultado más específico que prueba la one thing.
Una prueba vaga invalida el brief. Números reales, no aproximaciones.

READER TRANSFORMATION
Qué sabe o qué siente el lector al final que no sabía antes.
Si no se puede decir claro, la pieza no tiene razón de existir.

TRES ENTRADAS, ordenadas
Tres, distintas en enfoque y en tono. Ordénalas por qué tanto frenan el scroll.
Entrada 1 agresiva. Entrada 2 curiosa. Entrada 3 personal.

TRES CIERRES, ordenados
Tres, ordenados por urgencia y por qué tanto se quedan en la cabeza.
El cierre se escribe ANTES que el medio. Siempre.

## Salida
Guarda una nota nueva en 03-BRIEFS/ con el nombre [fecha]-[tema-en-kebab].md
Tag: #listo-para-escribir
Enlaza en el brief las notas fuente de 01-CAPTURES y 02-CONNECTIONS que lo sostienen.

---
name: write-content
description: Toma un brief aprobado de 03-BRIEFS y escribe la pieza completa en la voz del usuario, releyendo antes el CLAUDE.md de la raíz, las muestras de voz y las notas fuente enlazadas. Úsala cuando el usuario diga «escribe este brief», «produce el contenido de [tema]» o «ya escribe la pieza».
---

# Escribir la pieza

## Proceso
1. Lee el brief indicado en 03-BRIEFS/.
2. Lee todas las notas fuente enlazadas en el brief.
3. Vuelve a leer las secciones «Mi voz» y «Muestras de mi voz» del CLAUDE.md de la raíz.
4. Escribe la pieza completa en esa voz.
5. Estructura: entrada, prueba, cuerpo, cierre.
6. Cada sección agrega algo específico. Cero relleno.
7. Donde aplique, incluye al menos dos bloques copiables: prompts, comandos o ejemplos.
8. Cierra con la invitación a guardar el post y a seguir la cuenta.

## Voz
Aplica cada regla de voz del CLAUDE.md con precisión, incluidas las palabras prohibidas.
Cuando dudes, más corto y más directo.
Lo que salga tiene que ser indistinguible de algo que yo hubiera escrito.

## Salida
Guarda el borrador en 03-BRIEFS/, junto al brief original, con el sufijo -borrador.md
Tag: #escrito
No toques nada de 04-PUBLISHED.

El mecanismo completo de la primera trampa —qué viaja cuando tu agente corre sin ti y qué se queda en tu máquina— vive en el latido. Aquí basta con guardar las skills en el lugar correcto.

Convierte lo que ya repites en una skill

La regla para saber cuál sigue es simple: si ya le pegaste la misma instrucción tres veces, es una skill. Este prompt toma esa instrucción tuya, la que tienes en las notas del celular o en un archivo de texto, y la deja en el formato que sí carga, con la descripción escrita para disparar.

Voy a pegarte abajo una instrucción que le repito a mano cada semana. Conviértela en una skill de Claude Code bien formada y guárdala en este vault.

Reglas:
1. Créala como carpeta con archivo: .claude/skills/<nombre>/SKILL.md, adentro de este proyecto y no en mi carpeta personal.
2. El frontmatter lleva solo dos campos: name y description. Ningún otro.
3. La descripción es lo único que vas a leer al arrancar para decidir si esta skill sirve, así que escríbela para eso: qué hace, con los nombres reales de mis carpetas; en qué momento se usa; y las frases exactas con las que yo la voy a pedir. Menos de 1.536 caracteres.
4. El cuerpo es el procedimiento, numerado, en español, con una barra de calidad al final que diga cuándo el resultado todavía no está listo.
5. No metas las frases disparadoras en el cuerpo: ahí no sirven.
6. Si algún paso de mi instrucción es ambiguo, pregúntame antes de escribir el archivo en vez de inventar el criterio.

Cuando termines, dime la ruta exacta del archivo y enséñame solo la descripción que escribiste, para revisarla.

Mi instrucción:
[PEGA AQUÍ LO QUE YA REPITES]

Con esto tu agente ya sabe hacer cosas, pero las sigue haciendo todas él, en la misma ventana y con la misma cabeza. Cruzar noventa notas para encontrar tres conexiones se come la sesión entera antes de que llegues a escribir. Lo que sigue es repartir el trabajo: tres subagentes con contexto propio, herramientas recortadas y una memoria que no se les borra al terminar.

Hasta aquí tu agente tiene memoria y tiene habilidades, y todo lo hace en un solo lugar: tu conversación. Eso aguanta bien hasta el día en que le pides algo que se lee doscientas notas. La conversación se llena de notas, se compacta, y para cuando llegas a la parte interesante ya no se acuerda de qué ibas a hacer con eso.

La capa tres reparte el trabajo. Un subagente es un archivo de texto que describe a alguien con un oficio: cómo se llama, cuándo hay que llamarlo, qué herramientas puede tocar y qué se le queda grabado. Para un vault de contenido bastan tres: uno que ordena, uno que conecta y uno que escribe.

Una aclaración antes de seguir, porque la palabra subagente se usa para dos cosas muy distintas. Lanzar diez a la vez para barrer un problema grande es otra técnica y tiene su propia guía en workflows dinámicos. Aquí es exactamente lo contrario: pocos, fijos, con nombre. No los creas para una tarea y los tiras. Son los mismos tres el mes que viene, y para entonces son mejores que hoy, porque lo que aprenden se les queda.

Por qué no basta con pedírselo a Claude directo

La razón es mecánica, no de estilo. Cada subagente arranca con su propia ventana de contexto, y al padre solo le vuelve su mensaje final. Todo lo que leyó para llegar ahí se queda del otro lado.

Traducido a un vault: si le pides a tu conversación principal que lea doscientas notas para encontrar tres conexiones, terminas con doscientas notas dentro de tu conversación y tres conexiones al final. Si se lo pides al tejedor, las doscientas notas se leen en la ventana de él, y a ti te llega un mensaje con las tres.

Ése es el trato de toda la capa: pagas una ida y vuelta más lenta a cambio de que lo pesado no te toque el contexto. Cuando el encargo es corto, delegar estorba. Cuando el encargo es leer mucho para devolver poco, delegar es lo único que funciona.

El archivista, el tejedor y el escriba

Cada uno cubre una etapa del flujo que ya conoces: entra una captura, se ordena, se cruza con las demás y sale una pieza. La primera fila dice qué skill corre. Fíjate en las de herramientas y memoria, que son las que casi nadie llena: son exactamente lo que el agente le agrega a la skill.

Una honestidad sobre las herramientas: el campo que las recorta recorta herramientas, no carpetas. Decir «escribe solo en 02-CONNECTIONS» es una instrucción del cuerpo del archivo, y una instrucción se puede desobedecer. Si quieres que sea una pared y no una petición, eso ya es un hook, y son la parada de los reflejos. Para el uso diario la instrucción alcanza; para lo que no puedes permitirte que salga mal, no.

Para llamar a uno de los tres no hay menú que abrir ni comando que memorizar. Hay tres formas y sirven las tres.

Cómo se ve por dentro uno de los tres

Un subagente no es una configuración escondida en un menú: es un archivo de texto que puedes abrir, leer y corregir. Vive en la carpeta .claude/agents/ del repositorio, así que se versiona y viaja con el vault. Arriba va el frontmatter, que son los datos de la ficha. Abajo, en español, va lo que le pides.

Fíjate en lo corto que es el cuerpo. No trae el procedimiento: trae la línea que manda a correr la skill, las dos de la memoria y el formato del reporte. Todo lo demás ya está escrito una vez, del otro lado.

---
name: archivista
description: Procesa las capturas nuevas de 00-INBOX. Úsalo cuando
  el usuario pida vaciar el inbox, afilar capturas o etiquetar
  notas sueltas.
tools: Read, Write, Edit, Glob, Grep
model: haiku
memory: project
---

Eres el archivista del vault. Tu único trabajo es dejar 00-INBOX
vacío y cada nota en su carpeta.

El procedimiento no lo inventas tú: corre la skill process-inbox
y sigue sus pasos y su barra de calidad tal cual están escritos.

Antes de empezar, lee tu memoria: ahí está cómo clasificó este
usuario las capturas anteriores y qué correcciones te hizo. Eso
manda por encima de tu propio criterio.

Al terminar, anota en tu memoria las reglas nuevas que aprendiste
hoy sobre cómo clasifica este usuario.

Devuelve un reporte de media pantalla: cuántas notas moviste, a
dónde fue cada una, y la duda que te quedó. Nada más: al padre
solo le llega tu mensaje final.

Guarda ese reporte también en .claude/ultima-corrida.md. Cuando te
despierta la tarea programada no hay nadie leyendo, y el reflejo
de arranque lee ese archivo para contarte qué pasó.

Y éstos son todos los campos que acepta ese encabezado. Solo dos son obligatorios; el resto los pones cuando quieres apretar algo.

De los opcionales, el que más se nota es el de las herramientas. Un agente sin esa línea puede usar todo lo que puedes usar tú. Recortarla no es paranoia: es lo que evita que el archivista, buscando dónde va una nota, decida de paso reescribirte el CLAUDE.md.

La memoria de cada agente es suya

El campo de memoria le da al subagente una carpeta propia donde escribir lo que aprende. No es la tuya, no es la de la conversación principal y no es la de los otros dos: es un cajón por agente, y tiene tres alcances posibles.

Para un vault, project. Es el único de los tres que se versiona, y por eso es el único que llega a la sesión que va a despertar a tu agente con la laptop cerrada, que es la parada del latido. Un archivista con memoria local es un archivista que amanece amnésico del otro lado, repitiendo los errores que ya le corregiste en tu computadora.

Los tres archivos, de una sola vez

No escribas el frontmatter a mano. Abre Claude Code en la carpeta del vault, pega esto y revisa lo que te devuelva: los tres archivos quedan creados con las herramientas ya recortadas, la memoria ya apuntada y el cuerpo mandando a correr la skill que le toca a cada uno.

Crea los tres subagentes de este vault. Son tres archivos markdown en .claude/agents/ de este repositorio: archivista.md, tejedor.md y escriba.md. Escribe tú el frontmatter con los campos oficiales de Claude Code; yo no voy a tocar YAML a mano.

Las cuatro skills del vault ya están en .claude/skills/. Ningún agente vuelve a escribir el procedimiento: el cuerpo de cada uno dice qué skill corre y le ordena seguir sus pasos y su barra de calidad tal cual están escritos.

Reglas para los tres:
- memory: project, para que lo que aprendan se versione con el repositorio y viaje a las sesiones de nube.
- La descripción tiene que decir CUÁNDO delegarle, no qué es. Es lo que se lee para decidir si lo llamas.
- En el cuerpo, en español, incluye siempre estas dos líneas: que lea su memoria antes de empezar y la aplique por encima de su criterio, y que anote ahí lo que aprendió al terminar.
- Que el mensaje final sea corto y concreto: al padre solo le llega eso.

1. archivista - model: haiku
Corre la skill process-inbox sobre 00-INBOX. Herramientas: leer, escribir, editar y buscar archivos, y nada más.
Su memoria guarda cómo suelo clasificar y las correcciones que le hago.

2. tejedor - model: opus
Corre la skill weekly-connections sobre los últimos 7 días de 01-CAPTURES. Herramientas: leer y buscar, más escribir solo para la nota nueva de 02-CONNECTIONS; déjalo dicho en el cuerpo, y que no mueva ni reescriba mis capturas.
Su memoria guarda qué conexiones aprobé y cuáles descarté.

3. escriba - model: inherit
Corre la skill write-content sobre el brief de 03-BRIEFS que yo le indique. No publica nada.
Su memoria guarda las correcciones que le hago a sus borradores.

Cuando termines: enséñame los tres archivos y avísame si usaste algún campo de frontmatter que no exista en la documentación oficial de subagentes, o si algún cuerpo se puso a repetir el procedimiento de una skill en vez de invocarla.

Tres son suficientes. La tentación de la segunda semana es agregar un cuarto, un editor o un investigador o un publicador, y casi siempre sale peor que arreglar el que ya tienes: un agente más es una descripción más compitiendo por la delegación, un cajón más de memoria que llenar y una decisión más cada mañana. Antes de crear el cuarto, reescribe el tercero. Con el equipo montado tu agente ya reparte trabajo dentro del vault, y lo que sigue es lo de afuera: qué alcanza cuando lo que necesita no es una nota tuya, sino tu calendario, tu correo o una página que todavía no has leído.

Las tres capas anteriores viven adentro de la carpeta. La memoria sabe lo que escribiste, las habilidades hacen lo que le enseñaste y el equipo trabaja sobre lo que ya está guardado. Un agente así es bueno, pero solo sabe lo que tú alcanzaste a contarle.

Los sentidos son lo que alcanza sin que se lo pegues: tu calendario, tu correo, los archivos que viven en la nube, la web. Es la capa más fácil de exagerar y la más fácil de equivocar, porque casi toda guía del tema le llama MCP a cosas que no lo son.

Casi nada de lo que te venden como MCP lo es

Vas a ver listas de «MCPs que vale la pena prender» donde la mitad de las entradas no son MCP. Leer y escribir archivos, buscar en el disco, correr comandos, abrir una URL y buscar en la web son herramientas nativas de Claude Code: vienen adentro, no se instalan, no se configuran y ya están prendidas la primera vez que abres la terminal.

Y SuperWhisper no es un MCP de nada. Es una app de dictado: hablas, transcribe y te deja el texto en el portapapeles. Sirve muchísimo para capturar sin teclado, pero no es un sentido del agente. Es un teclado más rápido.

La distinción no es purismo. Buena parte de las tardes que la gente pierde armando su segundo cerebro se van en instalar algo que ya tenía prendido. Antes de conectar nada, la pregunta es si Claude Code no lo hace ya solo.

Los tres que le cambian el trabajo al agente

Con el calendario adentro, el agente deja de preguntarte cuándo. Sabe que el martes tienes tres horas libres y el jueves ninguna, así que el brief que te deja el lunes cabe en el martes y no en un día imaginario. Sabe con quién te reuniste ayer y puede abrir la nota de esa persona antes de que se la pidas. Y cuando lo despiertes temprano, puede decidir qué te sirve hoy en lugar de vaciarte encima todo lo que encontró.

El correo es donde llega el material que nunca capturas: la respuesta larga de un cliente, la objeción con las palabras exactas del que la tiene, el hilo donde alguien te explicó algo mejor de lo que tú lo explicas. Con el correo conectado, el agente puede sacar de ahí las frases que valen y dejarlas como notas en tu vault, en tu formato, sin que tú copies y pegues nada. Es la fuente de captura más rica que tienes y la que menos usas.

Los archivos en la nube son el puente entre tu carpeta y lo que hace el resto del mundo: el PDF que te mandaron, el documento que un colaborador editó, la hoja donde llevas los números. El agente los lee y los vuelve una nota tuya, resumida y conectada con lo que ya tenías, en vez de dejarlos ahí como un archivo más que vas a abrir cuando te acuerdes.

Los tres viven en tu cuenta de claude.ai, no en tu carpeta, y por eso son lo que una tarea programada en la nube alcanza el día que corra sin ti. Préndelos de a uno. Un conector, una semana de uso, y hasta entonces el siguiente. Un agente con seis conectores el primer día no es seis veces más útil: es seis veces más difícil de auditar el día que haga algo que no querías.

El paso a paso de prenderlos —cuáles se agregan de un clic desde el directorio, cuáles se agregan pegando una URL y qué permisos pide cada uno— está en la guía de conectores. Aquí solo importa la decisión, y la decisión tiene dos caras al mismo tiempo: cada conector que prendes es un sentido nuevo y también una puerta nueva.

Obsidian por MCP: cuándo sirve y cuándo sobra

Obsidian tiene su propio MCP. El plugin de la tienda se llama hoy Local REST API with MCP, y cuando lo prendes sirve un MCP nativo en una dirección de tu propia máquina, con un token que viaja en el encabezado de autorización. Obsidian tiene que estar abierto para que del otro lado haya alguien, y la primera vez hay que confiar a mano en su certificado, porque es un certificado que se firmó a sí mismo y tu sistema no lo conoce de antes.

Instala la última versión desde la tienda de plugins de Obsidian, no una que ya tuvieras guardada. Hubo una vulnerabilidad de path traversal —una falla que permite alcanzar archivos fuera de la carpeta que le tocaba— parchada en la línea 4.1.x. Por eso esta guía no fija un número de versión y sí dice lo otro: no conectes nada desde una versión vieja.

Quiero conectar Obsidian a Claude Code por MCP.

Ya instalé la última versión del plugin «Local REST API with MCP» desde la tienda de plugins de Obsidian, tengo el token que me generó y Obsidian está abierto.

Haz esto:
1. Da de alta el servidor MCP de Obsidian para esta carpeta, apuntando a la dirección local que sirve el plugin y mandando mi token en el encabezado de autorización. Pídeme el token cuando lo necesites y no lo dejes escrito en ningún archivo que pueda terminar en un repositorio.
2. Dime en una línea dónde quedó guardada esa configuración y si viaja con el repositorio o se queda solo en mi máquina.
3. Prueba la conexión: lee el título de una nota cualquiera del vault y dime qué te devolvió.
4. Si el certificado autofirmado del plugin da problema, dime exactamente qué tengo que aceptar y dónde. No desactives la verificación por tu cuenta.

Antes de tocar nada, dime en dos líneas qué vas a hacer y espera mi visto bueno.

Qué sale de tu máquina, y cuándo

Este tema no es de ninguna otra guía de la bóveda, así que va aquí y va completo. No es una advertencia de abogado: son tres situaciones distintas que casi todo el mundo mete en el mismo cajón.

El vault son archivos en tu disco. Cuando le preguntas algo a Claude, lo único que sale de tu máquina es el pedazo que necesita leer para contestarte: las notas que abrió, no la carpeta entera. Es exactamente lo mismo que pasa cuando pegas un texto en una conversación normal con tu suscripción. Ni más ni menos.

Un conector es otra cosa. Ahí no le estás mandando un mensaje: le estás dando acceso permanente a un servicio entero. Prender el correo no es enseñarle un correo, es dejarle la bandeja. Puede ser exactamente lo que quieres, porque es justo lo que lo vuelve útil, pero es una decisión distinta y se toma sabiendo que es distinta.

La tercera es la que sorprende: a una tarea programada en la nube se le incluyen por defecto todos los conectores que tengas prendidos, así que hay que quitarle uno por uno los que esa tarea no necesita antes de dejarla corriendo. Cómo se comporta esa corrida, y por qué no te va a preguntar nada, está en la parada del latido. Aquí basta con tenerlo presente antes de prender el sexto conector: el costo de un conector de más no se paga mientras tú estás sentado enfrente, se paga el día que el agente corra sin ti.

Lo que nunca va en el CLAUDE.md ni en una nota del vault

• Contraseñas, llaves de API y tokens de acceso. Ni completos, ni «solo el principio», ni comentados para acordarte.
• El token del plugin de Obsidian y cualquier otro secreto de configuración: van donde el programa los pida, no en una nota.
• Datos de terceros que no son tuyos para compartir: el contrato de un cliente, la conversación privada de alguien, el expediente de un paciente. Que tú los tengas no los vuelve tuyos.
• Nada que te dolería ver pegado en la salida de un agente que corrió solo a las tres de la mañana.

Escribir en el CLAUDE.md una regla dura del tipo «nunca leas archivos .env» ayuda, y vale la pena escribirla. Pero es contexto, no candado: es una instrucción que el modelo lee y casi siempre obedece, y «casi siempre» no es una garantía. El candado de verdad es un hook, que corre antes de la herramienta y la bloquea aunque el modelo opine otra cosa. Eso es la parada de los reflejos.

Con esto tu agente ya sabe, ya puede, ya delega y ya alcanza. Y las cuatro capas tienen el mismo defecto: todas esperan a que tú abras la terminal. Falta la que lo despierta solo.

Las cuatro capas anteriores hacen un asistente buenísimo. Ninguna lo hace JARVIS. Todo lo que llevas construido empieza igual: tú abres la terminal. El latido es la capa que quita ese paso.

Hay tres relojes que pueden despertarlo y no son intercambiables. Elegir mal es la razón número uno por la que alguien programa una tarea, se va de viaje, vuelve y no encuentra absolutamente nada esperándolo.

Los tres relojes

Uno corre en la infraestructura de Anthropic, otro en tu computadora con la app de escritorio abierta, y el tercero dentro de una sesión que tú dejaste corriendo. Suenan parecidos y no lo son.

Léela una vez de arriba abajo y quédate con la cuarta fila. Todo lo demás de esta sección sale de ahí.

La regla del repositorio

Una rutina de nube no corre en tu computadora. Corre en un contenedor limpio que se enciende para esa corrida y se apaga al terminar. Ese contenedor no tiene tu carpeta de documentos, no tiene tu vault y no tiene forma de llegar a ellos.

Lo que sí tiene es lo que tú le diste. Al crear la rutina seleccionas uno o más repositorios de GitHub, y cada uno se clona al empezar la corrida, desde su rama por defecto. Ése es el único puente. El trabajo que Claude haga ahí lo empuja a ramas con prefijo claude/, para que puedas revisarlo antes de que toque tu rama principal.

De ahí sale la frase que decide si tu JARVIS es real o es una demo: para que tu segundo cerebro siga trabajando con la laptop cerrada, tiene que ser un repositorio privado de GitHub. No «tener respaldo en GitHub». Ser un repositorio.

El plugin de sincronización con Git que apareció en la parada de los tres caminos cambia de papel en este punto. Cuando lo instalaste parecía una comodidad: respaldo automático, por si se pierde la laptop. No era respaldo. Era el transporte.

Es la pieza que sube tu vault al único lugar donde una rutina de nube puede alcanzarlo. Lo que la rutina escribe mientras duermes no vuelve solo: queda en una rama con prefijo claude/, y tú la revisas y la mezclas cuando quieras. Sin el transporte, el latido de nube no tiene dónde latir.

La otra mitad de la regla: tus skills tampoco viajan

El repositorio resuelve los archivos. Falta la mitad que rompe más sistemas: una sesión de nube no lee la carpeta personal de skills de tu máquina. No la ve, igual que no ve tu vault.

Sí lee dos cosas. Las skills que hayas prendido para tu cuenta, que se sincronizan al arrancar la sesión. Y las skills committeadas en el .claude/skills/ del repositorio que acaba de clonar. Esa segunda es la que importa para un vault.

Por eso la parada de las habilidades insistió en que la carpeta .claude/ viva dentro del vault y no en tu carpeta de usuario. No era orden por gusto. Todo el esqueleto de la parada del esqueleto estaba puesto para este momento: si tus cuatro skills están adentro del repositorio, la rutina las tiene; si están en tu carpeta personal, la rutina corre sin ellas y no te avisa.

• Las skills del vault van en .claude/skills/<nombre>/SKILL.md, dentro del repositorio, y se commitean como cualquier otro archivo.
• Tu CLAUDE.md de la raíz viaja también, porque también es un archivo del repositorio. La memoria automática no: vive en tu carpeta de usuario y la documentación dice textual que no se comparte con entornos de nube.
• Los subagentes de .claude/agents/ y los hooks declarados en .claude/settings.json viajan por la misma razón: son archivos versionados.
• Los servidores MCP que agregaste desde tu terminal no aparecen en la lista de conectores de una rutina, porque viven en tu máquina y no en tu cuenta. Para que una rutina los alcance hay que darlos de alta como conector de la cuenta o declararlos en un archivo de configuración committeado en el repositorio.

Qué agendar de verdad

La tentación es agendar todo. No funciona: una tarea que corre sola y que nadie lee es ruido con horario. Éstas son las cuatro del sistema de contenido, y cada una tiene un reloj que le queda.

Si una tarea cae en las dos listas, pártela en dos: la mitad de nube deja el material en una rama, y la mitad local lo integra a tu vault cuando abres la computadora.

Los avisos que cuestan caro

• Las rutinas de nube están en vista previa de investigación. La documentación avisa que el comportamiento, los límites y la superficie pueden cambiar, así que lo de aquí puede haberse movido cuando lo pruebes.
• Corren sin pedir permiso: no hay selector de modo de aprobación ni confirmaciones durante la corrida. Y por defecto se incluyen todos tus conectores conectados, con sus herramientas de escritura. Quítale los que no necesite antes de la primera corrida, no después.
• Un estado verde solo dice que la sesión arrancó y terminó sin error de infraestructura. No dice que la tarea haya salido bien. Hay que abrir la corrida y leerla, sobre todo las primeras semanas.
• En la nube el intervalo mínimo es de una hora y una expresión de cron más frecuente se rechaza. Las corridas también pueden empezar unos minutos tarde, por un desfase deliberado que es consistente para cada rutina.
• Hay un tope diario de corridas por cuenta, aparte del límite normal de tu suscripción. Las corridas de una sola vez no cuentan contra él.
• Las tareas locales solo corren con la app de escritorio abierta y la computadora despierta. Si se durmió a la hora agendada, la corrida se salta, y cerrar la tapa la duerme de todos modos.
• Al despertar, el Desktop arranca exactamente una corrida de recuperación: la del horario perdido más reciente de los últimos siete días, y descarta las anteriores. Una tarea diaria que perdió seis días corre una sola vez.

El tope cambia y no vale la pena memorizarlo: míralo en tu propio tablero de rutinas, que es el mismo lugar donde se abre cada corrida para leerla.

Una tarea programada es una skill

Éste es el detalle que amarra la sección con la parada de las habilidades. Cada tarea local que creas desde el Desktop se guarda en tu disco como un SKILL.md, con frontmatter de nombre y descripción y el prompt como cuerpo. No es una metáfora ni un parecido: es el mismo archivo que una skill.

~/.claude/scheduled-tasks/
└── procesar-inbox/
    └── SKILL.md

        ---
        name: procesar-inbox
        description: Afila las capturas crudas del INBOX y las archiva
        ---

        Antes de empezar, mira la hora. Si ya pasaron las
        cinco de la tarde, no proceses nada: dime qué se
        perdió y déjalo para mañana.

        Si estamos a tiempo, lee cada nota de 00-INBOX/ ...

Lo que no está en ese archivo es el horario, la carpeta, el modelo y si la tarea está prendida: eso lo guarda la app aparte. Puedes leer y editar el prompt de tu tarea como cualquier otro archivo de texto, pero el reloj se cambia desde la app.

Y hay un último giro. Una tarea que está corriendo puede cambiar su propio horario o su propio prompt con una herramienta que trae para eso, update_scheduled_task. Es la primera vez en toda la guía que el agente edita su propio latido: úsalo cuando se lo pidas explícitamente, no como costumbre.

Quiero que esta carpeta —mi vault— se vuelva un repositorio privado de GitHub, porque necesito que una rutina de Claude en la nube pueda clonarla y trabajar sobre ella cuando mi computadora esté apagada.

Hazlo en este orden y explícame cada paso en español, sin jerga:

1. Revisa si esta carpeta ya es un repositorio. Si no lo es, inicialízalo.

2. Escribe un .gitignore pensado para un vault de notas. Deja FUERA el estado local de la app de notas (workspace, caché, plugins con datos propios), los archivos temporales del sistema, y cualquier archivo con credenciales o tokens. Antes de escribirlo, enséñame la lista de lo que vas a excluir y espera mi visto bueno.

3. Confirma que la carpeta .claude/ de este vault SÍ entra al repositorio: skills, agentes, reglas y settings. Ésa es la parte que tiene que viajar a la nube. Si algo de .claude/ quedó excluido por el .gitignore, arréglalo y dímelo.

4. Recórreme la lista de archivos que están por subir y avísame si ves algo sensible o personal que quizá no quiero ni en un repositorio privado.

5. Explícame en dos líneas cómo crear el repositorio vacío y PRIVADO en GitHub, dime qué nombre ponerle, y espera a que te confirme que ya existe.

6. Conecta el remoto, haz el primer commit con un mensaje claro y empuja a la rama por defecto. Dime cómo se llama esa rama, porque es la que va a clonar la rutina.

7. Cierra con un resumen de tres líneas: qué subió, qué quedó fuera, y qué tengo que hacer de aquí en adelante para que el repositorio no se atrase.

No borres nada ni reescribas mis notas. Si algo no te queda claro, pregúntame antes de ejecutar.

Con el latido puesto, las cinco capas están completas: memoria, habilidades, equipo, sentidos y latido. Falta una cosa más, y no es una capa: que reaccione sin que nadie lo decida.

Todo lo que llevas montado hasta aquí es contexto. El CLAUDE.md, las skills, los subagentes, los conectores: se lo pones enfrente, se lo pides, y casi siempre te hace caso. Casi siempre es una palabra incómoda cuando de eso depende tu respaldo.

Un hook no pide nada. Es un comando que Claude Code corre en un momento fijo del ciclo de vida —al abrir la sesión, al cerrarla, justo antes o justo después de usar una herramienta— pase lo que pase y decida lo que decida el modelo. No hay una versión de la conversación en la que se le olvide, porque no es una instrucción: es un disparador.

Los tres que le sirven a un vault

No necesitas doce. Con estos tres el vault deja de depender de que tú te acuerdes de tres cosas.

Dónde se declaran

Un hook es un renglón en un archivo de configuración: qué evento lo dispara, con qué filtro, y qué comando corre. Puede vivir en los ajustes de tu usuario, en los del proyecto, en los del proyecto que no se versionan, en el paquete de un plugin, o en el frontmatter de una skill o de un subagente. El lugar que elijas decide quién los hereda.

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          { "type": "command", "command": ".claude/hooks/inbox.sh" }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          { "type": "command", "command": ".claude/hooks/indice.sh" }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": ".claude/hooks/respaldo.sh" }
        ]
      }
    ]
  }
}

Míralo, no lo copies. Lo único que hace falta que se te quede es la jerarquía: el nombre del evento arriba, el matcher opcional que filtra por herramienta, y abajo la lista de comandos que corren. Los eventos que no son de herramienta no llevan matcher.

Y ahora la parte que importa si no programas: no tienes que escribir nada de esto. Los scripts y el JSON los escribe Claude Code, en el mismo vault, si se lo pides bien.

Quiero tres hooks en este vault. No escribo JSON, así que hazlo tú: crea los scripts, déjalos registrados en .claude/settings.json y compruébalos antes de decirme que están.

1) SessionStart: al abrir la sesión dame un parte de dos líneas, sin que yo pregunte nada.
   - Primera línea: cuántas notas hay en 00-INBOX/. Si está en cero, dilo también.
   - Segunda línea: si la última corrida programada pasó y qué dejó. Busca primero el archivo .claude/ultima-corrida.md, que es donde la corrida deja su reporte; si todavía no existe, usa la fecha del archivo más reciente de 01-CAPTURES/ para saber cuándo se archivó algo por última vez. Si no hay rastro de una corrida reciente, dilo en claro: que se saltó y que el inbox está sin procesar.

2) Stop: cuando termine de trabajar, haz commit de todo el vault con un mensaje que incluya la fecha y empújalo al remoto. Si no hay cambios, que no haga commit vacío ni falle; y si no hay remoto configurado, que se salte el empujón en silencio en vez de tronar.

3) PostToolUse con matcher "Write|Edit": cada vez que se escriba o se edite una nota, actualiza el índice del vault con el título, la ruta y la fecha del archivo que se tocó.

Reglas:
- Los scripts van en .claude/hooks/ y tienen que quedar ejecutables.
- El parte de arranque cabe en dos líneas: si no hay nada que decir, que se calle en vez de llenarme la pantalla.
- Ninguno de los tres debe bloquear nada: solo informan y respaldan.
- Si a alguno le falta algo (por ejemplo, que el vault todavía no sea un repositorio de git), que falle en silencio en vez de tumbarme la sesión.
- Explícame en dos líneas qué hace cada script, en español y sin jerga.
- Al final dime con qué comando pruebo cada uno sin tener que abrir y cerrar sesiones.

Salida 2: la única forma de cerrar una puerta

Un hook puede hacer más que avisar. Si el script termina con código de salida 2, eso es un bloqueo, y qué bloquea depende del evento en el que esté colgado.

En la parada de memoria quedó abierto un desempate: qué haces cuando una regla no puede quedar a criterio del modelo. Ésta es la respuesta, y es corta. Una línea en el CLAUDE.md pide por favor. Un hook PreToolUse cierra la puerta.

• PreToolUse: la herramienta no llega a correr. Es el único punto donde puedes impedir de verdad que algo pase.
• Stop: la conversación no termina. Sirve para obligar un paso final, y también para dejarte encerrado si el script está mal escrito.
• UserPromptSubmit: el prompt se borra antes de llegar al modelo.
• PostToolUse: la herramienta ya corrió, así que salir con 2 no deshace nada. Ahí solo le enseña el error a Claude para que lo tome en cuenta.

Agrega un hook PreToolUse a este vault que impida escribir o editar cualquier archivo dentro de 04-PUBLISHED/. Es material ya publicado y no quiero que se toque por accidente.

Cómo lo quiero:
- Matcher de escritura: "Write|Edit".
- El script mira la ruta del archivo que se va a tocar. Si cae dentro de 04-PUBLISHED/, sale con código 2 y escribe una línea que explique por qué: que es material publicado y que si de verdad hay que cambiarlo, se cambia a mano.
- Si la ruta está fuera de esa carpeta, sale con 0 y no estorba.
- Déjalo registrado en .claude/settings.json.
- Cuando termines, pruébalo intentando editar un archivo de esa carpeta y enséñame que se bloqueó.
- Y dime cómo lo desactivo un rato el día que sí necesite editar ahí.

Estos tres son los que le sirven a un vault, pero la lista de eventos es más larga: hay uno para cuando arranca un subagente, otro para cuando cambia un archivo, y un par para antes y después de una compactación. Viven en la documentación oficial de hooks. Si se te ocurre un momento del ciclo de vida en el que algo debería pasar solo, revisa ahí si ya tiene evento antes de inventarte un rodeo.

Con los reflejos puestos ya no falta ninguna pieza: las cinco capas, más la que dispara aunque nadie la invoque. Lo que falta no es construir otra capa. Es usarlo, y eso pide un ritmo.

Las cinco capas ya están puestas. Lo que sigue decide si el sistema sobrevive al mes dos: cuándo te sientas, cuánto rato, y qué haces exactamente en ese rato.

Veinte minutos al día, treinta el domingo y una hora al mes. Lo que importa no es el tamaño, es quién hace qué: sin las capas puestas, la mitad del bloque diario se te iría mudando archivos de una carpeta a otra. Con ellas puestas esa parte ya pasó sin ti, y los veinte minutos se van completos en lo único que no se delega: decidir.

Por eso cada bloque de aquí abajo dice dos cosas que antes no decía. Qué capa hace el trabajo, y qué parte del ritual viejo te quitaron de encima.

Un aviso de alcance antes de entrar: en esta parada se usa el resultado de una tarea programada, no se explica cómo se da de alta. Eso está en 10 automatizaciones con Claude, y qué le pasa a un vault cuando la corrida es en la nube quedó en la parada del latido.

Los tres bloques, con su desglose

Un supuesto del bloque diario, y conviene decirlo antes: la corrida que procesa el inbox es de mañana temprano y pasa en tu máquina, así que necesita la computadora despierta y la app de escritorio abierta. Hay un ajuste «Keep computer awake» que evita que se duerma sola por inactividad, pero cerrar la tapa la duerme de todos modos: para que esa corrida no se salte, la máquina se queda abierta. Si no corrió, el reflejo de arranque te dice cuántas capturas quedaron sin procesar y la corres tú ahí mismo, antes del minuto 3. Qué reloj le toca a cada tarea está en la parada del latido.

Las capturas de hoy ya están archivadas en 01-CAPTURES.

Busca conexiones fuertes entre lo que entró HOY y cualquier nota agregada al vault en los últimos 14 días.

Reglas:
- Solo cuentan cuatro tipos: el mismo principio en dos dominios distintos, dos notas que se contradicen, un patrón que aparece en tres notas o más, o una pregunta que otra nota responde por accidente.
- Si la conexión es obvia, no me la cuentes.
- Para cada una: nómbrala, dame el puente en una frase y una entrada posible.
- Máximo tres. Quiero la mejor, no todas.

Cierra diciéndome cuál de las tres vale más la pena trabajar como brief hoy, y por qué. Si hoy no hay ninguna que llegue, dilo en la primera línea: prefiero cero conexiones a tres forzadas.

Corre la sesión de conexiones semanal sobre todas las capturas de los últimos 7 días.

Cuando termines de generarlas:
1. Quédate con las dos más fuertes, medidas por una sola cosa: cuál me sorprendería más a mí, que fui quien escribió las notas.
2. De cada una, genera el brief completo y guárdalo en 03-BRIEFS.
3. Devuélveme la ruta de los dos briefs, cuál crees que pega más con mi audiencia y por qué.
4. Si algo se está repitiendo en las capturas de las últimas semanas y todavía no tiene nombre, ponle uno y dime si merece entrar al CLAUDE.md como pilar nuevo.

No inventes un patrón que no está. Prefiero que me digas que la semana salió floja.

Lee todo lo que hay en 04-PUBLISHED. Cada nota trae sus números en el frontmatter.

Basándote SOLO en ese material, dime:
1. Qué temas dieron más guardados por impresión. Por proporción, no por totales.
2. Qué entradas superaron el promedio de su propio tema. Cítalas textuales; no me digas "las agresivas".
3. Tres ángulos que mis mejores piezas sugieren y que todavía no he probado.
4. Qué combinación de tema y formato debería repetir este mes.

Reglas: nada de consejo genérico. Si una conclusión necesita más material para ser confiable, márcala así en vez de redondearla. Y si este mes tiene muy pocas piezas para concluir algo, dímelo en la primera línea y ahí párate.

Lo que se te quitó de encima

Si hoy es tu día uno

JARVIS no es la app. Es la práctica que compone con el tiempo, y compone de una forma bastante aburrida: al principio no se nota nada.

El cambio no llega el día que terminas de instalar las capas. Llega el día que abres el vault buscando una cosa y te topas con dos notas tuyas de hace tres meses que se contestan entre ellas. Ahí no hubo creatividad: hubo memoria bien ordenada. Buena parte de lo que llamamos creatividad es memoria con buen orden de búsqueda, y eso es exactamente lo que construye este ritual.

Sostén el ritmo un trimestre y aparece un problema nuevo, que además es de los buenos: el vault empieza a saber cosas que tú nunca le dijiste a Claude. Cómo decides, qué descartas siempre, con qué palabras abres. Eso está en tus notas y en ninguna configuración. La parada que sigue es la de cobrarlo.

A los noventa días pasa algo raro: el vault funciona y el agente sigue igual de listo que el primer día. Hace lo mismo, con las mismas cuatro skills y con el CLAUDE.md que escribiste antes de saber cómo ibas a trabajar de verdad.

Tus notas, mientras tanto, sí aprendieron. No en sentido figurado: ahí está escrito cómo decides. Qué capturaste y qué dejaste pasar. Qué conexión te pareció buena y cuál descartaste sin dar explicaciones. Qué entrada aguantó y cuál murió. Qué palabras usas cuando escribes sin pensar. Nada de eso está en ninguna de las cinco capas.

Cosechar es cobrarlo. Le pides al agente que lea tu propio archivo, encuentre lo que repites y lo escriba como instrucción. Es la única parte de este sistema donde el material no lo pones tú en el momento: ya lo pusiste, hace tres meses, sin darte cuenta de que lo estabas escribiendo.

Cosechar es mover una fila de la columna de la izquierda a la de la derecha. No es escribir mejores instrucciones de la nada: es leer las que ya escribiste sin querer.

Tres cosechas, en el orden en que conviene hacerlas

Lee todo lo que hay en 04-PUBLISHED/ y quédate con las diez piezas que mejor funcionaron según las métricas del frontmatter. Tu trabajo es destilar cómo escribo YO, no cómo se escribe bien.

1. Léelas una por una y anota patrones reales: cómo abro, cómo cierro, largo promedio de oración, signos que evito, palabras que repito, cómo meto un número, cómo hago una transición.
2. Nada de juicios tipo "tu tono es directo". Quiero patrones que se puedan seguir sin adivinar: "abres con una afirmación contraintuitiva de seis a nueve palabras y la contradices en la línea siguiente".
3. Escribe una sección llamada "Huella de voz" con ocho a doce patrones concretos, redactados como instrucciones para ti, no como descripción para mí.
4. Lista cinco muletillas mías: palabras o construcciones que aparezcan en más de tres piezas.
5. Lista cinco cosas que nunca hago, deducidas de lo que está ausente en las diez.
6. Aparte, marca los patrones que solo viste en una o dos piezas. Ésos todavía no son mi voz: son casualidad, y no quiero que se vuelvan regla.

Al final escribe dos párrafos de prueba sobre [UN TEMA CUALQUIERA] aplicando la huella. Si suenan a mí, quedó. Si suenan genéricos, dime qué patrón te faltó.

Enséñame todo en pantalla antes de escribir en ningún archivo.

Lee todas las notas de 02-CONNECTIONS/ y también las conexiones que quedaron ahí sin volverse brief.

1. Agrúpalas por el TIPO de movimiento que hice, no por tema. Un tipo se ve así: "tomé un número de un dominio y lo comparé con su equivalente en otro" o "encontré la contradicción entre lo que alguien dice y lo que hace".
2. Dime cuáles tres movimientos repetí más veces, con la cuenta y con dos ejemplos de cada uno.
3. Del que más repetí, reconstruye el procedimiento paso por paso: con qué empiezo, qué comparo, qué descarto, y cómo se nota que la conexión sirve.
4. Después dime qué conexiones se quedaron a medias y qué tenían en común. Ese es mi filtro de calidad, y va dentro del procedimiento: sin él la skill produce ruido.
5. Con eso escribe una skill nueva en .claude/skills/ del repositorio de este vault. La descripción tiene que decir en qué momento quiero que se use, con las palabras que yo usaría al pedirlo. El cuerpo lleva el procedimiento y el filtro.
6. Enséñame el nombre, la descripción y los pasos antes de crear el archivo.

Compara cada borrador de 03-BRIEFS/ que termina en -borrador.md con la versión que quedó publicada en 04-PUBLISHED/.

1. Para cada par, lista los cambios que hice yo. Cambios de contenido y de redacción; ignora los de formato.
2. Agrupa los cambios que se repiten en tres o más piezas. Ésas son mis correcciones de verdad, no accidentes.
3. Traduce cada grupo a una regla en imperativo, escrita para ti: qué hacer o qué no hacer, con un ejemplo del antes y el después sacado de mis propias piezas.
4. Separa las reglas en dos listas: las que aplican siempre, y las que solo aplican para un formato o una plataforma en particular.
5. Dime también qué corregí una sola vez. Eso todavía no es regla: márcalo como pendiente de confirmar y no lo mezcles con lo demás.
6. Enséñame las dos listas antes de escribir nada. Yo te digo cuál va al CLAUDE.md y cuál a un archivo de reglas.

Los tres prompts entregan el archivo escrito, pero no te enseñan el oficio: cómo se redacta una descripción que dispare en el momento correcto, qué va en el cuerpo, qué sobra y cuándo conviene que la skill sea personal o del proyecto está en el creador de habilidades. Lo único que agrega la cosecha es de dónde sale el contenido: de tu archivo, no de tu memoria.

La diferencia se ve a simple vista

Las dos quieren decir lo mismo. Solo una se puede seguir sin adivinar, y esa no la escribiste tú: salió de comparar tus borradores con lo que de verdad publicaste.

Por qué esto mejora en vez de degradarse

  ┌──► 1. trabajas a mano en el vault
  │        capturas · conexiones · borradores · correcciones
  │              │
  │              ▼
  │     2. cosechas lo que ya se repite
  │        huella de voz · skill nueva · reglas duras
  │              │
  │              ▼
  │     3. eso entra a la capa 1 y a la capa 2
  │        CLAUDE.md · .claude/rules/ · .claude/skills/
  │              │
  │              ▼
  │     4. el agente hace mejor la parte repetida
  │        y tú trabajas encima de eso, no debajo
  │              │
  └──────────────┘

Fíjate en la dirección de la flecha. Nada de esto empieza en la capa 1. Empieza en el trabajo: el agente no se vuelve más útil porque te sientes a escribirle mejores instrucciones, sino porque produjiste material del cual se pueden sacar mejores instrucciones.

Por eso un vault de un año con cosecha no se parece a uno de un año sin ella, aunque tengan las mismas notas adentro. Uno acumuló archivos. El otro acumuló procedimiento, y el procedimiento es lo único que se ejecuta solo.

Con esto el sistema queda completo: cinco capas, un ritual que las mueve y una cosecha que las vuelve a escribir con lo que aprendiste haciéndolo. Lo que sigue es la lista de lo que lo tira. Diez errores: cinco de conducta, que se ven venir y de todos modos se cometen, y cinco mecánicos, que no avisan y dejan al agente viéndose funcional mientras no hace nada.

Estos diez son los que matan el sistema, y se parten en dos mitades que no se arreglan igual. Los primeros cinco son de conducta: la máquina hace lo suyo y el que falla eres tú. Los otros cinco son mecánicos: tú haces todo bien y la máquina no ejecuta. Confundirlos cuesta semanas, porque a un problema mecánico le puedes echar disciplina encima todo el mes y no se mueve un milímetro.

Cada ficha abre por el síntoma. Búscate en el índice de abajo, salta a tu ficha, arregla eso. El resto lo lees otro día.

Búscate por el síntoma

Los cinco de conducta

Ninguno de estos cinco se arregla con una configuración. Todos se arreglan decidiendo una cosa y sosteniéndola.

Los cinco mecánicos

Estos cinco no dan error. Ésa es la parte cara: el sistema no se queja, simplemente hace algo genérico o no hace nada, y tú lo lees como «no funcionó» y lo apagas.

Si tu CLAUDE.md no aparece ahí, no está cargado, por muy bien escrito que esté. El comando hermano, /memory, te lista los archivos de instrucciones y el interruptor de la memoria automática.

El manual de operación de las tareas programadas vive en 10 automatizaciones con Claude. Aquí solo va la parte que esa página no cubre: lo que le pasa a un vault cuando el que trabaja es el reloj.

Los cinco de conducta los sabes tú. Los mecánicos se ven en los archivos, y hay un prompt al pie de esta página que descarta los tres que dejan una tarea programada en blanco —las skills que no viajaron, la skill que no se puede disparar y el CLAUDE.md que no se cargó— mirando tu instalación de verdad. Los otros dos, el de la memoria que no cruza máquinas y el de la rutina que corre sin permisos, no se diagnostican con un prompt: se revisan abriendo la corrida y leyendo qué hizo.

Falta el error once, que no es una ficha porque es de orden: montar el latido antes de que el flujo te salga bien a mano. La regla es que una tarea se programa cuando ya la hiciste tú varias veces y el resultado te gustó; el argumento completo está en el orden de montaje de las cinco capas.

Con esto ya sabes qué se rompe, cómo se ve cuando se rompe y por dónde se entra a arreglarlo. Falta la prueba de que el esqueleto no era de contenido: la última parada cambia el dominio entero —ventas, finanzas, estudio— sobre las mismas cinco capas, y cierra con el prompt maestro que te entrevista y lo escribe completo.

Trece paradas atrás esto arrancó pareciendo un vault de contenido. No lo es. Lo que quedó armado es un agente al que le tocó vivir dentro de una carpeta de notas, con sus cinco capas puestas: memoria, habilidades, equipo, sentidos y latido.

Ninguna de esas cinco capas sabe de qué trata tu trabajo. Cambia lo que hay adentro de cada archivo y tienes otro agente, con la misma estructura y las mismas decisiones de diseño. Esta última parada es esa prueba, y termina con el prompt que lo construye para tu caso.

Esto ya está construido, y no es de contenido

Antes de proponerte nada, mira un agente que ya está publicado en la bóveda y que no tiene una sola nota adentro. Su trabajo es vender: sale a buscar negocios que encajan con lo que ofreces, verifica cuáles siguen vivos, descarta los que no y redacta el primer correo con un dato real de cada uno.

El agente de prospección de Apify · Clientes ilimitados no sabe qué es un brief y nunca abrió Obsidian. Pero si abres su carpeta, adentro están exactamente las mismas cinco piezas, en los mismos lugares.

Y con el mismo límite que ya conoces de la parada del latido: esa tarea vive en tu máquina, así que necesita la computadora despierta. Cambia el dominio y cambia el contenido de cada archivo. La estructura de carpetas no, y las decisiones de diseño tampoco: qué carga siempre, qué carga bajo demanda, qué corre aparte y qué corre solo.

Tres agentes que se parecen más de lo que crees

Estos tres no existen todavía: son plantillas para que veas la mecánica. Léelos en vertical y son tres agentes que no tienen nada que ver entre sí. Léelos en horizontal y ninguna fila cambió de trabajo.

La memoria siempre es lo que no quieres volver a explicar. Las habilidades siempre son lo que se repite con la misma forma. El equipo siempre es lo que ya no cabe en un solo contexto. Los sentidos siempre son lo que está fuera de la carpeta. Y el latido siempre es lo último. Si tu caso no entra en esas cinco frases, probablemente todavía no está bien acotado.

Lo que no cambia, cambies lo que cambies

El contenido de cada capa es tuyo. Estas cinco reglas no, y son las que se rompen primero cuando alguien adapta el esqueleto a su dominio sin releer las mecánicas.

• El CLAUDE.md va en la raíz del proyecto, nunca en una subcarpeta, y se queda corto.
• Cada habilidad es una carpeta con su SKILL.md adentro, dentro del proyecto. Su descripción tiene que decir cuándo usarla, no qué es, porque es lo único que Claude lee para decidir si la abre. Y si algún día quieres que corra en la nube, tiene que estar committeada en el repositorio: una skill personal de tu máquina no existe allá.
• El equipo se agrega cuando una sola tarea ya te llena el contexto, no antes. Un subagente sin un trabajo con principio y fin es un rodeo caro: le pagas la ventana entera para que te devuelva un párrafo.
• El latido va al final, siempre. Primero corres el trabajo a mano hasta que salga bien varias veces seguidas, y hasta entonces lo programas.
• La cosecha llega a los noventa días, no a las dos semanas. Antes de eso el sistema todavía no sabe nada que tú no le hayas dicho, y no hay skill que sacar de ahí.

Dos de esas reglas se explican en otra parada de esta misma página. Cuánto es «corto» para un CLAUDE.md, de dónde sale esa cifra y qué se hace con lo que no cabe está en la parada de la memoria. Aquí basta con dejarlo en la raíz.

Y por qué programar algo que todavía no sale bien a mano te sale caro está en la parada de la anatomía. Aquí basta con respetar el orden: el latido se prende al último.

El prompt maestro

Este es el entregable de la página. No te da una plantilla: te entrevista, te enseña el diseño de tus cinco capas y espera tu aprobación antes de escribir un solo archivo. Va en una carpeta nueva y vacía, con Claude Code abierto adentro, de preferencia en modo plan.

La parte que da flojera es la que sirve. Si te saltas la entrevista y le pides que construya de una vez, vas a terminar con la estructura de otra persona con tus nombres encima.

Vamos a construir un agente personal para mi trabajo. No crees ningún archivo todavía. Primero entrevístame, después enséñame el diseño completo, y solo cuando yo escriba "aprobado" empiezas a escribir en disco.

CONTEXTO: un agente personal tiene cinco capas.
1. Memoria — lo que sabe de mí sin que se lo repita. Vive en un CLAUDE.md en la raíz del proyecto.
2. Habilidades — un instructivo por trabajo, que se carga solo cuando toca. Cada uno en su carpeta, en .claude/skills/.
3. Equipo — subagentes con su propio contexto y sus propias herramientas, en .claude/agents/.
4. Sentidos — de dónde saca lo que no está en la carpeta: archivos que yo dejo ahí, conectores, servidores MCP.
5. Latido — lo que lo despierta sin que yo abra nada. ESTA CAPA NO SE MONTA HOY.

FASE 1 · ENTREVISTA
Hazme estas preguntas de una en una y espera mi respuesta antes de la siguiente. Si te contesto algo vago, repregunta una vez pidiéndome un ejemplo concreto antes de seguir.
1. ¿Qué trabajo repito cada semana y me gustaría dejar de hacer a mano? Descríbemelo como si me estuvieras viendo hacerlo.
2. ¿Qué decisiones tomo dentro de ese trabajo y con qué criterio? Dame dos casos reales: uno donde dije que sí y uno donde dije que no.
3. ¿Qué información consulto para decidir y dónde vive? Archivos, correo, calendario, una hoja de cálculo, o nada más mi cabeza.
4. ¿Cómo se ve un buen resultado y cómo se ve uno malo? Un ejemplo de cada uno.
5. ¿Qué no debe hacer nunca, ni aunque parezca buena idea? Mandar algo sin que yo lo lea, borrar cosas, gastar dinero, tocar ciertos archivos.
6. ¿Cada cuánto pasa esto: diario, semanal, mensual, o cuando llega algo de fuera?
7. ¿Cuánto de todo esto ya está escrito en algún lado que yo te pueda dar hoy mismo?

FASE 2 · DISEÑO (todavía sin crear archivos)
Devuélveme en una sola respuesta, en español:
- Las cinco capas rellenadas para MI caso, una por una, diciendo qué va en cada una y por qué.
- Los nombres exactos de las habilidades que propones, entre dos y cuatro, no más, y en qué momento se dispara cada una.
- Los subagentes que propones para empezar, cero, uno o dos, qué trabajo cerrado hace cada uno y qué herramientas le recortas.
- El árbol de carpetas completo, con el CLAUDE.md en la raíz.
- Lo que decidiste dejar fuera y por qué. Esta parte no te la saltes.
Después pregúntame si lo apruebo. Si te pido cambios, rehaz el diseño completo, no le pongas un parche.

FASE 3 · CONSTRUCCIÓN (solo con mi aprobación explícita)
Construye en este orden y enséñame cada archivo antes de pasar al siguiente:
1. El CLAUDE.md en la raíz. Menos de 200 líneas. Quién soy, qué es este proyecto, qué se guarda en cada carpeta, cómo se ve un buen resultado, y las reglas duras que no se rompen.
2. Las carpetas del árbol, cada una con un archivo de una línea que diga qué va ahí adentro.
3. Las habilidades, una por una, cada una en su carpeta con su SKILL.md. La descripción de cada una tiene que decir CUÁNDO usarla, con las palabras que yo usaría, no qué es.
4. Los subagentes, uno por archivo, con la lista de herramientas recortada a lo mínimo que necesitan para su trabajo.
5. Un archivo PRIMERA-SEMANA.md con las cinco cosas que tengo que hacer a mano esta semana para comprobar que el diseño sirve.

REGLAS
- No montes tareas programadas, no escribas hooks y no configures nada que corra solo. El latido va después, cuando el sistema ya haya funcionado a mano varias veces. Si te lo pido hoy, recuérdame esta línea.
- No inventes datos míos. Si te falta uno, deja el hueco marcado y dime cuál es.
- Nada de código. Todo lo que escribas es markdown y prosa en español.
- Si el diseño te pide más de cuatro habilidades, es señal de que el trabajo no está bien acotado. Dímelo en vez de crecer.

Lo que te devuelve la fase 2 vale por sí solo, aunque nunca construyas nada. Es tu trabajo descrito por capas, con la lista de lo que quedó fuera. La mayoría de la gente nunca ha visto eso escrito.

Esto compone porque cada capa le baja el costo a la siguiente, y en ese orden: memoria, habilidades, equipo, sentidos, latido. Por eso el orden importa, y por eso el latido es lo último que se prende.