Tus agentes no se leen la mente. Se leen el mismo cuaderno.
Armas un equipo: uno busca, otro escribe, otro revisa. Y en vez de ir más rápido, vas más lento, porque cada agente arranca en blanco y vuelve a buscar lo que el anterior ya encontró. La solución no es un modelo mejor: es un cuaderno compartido dentro del repo, con reglas de quién escribe dónde. Esta edición trae además las tres memorias que hoy se llaman casi igual y casi nadie distingue, dónde vale la pena que un equipo piense caro con ultrathink, y qué cambia cuando corres todo esto desde la app de escritorio.
Las ocho paradas · de un vistazo
Cada agente arranca en blanco
Un subagente hereda tu CLAUDE.md, pero no hereda tu mensaje ni lo que averiguó el agente anterior.
Tres cosas distintas se llaman igual
La tuya en el repo, la que Claude escribe solo en tu máquina, y la privada de cada agente. No son la misma.
Ocho archivos y seis reglas
Cuatro para empezar, cuatro para cuando escales. Y el protocolo que le enseña las reglas a cada agente.
Un agente, un trabajo, un archivo
Los cuatro roles base con el frontmatter al día, y cómo se cambian por los tuyos en dos minutos.
Dónde piensa caro un equipo
Tres momentos donde paga sola y tres donde es desperdicio. Y por qué la palabra va en el prompt del orquestador, no en el tuyo.
Qué se commitea y qué no
Para que alguien clone el repo y le llegue el palacio completo: agentes, protocolo, cuaderno y ajustes.
El mismo cuaderno, con GUI
La app lee los mismos archivos que la terminal. Y trae una trampa: cada sesión nueva abre su propio worktree.
El equipo resolviendo algo, en vivo
Un email de lanzamiento de principio a fin, con el equipo de marketing, y el checklist de que funciona.
Guía comunidad · 6 de agosto de 2026
Un cuaderno en el repo, seis reglas, cuatro agentes con un archivo de escritura cada uno. Ocho paradas y todo copiable.
Claude Code ya tiene una memoria propia que guarda notas solo, y por eso mucha gente cree que este patrón ya no hace falta. Hace falta: esa memoria vive en tu máquina, no viaja a git, y no se carga dentro de los subagentes. El cuaderno del repo sí hace las tres cosas, y es lo que convierte a un equipo de agentes en algo que se acumula en vez de repetirse. Adentro: la tabla que distingue las tres memorias, el protocolo de seis reglas para pegar en tu CLAUDE.md, los cuatro agentes con el frontmatter al día —incluido el campo que ajusta cuánto piensa cada rol—, los tres momentos exactos donde ultrathink paga sola en un equipo repartido y los tres donde es puro desperdicio, qué se commitea para que un compañero clone el repo y tenga el palacio completo, y la trampa de la app de escritorio que nadie ha escrito: cada sesión nueva abre su propio worktree, así que dos sesiones en paralelo escriben en dos copias del mismo cuaderno.
01 · el problema
Cada agente arranca en blanco
Armas el equipo que todo el mundo recomienda: uno busca, otro escribe, otro revisa. Y el resultado sale al revés del folleto. El segundo vuelve a buscar lo que el primero ya había encontrado. El tercero levanta como problema algo que el segundo ya resolvió y hasta justificó. Sumas agentes y el trabajo tarda más, no menos.
No es que el modelo esté flojo ni que hayas definido mal los roles. Es dónde vive lo que cada uno averigua.
Qué hereda de verdad un subagente
Un subagente es una sesión aparte que se lanza para una tarea acotada y que devuelve un resultado. Lo que casi nadie tiene claro es qué entra a esa sesión y qué se queda afuera, y esa lista explica el problema entero.
| lo que sí le llega | lo que no |
|---|---|
| Toda la jerarquía de CLAUDE.md: el archivo de instrucciones del repo, el tuyo de usuario y los de las subcarpetas que toque. | Tu mensaje. Lo que tú escribiste en el chat no viaja con él. |
| El prompt con el que lo lanzaron, que es literalmente todo su encargo. | La conversación principal. Ni lo que pediste hace diez turnos ni lo que Claude te respondió. |
| Las herramientas y los permisos que le dejaste puestos en su definición. | La memoria automática de Claude Code, esa que se escribe sola en tu máquina. La doc lo dice en seco: la memoria automática de la conversación principal no se carga. |
| Los archivos que él mismo abra con su herramienta de lectura, si su prompt le dice cuáles abrir. | Lo que averiguó el subagente anterior, aunque haya corrido hace treinta segundos en la misma tarea. |
Una excepción a la primera fila: los agentes Explore y Plan que trae Claude Code se saltan la jerarquía de CLAUDE.md a propósito.
ES DE DISEÑO
La burbuja no es una falla
Ese aislamiento es justo lo que hace que un subagente valga la pena. Su sesión no carga tu historial, así que puede leer veinte archivos sin gastarte el contexto de la conversación principal, o sea el espacio de lectura que Claude tiene disponible antes de tener que resumir para seguir.
El precio del ahorro es el olvido. Lo único que recibe es un prompt y lo único que devuelve es un resumen. Todo lo que leyó, comparó y descartó en el camino se va con la sesión cuando termina.
HONESTIDAD
Sí hay una forma de retomar a un agente, y no alcanza
Claude Code tiene hoy una herramienta, SendMessage, que retoma un subagente ya lanzado con su historial completo: le puedes pedir una segunda vuelta sin volver a explicarle nada. Es real y sirve.
Sirve dentro de una conversación. No sirve para que un agente que estrenas mañana sepa lo que se resolvió hoy, ni para que tu compañero lo sepa cuando clone el repo. Para eso es el cuaderno.
Orquesta con Claude · cómo se reparte el trabajo entre subagentes
Lo que falta no es un modelo más listo. Es un lugar fuera de la sesión donde lo que se averigua quede escrito.
01 · la fórmula
Todos leen y todos escriben en el mismo lugar
La solución cabe en una línea: un solo cuaderno compartido, con estructura clara, dentro del repo. Repo es la carpeta del proyecto que se versiona con git, la misma que clonas y que subes. Todos los agentes leen ese cuaderno antes de empezar y todos escriben en él al terminar.
Funciona por algo casi tonto: los agentes no comparten conversación, pero sí comparten la carpeta del proyecto. Si el hilo no puede pasar por el chat, pasa por el disco.
Lo importante no es la herramienta, es la estructura
Son tres piezas y ninguna es un producto que tengas que instalar. Ya están en cualquier proyecto donde uses Claude Code.
- Una carpeta memory/ con archivos de texto separados por tema: qué se decidió, qué se investigó, qué está bloqueado. Uno por tema, nunca un archivo gigante donde se pierda todo.
- Un CLAUDE.md en la raíz con el protocolo: quién lee qué antes de trabajar y quién escribe dónde al terminar. Es lo único que todos los agentes reciben sin pedirlo.
- Unos archivos en .claude/agents/ que definen a cada agente, con un archivo de escritura propio para cada uno, de forma que dos nunca se peleen la misma línea.
Qué cambia en la práctica
Sin cuaderno, cada sesión arranca de cero: vuelves a explicar el tono de la marca, vuelves a contar qué ya se decidió, vuelves a marcar qué no se toca. Con cuaderno, la sesión 20 arranca con todo lo de la 1 a la 19 ya escrito.
Y no es solo tu historial. Un agente que estrenas hoy sabe lo mismo que el orquestador de ayer, porque lee los mismos archivos. Tu compañero clona el repo y le llega el cuaderno completo sin que le cuentes nada.
La misma tarea, con cuaderno y sin cuaderno
se evapora
El investigador leyó seis archivos, comparó dos caminos y te dijo en el chat cuál conviene.
queda escrito
El investigador escribió el hallazgo, con la fuente y la fecha, en memory/research.md y lo apuntó en el índice.
El primero le sirvió a esa conversación. El segundo le sirve a cualquier agente que abra el repo después, incluido el que lances la semana que viene.
EL ARGUMENTO DURO
Qué sobrevive a la compactación
Cuando una conversación se llena, Claude Code la compacta: resume lo que hubo hasta ahí y sigue trabajando con el resumen. Ese momento es donde se nota la diferencia entre tener un archivo y tener un contexto.
Lo que vuelve solo, porque Claude Code lo re-inyecta desde disco: el CLAUDE.md de la raíz y la memoria automática. Regresan enteros, porque nunca dejaron de existir en un archivo.
Lo que se pierde: lo que un agente leyó con su herramienta de lectura, igual que cualquier otra lectura. También se caen las reglas de .claude/rules/ que están atadas a rutas de archivos, hasta que se vuelva a abrir un archivo que las active.
Por eso el cuaderno vive en el repo y no en la cabeza de nadie. Un archivo se vuelve a abrir cuando haga falta. Un contexto que se evaporó, no.
Lo que sigue es cómo se ve ese cuaderno por dentro, quién escribe en qué archivo y las seis reglas que lo mantienen ordenado cuando hay cuatro agentes trabajando a la vez.
02 · las tres memorias
Tres cosas distintas se llaman casi igual
Si hoy abres un proyecto con Claude Code y buscas la memoria, te vas a topar con tres cosas diferentes. Dos viven en una carpeta llamada memory/. Dos tienen un archivo índice. Y ninguna hace el trabajo de la otra.
La confusión no es culpa tuya. Claude Code trae una memoria automática cuya carpeta también se llama memory/ y cuyo índice se llama MEMORY.md. Viene prendida por defecto desde la instalación, así que lo más probable es que ya la tengas corriendo sin haberla pedido. El día que montes el cuaderno de esta guía vas a tener dos carpetas memory/ y dos archivos índice, con reglas distintas cada una.
Conviene separarlas de una vez y para siempre, porque la diferencia decide si el trabajo repartido entre varios agentes se acumula o se repite. Las tres, lado a lado:
| la pregunta | memory/ · el cuaderno del repo | la auto memory de Claude Code | .claude/agent-memory/ · la del agente |
|---|---|---|---|
| Quién la escribe | Tú y tus agentes, a propósito, siguiendo el protocolo que pegaste en el CLAUDE.md. | Claude solo, mientras trabaja contigo. Nadie se lo pide. | El propio subagente, y solo si su archivo de configuración trae el campo memory:. |
| Dónde vive | Dentro del repo, en memory/. Es un archivo más del proyecto. | Fuera del repo, en ~/.claude/projects/<proyecto>/memory/. | En .claude/agent-memory/<agente>/ cuando el alcance es project. Con user o local aterriza en otro lado. |
| ¿Se sube a git? | Sí. Quien clona el repo se lleva el cuaderno completo. | No. La doc lo dice sin rodeos: los archivos no se comparten entre máquinas ni entornos en la nube. | Solo con el alcance project. Los alcances user y local se quedan en tu computadora. |
| ¿La ven los subagentes? | Sí, porque el protocolo les ordena abrirla y ellos la abren con la herramienta de lectura. | No. La memoria automática de la conversación principal no se carga dentro de un subagente. | Solo el agente dueño. Es privada suya: ningún otro rol del equipo la lee. |
| Para qué sirve | Que lo que descubrió un agente quede escrito para el siguiente y para tu equipo. | Que tu conversación principal recuerde tus preferencias y el contexto del proyecto entre sesiones, en esta máquina. | Que un agente que corres seguido no vuelva a aprender lo mismo cada vez. |
01 · la de esta guía
memory/ — el cuaderno compartido del repo
Es la carpeta que montas tú dentro del proyecto: ocho archivos de texto y un INDEX.md que los mapea. La escriben tus agentes cuando terminan su parte, y la escribes tú cuando corriges algo.
Vive en el repo, o sea en la carpeta del proyecto que se versiona con git, el sistema donde queda el historial y desde donde tu equipo clona. Por eso se sube igual que cualquier otro archivo: un compañero clona y le llega el cuaderno entero, con todo lo que los agentes dejaron escrito.
La ve cualquier agente que la abra, y esa palabra es literal. Nadie se la inyecta por estar mencionada en el CLAUDE.md: el agente la abre con la herramienta de lectura porque el protocolo le dice que su primer paso es abrir INDEX.md.
Es la única de las tres que viaja entre computadoras y entra al trabajo repartido.
02 · viene prendida por defecto
~/.claude/projects/<proyecto>/memory/ — la auto memory
Es nativa de Claude Code y arranca encendida. Claude escribe ahí por su cuenta mientras trabajan juntos: lo que va aprendiendo de tus preferencias y del proyecto se le queda en notas que tú no pediste.
Adentro hay un MEMORY.md que funciona como índice, más archivos por tema. Al inicio de cada conversación se cargan las primeras 200 líneas de ese MEMORY.md o 25 KB, lo que llegue primero. Los archivos por tema no se cargan al arranque: Claude los abre cuando los necesita.
Es de tu máquina y nada más. La documentación lo pone así: los archivos no se comparten entre máquinas ni entornos en la nube. No entra a git, tu equipo no la ve, y si cambias de computadora se queda atrás.
Y el detalle que lo decide todo para esta guía: la memoria automática de la conversación principal no se carga dentro de los subagentes. El agente al que le delegas trabajo no la ve.
Se apaga desde el toggle de /memory, con autoMemoryEnabled: false en tus settings, o con la variable de entorno CLAUDE_CODE_DISABLE_AUTO_MEMORY=1. No hace falta apagarla.
03 · privada de cada agente
.claude/agent-memory/<agente>/ — la memoria de un subagente
Sale del campo memory: en el frontmatter del archivo del subagente, o sea en las primeras líneas de configuración de ese .md. Si no lo pones, ese agente no tiene memoria propia y punto.
Tiene tres alcances y cada uno cambia dónde aterriza la carpeta: user la manda a ~/.claude/agent-memory/<agente>/, project a .claude/agent-memory/<agente>/, y local a .claude/agent-memory-local/<agente>/.
project es el recomendado y el único que se versiona, porque es el que queda dentro del repo y viaja a git con el proyecto. Los otros dos se quedan en tu computadora.
Es privada de ese agente. No es un cuaderno compartido: ningún otro rol del equipo la lee, así que no sirve para pasarse trabajo entre agentes. Sirve para que un agente que corres seguido no empiece de cero cada vez.
Complemento del cuaderno, nunca su reemplazo.
LA PREGUNTA OBVIA
Si Claude ya guarda notas solo, para qué montar un cuaderno a mano
Es la duda razonable de cualquiera que ya tenga la memoria automática funcionando. La respuesta son tres huecos, y los tres pegan exactamente donde un equipo de agentes se rompe:
- No viaja a git. Vive en tu máquina, así que tu equipo no la ve y tú la pierdes en cuanto cambias de computadora.
- No entra a los subagentes. La memoria automática de la conversación principal no se carga dentro de ellos, y el trabajo repartido pasa justo por ahí.
- No la controlas tú. Claude decide qué guardar y cómo redactarlo. No hay protocolo, no hay formato de entrada, no hay quién escribe dónde.
El cuaderno del repo hace las tres al revés: se sube a git, lo abre cualquier agente al que le digas que lo abra, y lo que se escribe adentro lo mandas tú con seis reglas. Por eso sigue siendo la respuesta cuando el trabajo está repartido entre varios agentes.
AVISO DE UX
/memory no te va a mostrar tu cuaderno
Si tecleas /memory esperando ver la carpeta que acabas de montar, no la vas a encontrar. Ese comando hace otras tres cosas: lista tus archivos CLAUDE.md y CLAUDE.local.md, deja prender o apagar la memoria automática, y abre la carpeta de esa memoria automática. Ninguna de las tres toca memory/.
Tu cuaderno se abre como cualquier otro archivo del repo: pidiéndole a Claude que lo lea, o abriéndolo tú en el editor.
Y si lo que andas buscando son herramientas de terceros que persistan memoria entre sesiones, eso es otro tema y tiene su propia guía:
Memoria en Claude Code · qué recuerda y qué se le olvida entre sesiones
Las tres pueden convivir sin estorbarse y no hay que apagar nada: la automática te sigue ayudando en tu conversación, cada agente puede tener la suya, y el cuaderno del repo es el que mantiene a todo el equipo leyendo lo mismo.
03 · el cuaderno
Ocho archivos, cuatro agentes, cero confusión
El cuaderno son ocho archivos markdown dentro de una carpeta llamada memory/, en la raíz de tu proyecto. Markdown es texto plano con títulos y listas: se abre en cualquier editor, se lee sin herramientas y se sube a git como cualquier otro archivo del repo.
Cada archivo tiene un propósito y un dueño. No arrancas usando los ocho: creas los ocho vacíos, trabajas con los primeros cuatro, y los otros cuatro se empiezan a llenar solos cuando el equipo crece o el proyecto lleva días.
Así se ve completo. Arriba el cuaderno. Abajo la carpeta .claude/agents/, donde vive la definición de cada agente: esos cuatro archivos los escribes en la sección siguiente.
memory/ ├── INDEX.md ← mapa del cuaderno (TOC + últimas entradas) ├── context.md ← misión, alcance, stakeholders ├── decisions.md ← decisiones tomadas y por qué ├── research.md ← hallazgos del investigador ├── code-notes.md ← decisiones de código, patrones, trampas │ (si no programas: renómbralo a drafts.md) ├── reviews.md ← hallazgos de revisión + fixes ├── blockers.md ← unknowns y bloqueos activos └── glossary.md ← terminología del proyecto .claude/agents/ ├── investigador.md ├── coder.md ├── revisor.md └── orquestador.md
para empezar
Core 4 — arranca con esto
INDEX.md, context.md, decisions.md y research.md. Con estos cuatro ya tienes un cuaderno funcionando el primer día.
El que busca escribe en research. El que coordina escribe en decisions. context guarda la misión y el alcance para que nadie se salga del carril. Y el INDEX los conecta: es el mapa, el primer archivo que cualquier agente abre.
Cuatro archivos y dos agentes ya se notan. No necesitas más para probar el patrón hoy.
cuando crezcas
Extended 4 — activa al escalar
code-notes.md, reviews.md, blockers.md y glossary.md. Los creas vacíos desde el principio y los dejas ahí.
Entran en juego cuando sumas agentes: quien produce anota sus trampas en code-notes, quien revisa deja hallazgos en reviews, blockers junta lo que nadie ha podido resolver todavía, y glossary fija cómo se llaman las cosas en este proyecto para que dos agentes no le pongan dos nombres a lo mismo.
Un archivo vacío no estorba. Uno que no existe rompe el protocolo el día que un agente lo va a buscar.
SI NO PROGRAMAS, LEE ESTO
code-notes.md se llama drafts.md en un equipo que no escribe código
El archivo donde quien produce anota lo que decidió se llama code-notes.md porque este patrón nació en repos de código. Si tu equipo hace emails, guiones, propuestas o campañas, ese mismo archivo se llama drafts.md y guarda exactamente lo mismo: qué elegiste, qué casi rompes y de dónde sacaste el patrón que seguiste.
Lo pongo aquí en grande porque la versión anterior de esta guía lo decía en una sección y lo olvidaba en el protocolo, así que quien no programaba terminaba pegando en su CLAUDE.md un texto que le hablaba de un archivo que nunca creó.
El protocolo de la sección siguiente ya trae las dos formas escritas, así que lo puedes pegar tal cual. Solo renombra el archivo en memory/, renombra la línea que le corresponde en INDEX.md, y sigue.
La regla de oro del cuaderno es una sola: cada agente escribe en un archivo y nada más. Dos agentes que nunca abren el mismo archivo para escribir no se pisan la línea.
paso 01 · crea el cuaderno
Un comando monta toda la estructura
Desde la raíz de tu proyecto, que es la carpeta principal donde también va a vivir el CLAUDE.md, corre este comando. Crea la carpeta memory/ con los ocho archivos vacíos y la carpeta .claude/agents/, que es donde van a vivir tus agentes.
Los ocho archivos nacen en blanco a propósito. El cuaderno se llena con el trabajo del equipo, no con plantillas de relleno que nadie va a leer.
Monta la estructura — bash y zsh
mkdir -p memory .claude/agents && touch memory/{INDEX,context,decisions,research,code-notes,reviews,blockers,glossary}.mdLa parte entre llaves —memory/{INDEX,context,...}.md— se llama expansión de llaves y es una función de bash y zsh: convierte esa lista en las ocho rutas de un jalón. PowerShell y cmd no la entienden, así que si estás en Windows usa la variante de abajo.
Monta la estructura — PowerShell (Windows)
New-Item -ItemType Directory -Force -Path memory,.claude\agents; "INDEX","context","decisions","research","code-notes","reviews","blockers","glossary" | ForEach-Object { New-Item -ItemType File -Force -Path "memory\$_.md" }Con las carpetas puestas, pega esto como contenido inicial de memory/INDEX.md. Es el mapa del cuaderno: el primer archivo que cualquier agente abre y el que le dice dónde está todo lo demás.
memory/INDEX.md — plantilla inicial
El mapa del cuaderno. Cada agente lo lee primero y le agrega una línea al terminar su parte.
# INDEX — Memory Palace > Mapa del cuaderno. Toda entrada nueva se referencia aquí en una línea. ## Archivos activos - [context](context.md) — misión y alcance - [decisions](decisions.md) — decisiones tomadas y por qué - [research](research.md) — investigación en curso - [code-notes](code-notes.md) — decisiones de código (o drafts.md si no programas) - [reviews](reviews.md) — hallazgos de revisión - [blockers](blockers.md) — unknowns activos - [glossary](glossary.md) — terminología del proyecto ## Últimas entradas <!-- formato: - [AAAA-MM-DD] [agente] → archivo#anchor — título -->
paso 02 · las reglas
El archivo que le enseña el cuaderno a cada agente
Todo agente que abre este proyecto lee el CLAUDE.md antes de hacer nada, y eso incluye a los subagentes: heredan completa la jerarquía de archivos de instrucciones. La única excepción documentada son los agentes integrados Explore y Plan, que se la saltan.
Ahí adentro van las seis reglas del cuaderno, escritas una sola vez para todo el equipo. Estas son, en corto, antes de que las pegues.
Lee antes de escribir
Primero abres INDEX.md y los archivos de tu rol. Después empiezas.
Y aquí va la aclaración que evita el fallo número uno del patrón: "lee INDEX.md" significa que el agente abre el archivo con su herramienta de lectura. Mencionarlo en el CLAUDE.md deja la instrucción, no inyecta el contenido. Si el agente no lo abre, no sabe qué dice.
Escribe con fecha y nombre
Cada entrada arranca con ### [AAAA-MM-DD] [agente] — título. Con eso sabes quién escribió qué y cuándo sin abrir el historial de git.
No borres lo de otro
Si algo quedó viejo, se tacha con ~~así~~ y se queda ahí. Saber qué se descartó le ahorra al siguiente agente la vuelta de volver a proponerlo.
Contradice con aviso
Si tu hallazgo rompe una decisión previa, no la sobrescribes: abres una entrada nueva en decisions.md con CONFLICTO: al inicio. El orquestador resuelve y deja escrito por qué.
Actualiza el INDEX al terminar
Una línea por entrada nueva. Si el índice no creció, la tarea no se cerró.
Respeta tu archivo
Un agente, un archivo de escritura. Si necesitas escribir en otro, se lo pides al orquestador. Eso es lo que evita que dos agentes editen el mismo archivo a la vez y uno pise al otro.
Pega este bloque en el CLAUDE.md de la raíz. Si ya tienes uno, va al final, después de una línea en blanco.
CLAUDE.md — el protocolo del equipo
Las seis reglas, la lista de los ocho archivos y quién escribe dónde. Va tal cual en la raíz del proyecto.
# Equipo de agentes — Memory Palace
Todo agente que trabaje en este repo (principal o sub) lee y escribe en
`memory/` siguiendo este protocolo.
## Qué NO es esta carpeta
`memory/` es el cuaderno compartido del equipo: vive en el repo y se sube a
git. No es la memoria automática de Claude Code, que vive fuera del repo, es
de una sola máquina y no se carga dentro de los subagentes. Cuando el
protocolo dice "memoria", habla de esta carpeta.
## Archivos (Core 4 — arranca con estos)
- memory/INDEX.md → mapa del cuaderno (TOC + últimas entradas)
- memory/context.md → misión, alcance, stakeholders
- memory/decisions.md → decisiones tomadas (fecha, autor, por qué)
- memory/research.md → hallazgos de investigación
## Archivos (Extended — activa cuando escales)
- memory/code-notes.md → patrones y trampas de quien produce
(equipos que no programan: drafts.md)
- memory/reviews.md → hallazgos de revisión + fixes aplicados
- memory/blockers.md → unknowns, bloqueos activos
- memory/glossary.md → terminología del proyecto
## Protocolo (6 reglas — obligatorias)
1. Antes de trabajar: lee INDEX.md + los archivos relevantes a tu rol.
"Lee" significa abrirlos con la herramienta de lectura. Nadie te los
inyecta solo por estar mencionados aquí.
2. Al terminar: añade entrada con formato `### [AAAA-MM-DD] [agente] — título`.
3. Nunca borres lo que otro escribió. Marca obsoleto con `~~texto~~`.
4. Si contradices una decisión, NO la sobrescribas: escribe en decisions.md
con prefijo "CONFLICTO:" y avisa al orquestador.
5. Mantén INDEX.md actualizado: una línea por entrada nueva.
6. Cada agente escribe en UN solo archivo de memoria. Si necesitas otro,
pide al orquestador que lo haga por ti.
## Dónde se piensa a fondo
La palabra `ultrathink` sube el razonamiento de un turno. En este equipo se
usa en tres momentos y no en más: planear el reparto, resolver un
"CONFLICTO:", y sintetizar los retornos en una decisión. Y va en el prompt
del agente que va a pensar — cada subagente arranca sin ver el mensaje que le
escribiste al orquestador.
## Roles disponibles (.claude/agents/)
- investigador → lee todo, escribe en research.md
- coder → lee research + decisions, escribe código y code-notes.md
- revisor → lee código + code-notes, escribe en reviews.md
- orquestador → lee todo, escribe decisions.md + INDEX.md, delega a los demás
La disciplina del cuaderno es más importante que la herramienta. Si añades un
5.º agente, dale un archivo de escritura único y agrégalo aquí.
DOS DETALLES DE UBICACIÓN
Dónde ponerlo, y qué hacer si tu CLAUDE.md ya está gordo
El archivo puede vivir en la raíz como CLAUDE.md o dentro de la carpeta del proyecto como ./.claude/CLAUDE.md. Las dos rutas son válidas y los archivos de la jerarquía se concatenan, no se sobrescriben: lo que ya tengas en tu CLAUDE.md personal sigue vigente y este protocolo se suma abajo.
La recomendación oficial es apuntar a menos de 200 líneas por CLAUDE.md. Si el tuyo ya anda cerca, el protocolo se puede mudar a la carpeta .claude/rules/, que es el mecanismo oficial para partir instrucciones en archivos por tema: las reglas que no llevan el campo paths: se cargan al arranque con la misma prioridad que .claude/CLAUDE.md.
Qué se queda en el CLAUDE.md y qué se muda a reglas por tema
paso 03 · tu equipo
Cuatro agentes: copia, pega y listo
Cada agente es un archivo de texto dentro de la carpeta .claude/agents/ de tu proyecto. Cuatro archivos, cuatro roles, y cada uno con un único archivo del cuaderno donde tiene permiso de escribir. Esa es toda la instalación.
Cómo se reparte trabajo entre varios agentes y cómo se elige el modelo de cada rol ya está contado en otra guía; aquí damos eso por visto y vamos a lo que cambia cuando el equipo comparte cuaderno.
Orquesta con Claude · repartir trabajo entre agentes
REGLA DE ORO
Un agente, un trabajo
Si sientes que tu coder también debería revisar lo que escribe, no le agregues la revisión: créate un revisor. Un agente con dos trabajos hace los dos a medias y, peor, empieza a escribir en archivos que no le tocan.
Sobrecargar un agente es exactamente donde el equipo empieza a pisarse. Un trabajo fijo, un archivo de escritura fijo, y el cuaderno se mantiene legible aunque corran cuatro a la vez.
ANTES DE COPIAR
Estos cuatro son un ejemplo, no la única versión
El equipo de abajo está orientado a proyectos de código porque es el caso más fácil de mostrar. Si tu trabajo es marketing, video o ventas, en el paso 04 los cambias por los tuyos en dos minutos. El patrón no se mueve.
Las primeras líneas de cada archivo son la configuración
Arriba de cada archivo, entre dos líneas de tres guiones, hay un bloque de ajustes. No son instrucciones para el agente: son datos que Claude Code lee para saber quién es, con qué modelo corre y qué tiene permitido tocar. Esta es la parte que más se movió este año, así que vale la pena leerla campo por campo.
| campo | qué hace |
|---|---|
| name y description | Los dos únicos obligatorios. El nombre es como lo llamas; la descripción es lo que hace que Claude sepa cuándo delegarle a ese agente y cuándo no. Escríbela como el letrero de la puerta, no como un resumen bonito. |
| model | Acepta sonnet, opus, haiku, fable, o inherit. Por defecto es inherit: el agente usa el mismo modelo de tu conversación. Aquí lo fijamos en cada rol porque leer y decidir no cuestan lo mismo. |
| tools | La lista de herramientas que ese agente puede usar. Si lo omites, hereda todas las que están disponibles para subagentes. Listar Agent es lo que le permite lanzar subagentes propios, y por eso solo lo lleva el orquestador. Se puede anidar hasta tres capas por debajo de la conversación principal. |
| effort | El nivel de razonamiento mientras ese agente está activo. Sobrescribe el de la sesión. Aquí solo lo llevan el coder y el orquestador, y la sección 05 explica por qué. Si pones un nivel que ese modelo no soporta, Claude Code cae al más alto que sí soporte por debajo del que pediste. |
| color | Con qué color ves a ese agente en la lista de tareas. Es cosmético, pero con cuatro corriendo al mismo tiempo se agradece poder distinguirlos de un vistazo. |
| memory | Existe, y aquí no lo usamos a propósito: le da a ese agente una memoria privada suya en .claude/agent-memory/<agente>/, que es justo lo contrario de un cuaderno compartido. Si algún día quieres las dos cosas, se pueden combinar. |
.claude/agents/investigador.md
Lee el repo, las docs y fuentes externas. Escribe en memory/research.md. Modelo: haiku, porque su trabajo es buscar, no decidir.
--- name: investigador description: Investiga código, docs y fuentes externas. Escribe hallazgos en memory/research.md. model: haiku tools: Read, Grep, Glob, WebFetch, WebSearch color: blue --- Eres el Investigador del equipo Memory Palace. Tu único trabajo es leer, buscar y sintetizar información. No escribes código ni tomas decisiones de arquitectura. ## Lee antes de trabajar Abre estos archivos tú mismo, con la herramienta de lectura. Nadie te los inyecta solo: - memory/INDEX.md (siempre primero) - memory/context.md (para entender la misión) - memory/research.md (para NO repetir hallazgos previos) - memory/blockers.md (para saber qué unknowns buscar) ## Escribe (un único destino) memory/research.md Formato de cada entrada nueva: ### [AAAA-MM-DD] [investigador] — título corto **Pregunta:** qué pregunta respondes **Hallazgo:** respuesta con evidencia (citar archivo:línea o URL) **Implicación:** qué significa para el equipo ## Protocolo (cumple las 6 reglas del CLAUDE.md raíz) 1. Lee INDEX.md + research.md antes de arrancar. 2. Añade con fecha. Nunca sobrescribas. 3. Marca obsoleto con ~~tachado~~, no borres. 4. Si tu hallazgo contradice una decisión ya tomada, escala a decisions.md con "CONFLICTO:" — no lo silencies. 5. Añade una línea al INDEX.md apuntando a tu entrada. 6. Si necesitas escribir fuera de research.md, pide al orquestador. ## Tu trabajo no cuenta si - La entrada no cita una fuente concreta: archivo:línea o URL. - Repite un hallazgo que ya estaba en research.md sin citarlo. - El INDEX.md no creció. ## Escala al orquestador cuando - Tu hallazgo cambia una decisión ya tomada - Hay un blocker que no puedes resolver leyendo - La pregunta requiere ejecutar código o modificar archivos del repo ## Formato de salida al padre que te invocó 3 a 5 bullets con los hallazgos nuevos + el anchor de research.md donde está el detalle. Nada más. Nada de discusión, nada de siguiente-pasos.
.claude/agents/coder.md
Lee research y decisions, implementa. Escribe código y memory/code-notes.md. Modelo: sonnet, con effort en high.
--- name: coder description: Implementa el código. Lee research + decisions, escribe código y documenta decisiones en memory/code-notes.md. model: sonnet tools: Read, Edit, Write, Grep, Glob, Bash effort: high color: green --- Eres el Coder del equipo Memory Palace. Implementas el código. No investigas desde cero — eso ya lo hizo el investigador y está en research.md. ## Lee antes de trabajar Ábrelos tú mismo antes de escribir una línea: - memory/INDEX.md (siempre primero) - memory/context.md (alcance de la tarea) - memory/decisions.md (restricciones de arquitectura) - memory/research.md (hallazgos relevantes — NO los repliques) - memory/code-notes.md (trampas y gotchas que otros ya documentaron) ## Escribe - Código del proyecto (archivos del repo según corresponda) - Un único archivo de memoria: memory/code-notes.md Formato de cada entrada en code-notes.md: ### [AAAA-MM-DD] [coder] — título corto **Decisión de código:** qué implementaste **Trampa evitada:** qué casi rompes (si aplica) **Patrón reusable:** convenciones que seguiste (cita archivo:línea) ## Protocolo (cumple las 6 reglas del CLAUDE.md raíz) 1. Lee INDEX.md + decisions.md + research.md antes de escribir código. 2. Si vas a contradecir una decisión de arquitectura, NO lo hagas: escala al orquestador con "CONFLICTO:" en decisions.md. 3. Documenta trampas y patrones en code-notes.md, no en comentarios del código. 4. Añade tu entrada al INDEX.md al terminar. 5. Marca code-notes obsoletos con ~~tachado~~, no los borres. ## Tu trabajo no cuenta si - Tocaste un archivo que no está en el alcance de context.md. - La entrada de code-notes.md no dice qué patrón seguiste ni de dónde lo sacaste. - Descubriste una trampa y no la escribiste. ## Escala al orquestador cuando - La decisión de arquitectura no cubre tu caso - Necesitas cambiar una dependencia compartida - El scope real de la tarea es mayor al descrito en context.md ## Formato de salida al padre Resumen de 3 puntos: qué archivos tocaste, qué decisión clave tomaste, qué entrada de code-notes.md acabas de escribir.
.claude/agents/revisor.md
Lee el diff y code-notes. Escribe en memory/reviews.md y no arregla nada. Modelo: haiku, sin effort propio.
--- name: revisor description: Revisa el código y las decisiones del coder. Escribe hallazgos en memory/reviews.md. model: haiku tools: Read, Grep, Glob, Bash color: orange --- Eres el Revisor del equipo Memory Palace. Revisas lo que escribió el coder y documentas hallazgos. No arreglas — documentas y escalas. ## Lee antes de trabajar - memory/INDEX.md (siempre primero) - memory/decisions.md (qué debía respetarse) - memory/code-notes.md (qué decisiones tomó el coder y por qué) - El diff de los cambios (git diff / archivos modificados) ## Escribe (un único destino) memory/reviews.md Formato de cada entrada: ### [AAAA-MM-DD] [revisor] — título corto **Archivo/línea:** path:línea del hallazgo **Problema:** descripción en una oración **Severidad:** crítico | alto | medio | bajo **Fix sugerido:** qué cambio haría (sin aplicarlo) ## Protocolo (cumple las 6 reglas del CLAUDE.md raíz) 1. Lee code-notes.md antes del diff — muchas dudas ya están respondidas ahí. 2. Nunca modifiques código. Solo documenta. 3. Si el coder violó una decisión de decisions.md, marca severidad crítico y escala al orquestador. 4. Añade tu entrada al INDEX.md al terminar. ## Tu trabajo no cuenta si - Un hallazgo no apunta a un archivo y una línea concretos. - Levantas una alarma sobre algo que el coder ya justificó en code-notes.md. - No dices explícitamente que no encontraste nada crítico, cuando así fue. ## Escala al orquestador cuando - Hay un hallazgo crítico (violación de decisión o bug claro) - El diff es demasiado grande para una sola review — pide split ## Formato de salida al padre Lista de findings con severidad + anchor a reviews.md. Si no encontraste nada crítico, dilo explícitamente.
.claude/agents/orquestador.md
Lee todo y delega. Escribe en memory/decisions.md y memory/INDEX.md. Modelo: opus, effort en xhigh, y el único con la herramienta Agent.
--- name: orquestador description: Lee todo, delega a los demás agentes, sintetiza decisiones en memory/decisions.md y mantiene memory/INDEX.md. model: opus tools: Read, Edit, Write, Grep, Glob, Bash, Agent effort: xhigh color: purple --- Eres el Orquestador del equipo Memory Palace. Tu trabajo es leer el estado global, planear, delegar y sintetizar. NO investigas, NO codeas, NO revisas de primera mano — para eso están los demás. ## Lee antes de trabajar TODO. Sin excepción, y abriéndolo tú mismo. - memory/INDEX.md - memory/context.md - memory/decisions.md - memory/research.md - memory/code-notes.md (si existe) - memory/reviews.md (si existe) - memory/blockers.md (si existe) ## Escribe - memory/decisions.md (ADRs nuevas) - memory/INDEX.md (curación del índice) Formato en decisions.md: ### [AAAA-MM-DD] [orquestador] — título de la decisión **Contexto:** qué problema resuelves **Decisión:** qué se eligió **Por qué:** razones (cita research.md#anchor si aplica) **Alternativas descartadas:** 1-2 líneas cada una ## Cuándo piensas a fondo Escribe ultrathink en tu propio razonamiento en estos tres momentos, y solo en estos tres: 1. Al planear el reparto, después de leer INDEX.md y decisions.md. 2. Al resolver una entrada "CONFLICTO:" entre dos agentes. 3. Al sintetizar los retornos de los subagentes en una decisión nueva. El resto del trabajo no lo necesita. Y si quieres que un subagente piense a fondo, la palabra va en el prompt que TÚ le escribes a él, porque él no lee el tuyo. ## Cómo delegas 1. Divide la tarea en sub-trabajos independientes. 2. Lanza subagentes EN PARALELO cuando los sub-trabajos no dependen entre sí (ej. investigador + revisor pueden correr a la vez). 3. Cada subagente recibe en su prompt: objetivo, paths de lectura, path de escritura y criterios de éxito. Da por hecho que arranca sin saber nada de esta conversación. 4. Cuando regresan, consolidas en decisions.md. ## Protocolo (cumple las 6 reglas del CLAUDE.md raíz) 1. Nunca dupliques trabajo que ya está en la memoria — cítalo. 2. Si dos agentes se contradicen, abre una entrada "CONFLICTO:" en decisions.md y resuelve tú. 3. Al terminar una tarea, curar INDEX.md es PARTE del trabajo, no opcional. ## Formato de salida al usuario humano - Qué se decidió (1 párrafo) - Quién escribió qué (mapa agente → archivo) - Próxima acción sugerida
paso 04 · cámbialos por los tuyos
El mismo patrón sirve para cualquier trabajo
El patrón, quitándole los nombres, es este: buscar, producir, revisar, coordinar. Sirve igual si lo que sale al final es una función, un email de lanzamiento, un guion de video o un pitch de ventas.
Cambias los nombres de los roles y el modelo según tu chamba. El cuaderno, las seis reglas del protocolo y el CLAUDE.md se quedan exactamente igual.
Cuatro equipos, el mismo esqueleto
código
El que acabas de copiar
investigador → research.md
coder → code-notes.md
revisor → reviews.md
orquestador → decisions.md
Es el equipo del paso 03, tal cual.
marketing y contenido
Posts, emails y campañas
analista-tendencias → research.md
copywriter → drafts.md
editor → reviews.md
director → decisions.md
video
Guiones, cortos y formato largo
investigador-viral → research.md
guionista → drafts.md
editor-de-cortes → reviews.md
productor → decisions.md
ventas
Leads, pitches y cierres
analista-leads → research.md
redactor-pitches → drafts.md
revisor-objeciones → reviews.md
cerrador → decisions.md
EN DOS MINUTOS
Qué tocas y qué dejas intacto
Abre los cuatro archivos del paso 03 y haz solo estos cambios. Es literalmente reemplazar palabras, no reescribir.
- Cambias: name, description, model y las instrucciones específicas del rol.
- Dejas intacto: el protocolo de seis reglas y los paths de lectura y escritura. Esos son los que hacen que el cuaderno funcione.
Y si no programas, code-notes.md se llama drafts.md en los tres presets de arriba. Mismo archivo, mismo lugar en el protocolo, otro nombre en la portada.
05 · ultrathink
Dónde piensa caro un equipo repartido
La palabra ultrathink se escribe dentro de tu mensaje y le pide a Claude razonar más a fondo en ese turno. Eso es todo lo que vamos a explicar de la palabra en esta guía.
Lo que sí es tema aquí: cuando el trabajo está repartido entre un orquestador y cuatro subagentes, pensar a fondo no vale lo mismo en todos lados. Vale en tres puntos y en el resto es dinero tirado. Y falta un paso que casi nadie da: escribir lo que salió de ese turno en el cuaderno, para que no se vaya con el turno.
Si quieres el detalle de la palabra, qué hace exactamente y en qué parte del prompt conviene ponerla, eso ya vive en la sección de ultrathink de la guía de Andromeda.
LA CORRECCIÓN
Sigue viva, pero ya no significa lo que dice media internet
Dos cosas cambiaron y la mayoría de los tutoriales que andan circulando todavía no se enteran. Las dos están en la documentación oficial de configuración del modelo, y las dos importan si vas a repartir trabajo entre agentes.
- No sube el nivel de esfuerzo. Lo que hace es agregar una instrucción en contexto para ese turno: la doc lo dice sin rodeos, el nivel de esfuerzo que se manda queda igual. Y es por turno, no persiste al mensaje siguiente. Si la quieres otra vez, la escribes otra vez.
- «think», «think hard» y «think more» ya no son palabras clave. Pasan como texto común de tu prompt, igual que cualquier otra frase. Si alguna guía te enseñó la escalera think, think hard, think harder, ultrathink, esa escalera ya no existe.
Escribir esas frases no rompe nada. Simplemente ya no hacen lo que creías que hacían.
Tres cosas distintas que se mezclan en la misma conversación
Antes de decidir dónde va el pensamiento caro, conviene separar lo que se confunde a diario. Son tres mecanismos con duraciones y lugares distintos.
| cuál | qué es | cuánto dura | dónde se pone |
|---|---|---|---|
| ultrathink | Una palabra que escribes dentro del prompt. Pide razonar más a fondo agregando una instrucción en contexto; el nivel de esfuerzo que se manda no cambia. | Un turno. El mensaje siguiente ya no la trae. | En el mensaje, donde tú la escribes. |
| /effort | El nivel de razonamiento de la sesión. Acepta low, medium, high, xhigh, max y ultracode; sin argumento abre un deslizador. | Hasta que lo cambies. | El comando en la sesión, o el campo effort: en el archivo de un subagente. |
| ultracode | Un ajuste de Claude Code, no un nivel del modelo: manda xhigh y además hace que Claude orqueste workflows dinámicos. | Solo esa sesión. | En el menú de /effort. |
La escalera completa de /effort, con el nivel en el que arranca cada modelo, vive en Niveles de esfuerzo.
Cómo se prende ultracode y qué cambia cuando lo prendes, en Ultracode en Claude Code.
Los tres momentos donde paga sola en este patrón
En una vuelta del equipo hay decenas de turnos y casi todos son mecánicos: leer un archivo, resumirlo, escribir una entrada. Tres no lo son. En esos tres alguien tiene que elegir entre caminos que no son equivalentes, y equivocarse ahí cuesta el resto de la vuelta.
Planear el reparto
Después de leer INDEX.md y decisions.md, antes de lanzar a nadie. Es la decisión con más consecuencias de toda la vuelta: qué se delega, qué corre en paralelo, qué depende de la respuesta de otro y qué no hay que volver a trabajar porque ya está en el cuaderno.
Un reparto mal pensado se paga cuatro veces, una por cada subagente que sale a hacer trabajo que no servía.
Resolver una entrada CONFLICTO:
Dos agentes escribieron cosas que no pueden ser ciertas al mismo tiempo. Alguien tiene que decidir cuál gana y dejar por escrito por qué ganó.
Eso no es leer: es juzgar, con las dos versiones enfrente, evidencia despareja y consecuencias para todo lo que venga después. Es el turno más difícil del protocolo.
Sintetizar los retornos en una decisión
Cuatro resúmenes entran, sale una entrada de decisions.md: un ADR, o sea una decisión escrita con su contexto, su porqué y lo que se descartó.
Ahí se gana o se pierde el valor de la vuelta entera. Si la síntesis queda floja, los agentes de mañana leen algo que no los ayuda y vuelven a investigar lo mismo.
Y los tres donde es puro desperdicio
La regla es corta: se piensa caro donde se decide, no donde se ejecuta. Estos tres turnos no deciden nada.
- El investigador leyendo y resumiendo. Su trabajo es traer lo que hay y citar de dónde salió, no elegir entre opciones.
- El revisor listando hallazgos contra una lista que ya existe. Los criterios están escritos en decisions.md; compararlos contra el diff no requiere razonar más a fondo.
- El coder siguiendo una instrucción que ya quedó cerrada. La decisión difícil la tomó el orquestador y está escrita; aquí solo se implementa.
Si un agente puede terminar su trabajo consultando el cuaderno, no necesita pensar más caro. Necesita leer mejor.
La mecánica que casi nadie escribe
Un subagente arranca con dos cosas: el prompt que el orquestador le escribió a él, y la jerarquía de archivos CLAUDE.md del proyecto. Tu conversación no está ahí. No ve tu mensaje.
De ahí se desprende algo práctico que cambia dónde escribes la palabra.
La misma palabra, dos efectos distintos
piensa el orquestador
Tu mensaje al orquestador: «ultrathink, arma el email de lanzamiento y reparte el trabajo».
piensa el worker
El prompt que el orquestador le escribe al investigador: «ultrathink. Lee memory/INDEX.md y memory/research.md, y devuélveme…».
Las dos formas son válidas y hacen cosas distintas. Escribir la palabra en tu mensaje hace que piense a fondo el orquestador, que es justo lo que quieres en el turno de planear. Si lo que quieres es que un worker piense a fondo, la palabra tiene que ir en el prompt que el orquestador le escribe a ese worker.
LO QUE SÍ QUEDA ESCRITO
El ajuste que no depende de que alguien se acuerde
Depender de que la palabra aparezca en el prompt correcto cada vez es frágil: basta un turno con prisa para que se caiga. El ajuste documentado por subagente es el campo effort: en el frontmatter de su archivo .md, o sea el bloque de configuración que va hasta arriba, entre las dos líneas de tres guiones. Sobrescribe el nivel de la sesión mientras ese subagente está activo, queda escrito en el repo y aplica en todas las vueltas.
Por eso, en el equipo base del paso 04, el orquestador trae effort: xhigh y el investigador no trae ninguno: el nivel se sube donde hay una decisión que tomar, no donde hay texto que leer.
Dato extra por si vienes de una versión vieja: desde la 2.1.198 los subagentes heredan la configuración de pensamiento extendido de la conversación principal, y no hay un ajuste de pensamiento por subagente.
El costo, sin números
Pensar a fondo consume más que no hacerlo. Dónde lo pones decide cuántas veces lo pagas.
En el orquestador se paga una vez por vuelta: un turno para planear, otro para sintetizar. Metido en la plantilla de un worker se paga una vez por cada worker, en cada vuelta, y para siempre, porque esa plantilla vive en el repo y nadie la vuelve a mirar.
Es la diferencia entre pensar caro en el punto donde se decide y pensar caro en cuatro lugares donde solo se ejecuta.
EL GANCHO DE ESTA GUÍA
Pensar caro y no escribirlo es pagar dos veces
El razonamiento de un turno se va con el turno. Nadie lo hereda: ni tú en la sesión de mañana, ni el subagente que abras en diez minutos. Si el orquestador pensó a fondo cómo repartir y no lo escribió, lo va a volver a pensar desde cero, y vas a volver a pagarlo.
Pensar a fondo una vez y escribir el resultado en memory/decisions.md convierte ese turno caro en algo que todos los demás agentes leen barato, y lo leen para siempre. El cuaderno es lo que hace que ultrathink sea una inversión en vez de un gasto.
Los cuatro bloques, listos para pegar
Tres son para el orquestador, uno por cada momento caro. El cuarto es distinto: es lo que el orquestador le escribe a un worker cuando de verdad quiere que ese worker piense a fondo, y por eso lleva la palabra adentro y los paths explícitos.
Planear el reparto
Primer turno del orquestador, antes de lanzar a nadie.
ultrathink
Antes de ejecutar nada, abre estos archivos con la herramienta de lectura:
- memory/INDEX.md
- memory/context.md
- memory/decisions.md
Objetivo de esta vuelta:
{{OBJETIVO}}
Restricciones:
{{RESTRICCIONES}}
Devuélveme un plan de delegación, y nada más que el plan:
1. Qué ya está resuelto en el cuaderno y NO hay que volver a trabajar. Cita el
archivo y la entrada exacta.
2. Las sub-tareas, una por línea, con el agente que le toca a cada una.
3. Cuáles corren en paralelo y cuáles esperan la respuesta de otra.
4. Qué archivo de memory/ va a escribir cada agente.
5. Qué es lo más probable que salga mal con este reparto.
No lances subagentes todavía. Espera mi visto bueno.Resolver un CONFLICTO:
Cuando dos agentes escribieron cosas que no pueden ser ciertas a la vez.
ultrathink
En memory/decisions.md hay una entrada con prefijo "CONFLICTO:" sobre
{{TEMA DEL CONFLICTO}}.
1. Lee la entrada del conflicto completa.
2. Lee las dos entradas originales que se contradicen, en el archivo donde
escribió cada agente: research.md, code-notes.md o reviews.md según toque.
3. Compara la evidencia de cada lado: qué cita cada uno, qué tan directa es la
fuente y qué tan reciente.
4. Decide cuál gana. Si ninguna gana limpio, di qué falta averiguar y a qué
agente le toca averiguarlo.
Después escribe la resolución en memory/decisions.md con este formato:
### [AAAA-MM-DD] [orquestador] — resolución: {{TEMA DEL CONFLICTO}}
**Conflicto:** las dos posturas, una línea cada una
**Decisión:** cuál gana
**Por qué:** la razón, citando la evidencia que pesó
**Qué queda obsoleto:** marca con ~~tachado~~ la entrada perdedora, sin borrarla
**Quién queda notificado:** el agente que tiene que rehacer trabajo
Al terminar, agrega la línea correspondiente en memory/INDEX.md.Sintetizar los retornos en una decisión
Turno final del orquestador: entran cuatro resúmenes, sale un ADR.
ultrathink
Ya regresaron todos los subagentes. Antes de escribir nada, vuelve a abrir las
entradas nuevas que dejaron en memory/research.md, memory/code-notes.md y
memory/reviews.md. No te quedes con el resumen que te devolvieron: lo que vale
es lo que quedó escrito en el cuaderno.
Escribe UNA entrada en memory/decisions.md con este formato:
### [AAAA-MM-DD] [orquestador] — {{TÍTULO DE LA DECISIÓN}}
**Contexto:** qué problema estábamos resolviendo
**Decisión:** qué se eligió, en una oración que se entienda sin leer nada más
**Por qué:** las razones, citando research.md#anchor o reviews.md#anchor
**Alternativas descartadas:** una o dos líneas por cada una, con su motivo
**Qué cambia de aquí en adelante:** qué tiene que hacer distinto el próximo agente
Reglas:
- No borres ni reescribas entradas de otros. Lo obsoleto se marca ~~tachado~~.
- Agrega una línea en memory/INDEX.md por cada entrada nueva de cualquier agente.
- Lo que quedó sin resolver va a memory/blockers.md, no adentro de la decisión.El bloque para que un worker sí piense a fondo
Lo escribe el orquestador dentro del prompt del subagente. La palabra va aquí, no en tu mensaje.
ultrathink
Eres el {{AGENTE}} del equipo Memory Palace de este repo. No viste la
conversación anterior: todo lo que necesitas saber está aquí abajo o en los
archivos que te digo que abras.
Lee primero, con la herramienta de lectura:
- memory/INDEX.md
- {{ARCHIVOS A LEER, uno por línea}}
Tu tarea:
{{TAREA CONCRETA}}
Esta tarea pide que razones a fondo porque {{POR QUÉ NO ES MECÁNICA}}. Compara
al menos dos caminos posibles antes de quedarte con uno, y dime cuál
descartaste y por qué.
Escribe el resultado únicamente en: {{ARCHIVO DE ESCRITURA}}
Formato de la entrada:
### [AAAA-MM-DD] [{{AGENTE}}] — título corto
Tu trabajo cuenta como terminado cuando:
- La entrada está escrita y cita sus fuentes: archivo:línea o URL.
- Agregaste una línea en memory/INDEX.md apuntando a tu entrada.
- Me devuelves de 3 a 5 bullets con lo nuevo y el anchor donde está el detalle.
Si tu resultado contradice algo que ya está en memory/decisions.md, no lo
sobrescribas: escribe una entrada con prefijo "CONFLICTO:" y avísame.Nada de esto depende de que te acuerdes en el momento. Los tres momentos caros ya están escritos en el protocolo del CLAUDE.md del paso 03, y el archivo del orquestador del paso 04 los repite con su effort: puesto. Se copian una vez y quedan.
paso 05 · arranca una tarea
El prompt que despierta al equipo completo
Pega esto en tu sesión principal cada vez que arranques una tarea nueva. Reemplazas {{OBJETIVO}} y {{CONSTRAINTS}} con los tuyos: el objetivo es qué quieres que quede hecho, y los constraints son los límites que nadie cruza — qué carpetas no se tocan, qué fecha manda, en qué idioma va todo.
El orquestador toma el control desde ahí. Lee el cuaderno, planea el reparto y delega. Tú no vuelves a meter mano hasta que te reporta qué se decidió y quién escribió dónde.
El paso 2 del prompt trae la palabra ultrathink a propósito: ese es el único momento del arranque donde conviene que el orquestador piense a fondo, justo antes de repartir. Por qué ahí y no en los demás pasos: Dónde piensa caro un equipo
Prompt de arranque — pégalo en cada tarea
El orquestador lee la memoria, planea el reparto y delega a los agentes.
Eres el Orquestador del equipo Memory Palace de este repo. Vas a resolver la
siguiente tarea leyendo y escribiendo en memory/ según el protocolo de CLAUDE.md.
## Objetivo
{{OBJETIVO}}
## Constraints
{{CONSTRAINTS}}
## Cómo proceder (no brinques pasos)
1. Lee memory/INDEX.md, memory/context.md y memory/decisions.md antes de
mover un dedo. Si encuentras una decisión previa que resuelve parte de la
tarea, cítala y apóyate en ella.
2. ultrathink — planea el reparto: qué sub-tareas se pueden delegar, cuáles
corren en paralelo, cuáles dependen de la respuesta de otra. Este es el
punto donde pensar a fondo se paga solo: una vez, aquí, y el resto del
trabajo sale ordenado.
3. Delega a los subagentes con el Agent tool:
- Lo que es leer/buscar → investigador
- Lo que es implementar → coder
- Lo que es revisar diff → revisor
En el prompt de cada uno incluye: objetivo, qué archivos leer, en qué
archivo escribir y cuándo su trabajo cuenta como terminado. Ninguno ve
este mensaje, así que lo que no le escribas, no lo sabe.
4. Cuando todos regresen, sintetiza en memory/decisions.md con fecha, autor
(orquestador) y las razones.
5. Actualiza memory/INDEX.md con una línea por cada entrada nueva de
cualquier agente.
6. Responde al usuario humano con: qué se decidió, quién escribió qué y la
próxima acción sugerida.
No empieces a producir directamente. Primero lee la memoria, planea y delega.
bundle · todo de un jalón
Un solo prompt que monta el palacio completo
Si no quieres copiar bloque por bloque, pega este prompt en Claude Code desde la raíz de tu proyecto. La raíz es la carpeta de más arriba de tu repo, la misma donde vive el CLAUDE.md.
Crea las carpetas, los ocho archivos del cuaderno, los cuatro agentes y el CLAUDE.md. Al terminar te confirma qué quedó escrito y si tu repo ya tenía un CLAUDE.md o si lo creó él.
ANTES DE COMMITEAR
Lee el CLAUDE.md con tus propios ojos
El prompt agrega el bloque al final si ya existe un CLAUDE.md; no lo reemplaza. Aun así, ábrelo antes de subirlo a git. Es el archivo que cargan todos tus agentes en cada sesión, y ahí no quieres reglas duplicadas ni una instrucción vieja peleándose con el protocolo nuevo.
Mega-prompt — monta el Memory Palace completo
Pégalo desde la raíz del proyecto. Deja el cuaderno, los cuatro agentes y el protocolo puestos.
Estás en la raíz de un proyecto. Vas a crear la estructura completa del Memory Palace siguiendo los pasos de abajo. Al terminar, confírmame qué archivos creaste.
## Paso 1 — crea las carpetas
Crea la carpeta memory/ con estos ocho archivos vacíos: INDEX.md, context.md, decisions.md, research.md, code-notes.md, reviews.md, blockers.md, glossary.md. Crea también la carpeta .claude/agents/. Usa los comandos que correspondan a mi sistema operativo.
## Paso 2 — escribe memory/INDEX.md
Escribe exactamente este contenido en memory/INDEX.md:
---START memory/INDEX.md---
# INDEX — Memory Palace
> Mapa del cuaderno. Toda entrada nueva se referencia aquí en una línea.
## Archivos activos
- [context](context.md) — misión y alcance
- [decisions](decisions.md) — decisiones tomadas y por qué
- [research](research.md) — investigación en curso
- [code-notes](code-notes.md) — decisiones de código (o drafts.md si no programas)
- [reviews](reviews.md) — hallazgos de revisión
- [blockers](blockers.md) — unknowns activos
- [glossary](glossary.md) — terminología del proyecto
## Últimas entradas
<!-- formato: - [AAAA-MM-DD] [agente] → archivo#anchor — título -->
---END memory/INDEX.md---
## Paso 3 — CLAUDE.md raíz
Si ya existe un CLAUDE.md en la raíz del proyecto, añade este bloque al final (después de una línea en blanco). Si no existe, créalo con este contenido:
---START CLAUDE.md---
# Equipo de agentes — Memory Palace
Todo agente que trabaje en este repo (principal o sub) lee y escribe en
`memory/` siguiendo este protocolo.
## Qué NO es esta carpeta
`memory/` es el cuaderno compartido del equipo: vive en el repo y se sube a
git. No es la memoria automática de Claude Code, que vive fuera del repo, es
de una sola máquina y no se carga dentro de los subagentes. Cuando el
protocolo dice "memoria", habla de esta carpeta.
## Archivos (Core 4 — arranca con estos)
- memory/INDEX.md → mapa del cuaderno (TOC + últimas entradas)
- memory/context.md → misión, alcance, stakeholders
- memory/decisions.md → decisiones tomadas (fecha, autor, por qué)
- memory/research.md → hallazgos de investigación
## Archivos (Extended — activa cuando escales)
- memory/code-notes.md → patrones y trampas de quien produce
(equipos que no programan: drafts.md)
- memory/reviews.md → hallazgos de revisión + fixes aplicados
- memory/blockers.md → unknowns, bloqueos activos
- memory/glossary.md → terminología del proyecto
## Protocolo (6 reglas — obligatorias)
1. Antes de trabajar: lee INDEX.md + los archivos relevantes a tu rol.
"Lee" significa abrirlos con la herramienta de lectura. Nadie te los
inyecta solo por estar mencionados aquí.
2. Al terminar: añade entrada con formato `### [AAAA-MM-DD] [agente] — título`.
3. Nunca borres lo que otro escribió. Marca obsoleto con `~~texto~~`.
4. Si contradices una decisión, NO la sobrescribas: escribe en decisions.md
con prefijo "CONFLICTO:" y avisa al orquestador.
5. Mantén INDEX.md actualizado: una línea por entrada nueva.
6. Cada agente escribe en UN solo archivo de memoria. Si necesitas otro,
pide al orquestador que lo haga por ti.
## Dónde se piensa a fondo
La palabra `ultrathink` sube el razonamiento de un turno. En este equipo se
usa en tres momentos y no en más: planear el reparto, resolver un
"CONFLICTO:", y sintetizar los retornos en una decisión. Y va en el prompt
del agente que va a pensar — cada subagente arranca sin ver el mensaje que le
escribiste al orquestador.
## Roles disponibles (.claude/agents/)
- investigador → lee todo, escribe en research.md
- coder → lee research + decisions, escribe código y code-notes.md
- revisor → lee código + code-notes, escribe en reviews.md
- orquestador → lee todo, escribe decisions.md + INDEX.md, delega a los demás
La disciplina del cuaderno es más importante que la herramienta. Si añades un
5.º agente, dale un archivo de escritura único y agrégalo aquí.
---END CLAUDE.md---
## Paso 4 — .claude/agents/investigador.md
Crea el archivo con este contenido exacto:
---START .claude/agents/investigador.md---
---
name: investigador
description: Investiga código, docs y fuentes externas. Escribe hallazgos en memory/research.md.
model: haiku
tools: Read, Grep, Glob, WebFetch, WebSearch
color: blue
---
Eres el Investigador del equipo Memory Palace. Tu único trabajo es leer, buscar
y sintetizar información. No escribes código ni tomas decisiones de
arquitectura.
## Lee antes de trabajar
Abre estos archivos tú mismo, con la herramienta de lectura. Nadie te los
inyecta solo:
- memory/INDEX.md (siempre primero)
- memory/context.md (para entender la misión)
- memory/research.md (para NO repetir hallazgos previos)
- memory/blockers.md (para saber qué unknowns buscar)
## Escribe (un único destino)
memory/research.md
Formato de cada entrada nueva:
### [AAAA-MM-DD] [investigador] — título corto
**Pregunta:** qué pregunta respondes
**Hallazgo:** respuesta con evidencia (citar archivo:línea o URL)
**Implicación:** qué significa para el equipo
## Protocolo (cumple las 6 reglas del CLAUDE.md raíz)
1. Lee INDEX.md + research.md antes de arrancar.
2. Añade con fecha. Nunca sobrescribas.
3. Marca obsoleto con ~~tachado~~, no borres.
4. Si tu hallazgo contradice una decisión ya tomada, escala a decisions.md
con "CONFLICTO:" — no lo silencies.
5. Añade una línea al INDEX.md apuntando a tu entrada.
6. Si necesitas escribir fuera de research.md, pide al orquestador.
## Tu trabajo no cuenta si
- La entrada no cita una fuente concreta: archivo:línea o URL.
- Repite un hallazgo que ya estaba en research.md sin citarlo.
- El INDEX.md no creció.
## Escala al orquestador cuando
- Tu hallazgo cambia una decisión ya tomada
- Hay un blocker que no puedes resolver leyendo
- La pregunta requiere ejecutar código o modificar archivos del repo
## Formato de salida al padre que te invocó
3 a 5 bullets con los hallazgos nuevos + el anchor de research.md donde está
el detalle. Nada más. Nada de discusión, nada de siguiente-pasos.
---END .claude/agents/investigador.md---
## Paso 5 — .claude/agents/coder.md
Crea el archivo con este contenido exacto:
---START .claude/agents/coder.md---
---
name: coder
description: Implementa el código. Lee research + decisions, escribe código y documenta decisiones en memory/code-notes.md.
model: sonnet
tools: Read, Edit, Write, Grep, Glob, Bash
effort: high
color: green
---
Eres el Coder del equipo Memory Palace. Implementas el código. No investigas
desde cero — eso ya lo hizo el investigador y está en research.md.
## Lee antes de trabajar
Ábrelos tú mismo antes de escribir una línea:
- memory/INDEX.md (siempre primero)
- memory/context.md (alcance de la tarea)
- memory/decisions.md (restricciones de arquitectura)
- memory/research.md (hallazgos relevantes — NO los repliques)
- memory/code-notes.md (trampas y gotchas que otros ya documentaron)
## Escribe
- Código del proyecto (archivos del repo según corresponda)
- Un único archivo de memoria: memory/code-notes.md
Formato de cada entrada en code-notes.md:
### [AAAA-MM-DD] [coder] — título corto
**Decisión de código:** qué implementaste
**Trampa evitada:** qué casi rompes (si aplica)
**Patrón reusable:** convenciones que seguiste (cita archivo:línea)
## Protocolo (cumple las 6 reglas del CLAUDE.md raíz)
1. Lee INDEX.md + decisions.md + research.md antes de escribir código.
2. Si vas a contradecir una decisión de arquitectura, NO lo hagas: escala
al orquestador con "CONFLICTO:" en decisions.md.
3. Documenta trampas y patrones en code-notes.md, no en comentarios del código.
4. Añade tu entrada al INDEX.md al terminar.
5. Marca code-notes obsoletos con ~~tachado~~, no los borres.
## Tu trabajo no cuenta si
- Tocaste un archivo que no está en el alcance de context.md.
- La entrada de code-notes.md no dice qué patrón seguiste ni de dónde lo sacaste.
- Descubriste una trampa y no la escribiste.
## Escala al orquestador cuando
- La decisión de arquitectura no cubre tu caso
- Necesitas cambiar una dependencia compartida
- El scope real de la tarea es mayor al descrito en context.md
## Formato de salida al padre
Resumen de 3 puntos: qué archivos tocaste, qué decisión clave tomaste,
qué entrada de code-notes.md acabas de escribir.
---END .claude/agents/coder.md---
## Paso 6 — .claude/agents/revisor.md
Crea el archivo con este contenido exacto:
---START .claude/agents/revisor.md---
---
name: revisor
description: Revisa el código y las decisiones del coder. Escribe hallazgos en memory/reviews.md.
model: haiku
tools: Read, Grep, Glob, Bash
color: orange
---
Eres el Revisor del equipo Memory Palace. Revisas lo que escribió el coder
y documentas hallazgos. No arreglas — documentas y escalas.
## Lee antes de trabajar
- memory/INDEX.md (siempre primero)
- memory/decisions.md (qué debía respetarse)
- memory/code-notes.md (qué decisiones tomó el coder y por qué)
- El diff de los cambios (git diff / archivos modificados)
## Escribe (un único destino)
memory/reviews.md
Formato de cada entrada:
### [AAAA-MM-DD] [revisor] — título corto
**Archivo/línea:** path:línea del hallazgo
**Problema:** descripción en una oración
**Severidad:** crítico | alto | medio | bajo
**Fix sugerido:** qué cambio haría (sin aplicarlo)
## Protocolo (cumple las 6 reglas del CLAUDE.md raíz)
1. Lee code-notes.md antes del diff — muchas dudas ya están respondidas ahí.
2. Nunca modifiques código. Solo documenta.
3. Si el coder violó una decisión de decisions.md, marca severidad crítico
y escala al orquestador.
4. Añade tu entrada al INDEX.md al terminar.
## Tu trabajo no cuenta si
- Un hallazgo no apunta a un archivo y una línea concretos.
- Levantas una alarma sobre algo que el coder ya justificó en code-notes.md.
- No dices explícitamente que no encontraste nada crítico, cuando así fue.
## Escala al orquestador cuando
- Hay un hallazgo crítico (violación de decisión o bug claro)
- El diff es demasiado grande para una sola review — pide split
## Formato de salida al padre
Lista de findings con severidad + anchor a reviews.md. Si no encontraste
nada crítico, dilo explícitamente.
---END .claude/agents/revisor.md---
## Paso 7 — .claude/agents/orquestador.md
Crea el archivo con este contenido exacto:
---START .claude/agents/orquestador.md---
---
name: orquestador
description: Lee todo, delega a los demás agentes, sintetiza decisiones en memory/decisions.md y mantiene memory/INDEX.md.
model: opus
tools: Read, Edit, Write, Grep, Glob, Bash, Agent
effort: xhigh
color: purple
---
Eres el Orquestador del equipo Memory Palace. Tu trabajo es leer el estado
global, planear, delegar y sintetizar. NO investigas, NO codeas, NO revisas
de primera mano — para eso están los demás.
## Lee antes de trabajar
TODO. Sin excepción, y abriéndolo tú mismo.
- memory/INDEX.md
- memory/context.md
- memory/decisions.md
- memory/research.md
- memory/code-notes.md (si existe)
- memory/reviews.md (si existe)
- memory/blockers.md (si existe)
## Escribe
- memory/decisions.md (ADRs nuevas)
- memory/INDEX.md (curación del índice)
Formato en decisions.md:
### [AAAA-MM-DD] [orquestador] — título de la decisión
**Contexto:** qué problema resuelves
**Decisión:** qué se eligió
**Por qué:** razones (cita research.md#anchor si aplica)
**Alternativas descartadas:** 1-2 líneas cada una
## Cuándo piensas a fondo
Escribe ultrathink en tu propio razonamiento en estos tres momentos, y solo
en estos tres:
1. Al planear el reparto, después de leer INDEX.md y decisions.md.
2. Al resolver una entrada "CONFLICTO:" entre dos agentes.
3. Al sintetizar los retornos de los subagentes en una decisión nueva.
El resto del trabajo no lo necesita. Y si quieres que un subagente piense a
fondo, la palabra va en el prompt que TÚ le escribes a él, porque él no lee
el tuyo.
## Cómo delegas
1. Divide la tarea en sub-trabajos independientes.
2. Lanza subagentes EN PARALELO cuando los sub-trabajos no dependen entre sí
(ej. investigador + revisor pueden correr a la vez).
3. Cada subagente recibe en su prompt: objetivo, paths de lectura, path de
escritura y criterios de éxito. Da por hecho que arranca sin saber nada de
esta conversación.
4. Cuando regresan, consolidas en decisions.md.
## Protocolo (cumple las 6 reglas del CLAUDE.md raíz)
1. Nunca dupliques trabajo que ya está en la memoria — cítalo.
2. Si dos agentes se contradicen, abre una entrada "CONFLICTO:" en
decisions.md y resuelve tú.
3. Al terminar una tarea, curar INDEX.md es PARTE del trabajo, no opcional.
## Formato de salida al usuario humano
- Qué se decidió (1 párrafo)
- Quién escribió qué (mapa agente → archivo)
- Próxima acción sugerida
---END .claude/agents/orquestador.md---
## Paso 8 — confirma
Lista los archivos que creaste y dime si el repo ya tenía un CLAUDE.md o si lo creaste tú. Si algo falló, avísame antes de continuar. No modifiques ningún otro archivo del proyecto.
06 · configuración
Qué se commitea para que el palacio viaje
Un cuaderno que solo existe en tu máquina no es un cuaderno compartido: es un archivo tuyo. La prueba de que este patrón quedó bien hecho no es que a ti te funcione, es que otra persona clone el repo y le llegue completo, sin que tú le mandes nada por chat.
La buena noticia es que casi todo lo que armaste son archivos del repo. El protocolo, el cuaderno y los agentes viajan con git clone sin que hagas nada especial. Lo único que hay que decidir es qué se sube y qué se queda de tu lado.
Y esto es idéntico en la terminal y en la app de escritorio, porque las dos leen los mismos archivos de configuración.
Qué se sube a git y qué no
Cinco archivos y una carpeta que no es tuya. Con esto queda decidido todo:
| qué | ¿va a git? | por qué |
|---|---|---|
| CLAUDE.md | Sí | Es el protocolo. Sin él, los agentes no saben las reglas: quién lee qué, quién escribe dónde y qué hacer cuando dos se contradicen. |
| memory/ | Sí | Es el cuaderno. Es el punto entero de esta guía. Si no viaja, quien clone el repo vuelve a arrancar en blanco. |
| .claude/agents/ | Sí | Son tus agentes: los cuatro archivos con el rol, el modelo y el archivo de escritura de cada uno. |
| .claude/settings.json | Sí | Son los ajustes compartidos del proyecto. Lo que quieres que aplique igual para cualquiera que trabaje aquí. |
| .claude/settings.local.json | No | Es tuyo y de esta máquina. Va en el .gitignore, y ahí es donde metes lo que no le sirve a nadie más. |
| La memoria automática de Claude | No se puede | Vive fuera del repo, en tu carpeta de usuario, y la doc oficial dice que esos archivos no se comparten entre máquinas ni con entornos en la nube. No hay forma de subirla aunque quieras. Por eso existe memory/. |
DÓNDE VIVEN LOS AJUSTES
Tres archivos de settings y un orden de quién gana
La configuración de Claude Code se guarda en archivos JSON, que son archivos de texto con pares de clave y valor. Hay tres que le importan a este patrón:
- ~/.claude/settings.json (tuyo, aplica a todos tus proyectos).
- .claude/settings.json (del proyecto, se commitea). Este es el que hace que tu equipo arranque parejo.
- .claude/settings.local.json (del proyecto, no se commitea). Tus ajustes de esta máquina, fuera del control de versiones.
Cuando dos archivos dicen cosas distintas sobre la misma clave, el orden oficial de quién gana va así, de más fuerte a más débil: lo gestionado por tu organización, después los argumentos que pases en la línea de comandos, después el local, después el del proyecto, y hasta el final el tuyo de usuario.
Los tres ajustes que le importan a este patrón
De todo lo que se puede configurar, solo tres cambian cómo se comporta este equipo. Van en el settings del proyecto si quieres que apliquen para todos, o en el tuyo de usuario si son nada más para ti.
ajuste 01
effortLevel
Fija qué tan a fondo razonan tus sesiones sin que tengas que pedirlo cada vez. Acepta cuatro valores: low, medium, high y xhigh.
No acepta max ni ultracode. Los dos existen, pero son de sesión: se piden en el momento y no se guardan en un archivo de ajustes.
Puesto en el settings del proyecto, todo el equipo arranca en el mismo nivel sin acordarse de pedirlo.
ajuste 02
autoMemoryEnabled
Prende o apaga la memoria automática de Claude, la que él escribe solo en tu máquina mientras trabajan. Viene prendida por defecto.
Aquí va la recomendación honesta: no hace falta apagarla para usar este patrón. Las dos conviven sin pelearse. Lo único que tienes que tener claro es cuál es cuál, y eso ya lo separaste en la sección 02.
Si la dejas prendida, no la trates como respaldo del cuaderno: no viaja a git ni se carga dentro de los subagentes.
ajuste 03
alwaysThinkingEnabled
Deja el pensamiento extendido prendido por defecto en tus sesiones, en vez de que cada quien decida en el momento.
Es el ajuste que menos vas a discutir con tu equipo: lo pones una vez y todos arrancan igual. La palabra ultrathink sigue siendo cosa del turno, no de esta clave.
La escalera completa de esfuerzo, peldaño por peldaño y con lo que cambia en cada uno, ya vive en otra guía: Niveles de esfuerzo · la escalera de /effort completa
Un ajuste que todavía no existe en tu versión no te avisa: simplemente no hace nada. Varias de las cosas de esta guía llegaron en versiones recientes, así que cuando algo no te aparezca, lo primero es ver contra qué versión estás trabajando.
Contra qué versión estás
claude --versionEsta guía se escribió contra la 2.1.224. Si tu número es menor y un campo del frontmatter de un agente o una clave del settings no responde, actualiza antes de darlo por roto.
LA PRUEBA
Clona tu propio repo y pregúntale
No des por hecho que quedó. Compruébalo como lo va a vivir la otra persona:
- Clona tu propio repositorio en otra carpeta, como si fueras alguien que acaba de entrar al proyecto.
- Abre Claude Code ahí, en esa copia nueva. Terminal o app de escritorio, da lo mismo.
- Pídele dos cosas en un solo mensaje: que te diga qué dice memory/INDEX.md y qué agentes tiene disponibles.
Si te contesta las dos, el palacio viaja. Si te contesta una sola, ya sabes cuál de las dos carpetas se quedó fuera del commit.
Con esto el patrón deja de depender de tu máquina. Lo que sigue es la superficie: abrir el mismo cuaderno desde la app de escritorio, donde aparece una trampa que en la terminal no existe.
07 · en la app
El mismo cuaderno, con interfaz
La documentación de la app de escritorio lo dice en una línea: la app lee los mismos archivos de configuración que el CLI, o sea que la terminal. Ese dato es el que hace que todo lo anterior siga sirviendo tal cual. Tu CLAUDE.md con el protocolo de seis reglas, tu carpeta memory/ con los ocho archivos y tus cuatro definiciones en .claude/agents/ valen exactamente igual del otro lado.
No existe una versión de app del patrón. No hay que volver a declarar los agentes, ni duplicar el cuaderno, ni cambiar una coma del protocolo. Abres la carpeta del proyecto en la app y el palacio ya está ahí, porque el palacio son archivos del repo y no un ajuste de la interfaz.
Lo que sí cambia es lo que ves mientras el equipo trabaja, y una trampa que la app trae de fábrica. Eso es lo único que vas a encontrar en esta sección.
Instalar Claude Code y el mapa completo de sus superficies ya está resuelto en otra guía de la bóveda, y no lo repetimos aquí: Claude Chat, Cowork y Code · los 3 modos en una sola app
LO MÍNIMO PARA LLEGAR AHÍ
Cuatro datos y ya estás adentro
- La app tiene tres pestañas: Chat, Cowork y Code. La pestaña Code es Claude Code, y ahí es donde vive este patrón.
- La app trae Claude Code adentro. No necesitas instalar Node.js ni el CLI aparte.
- Requiere plan Pro, Max, Team o Enterprise. En Windows además hace falta Git for Windows.
- Para arrancar: eliges entorno Local, le das a "Select folder" y escoges la carpeta de tu proyecto, eliges modelo y modo de permisos, y escribes.
Qué comparten y qué no
La lista corta de qué archivo lee cada superficie. Todo lo que este patrón necesita cae del lado de lo compartido; lo único que se queda en la terminal son los atajos de teclado.
| qué | en la terminal | en la app |
|---|---|---|
| CLAUDE.md y CLAUDE.local.md | Los lee al arrancar la sesión. | Los mismos archivos, sin copia aparte. Tu protocolo de seis reglas llega igual. |
| Settings de ~/.claude y de .claude del proyecto | Los lee con la precedencia de siempre. | Los lee igual. Son literalmente los mismos archivos en disco. |
| .claude/agents/ | De ahí salen tus cuatro agentes. | De ahí mismo. No hay una lista de agentes propia de la app. |
| Servidores MCP | Los que declaraste para Claude Code. | Esos, y además los de claude_desktop_config.json, que el CLI no carga. |
| Hooks y skills | Los tuyos, del usuario y del proyecto. | Los mismos, sin configurar nada de nuevo. |
| Atajos del modo interactivo de terminal (Shift+Tab para ciclar modos) | Funcionan. | No. La documentación es explícita: esos atajos "do not apply in Desktop". |
Los atajos que sí
La app tiene los suyos, y son los cuatro que vas a usar corriendo este patrón:
- Cmd+Shift+E abre el menú de esfuerzo.
- Cmd+Shift+I abre el de modelo.
- Cmd+Shift+M abre el de modo de permisos.
- Cmd+N abre una sesión nueva.
Los modos de permisos en la app se llaman Manual, Accept edits, Plan, Auto y Bypass permissions.
Ultrathink en la app
La palabra ultrathink se escribe dentro del mensaje, igual que en la terminal. No la busques en un menú: no es un ajuste de la interfaz, es parte del prompt, y por eso viaja en el texto que escribes y no en la configuración de la sesión.
El deslizador que abre Cmd+Shift+E es otra cosa: es el nivel de esfuerzo de la sesión, que se queda puesto hasta que lo cambies. La palabra en el mensaje aplica al turno que estás escribiendo. Son dos perillas distintas y conviene no confundirlas, sobre todo cuando el que va a pensar a fondo es el orquestador y no tú.
Dónde ves a tu equipo trabajando
El panel de tareas de la sesión lista los subagentes, los comandos que corren en segundo plano y los workflows dinámicos. Esa es la ventaja concreta de la app para este patrón: en la terminal ves texto pasando y adivinas quién habla; aquí ves a los cuatro agentes como filas, cada uno con su color, y puedes abrir la salida de cualquiera sin perder el hilo de la conversación principal.
El color de cada fila sale del campo color que le pusiste a cada agente en su frontmatter, en la sección del equipo. Ahí se ve para qué servía: el investigador en azul, el coder en verde, el revisor en naranja y el orquestador en morado. Cuando algo se atore, sabes de un vistazo quién es.
LA TRAMPA
Cada sesión nueva abre su propia copia del repo, y por lo tanto su propio cuaderno
Cada sesión que abres desde el sidebar, sea con el botón de sesión nueva o con Cmd+N, arranca en su propio git worktree. Un worktree es una copia de trabajo del repo que apunta a otra rama, y la app las guarda por defecto en la carpeta .claude/worktrees/ dentro de tu proyecto.
Para escribir código eso es una maravilla: dos tareas en paralelo sin pisarse los archivos. Para este patrón es un problema silencioso, porque cada copia tiene su propia carpeta memory/. Dos sesiones trabajando al mismo tiempo escriben en dos cuadernos distintos, y ninguna de las dos ve lo que anotó la otra. Nadie te avisa: los agentes leen su INDEX.md, lo encuentran, y siguen tan tranquilos con la mitad de la historia.
Qué hacer: si la tarea toca el cuaderno, trabájala en una sola sesión. Y si ya abriste varias y cada una escribió, juntar los cuadernos es un merge normal de esas ramas, con los conflictos de siempre. Por eso el protocolo pide añadir entradas con fecha en vez de reescribir: así el merge casi siempre se resuelve solo.
Cowork no es Code
La pestaña Cowork no lee el directorio ~/.claude del CLI. Sus skills, plugins y connectors salen de "Customize", que se sincroniza por tu cuenta de claude.ai. Este patrón vive en la pestaña Code y solo ahí.
Vale la pena decirlo claro porque la versión anterior de esta guía afirmaba lo contrario: no es cierto que todo funcione igual en todas las superficies. Lo que se comparte se comparte porque son los mismos archivos en disco, y Cowork no los lee.
Si arrancaste la sesión en la terminal y a media tarea quieres seguir con interfaz, no hace falta empezar de nuevo. Un comando mueve la sesión a la app, con su historial:
Mueve la sesión de la terminal a la app
/desktopEl cuaderno no se entera del cambio. Sigue siendo la misma carpeta del mismo repo.
08 · una tarea real
Un email de lanzamiento, paso por paso
La tarea: escribir el email que anuncia un producto nuevo. El equipo es el de marketing de la sección 04, el que cambia los cuatro roles de código por analista-tendencias, copywriter, editor y director. El director hace de orquestador: es el agente que reparte el trabajo y junta lo que cada uno regresa.
Sigue quién lee qué y quién escribe dónde. Ahí está todo el mecanismo.
El director arranca leyendo, no escribiendo
Abre INDEX.md y encuentra en decisions.md una entrada de una vuelta anterior: “Tono de la marca: cercano, corto, sin exageraciones”. Ya no tiene que pensar el tono desde cero. Con eso planea dos sub-tareas que pueden correr en paralelo.
Este es el único turno de toda la vuelta donde alguien piensa a fondo. Es también el turno donde la palabra ultrathink se paga sola: se escribe una vez, aquí, y el reparto que sale de ahí ordena el resto del trabajo.
Delega al analista y al editor al mismo tiempo
El analista-tendencias busca qué emails de lanzamiento están funcionando esta semana, en las newsletters que ya sigue y en lo que ya tiene a la mano, y escribe tres hallazgos con su liga en research.md.
El editor abre los últimos cinco emails que mandó la marca y apunta en reviews.md los patrones que se repiten: saludo corto, un párrafo por idea, una sola llamada a la acción.
Los dos corren a la vez porque ninguno necesita el resultado del otro.
El copywriter entra después, no antes
Lee el INDEX, ve las dos entradas nuevas, abre research.md y reviews.md, y escribe el email. No busca tendencias, porque eso ya se hizo. No adivina el tono, porque ya está escrito.
Al terminar apunta en drafts.md de dónde salió cada decisión: “usé el gancho del ejemplo 2 de research.md, cerré con una llamada a la acción de una línea según reviews.md”.
El editor cierra citando el borrador
Revisa el email con drafts.md abierto, así no levanta alarma sobre cosas que el copywriter ya justificó. Marca un cambio concreto: “el asunto quedó muy genérico, probar dos variantes”.
El director consolida y actualiza el índice
Abre entrada en decisions.md: “Email aprobado con dos variantes de asunto para probar. Próximo lanzamiento, misma estructura”. Después agrega al INDEX.md una línea por cada entrada nueva que escribió cualquier agente. Ahí cierra la vuelta.
LO QUE GANASTE
El próximo email arranca con esto ya escrito
El siguiente lanzamiento no empieza en blanco. Empieza con el tono decidido, los patrones de los emails anteriores apuntados y las dos variantes de asunto que ya probaste.
Y si mañana sumas un quinto agente, un diseñador que arme las imágenes, lee el cuaderno y entiende el tono sin que se lo expliques. El equipo creció sin estorbarse.
08 · cómo sabes que funciona
Checklist observable
Nada de esto se mide por sensación. Son siete cosas que puedes abrir y ver. Revísalas después de dos o tres vueltas del equipo, no en la primera.
Siete señales de que el cuaderno está vivo
- Nadie repite preguntas. Al abrir research.md, cada hallazgo cita uno anterior o construye sobre él. Si ves la misma pregunta dos veces, alguien no leyó el cuaderno.
- El INDEX crece solo, entrada por entrada, conforme los agentes terminan. Si alguien lo llena de un jalón al final del día, el protocolo se rompió.
- Los reviews citan líneas concretas. El revisor arranca con “según code-notes.md...” y apunta a un archivo y una línea. Eso significa que leyó antes de opinar.
- Sumar un agente ahorra tiempo. Metes un quinto rol y la tarea sale más rápido, no más lento. Si se pone lento, al cuaderno le falta estructura.
- blockers.md tiene dueño y fecha. Cada pendiente dice quién lo mira y cuándo. Nada de pendientes abandonados sin nombre.
- El orquestador no investiga. Si lo ves leyendo documentación por su cuenta, algo falló: su trabajo es repartir y juntar, no ejecutar.
- Nadie confundió el cuaderno con la memoria automática. Si un agente te dice que “ya se acuerda” de algo que nunca escribiste en memory/, está hablando de otra cosa, y eso no viaja a git ni lo ven los demás agentes.
Si te fallan tres o más, el problema casi nunca es el modelo. Suele ser una de dos cosas: el protocolo no quedó pegado en el CLAUDE.md de la raíz, o dos agentes están compartiendo el mismo archivo de escritura.
cierre · reúsalo
Cada agente nuevo hace al equipo más listo
La fórmula completa sirve igual en el siguiente proyecto. Corres el comando que crea las carpetas, pegas el protocolo de seis reglas en el CLAUDE.md de la raíz, y copias las cuatro definiciones de agente tal cual o las cambias por los roles que de verdad tienes. En diez minutos hay un equipo trabajando y dejando rastro de lo que hizo.
Sumar agentes es la misma receta y no tiene truco: al nuevo le das un archivo de escritura propio, lo agregas a la lista de roles del CLAUDE.md, y ya. El cuaderno no cambia. Un SEO escribe en seo-notes.md, un diseñador en design-notes.md, un tester en test-notes.md. Esa regla de un agente, un archivo es lo único que evita que dos se pisen la misma línea, y por eso escala sin volverse un desorden.
QUÉ CAMBIÓ EN ESTA EDICIÓN
Tres cosas nuevas si ya conocías esta guía
Si llegaste por la versión anterior, esto es lo que se movió y dónde conviene que vuelvas a pasar:
- Claude Code ahora trae su propia memoria automática, prendida por defecto y guardada en tu máquina, fuera del repo. La guía ya no la ignora: la pone lado a lado con tu cuaderno y con la memoria privada de cada agente, para que sepas cuál de las tres te sirve para qué y cuál viaja a git.
- El frontmatter de los agentes, que es el bloque de configuración arriba de cada archivo .md, ahora tiene un campo de esfuerzo: fija cuánto piensa ese subagente mientras está activo, sin tocar el nivel de tu sesión. Las cuatro definiciones ya vienen con él puesto donde tiene sentido, y sin él donde solo hay texto que leer.
- Hay una sección dedicada a dónde conviene que el equipo piense a fondo: tres momentos donde se paga solo y tres donde es desperdicio, con el detalle de en qué prompt va la palabra, porque un subagente nunca lee el mensaje que le escribiste al orquestador.
El espinazo no se movió: un cuaderno en el repo, seis reglas y un archivo de escritura por agente.
Nada de esto exige que programes. Un equipo de marketing con un investigador, un redactor y un editor usa exactamente los mismos ocho archivos; lo único que cambia es el nombre de code-notes.md por drafts.md y el contenido de context.md.
Si hoy vas a hacer una sola cosa: abre el proyecto en el que ya estás trabajando, corre el prompt que arma el cuaderno completo, y lanza la próxima tarea con el orquestador en lugar de con un chat suelto.
Guía de la comunidad
Esta guía es parte de la bóveda abierta de tododeia.
Las fuentes · todo lo de aquí está verificado
Cada dato técnico de esta guía salió de la documentación oficial de Anthropic y quedó verificado el 6 de agosto de 2026, contra Claude Code 2.1.224. Hay una sola afirmación que no viene de ahí y está marcada como tal dentro de la guía: que la palabra ultrathink se escribe igual en el mensaje cuando trabajas desde la app de escritorio. La página de la app no la menciona, así que eso va como recomendación práctica y no como cita. Si algo cambió desde entonces, la fuente manda sobre la guía.
La memoria de Claude Code
De dónde sale la sección 02: la memoria automática, su carpeta real, el índice MEMORY.md con su tope de 200 líneas, la jerarquía completa de CLAUDE.md y las reglas de .claude/rules/
Subagentes: el archivo completo
Los diecisiete campos del frontmatter, incluidos effort, memory, isolation y color; qué hereda un subagente y qué no; y por qué listar Agent en tools es lo que deja anidar
Modelo y nivel de esfuerzo
La cita exacta de qué hace hoy la palabra ultrathink, por qué think y think hard dejaron de ser palabras clave, y en qué se diferencia ultracode de un nivel de esfuerzo
Claude Code en la app de escritorio
Que la app lee los mismos archivos de configuración que la terminal, los atajos del Code tab, y el worktree por sesión que es la trampa de la sección 07
Arrancar en la app, de cero
Las tres pestañas, por qué no necesitas instalar el CLI aparte, el plan que hace falta y cómo se elige la carpeta del proyecto
Qué sobrevive a la compactación
La tabla que sostiene el argumento de la sección 01: el CLAUDE.md de la raíz y la memoria automática se re-inyectan desde disco, y lo que un agente leyó se pierde
Los archivos de configuración
Dónde vive cada settings.json, en qué orden gana uno sobre otro, y qué valores acepta la clave de nivel de esfuerzo
Sigue por aquí
Cómo se reparte el trabajo, a fondo
Aquí el orquestador solo delega. Allá está el oficio entero: las formas de repartir una tarea, cómo se elige el modelo por rol, y el contrato que te deja rechazar un entregable sin discutir.
Si tu CLAUDE.md todavía no existe
El cuaderno se monta encima de una estructura. Allá está el CLAUDE.md de la raíz, el de cada subcarpeta y el comando que te lo escribe en dos minutos. Vuelve aquí cuando ya lo tengas.
Antes de engordar el CLAUDE.md
El protocolo de la sección 04 le suma renglones a un archivo que conviene tener corto. Allá está qué se queda y qué se muda a otro lado, con el criterio para decidirlo.
Para que el revisor no dependa de ti
El cuaderno guarda lo que pasó; no decide si estuvo bien. Allá está el estándar escrito una sola vez y los cerradores que lo aplican solos, incluido el que sí corre comandos antes de decidir.
La escalera completa del esfuerzo
La sección 05 solo dice dónde conviene pensar a fondo en un equipo. Allá está el mapa entero de los niveles, qué nivel le queda a qué tarea y cómo se cambia sin pensarlo cada vez.
Memoria entre sesiones, no entre agentes
Este cuaderno resuelve que dos agentes se enteren uno del otro. Si lo que quieres es que Claude no amanezca en blanco mañana, allá están las herramientas que se dedican a eso.
En qué superficie estás parado
Aquí damos por hecho que ya tienes Claude Code abierto. Si todavía no sabes cuál de las tres pestañas de la app te toca, ni cómo se instala, ese es el mapa.
144 agentes ya escritos
Si no quieres redactar tus cuatro roles desde cero, ahí hay un catálogo entero por división. Bájalos y ponles encima el protocolo de esta guía: sin cuaderno, 144 agentes se estorban 144 veces.
Lo que yo hago
“La primera vez que armé un equipo de agentes me gastó el doble de tiempo que hacerlo yo solo, y me tardé en entender por qué. No era el modelo. Era que cada uno arrancaba sin saber nada y yo era el único que llevaba el hilo, en mi cabeza, repitiéndolo en cada prompt. El día que puse el cuaderno en el repo dejé de ser el pegamento del equipo. Ahora lo primero que hago en un proyecto nuevo no es escribir el primer agente: es correr el comando de la sección 04 y pegar el protocolo. Diez minutos, y todo lo que venga después se acumula en vez de repetirse.”
Una nota honesta
Este patrón no es gratis y no siempre vale la pena. Cada agente que sumas es Claude trabajando otra vez, y mantener el cuaderno cuesta disciplina: si nadie actualiza el INDEX, en dos semanas tienes ocho archivos que ya no reflejan nada y estorban más de lo que ayudan. Para una tarea de una tarde, con un solo agente, no montes nada de esto: pídeselo directo. El palacio se justifica cuando el proyecto dura más que tu memoria, cuando hay varios roles produciendo cosas distintas, y cuando alguien más — un socio, un cliente, tú mismo en tres meses — va a tener que entender por qué se decidió lo que se decidió.