Aprendiendo Claude Code

Este es el primer «Aprendemos con TEO», y su método es deliberadamente práctico: en lugar de exponer teoría, abrimos la terminal y trabajamos sobre un proyecto real. Claude Code es la herramienta de Anthropic que integra a Claude dentro de tu terminal, con acceso a tus archivos y a tus comandos, de modo que participe directamente en el desarrollo: lee tu proyecto, propone cambios, ejecuta tests y solicita tu permiso antes de modificar nada.

La razón de aprender así tiene fundamento. Una herramienta como esta se interioriza haciendo, no leyendo, porque su valor no reside en un conjunto de conceptos que memorizar, sino en una serie de gestos que automatizar: arrancar en la carpeta correcta, formular una petición precisa, leer un diff (las líneas que cambian) y decidir. Esos gestos solo se afianzan con repetición deliberada sobre material real, de modo que cada paso de este curso está diseñado para que ejecutes algo y observes su efecto antes de seguir. La teoría que necesitas aparece intercalada, justo cuando el gesto la requiere, y no antes.

Lo recorreremos de principio a fin, del punto de partida absoluto a la automatización avanzada, organizado en tres niveles. Cada paso indica qué escribir, qué resultado deberías observar y por qué se procede así, de manera que el progreso no dependa de conocimientos previos. Avanza con calma, reproduce los comandos y verifica cada checkpoint (punto de control) antes de pasar al siguiente escalón.

Conviene empezar por entender cómo opera la herramienta, porque el resto del curso se apoya en este mecanismo. Claude Code funciona como un bucle: tú formulas una petición, Claude examina tu proyecto y propone un cambio en forma de diff (las líneas que añade y quita); a continuación se detiene y te pide permiso antes de escribir en el disco. Tú apruebas o rechazas, el cambio se aplica y el ciclo se reinicia. Esa «puerta de permisos» es el principio rector de Claude Code: nunca modifica tus archivos sin tu consentimiento explícito. Reconocerás este esquema en cada uno de los pasos siguientes.

Detente un momento en por qué este bucle importa tanto. Un modelo de lenguaje como Claude es, por su naturaleza, probabilístico: genera la continuación más plausible dado tu encargo y el contexto que tiene a la vista, pero no garantiza acertar a la primera ni comprende las consecuencias de escribir en un disco como las comprendes tú. La puerta de permisos convierte esa incertidumbre en algo manejable: interpone una decisión humana entre la propuesta y la modificación, de modo que el coste de una sugerencia equivocada sea, en el peor caso, leer un diff y rechazarlo. Por eso la práctica central que vas a cultivar en todo el curso no es escribir buenos prompts, sino leer bien lo que Claude propone antes de aceptarlo. Quien aprende a revisar trabaja con confianza incluso cuando el modelo se equivoca; quien acepta a ciegas hereda cada error sin filtro.

Una nota antes de empezar: Claude Code cambia rápido. Lo que cuento está datado (fecha de corte al final) y contrastado con la documentación oficial. Cuando una función sea muy reciente, te aviso para que verifiques que tu versión la tiene.

Esa advertencia no es un trámite, sino una consecuencia del modelo de desarrollo de la herramienta. Claude Code se publica con cadencia muy alta y sus funciones llegan a veces de forma escalonada, de modo que dos personas con la misma versión instalada pueden tener disponibles capacidades ligeramente distintas según cuándo actualizaron. Por eso la estrategia sensata no es memorizar listas de comandos, que envejecen, sino adquirir el método: saber dónde está la ayuda integrada, cómo se comprueba la versión y cómo se contrasta una duda con la documentación oficial. Un curso que enseña a pescar resiste las actualizaciones; uno que solo reparte peces caduca con la siguiente.

Qué vas a saber hacer

Al terminar este curso podrás:

• Instalar Claude Code, abrirlo en un proyecto y darle tu primer encargo con seguridad.
• Leer y editar archivos con Claude, aceptando o rechazando cada cambio.
• Configurar la memoria del proyecto (CLAUDE.md) y los permisos para trabajar rápido sin sustos.
• Usar el día a día real: planificar antes de tocar código, limpiar el contexto, retroceder un cambio, cambiar de modelo y conectar herramientas externas.
• Crear tus propios subagentes (agentes especializados), skills (habilidades), hooks (ganchos automáticos) y comandos a medida, y empaquetarlos en plugins.
• Lanzar Claude en modo headless (sin interfaz, automatizable) para integrarlo en tu CI y procesar muchos archivos de golpe.
• Entender qué dice la documentación oficial sobre buenas prácticas, y evitar los antipatrones más comunes.

Conviene leer esta lista como una progresión, no como un inventario suelto. Los primeros puntos describen competencias operativas, arrancar, leer, editar, que se sostienen unas en otras; los intermedios introducen el gobierno de la herramienta, memoria, permisos, contexto, que es lo que distingue un uso esporádico de un flujo de trabajo fiable; y los últimos abren la puerta a la extensión y la automatización, donde dejas de usar Claude Code como asistente puntual y empiezas a moldearlo para tu proyecto concreto. Cada bloque presupone el anterior, así que el orden en que están escritos es también el orden en que conviene dominarlos.

Si paras en el nivel 1, ya sabrás hacer algo útil hoy. Si llegas al 3, estarás en el estado del arte.

Requisitos y setup

No necesitas saber programar para empezar, pero sí moverte un poco por la terminal. Esto es lo que hace falta:

Antes de la lista, una aclaración por si la palabra «terminal» te resulta ajena. Una terminal (o consola) es un programa que te deja dar órdenes al ordenador escribiéndolas como texto, en lugar de pulsando botones. Cada línea que tecleas es un comando: un nombre de programa seguido, a veces, de opciones. Claude Code vive precisamente ahí porque la terminal es el lugar donde ya conviven tus archivos, tu control de versiones y los comandos que construyen y prueban tu proyecto; al instalarse en ese entorno, Claude puede participar en el mismo flujo que tú usas, sin cambiar de herramienta. No necesitas dominar la terminal para seguir el curso, solo perder el miedo a escribir en ella y leer lo que responde.

• Node.js 18 o superior. Claude Code se instala como paquete de Node. Node.js es el entorno que ejecuta JavaScript fuera del navegador; aquí solo lo usamos como instalador.
• Una terminal. En macOS, Terminal o iTerm; en Linux, la que uses; en Windows, lo recomendado es WSL (el subsistema Linux para Windows).
• Una cuenta de Anthropic (plan Claude o clave de API). La autenticación se hace la primera vez que abres la herramienta.
• Un proyecto en una carpeta, idealmente un repositorio Git. No es obligatorio Git, pero lo recomiendo: Claude trabaja mucho mejor cuando puede ver diffs y tú puedes deshacer cambios.

Merece la pena detenerse en por qué un repositorio ayuda tanto, porque es la recomendación menos evidente de la lista. Un repositorio Git es una carpeta de la que Git lleva un registro histórico: cada vez que confirmas un cambio, queda una instantánea a la que siempre puedes volver. Eso transforma la relación con un asistente que edita archivos. Por un lado, te da una red de seguridad: si una edición resulta equivocada, la descartas y el proyecto vuelve exactamente a como estaba, sin depender de copias manuales. Por otro, da a Claude un punto de referencia claro de qué se ha modificado, porque el propio Git sabe distinguir lo confirmado de lo pendiente y expresar la diferencia como un diff. Trabajar sin Git es posible, pero te priva de esa red y obliga a revisar a ciegas; trabajar con él convierte cada experimento en algo reversible, que es justo lo que invita a probar con tranquilidad.

Primero comprueba que tienes Node:

node --version

Deberías ver algo como v20.11.0 (cualquier número 18 o mayor vale). Si da error «command not found», instala Node desde nodejs.org y vuelve a probar. Por qué: sin Node, el instalador del siguiente paso no existe.

Este primer comando ilustra un hábito que conviene adoptar desde ya: verificar antes de avanzar. Pedir a un programa que imprima su versión es la forma más barata de confirmar dos cosas a la vez, que está instalado y que tu terminal sabe encontrarlo. La condición «18 o mayor» no es caprichosa: Claude Code emplea capacidades del entorno de ejecución que solo existen a partir de esa versión, así que comprobarlo ahora evita un fallo más confuso de diagnosticar después. El error «command not found» («orden no encontrada») no significa necesariamente que falte el programa, sino que la terminal no lo localiza en las rutas donde busca; en el caso de Node recién instalado, la causa más habitual es que la terminal se abrió antes de la instalación y conserva la lista de rutas antigua.

Ahora instala Claude Code. La vía recomendada por la doc oficial es el instalador nativo, que no depende de npm.¹

Antes de copiar la orden, entiende qué distingue esta vía. El instalador nativo descarga un ejecutable autocontenido de Claude Code y lo coloca en tu sistema sin pasar por el gestor de paquetes de Node. La ventaja es de independencia: la herramienta queda desacoplada de tu instalación de Node y de sus permisos globales, de modo que actualizarla o repararla no interfiere con tus otros proyectos JavaScript. Por eso la documentación la prefiere como ruta por defecto, y por eso es la primera que te muestro.

En macOS, Linux o WSL:

curl -fsSL https://claude.ai/install.sh | bash

En Windows con PowerShell:

irm https://claude.ai/install.ps1 | iex

Estas dos órdenes hacen lo mismo en sistemas distintos: descargan un guion de instalación desde el dominio oficial de Anthropic y lo ejecutan. Conviene que entiendas el patrón, porque lo verás a menudo y porque tiene una contrapartida de seguridad que merece criterio. «Descargar y ejecutar de un tirón» es cómodo, pero implica confiar en el origen del guion, ya que se ejecuta con tus permisos; por eso solo debe hacerse desde dominios en los que confías, como aquí el oficial. Las banderas de curl, -fsSL, sirven para que la descarga falle de forma limpia ante un error del servidor y no se ejecute un guion a medias, y para que el proceso sea silencioso pero siga avisando si algo va mal. No necesitas memorizarlas; basta con que sepas que están ahí para que el atajo sea seguro.

Tienes varias alternativas igual de válidas, elige la que más te encaje:¹

brew install --cask claude-code              # macOS con Homebrew
winget install Anthropic.ClaudeCode          # Windows con winget
npm install -g @anthropic-ai/claude-code     # cualquier sistema con Node 18+

La existencia de varias vías responde a que cada sistema operativo tiene su gestor de paquetes habitual, y usar el que ya empleas tiene una ventaja concreta: ese gestor se encargará después de las actualizaciones junto con el resto de tu software, sin que tengas que recordar un procedimiento aparte. Homebrew cumple ese papel en macOS y winget en Windows; ambos llevan un registro de lo que instalan y saben actualizarlo. La tercera opción, vía npm, es la más portable porque funciona en cualquier sistema con Node, a costa de quedar atada a tu instalación global de Node. Elige por familiaridad: la vía que ya usas para otras herramientas será la que mejor mantengas al día.

En la última, npm es el gestor de paquetes de Node y -g significa «global». Al terminar, ninguna mostrará nada espectacular, solo el resumen de la instalación. Comandos de verificación:

claude --version
claude doctor

claude --version debe imprimir un número de versión; si lo ves, está instalado y en el PATH. claude doctor hace un chequeo de salud de la instalación (versión, dependencias, configuración) y te dice si algo falla.¹ Si claude da «command not found», cierra y reabre la terminal para que reconozca el comando recién instalado.

Detengámonos en claude doctor, porque es la herramienta de diagnóstico que más rentabilidad te dará cuando algo no encaje. Su cometido es revisar de una pasada las piezas de las que depende Claude Code, qué versión tienes, si las dependencias están en su sitio, si la configuración es coherente, y reportar cada hallazgo. La lógica de usarlo ahora, recién instalado y con todo presumiblemente correcto, es doble: confirmas que el punto de partida es sólido y, sobre todo, aprendes a leer su salida cuando no hay problemas, de modo que más adelante sepas reconocer una anomalía por contraste. En cuanto a «command not found» justo después de instalar, la causa casi siempre es la misma que con Node: el PATH, la lista de carpetas donde la terminal busca programas, solo se relee al abrir una sesión nueva, así que reabrir la terminal basta para que el comando recién colocado aparezca.

El mapa

El curso es una escalera de tres niveles. Cada uno es útil por sí solo y termina con un checkpoint.

flowchart LR
    S[Setup<br/>instalar y verificar] --> N1[Nivel 1<br/>primeros pasos]
    N1 --> N2[Nivel 2<br/>manejo real]
    N2 --> N3[Nivel 3<br/>un poco más avanzado]
    N3 --> A[Automatización<br/>headless y CI]

• Nivel 1 · primeros pasos. Abrir Claude, autenticarte, tu primer prompt, leer y editar un archivo, aceptar o rechazar cambios, pedir ayuda y salir.
• Nivel 2 · manejo real. El día a día: memoria de proyecto, permisos, comandos de barra, el flujo explorar→planificar→codificar→confirmar, contenido rico, reanudar sesiones y conectar herramientas (MCP).
• Nivel 3 · un poco más avanzado. Subagentes, skills, hooks deterministas, comandos propios, reglas por ruta, modo headless para CI, mezcla de modelos y gestión del contexto.

La metáfora de la escalera no es decorativa, sino una indicación sobre cómo recorrer el curso. Cada nivel deja una capacidad cerrada y verificable, de ahí que termine en un checkpoint, una lista de comprobación que solo confirmas cuando los gestos te salen sin consultar, y cada nivel presupone el anterior como base firme. La tentación natural es saltar a lo vistoso, los subagentes o la automatización, pero hacerlo sin haber interiorizado la puerta de permisos y la revisión de diffs del nivel 1 es construir sobre arena: las funciones avanzadas amplifican tanto tus aciertos como tus descuidos. Por eso el criterio para subir no es el tiempo invertido ni las ganas, sino la fluidez real en el escalón actual.

Sube cuando el checkpoint del nivel te salga sin mirar.

Nivel 1 · primeros pasos

Aquí partimos de cero absoluto: acabas de instalar Claude Code y nunca lo has usado. Al final de este nivel habrás tenido una conversación real con Claude dentro de un proyecto y le habrás hecho editar un archivo.

El objetivo de este nivel es menos ambicioso de lo que parece y, por eso mismo, más valioso. No se trata de que Claude resuelva nada complicado, sino de que recorras el bucle completo al menos una vez con plena conciencia de cada fase: arrancar donde toca, pedir algo, ver lo que propone, decidir. Una vez que ese circuito te resulte familiar, todo lo demás del curso son variaciones sobre él. Conviene por tanto resistir la prisa: cada uno de los nueve pasos siguientes aísla deliberadamente un gesto para que lo observes por separado, antes de que en los niveles posteriores se encadenen a velocidad de trabajo real.

Paso 1 · entra en una carpeta de proyecto

Objetivo: abrir Claude dentro del proyecto donde quieres trabajar, porque Claude solo ve los archivos de la carpeta desde la que lo arrancas.

cd ruta/a/tu/proyecto

No verás salida si la carpeta existe. Por qué: cd («change directory», cambiar de carpeta) te sitúa dentro del proyecto. Si no tienes ninguno a mano, crea uno de prueba:

mkdir prueba-claude && cd prueba-claude

Este paso parece trivial y es, en realidad, el que más malentendidos previene. Cuando arrancas Claude Code, la carpeta desde la que lo lanzas se convierte en su directorio de trabajo: el límite de lo que la herramienta considera «tu proyecto» y la raíz a partir de la cual lee archivos y entiende rutas. Que Claude solo vea esa carpeta no es una limitación accidental, sino una decisión de diseño con dos virtudes. La primera es de seguridad: acota lo que el asistente puede leer y modificar a un perímetro que tú eliges deliberadamente, en lugar de darle acceso a todo tu disco. La segunda es de foco: cuanto más ceñido esté el directorio al proyecto real, menos ruido habrá en lo que Claude examina y más pertinentes serán sus respuestas. El error típico del principiante es lanzar claude desde su carpeta personal o desde la raíz del sistema y luego extrañarse de que «no encuentre» los archivos; la cura es siempre la misma, situarse con cd en la carpeta correcta antes de arrancar. La orden compuesta mkdir prueba-claude && cd prueba-claude encadena dos acciones con &&, que significa «si la primera tiene éxito, ejecuta la segunda»: crea la carpeta y, solo si se creó bien, entra en ella.

Paso 2 · arranca Claude Code

Objetivo: abrir la sesión interactiva.

claude

Deberías ver una pantalla de bienvenida con un cuadro de texto al final donde escribir. Es la interfaz conversacional: tú escribes arriba, Claude responde abajo. Por qué: claude sin argumentos abre el modo interactivo, que es donde vivirás casi todo el tiempo.

Lo que se abre al teclear claude es un REPL, sigla inglesa de «read-eval-print loop» (bucle de leer, evaluar e imprimir): un programa que se queda esperando lo que escribes, lo procesa y muestra el resultado, una y otra vez, sin cerrarse entre turnos. Esa persistencia es justo lo que distingue el modo interactivo de ejecutar un comando suelto: la sesión mantiene viva la conversación, de modo que Claude recuerda lo dicho antes y puedes construir sobre ello. Más adelante verás que claude admite argumentos para otros usos, por ejemplo, lanzarlo sin interfaz para automatizar, pero arrancarlo a secas, sin nada detrás, es lo que abre este espacio conversacional donde transcurrirá la mayor parte de tu trabajo. Tómate un momento para fijarte en la disposición: el cuadro de texto al pie es tu turno de palabra, y el espacio sobre él es donde Claude irá respondiendo y mostrando lo que hace.

Paso 3 · autentícate la primera vez

Objetivo: vincular la herramienta con tu cuenta. Solo ocurre la primera vez.

La primera vez que arrancas, Claude Code abre el navegador para que entres con tu cuenta de Anthropic y luego vuelves a la terminal. Deberías ver un mensaje confirmando que la sesión quedó autenticada. Si en el futuro necesitas re-autenticarte (cambias de cuenta, caduca la sesión), dentro de claude escribe /login. Por qué: sin autenticación, Claude no puede llamar al modelo.

La autenticación responde a un hecho fundamental sobre cómo funciona la herramienta: Claude Code es un cliente, no el modelo en sí. La parte que razona, Claude, se ejecuta en la infraestructura de Anthropic, y la herramienta de tu terminal se limita a enviarle tus peticiones y recibir sus respuestas. Para que ese intercambio sea posible y quede asociado a tu plan o a tu consumo, el sistema necesita saber quién eres, y eso es lo que establece este paso. El procedimiento de abrir el navegador no es un rodeo: delega la comprobación de identidad en una sesión web segura, de modo que tu credencial se valida allí y la terminal solo recibe la confirmación, sin que tengas que pegar contraseñas en la consola. Que ocurra una sola vez se debe a que la sesión queda guardada localmente; /login existe precisamente para los casos en que esa sesión deja de servir, porque caducó o porque quieres usar otra cuenta, y necesitas rehacer el vínculo sin reinstalar nada.

Paso 4 · tu primer prompt

Objetivo: pedirle algo concreto y ver cómo responde. Un prompt (instrucción) es simplemente lo que le escribes.

En el cuadro de texto escribe y pulsa Enter:

¿Qué archivos hay en este proyecto y para qué sirve cada uno?

Claude listará los archivos y te dará un resumen. Si la carpeta está vacía, te lo dirá. Por qué: es la forma más segura de empezar, porque solo lee, no cambia nada. Te sirve para comprobar que «ve» tu proyecto.

Esta primera petición está elegida con cuidado, y conviene entender por qué es un buen punto de partida. Cuando preguntas qué hay en el proyecto, Claude no responde de memoria ni adivina: ejecuta acciones de lectura, listar la carpeta, abrir archivos, y construye la respuesta a partir de lo que realmente encuentra. Comprobar que «ve» tu proyecto significa, en concreto, verificar que arrancaste en el directorio correcto y que el asistente accede a su contenido; si la respuesta describe archivos que reconoces, el perímetro del Paso 1 quedó bien fijado. La segunda razón para empezar así es de seguridad psicológica: una petición de solo lectura no puede estropear nada, de modo que es el terreno ideal para perderle el miedo a la herramienta antes de pedirle que modifique algo. A medida que avances notarás un principio que conviene retener desde ya: cuanto más concreta es la pregunta, más útil es la respuesta, porque orientas la atención de Claude hacia lo que de verdad te importa en lugar de dejar que reparta esfuerzo a ciegas.

Paso 5 · pídele que lea un archivo concreto

Objetivo: dirigir su atención a un archivo, no a todo.

Lee el archivo README.md y dime en dos frases de qué va.

Claude leerá el archivo y resumirá. Si no existe, te avisará. Por qué: cuanto más concreto eres, mejor responde. «Lee README.md» gasta mucho menos contexto que «mírate el proyecto entero».

Detrás del consejo de ser concreto hay un concepto que gobierna todo el trabajo con Claude y que conviene introducir aquí: el contexto (la información que el modelo tiene presente mientras razona) es un recurso limitado. Todo lo que Claude lee, cada archivo, cada mensaje previo, ocupa espacio en esa ventana de atención, y ese espacio es finito. Pedirle que lea un archivo concreto en lugar de explorar el proyecto entero no es solo cuestión de rapidez: es administrar deliberadamente ese recurso para que se gaste en lo relevante. Un encargo difuso como «mírate todo» llena la ventana de material que quizá no necesitas, mientras que «lee README.md» reserva la atención para lo que has señalado. La consecuencia práctica es directa: las respuestas mejoran cuando reduces lo que Claude tiene que considerar, porque la señal pertinente no queda diluida en ruido. Acostúmbrate a apuntar a lo concreto; es un hábito que rinde más cuanto mayor se vuelve el proyecto.

Paso 6 · pídele un cambio y revisa el diff

Objetivo: ver el momento clave de Claude Code: propone un cambio y tú decides.

Añade al final del README.md una sección «## Notas» con la frase: «Proyecto de prueba con Claude Code.»

Claude te mostrará un diff (las líneas que quiere añadir o quitar, en verde y rojo) y te pedirá permiso. Verás opciones para aceptar o rechazar. Por qué: Claude nunca escribe a ciegas en tu disco; primero te enseña exactamente qué va a cambiar.

Este es el paso donde aparece por primera vez el corazón de la herramienta, así que merece detenimiento. Un diff, abreviatura de «difference», diferencia, es la forma estándar en el mundo del desarrollo de expresar un cambio: en lugar de mostrarte el archivo entero modificado, te enseña solo lo que varía, marcando en verde las líneas que se añaden y en rojo las que se quitan. Esa representación es valiosa porque concentra tu atención exactamente en el cambio, sin obligarte a comparar mentalmente dos versiones completas. Revisar el diff antes de aceptar es la habilidad central que este curso quiere que cultives, porque es tu único punto de control real: ahí compruebas que Claude entendió bien tu encargo, que toca lo que debía y nada más, y que no introduce algo inesperado. La regla a interiorizar es que Claude nunca escribe en tu disco a ciegas; primero te muestra la propuesta y espera. Lo que puede salir mal no es que la herramienta actúe a tus espaldas, no lo hace, sino que tú apruebes sin leer; por eso el gesto que de verdad importa no es pedir el cambio, sino mirar el diff con atención antes de decidir.

Paso 7 · acepta o rechaza el cambio

Objetivo: tomar el control de cada edición.

Cuando aparezca el diff, elige aceptar (aplica el cambio al archivo) o rechazar (no lo aplica). Si aceptas, Claude confirmará que el archivo se ha modificado. Por qué: este es el acuerdo fundamental de Claude Code: él propone y tú apruebas. Mientras tengas dudas, rechaza; hacerlo no tiene coste alguno.

La decisión que tomas aquí es la puerta de permisos en funcionamiento, y conviene apreciar la asimetría que la hace valiosa. Aceptar y rechazar no son acciones simétricas en sus consecuencias: aceptar escribe en el disco y, aunque con Git todo cambio es reversible, deja una huella que luego hay que deshacer; rechazar no toca absolutamente nada y devuelve la palabra a Claude para que reformule. Esa asimetría justifica una norma sencilla: ante la duda, rechaza. Rechazar no es un fracaso ni desperdicia el trabajo, porque puedes explicar a continuación qué no encajaba y Claude propondrá de nuevo con esa corrección incorporada; el coste de un rechazo es, literalmente, nulo. El antipatrón que esta disciplina previene es el de la aceptación por inercia: aprobar propuesta tras propuesta sin leerlas porque las primeras salieron bien. Cultivar el reflejo contrario, leer siempre, aceptar solo cuando el diff te convence, es lo que mantiene el control en tus manos a medida que el ritmo de trabajo se acelera.

Paso 8 · pide ayuda con /help

Objetivo: conocer los comandos disponibles sin salir.

En el cuadro de texto escribe:

/help

Verás la lista de slash commands (comandos de barra: instrucciones especiales que empiezan por /). Por qué: /help es tu chuleta integrada; cuando no recuerdes un comando, está ahí.

Conviene distinguir bien las dos clases de cosas que puedes escribir en el cuadro de texto, porque es una distinción que usarás todo el rato. Cuando escribes en lenguaje natural, «lee el README», te diriges al modelo, que interpreta tu intención. Cuando escribes algo que empieza por barra, /help, /login, /exit, te diriges a la propia herramienta: son slash commands, instrucciones con un efecto fijo y predecible que Claude Code ejecuta sin pasar por el modelo. Esa diferencia importa porque los comandos de barra son deterministas: hacen exactamente lo que prometen, siempre igual, sin la variabilidad propia de una respuesta generada. /help es el más útil al principio precisamente porque te muestra el repertorio completo de esos comandos sin que tengas que salir de la sesión ni buscar en la documentación. Recordando este apoyo, enlaza con la nota del comienzo del curso: no necesitas memorizar listas que envejecen, te basta saber que la ayuda vive aquí dentro y consultarla cuando la necesites.²

Paso 9 · interrumpir y salir

Objetivo: saber parar a Claude y cerrar la sesión.

• Si Claude se está yendo por las ramas o quieres pararlo a media respuesta, pulsa Esc. Detiene lo que esté haciendo sin cerrar la sesión.
• Para salir del todo, escribe /exit o pulsa Ctrl+D.

Tras /exit vuelves a la terminal normal. Por qué: conviene interiorizar Esc desde el primer día, porque interrumpir pronto una respuesta que se desvía ahorra tiempo y preserva el contexto que, de otro modo, se llenaría de material inútil.

Vale la pena entender por qué interrumpir a tiempo es una habilidad y no solo un botón de emergencia. Recuerda que el contexto es la ventana finita de información con la que Claude razona; pues bien, cuando una respuesta arranca en la dirección equivocada, lee archivos que no tocaban, explica algo que no pediste, cada segundo que la dejas correr llena esa ventana de material que no querías. Pulsar Esc en cuanto detectas el desvío hace dos cosas a la vez: te ahorra esperar a que termine algo inservible y, más importante, evita que ese material inútil ocupe espacio que necesitarás para lo que de verdad importa. Por eso conviene cultivar el reflejo desde el primer día, antes de que las sesiones se vuelvan largas y costosas. Esc detiene sin cerrar, de modo que tras la interrupción sigues en la conversación y puedes reformular; salir es otra cosa, y para eso están /exit o Ctrl+D, que terminan la sesión y te devuelven a la terminal normal. La distinción es la misma que ya viste con aceptar y rechazar: parar no es salir, igual que rechazar no es romper nada.

Un par de atajos del REPL (la consola interactiva) que conviene saber ya:²

• Flechas ↑/↓: recorren el historial de lo que has escrito.
• /: al teclear la barra, se despliega la lista de comandos disponibles.
• Shift+Tab: cicla el modo de permisos de la sesión (default → acceptEdits → plan → bypassPermissions). Lo veremos en el nivel 2.
• Esc, Esc (doble): retrocede a un punto anterior (deshacer/rewind).

Estos atajos comparten una lógica que conviene captar más allá de memorizarlos uno a uno: el REPL guarda un historial de tu sesión, y casi todos ellos son formas de moverte por él. Las flechas recuperan lo que ya escribiste para no teclearlo de nuevo; la barra te ahorra recordar el nombre exacto de un comando desplegando la lista; y el doble Esc lleva esa idea hasta sus últimas consecuencias, permitiéndote retroceder a un estado anterior de la conversación, como si rebobinaras. Esta última capacidad enlaza con todo lo dicho sobre el contexto: si una sesión tomó un rumbo que no querías, no estás obligado a arrastrarlo, puedes volver atrás. Shift+Tab pertenece a otra familia, gobierna cuánta autonomía concedes a Claude para editar sin preguntar, y por su importancia merece su propio tratamiento en el nivel 2; por ahora basta con que sepas que existe y que el modo por defecto es el más prudente.

Checkpoint del nivel 1

Ahora ya puedes:

• Instalar Claude Code y verificarlo con claude --version.
• Abrir claude dentro de un proyecto y autenticarte.
• Pedirle que lea un archivo y que proponga un cambio.
• Leer un diff y aceptarlo o rechazarlo conscientemente.
• Usar /help, parar con Esc y salir con /exit.

Trata esta lista como lo que su nombre indica, un punto de control y no un mero resumen. La diferencia entre haber leído estos pasos y haberlos interiorizado se mide en fluidez: el criterio no es reconocer cada punto cuando lo lees, sino ser capaz de ejecutarlo sin volver a consultar el curso. Si alguno te hace dudar, si tienes que pararte a recordar cómo se interrumpe, o vacilas ante un diff sin saber si aceptarlo, ese es exactamente el gesto que conviene repetir un par de veces más antes de seguir. No es perfeccionismo: el nivel 2 encadena estos gestos a velocidad de trabajo real y da por supuesto que la puerta de permisos y la revisión de diffs ya forman parte de tu manera de proceder.

Si los nueve pasos te salen sin mirar, sube al nivel 2.

Nivel 2 · manejo real

Llegas desde el nivel 1 con las conversaciones y las ediciones puntuales ya resueltas. Este nivel aborda el uso cotidiano, que es donde la herramienta produce el mayor ahorro de tiempo: la memoria de proyecto, los permisos, los comandos de uso frecuente, un flujo de trabajo riguroso y la conexión con herramientas externas.

Conviene que entiendas el hilo conductor antes de empezar. Todo lo que sigue gira alrededor de un mismo recurso escaso: la ventana de contexto (context window), es decir, la cantidad finita de texto que el modelo puede tener «delante de los ojos» en cada turno. La memoria de proyecto sirve para no malgastar esa ventana repitiendo lo de siempre; los permisos, para que Claude actúe sin pedirte autorización a cada paso pero sin pasarse de la raya; el flujo de trabajo estructurado, para que no llene la ventana de callejones sin salida; y la verificación, para que cada cosa que da por terminada esté respaldada por una prueba y no por una afirmación. Si retienes esa idea, proteger el contexto y exigir evidencia, el resto de pasos encajan solos.

Paso 1 · genera la memoria del proyecto con /init

Objetivo: crear el CLAUDE.md, el archivo de memoria que Claude lee al arrancar en este proyecto.

Dentro de claude, escribe:

/init

Claude analizará el proyecto y generará un CLAUDE.md con lo básico: cómo se construye, cómo se testea, convenciones. Deberías ver el archivo nuevo en la raíz. Por qué: lo que pones en CLAUDE.md se carga en cada sesión, así no repites lo mismo una y otra vez.³

Conviene que sepas qué ocurre por dentro cuando lanzas /init. El comando no inventa la documentación: recorre el proyecto leyendo las señales que un programador experto leería primero, el README, los archivos de configuración del gestor de paquetes (package.json, pyproject.toml y similares), la estructura de carpetas, los scripts disponibles, e infiere a partir de ahí cómo se compila, cómo se ejecutan los tests y qué convenciones sigue el código. El resultado se escribe en CLAUDE.md precisamente porque ese archivo es el único bloque de texto que Claude vuelve a leer entero al principio de cada sesión, sin que tengas que adjuntarlo; es memoria persistente, no una nota de usar y tirar.³

El porqué de fondo es económico. Cada vez que arrancas una sesión, el modelo parte de cero: no recuerda nada de ayer. Sin memoria de proyecto, tendrías que reexplicarle el comando de construcción, la versión del lenguaje o la regla de estilo en cada conversación, y eso consume tu tiempo y, sobre todo, ocupa la ventana de contexto con material repetido. El CLAUDE.md traslada ese coste fijo a un archivo que se carga una vez y queda disponible para todo el trabajo posterior. Donde más conviene es justo al incorporarte a un repositorio nuevo o al empezar a usar Claude Code en uno que ya existe: es el primer gesto que rentabiliza la herramienta.

Un aviso para que no te lleves a engaño: lo que /init genera es un borrador, no una verdad revelada. La inferencia a la documentación puede equivocarse, dar por bueno un script que ya no se usa, omitir una convención tácita o, lo más frecuente, producir un texto más largo de lo necesario. Por eso el paso siguiente no es opcional: hay que leer ese borrador con ojo crítico y podarlo. Trátalo como el punto de partida de tu memoria, no como su forma final.

Paso 2 · entiende y afina CLAUDE.md

Objetivo: que la memoria sea corta, humana y útil. La regla de oro oficial: si quitar una línea no provoca ningún error ni malentendido, bórrala.⁴

La memoria se organiza en una jerarquía que se concatena (no se sobrescribe), de menor a mayor cercanía:³

• ~/.claude/CLAUDE.md, tu memoria de usuario, para todos tus proyectos.
• ./CLAUDE.md o ./.claude/CLAUDE.md, memoria del proyecto, se versiona en Git y la comparte el equipo.
• ./CLAUDE.local.md, memoria local tuya, no se versiona (va en .gitignore).

A esto se suma, por encima, la política gestionada por tu organización (si la hay). La clave es que estas capas se concatenan: no compiten ni se tapan, se apilan. Lo que Claude tiene en la cabeza al arrancar es la suma de todas.

Que la jerarquía se concatene y no se sobrescriba tiene una consecuencia práctica que conviene interiorizar. En un sistema de sobrescritura, la capa más cercana «gana» y anula a las demás; aquí no hay ganador, hay suma. Eso reparte bien las responsabilidades, lo que vale para todos tus proyectos vive en la memoria de usuario, lo que vale para este equipo viaja en el CLAUDE.md del repositorio bajo control de versiones, y tus manías personales que nadie más necesita ver quedan en el CLAUDE.local.md que no se versiona, pero también significa que las contradicciones no se resuelven solas. Si tu memoria de usuario dice una cosa y la del proyecto dice la contraria, Claude recibe ambas instrucciones a la vez y tendrá que arbitrar entre ellas, casi siempre con peor criterio que tú. La higiene, entonces, consiste en que cada hecho viva en una sola capa, la que le corresponde por alcance.

El mecanismo de los imports (importaciones con @ruta) merece una explicación, porque resuelve una tensión real. Una memoria de proyecto debe ser corta, pero algunos proyectos tienen documentación de arquitectura o de estilo que sí importa y que es larga. La sintaxis @ruta permite que el CLAUDE.md enlace a esos archivos en lugar de copiar su contenido: mantienes el índice breve y delegas el detalle en documentos especializados que se incorporan cuando hacen falta. Las rutas son relativas y admiten hasta cuatro niveles de anidamiento, un archivo importado puede a su vez importar otro, lo que te deja componer la memoria por piezas en vez de en un único bloque inmanejable. El límite de profundidad existe para evitar cadenas de importación que se vuelvan imposibles de seguir.

Puedes importar otros archivos con @ruta (rutas relativas, hasta cuatro niveles de profundidad). Un CLAUDE.md mínimo y sano:

# Proyecto Acme

## Comandos
- Construir: `npm run build`
- Tests: `npm test`
- Lint: `npm run lint`

## Convenciones
- TypeScript estricto. Nada de `any`.
- IMPORTANT: nunca toques `db/migrations/` sin avisar.

## Contexto extra
@docs/arquitectura.md

Marca lo crítico con IMPORTANT o YOU MUST: la doc señala que Claude les hace más caso.⁴ Por qué corto: un CLAUDE.md sobrecargado es uno de los cinco antipatrones oficiales; cada línea de más resta atención a las que importan.

La regla de oro, si quitar una línea no provoca ningún error ni malentendido, bórrala, no es una preferencia estética, sino una consecuencia de cómo lee el modelo. El CLAUDE.md no es un documento de referencia que Claude consulta cuando lo necesita; es texto que ocupa la ventana de contexto en cada turno, compitiendo con tu pregunta, con el código que estás mirando y con el resto de la conversación. La atención del modelo se reparte entre todo lo que tiene delante, de modo que cada instrucción superflua diluye el peso de las que de verdad importan. Una memoria de diez líneas afiladas guía mejor que una de cien líneas tibias, igual que una señal de tráfico clara funciona mejor que un panel saturado de avisos. Por eso conviene incluir solo lo que no es deducible mirando el proyecto, los comandos no obvios, las convenciones tácitas, las prohibiciones explícitas, y dejar fuera lo que Claude ya puede inferir leyendo el código.

El énfasis con IMPORTANT o YOU MUST se apoya en el mismo principio desde el otro lado: como no todas las líneas pesan igual a ojos del modelo, marcar las pocas que son innegociables las eleva por encima del ruido. Pero es una palanca de dosis pequeña. Si subrayas la mitad de la memoria, no subrayas nada: el énfasis pierde valor en cuanto se generaliza. Resérvalo para las reglas cuyo incumplimiento causaría un daño real, tocar una carpeta de migraciones, exponer un secreto, y deja el resto en tono normal.

Paso 3 · controla los permisos

Objetivo: decidir qué puede hacer Claude solo y qué requiere tu visto bueno.

Dentro de claude:

/permissions

Verás las listas de permitido (allowlist) y denegado (denylist). Cada vez que Claude quiere usar una herramienta con efectos, editar un archivo, ejecutar un comando, consulta estas listas: si la acción figura en la allowlist, procede sin preguntar; si figura en la denylist, la rechaza; y en cualquier otro caso, te consulta. Puedes autorizar de forma permanente las acciones que repites con frecuencia (por ejemplo, ejecutar los tests) y bloquear las peligrosas. Por qué: al principio Claude pregunta por casi todo, porque su allowlist está vacía; ir poblándola reduce la fricción sin que pierdas el control sobre lo que importa.⁴

Conviene precisar qué es un permiso, porque ahí está la lógica de seguridad de toda la herramienta. Claude tiene dos clases de capacidades: las que solo leen, mirar un archivo, buscar en el proyecto, y las que tienen efectos sobre el mundo, escribir en disco, ejecutar un comando de terminal, borrar algo. Las primeras son reversibles y baratas; las segundas, no necesariamente. El sistema de permisos es la frontera que separa ambas: las acciones con efectos requieren autorización, las de solo lectura suelen fluir. Esa asimetría es deliberada. Quieres que Claude explore con libertad para entender el problema, pero que se detenga antes de modificar nada que no hayas previsto.

La allowlist y la denylist son las dos respuestas permanentes a esa pregunta de autorización. Cuando aceptas «no volver a preguntar» por una acción, la estás añadiendo a la lista de permitidas; cuando bloqueas algo, va a la de denegadas. La granularidad importa: puedes autorizar un comando concreto sin abrir la puerta a toda una familia, de modo que permitir npm test no implica permitir cualquier orden de npm. La estrategia sensata es poblar la allowlist con lo repetitivo e inocuo, tests, linter, construcción, y reservar la denylist para lo que nunca debería ocurrir sin tu intervención directa.

El problema que todo esto combate tiene nombre: la fatiga de aprobación (approval fatigue). Si Claude te pregunta por cada acción, por trivial que sea, acabas pulsando «sí» de forma mecánica, sin leer; y el día que la pregunta importa de verdad, la apruebas con el mismo automatismo. Una allowlist bien ajustada rompe ese círculo: silencia el ruido de lo rutinario para que las pocas preguntas que quedan recuperen tu atención. El objetivo no es aprobar menos por comodidad, sino concentrar tu juicio donde aporta valor.

Sin salir del cuadro de texto, Shift+Tab cicla el modo de permisos de la sesión: default → acceptEdits (acepta las ediciones sin preguntar) → plan (solo planifica, no toca nada) → bypassPermissions (no pregunta por nada; úsalo con cabeza).² Es el atajo más rápido para, por ejemplo, ponerte en modo plan antes de un cambio grande.

Mientras que la allowlist es una política permanente que persiste entre sesiones, el modo de permisos es un ajuste momentáneo que vale solo para la conversación en curso. Son dos perillas distintas que conviene no confundir: la primera responde «¿qué acciones concretas confío siempre?», y la segunda, «¿cuánta autonomía le doy a Claude ahora mismo?». Los cuatro modos forman una escala creciente de confianza. En default se respeta tu política normal de permisos. En acceptEdits dejas de revisar cada edición de archivo una por una, lo cual encaja cuando el trabajo es mecánico y ya has acordado el plan. En plan impones la restricción opuesta: Claude puede leer y razonar, pero el sistema le impide escribir, de modo que no hay riesgo de que se adelante a tocar nada. Y en bypassPermissions desactivas las preguntas por completo. Cada peldaño afloja la correa un poco más, y la elección correcta depende de cuánto te juegues en ese momento. El modo bypassPermissions ahorra interrupciones, pero entrega a Claude la llave de todo: resérvalo para entornos donde un error no tenga consecuencias serias, un contenedor aislado, una rama desechable, y no lo uses por costumbre sobre tu sistema de trabajo.

Tienes además dos comodidades recientes (verifica que tu versión las tiene):

• Auto mode, un modo automático con un clasificador que deja pasar lo seguro y bloquea lo arriesgado.⁴
• /sandbox, que ejecuta en un entorno aislado para reducir el riesgo de comandos con efectos.⁴

Estas dos comodidades atacan la fatiga de aprobación desde ángulos complementarios, y conviene entender la diferencia. El Auto mode automatiza el juicio: en lugar de mantener tú una allowlist manual, un clasificador evalúa cada acción y decide si es lo bastante segura para dejarla pasar o lo bastante arriesgada para detenerla; reduce las preguntas sin que tengas que anticipar caso por caso. El sandbox, en cambio, no automatiza el juicio sino que cambia las apuestas: ejecuta los comandos en un entorno aislado del resto de tu sistema, de forma que aunque algo salga mal, el daño queda confinado. La consecuencia es elegante: si la acción no puede romper nada importante porque está enjaulada, ya no necesita tu visto bueno, y muchas preguntas desaparecen no porque las hayas autorizado, sino porque dejan de ser peligrosas. Aislar el riesgo es, a menudo, más seguro que confiar en aprobarlo bien.

Paso 4 · los slash commands del día a día

Objetivo: tener en los dedos los comandos que de verdad se usan. Pruébalos uno a uno dentro de claude:

Los slash commands (comandos de barra) son instrucciones que escribes empezando por / y que la herramienta interpreta directamente, sin pasárselas al modelo como si fueran una petición en lenguaje natural. Esa distinción es lo que los hace fiables: cuando escribes /clear, el contexto se borra de verdad, no «si Claude decide hacerte caso». La mayoría de los que verás aquí giran, una vez más, alrededor de la ventana de contexto, medirla, limpiarla, comprimirla, porque ese es el recurso que más condiciona la calidad de una sesión larga. Aprenderlos no es memorizar una lista, sino adquirir el vocabulario para administrar ese recurso a conciencia.

/clear

Borra el contexto de la conversación y empieza desde cero. Úsalo al cambiar de tarea. Por qué: el cuello de botella de Claude es la ventana de contexto (la memoria de trabajo de la conversación, limitada en tamaño); arrastrar material irrelevante de una tarea anterior ocupa ese espacio y degrada la calidad de las respuestas.⁴

/compact resume lo decidido y los archivos tocados

Compactar resume la conversación para liberar contexto sin perder el hilo. Puedes darle instrucciones de qué conservar. Por qué: cuando la sesión es larga pero quieres seguir, compactar dirigido conserva lo importante.⁴

La diferencia entre /clear y /compact es la diferencia entre olvidar y resumir, y elegir mal cuesta. /clear descarta el contexto por completo: lo usas cuando cambias de tarea y lo de antes ya no aporta nada, de modo que arrastrarlo solo estorbaría. /compact hace algo más sutil: pide al modelo que condense la conversación en un resumen mucho más corto y sustituye el historial largo por ese resumen, liberando espacio sin romper la continuidad. Por eso /compact es la herramienta adecuada cuando sigues en la misma tarea pero la sesión ha crecido tanto que se acerca al límite. Que puedas indicarle qué conservar, «resume lo decidido y los archivos tocados», es clave, porque todo resumen pierde detalle: si no diriges la compactación, el modelo decide por su cuenta qué es prescindible y puede tirar justo lo que tú necesitabas. Una compactación guiada protege lo que importa; una a ciegas es una apuesta.

Para retroceder un paso (con Esc dos veces) hay un paso entero más abajo, porque tiene su miga; aquí solo lo dejamos apuntado.

/model

Cambia el modelo de la sesión (por ejemplo, uno más potente para planificar y otro más rápido para ejecutar). Lo veremos a fondo en el nivel 3.

/context

Te muestra cuánto contexto llevas consumido: tu «medidor de gasolina» para saber cuándo conviene compactar o limpiar.⁵ El valor de este comando es que convierte una intuición vaga, «llevamos un rato largo», en un dato. La degradación por contexto saturado no avisa con un error; se manifiesta como respuestas que poco a poco pierden precisión, olvidan detalles del principio o repiten cosas ya dichas. Mirar el medidor de vez en cuando, sobre todo antes de abordar una parte delicada de la tarea, te permite decidir con criterio si te queda margen o si conviene compactar antes de seguir, en lugar de descubrirlo cuando la calidad ya ha caído.

/effort high

Ajusta el esfuerzo de razonamiento extendido (low/medium/high): más esfuerzo, más reflexión antes de actuar, útil para problemas difíciles.⁵ El mecanismo es que, a mayor esfuerzo, el modelo dedica más pasos internos a pensar antes de responder, lo que mejora su rendimiento en tareas que requieren encadenar razonamientos, un algoritmo intrincado, una depuración con muchas piezas, a cambio de respuestas más lentas. No es gratis ni siempre conveniente: para tareas mecánicas o de poca enjundia, subir el esfuerzo solo añade espera sin mejorar el resultado. La pauta razonable es subirlo cuando notes que el problema tiene miga y bajarlo cuando el trabajo sea rutinario, igual que no usarías la marcha más corta para circular por autovía.

Otros comandos que existen hoy y conviene conocer (la lista completa está en la doc y / la despliega): /memory (edita los archivos de memoria), /plan (entra en modo plan), /resume (retoma una sesión), /init, /permissions, /agents, /mcp, /config, /login, /btw, /tasks, /background y /exit.⁵ No hace falta dominarlos hoy; basta saber que existen y que /help los lista.

Paso 5 · trabaja con el flujo explorar → planificar → codificar → confirmar

Objetivo: sustituir las peticiones de cambio improvisadas por el flujo de trabajo estructurado que recomienda la documentación.⁴

La razón de fondo para separar la investigación de la ejecución es la misma que en cualquier oficio: medir dos veces y cortar una. Un modelo de lenguaje, si le pides directamente «arregla esto», tiende a empezar a escribir código de inmediato, sobre la primera hipótesis que se le ocurre; y si esa hipótesis es errónea, porque no ha entendido cómo encaja la pieza en el conjunto, el error se materializa en ediciones que luego hay que deshacer. Cada una de las cuatro fases corrige un fallo distinto de ese atajo. Explorar primero obliga a construir un entendimiento antes de proponer nada. Planificar antes de codificar saca la estrategia a la luz, donde tú puedes corregirla barata y verbalmente, en vez de tener que revertir código. Codificar solo con tu visto bueno mantiene el control en el punto de máximo riesgo. Y confirmar al final convierte el trabajo en algo verificable y recuperable. El coste de añadir estas fases es minutos; el coste de saltárselas es rehacer.

El plan mode (modo plan) es la pieza técnica que hace creíble la fase de planificación. No basta con pedirle a Claude «no escribas todavía» y fiarse de que obedezca: en modo plan, es el propio sistema el que le impide tocar el disco, de modo que la separación entre pensar y hacer deja de depender de su buena voluntad y pasa a estar garantizada por la herramienta. Eso te permite dejarle explorar a fondo y discutir el plan con tranquilidad, sabiendo que ni por descuido ni por exceso de iniciativa va a modificar nada hasta que tú levantes la barrera. Es la diferencia entre pedir prudencia y tener una salvaguarda.

1. Explorar. Pídele que entienda antes de tocar:

   Explora cómo se gestiona la autenticación en este proyecto. No cambies nada todavía.
   

2. Planificar. Entra en plan mode (modo plan). En este modo, Claude puede leer y explorar el proyecto, pero el sistema le impide escribir en el disco: produce un plan razonado en lugar de ediciones. En versiones recientes, Ctrl+G abre ese plan en tu editor para revisarlo con calma (verifica que tu versión lo soporta).⁴

   Hazme un plan para añadir recuperación de contraseña. Enséñame el plan antes de escribir código.
   

3. Codificar. Cuando el plan te convenza, dale luz verde para implementarlo.

4. Confirmar. Pídele que confirme en Git:

   Haz commit de estos cambios con un mensaje claro.
   

Por qué: darle a Claude una forma de verificar su trabajo (tests, build, linter, diffs) es lo que más sube la calidad. Planificar antes de codificar evita que se lance a escribir sobre una idea equivocada.⁴

Paso 6 · dale a Claude una forma de verificar su trabajo

Objetivo: que Claude no te diga «ya está» a ciegas, sino que lo demuestre. Esta es, según la doc, la palanca que más sube la calidad de todo lo que escribe.⁴

Para entender por qué esto pesa tanto hay que mirar cómo decide un modelo de lenguaje que algo «está bien». Por su naturaleza, un modelo genera el texto más plausible dada la conversación; produce código que parece correcto porque se asemeja al código correcto que ha visto, pero esa plausibilidad no es lo mismo que el funcionamiento. El modelo no ejecuta el programa en su cabeza: estima. Y como además tiende a la afirmación segura, fue entrenado para sonar resolutivo, su instinto es declarar la tarea terminada en cuanto el código tiene buen aspecto. Ese es exactamente el momento en que se cuelan los fallos, porque «tiene buen aspecto» y «funciona» son juicios distintos que solo coinciden por suerte.

El grounding (anclaje a la realidad) es el remedio: consiste en darle al modelo una fuente de verdad externa a su propio juicio, una comprobación que arroja un resultado objetivo que él no controla. Un test que pasa o falla, un compilador que acepta o rechaza, un linter que señala o calla: ninguno de esos veredictos depende de lo que el modelo crea. Cuando le das acceso a una de esas comprobaciones y le pides que la ejecute, ocurre algo cualitativamente nuevo. El modelo deja de operar a ciegas y entra en un bucle: escribe, ejecuta, lee el error real, corrige, vuelve a ejecutar. Cada vuelta sustituye una conjetura por una observación. No es que el modelo se vuelva más listo; es que por fin puede comprobar su propio trabajo en lugar de suponerlo, y esa diferencia, entre suponer y comprobar, es la que más sube la calidad de todo lo que produce.

La idea es sencilla: un modelo que solo escribe código no sabe si funciona; un modelo que además puede ejecutar una comprobación y leer el resultado se corrige solo. Dale siempre una vara de medir y pídele que la use antes de cantar victoria:

Implementa la función y luego ejecuta `npm test`. Si algún test falla, arréglalo y vuelve a pasarlos. Enséñame la salida final.

Las cuatro varas de medir más útiles, de más a menos automática:

1. Tests. Lo más fuerte: o pasan o no pasan. Si el proyecto no tiene, pídele que escriba uno que falle primero y luego el código que lo haga pasar.
2. Build. npm run build (o el que sea) caza errores que el ojo no ve.
3. Linter y tipos. npm run lint, tsc --noEmit: estilo y tipados mal puestos.
4. Diff contra una referencia. Cuando no hay tests, pídele que compare su resultado con un ejemplo o una especificación y te señale las diferencias.

Esta lista no es caprichosa: está ordenada por cuán difícil es engañarla. Un test es la vara más fuerte porque codifica una expectativa concreta y comprobable; por eso, cuando no exista, la inversión más rentable es pedir que se escriba el test primero, que falle, y luego el código que lo haga pasar, porque así la prueba nace independiente de la implementación y no se limita a confirmar lo que el código ya hace. La construcción y el comprobador de tipos son redes más bastas pero valiosísimas, porque cazan clases enteras de errores, una referencia rota, un tipo incompatible, que el ojo humano pasa por alto al leer. Y la comparación contra una referencia es el recurso para cuando no hay nada automático: menos rigurosa, pero infinitamente mejor que la palabra del modelo.

La regla de oro: pide evidencia, no aserciones. «Funciona» no vale; «aquí está la salida de los tests en verde» sí. Por qué: sin una forma de verificar, Claude tiende a dar por bueno lo que escribió, y tú heredas el fallo. Con ella, el bucle de corrección lo hace él, no tú.⁴ Hay una razón concreta para exigir la salida y no la conclusión: la afirmación «los tests pasan» es justo el tipo de texto plausible que el modelo puede generar sin haber ejecutado nada, mientras que pegar la salida real lo obliga a haber corrido la prueba de verdad. Pedir la evidencia cierra la puerta a la conjetura disfrazada de hecho. Adoptado como costumbre, este hábito traslada la carga de verificar desde tus hombros a los del modelo: en vez de descubrir tú el fallo más tarde, lo descubre él ahora, que es cuando arreglarlo es barato.

Paso 7 · retrocede con checkpoints (Esc, Esc)

Objetivo: deshacer el último paso de la conversación o del código cuando algo se tuerce, sin salir de la sesión.

Para usar bien esta función conviene saber qué guarda exactamente. Una sesión de Claude Code tiene dos estados que avanzan en paralelo: el de la conversación, lo que os habéis dicho, lo que el modelo lleva en su contexto, y el de tus archivos en disco. Cada vez que Claude está a punto de modificar el código, captura un checkpoint (punto de guardado) de ambos antes de actuar, de forma automática y sin que tengas que pedírselo. Que sean dos estados distintos es justo lo que da sentido a las tres opciones de restauración que verás a continuación: a veces quieres rebobinar la charla sin tocar el código, otras deshacer las ediciones conservando lo hablado, y otras volver del todo. Poder elegir cuál de los dos hilos retroceder es lo que convierte el rewind en una herramienta fina y no en un martillo.

Pulsa Esc dos veces (o usa el comando de retroceso si tu versión lo expone como /rewind). Verás una lista de checkpoints (puntos de guardado que Claude crea automáticamente) y podrás restaurar tres cosas:

• Solo la conversación, para volver a un punto del diálogo sin tocar tus archivos.
• Solo el código, para deshacer las ediciones manteniendo lo hablado.
• Ambos, para volver del todo a como estaba.

Esc, Esc

Aviso importante: es una función reciente de checkpoints; verifica que tu versión la tiene. Y, sobre todo, no sustituye a Git: los checkpoints son una red de seguridad dentro de la sesión, no un historial de versiones. Por qué: equivocarse es parte del trabajo; poder retroceder un paso sin perder toda la sesión te anima a probar cosas, pero lo serio se sigue guardando en Git.⁴

La distinción entre checkpoints y Git no es un matiz, sino una diferencia de propósito que importa no confundir. Los checkpoints son volátiles y locales a la sesión: cubren las ediciones que hace Claude, viven mientras dura la conversación y no entienden de ramas, mensajes de commit ni colaboración. Git es lo contrario: un historial deliberado y permanente, donde tú decides qué momentos merecen quedar registrados, los describes con un mensaje y los compartes con tu equipo. Uno es el botón de deshacer de la sesión; el otro, la memoria duradera del proyecto. La regla práctica que se deriva es clara: apóyate en los checkpoints para experimentar sin miedo dentro de una conversación, pero confía a Git todo hito que quieras conservar mañana. Si solo dependieras de los checkpoints, un cambio que te gustó podría evaporarse al cerrar la sesión; por eso el flujo del paso anterior terminaba, precisamente, en un commit.

Paso 8 · deja que Claude lleve Git por ti

Objetivo: que Claude haga los commits y abra las pull requests (peticiones de cambios) por ti, con mensajes claros, en vez de teclearlos tú.

Que Claude maneje Git bien tiene una explicación: Git es una de las herramientas más documentadas que existen, con décadas de ejemplos públicos, de modo que el modelo conoce a fondo sus comandos y, lo que es más útil, las convenciones de un buen mensaje de commit. Eso lo habilita para una tarea en la que las personas solemos flaquear por pereza: redactar mensajes que expliquen el porqué del cambio y no solo el qué. Donde tú escribirías «arreglos varios» a las ocho de la tarde, Claude puede mirar el diff real y describir con precisión qué se modificó y con qué intención, porque tiene delante los cambios concretos en lugar de un recuerdo difuso.

Claude conoce Git y, si tienes el CLI gh (el de GitHub) instalado y autenticado, también sabe abrir PRs. Pídeselo en lenguaje normal:

Haz commit de estos cambios con un mensaje claro que explique el porqué, no solo el qué.

Y para subir el trabajo a revisión:

Crea una rama, haz commit, súbela y abre una PR con gh resumiendo qué cambia y por qué.

Claude redactará el mensaje, ejecutará los comandos (pidiéndote permiso en la puerta, como siempre) y te devolverá el enlace de la PR. Por qué: un buen mensaje de commit es documentación que tu yo futuro agradecerá, y delegar el «ritual» de Git en Claude te quita fricción sin perder el control, porque cada paso pasa por la puerta de permisos.⁴

Paso 9 · aliméntalo con contenido rico

Objetivo: pasarle archivos, imágenes, logs y URLs, no solo texto.

El principio que une a todas estas vías es uno: cuanto más exacto sea el contexto que le das, menos tiene que adivinar el modelo, y adivinar es la fuente principal de sus errores. Una descripción tuya de un error de pantalla es una traducción aproximada de lo que viste; la captura misma es el dato sin pérdidas. El nombre de un archivo dicho de memoria puede estar equivocado; la referencia @ apunta al archivo real y carga su contenido literal. Cada uno de estos mecanismos sustituye tu reconstrucción imperfecta por la fuente directa. Que el modelo sea multimodal, que entienda imágenes además de texto, no es un adorno: es lo que te permite enseñarle el problema en vez de contárselo, y mostrar casi siempre comunica mejor que describir.

• Referencia un archivo con @:

  Revisa @src/auth/login.ts y dime si hay algún fallo de seguridad.
  

• Pega una imagen (una captura de un error de la interfaz, un diseño) directamente en el cuadro de texto. Claude la interpreta.

• Pega una URL y Claude puede recuperar su contenido para usarlo como contexto.

• Cánalízale un log desde la terminal con el modo -p (lo veremos en el nivel 3):

  cat error.log | claude -p "explícame este error y cómo arreglarlo"
  

Por qué: @ ahorra que adivine qué archivo es; las imágenes y logs le dan el contexto exacto del problema en vez de tu descripción aproximada.⁶

Paso 10 · deja que use tus CLIs

Objetivo: que use herramientas reales en vez de inventar.

Si tienes instalados y autenticados CLIs como gh (GitHub) o aws, díselo:

Usa el CLI gh para listar las PR abiertas y resúmemelas.

Por qué: la doc recomienda apoyarse en CLIs existentes en lugar de que Claude reconstruya información de memoria; el resultado es real y verificable.⁴

Hay además una razón de eficiencia que conviene entender. Un CLI (command-line interface, interfaz de línea de comandos) como gh o aws es una herramienta que Claude ejecuta y de la que lee solo la respuesta concreta a lo que pidió: las PR abiertas, el estado de un recurso. Acceder en bruto a una API equivalente suele obligar a manejar autenticación, paginación y respuestas verbosas en formato estructurado, todo lo cual termina ocupando la ventana de contexto con material de andamiaje que no aporta a la tarea. El CLI absorbe esa complejidad por dentro y devuelve un resultado ya digerido y legible. El efecto neto es doble: gastas menos contexto, porque entra la respuesta y no el aparato que la produce, y obtienes un dato verificable que el modelo no ha tenido que reconstruir de memoria. Por eso, siempre que exista un CLI ya instalado y autenticado para una tarea, es preferible a que Claude improvise el acceso por su cuenta.

Conviene matizar un punto que a veces se malinterpreta: apoyarse en un CLI ya autenticado no equivale a dar acceso ilimitado. Cada comando que el CLI ejecuta sigue pasando por la puerta de permisos del paso 3, igual que cualquier otra acción con efectos. La ventaja está en la calidad y la economía del resultado, no en saltarse el control. Donde más rinde es en cualquier trabajo que toque servicios externos, repositorios, infraestructura en la nube, despliegues, porque ahí el ahorro de contexto y la fiabilidad del dato se notan en cada interacción.

Paso 11 · reanuda sesiones

Objetivo: no perder el hilo entre días.

Para retomar la última conversación de esta carpeta (-c es la forma corta de --continue):

claude --continue
claude -c

Para elegir cuál retomar de un listado (-r es la forma corta de --resume):

claude --resume
claude -r

Dentro de la sesión, /resume hace lo mismo desde el REPL. Por qué: el trabajo real abarca varias sesiones; reanudar conserva el contexto en vez de empezar de cero.⁴

El mecanismo es que Claude Code guarda el historial de cada conversación asociado a la carpeta del proyecto, de modo que reanudar no «recuerda» en un sentido humano, sino que recarga ese historial en la ventana de contexto y reconstruye el estado en que lo dejaste. La distinción entre las dos formas tiene su lógica: --continue retoma sin preguntar la última conversación de la carpeta actual, ideal cuando solo quieres seguir donde estabas; --resume te ofrece la lista para elegir, útil cuando llevas varios hilos en paralelo en el mismo proyecto y necesitas volver a uno concreto. Que el historial esté ligado a la carpeta explica un detalle práctico: si lanzas Claude desde otro directorio, no encontrará esas sesiones.

Conviene combinar esto con lo que ya sabes del contexto. Reanudar recupera el hilo, pero también recupera todo el peso que esa conversación había acumulado; si la dejaste larga y saturada, la heredas saturada. Por eso reanudar y compactar son hábitos complementarios: el primero te devuelve donde estabas, y el segundo mantiene ese «donde estabas» manejable. Para trabajo que de verdad cruza días, sin embargo, la memoria fiable no es el historial de la sesión sino lo que hayas dejado por escrito en el CLAUDE.md y confiado a Git; el historial es continuidad cómoda, no almacén permanente.

Paso 12 · conecta una herramienta externa con MCP

Objetivo: dar a Claude acceso a servicios externos mediante MCP (Model Context Protocol, el protocolo estándar para conectar herramientas).

Desde la terminal, en la raíz del proyecto:

claude mcp add --transport http nombre-servicio --scope project https://url-del-servidor-mcp

Esto registra el servidor en el archivo .mcp.json del proyecto (que se versiona en Git, gracias a --scope project). Dentro de claude, /mcp te muestra las conexiones activas. Por qué: MCP estandariza la forma en que Claude se comunica con bases de datos, gestores de incidencias o tu propia API. En lugar de que copies y pegues datos a mano, el servidor MCP expone esos recursos mediante un protocolo común y Claude los consulta directamente; al ser un estándar, el mismo servidor sirve para cualquier herramienta compatible.⁷

Para apreciar el alcance de esto conviene entender qué problema resuelve un protocolo. Antes de MCP, conectar un asistente a cada servicio externo exigía una integración a medida: un puente específico para la base de datos, otro distinto para el gestor de incidencias, otro para tu API, cada uno con su propia forma de hablar. Eso no escala, el número de puentes crece con cada combinación de asistente y herramienta, y obliga a reescribir el mismo trabajo una y otra vez. El MCP (Model Context Protocol, protocolo de contexto del modelo) introduce un idioma común: define una manera estándar de que un servidor describa los recursos y acciones que ofrece y de que un modelo los consulte, igual que un enchufe estandarizado permite que cualquier aparato se conecte a cualquier toma sin un adaptador a medida.

Que sea un estándar abierto es lo que multiplica su valor, y merece subrayarse. Como la especificación es pública y no propiedad de un solo fabricante, cualquiera puede escribir un servidor MCP para su servicio, y ese servidor funcionará con cualquier cliente que hable el protocolo, no solo con Claude. El efecto es de red: cada servidor nuevo que alguien publica amplía lo que toda la comunidad puede conectar, y el esfuerzo de integrar una herramienta se hace una vez y sirve para muchos. En la práctica, esto significa que rara vez tendrás que construir el puente tú mismo: para los servicios habituales, lo más probable es que ya exista un servidor MCP que solo tienes que registrar, como acabas de hacer.

Un apunte sobre el alcance del registro. El --scope project no es un detalle administrativo: al escribir la conexión en el .mcp.json versionado, haces que el servidor forme parte de la configuración compartida del repositorio, de modo que tu equipo dispondrá de la misma herramienta sin reconfigurar nada. Y, como con todo lo que tiene efectos, las acciones que el servidor MCP ejecute seguirán pasando por la puerta de permisos: conceder a Claude acceso a un servicio no es entregarle un cheque en blanco sobre él.

Checkpoint del nivel 2

Ahora ya puedes:

• Crear y afinar un CLAUDE.md corto y entender la jerarquía de memoria que se concatena.
• Gestionar permisos con /permissions, ciclar los cuatro modos con Shift+Tab y conocer Auto mode y /sandbox.
• Manejar /clear, /compact, /model, /context y /effort.
• Trabajar con el flujo explorar→planificar→codificar→confirmar y el plan mode.
• Pedirle que verifique su trabajo con tests, build o linter, y exigir evidencia.
• Retroceder con checkpoints (Esc+Esc) sabiendo que no sustituyen a Git.
• Delegar Git: commits con mensajes claros y PRs con gh.
• Pasarle archivos con @, imágenes, URLs y logs.
• Reanudar sesiones con --continue y --resume.
• Conectar un servidor MCP con claude mcp add.

Cuando esto sea tu rutina, sube al nivel 3.

Nivel 3 · un poco más avanzado

Llegas desde el nivel 2 manejando el flujo completo con soltura. Este nivel cubre las prácticas de quienes aprovechan Claude Code de forma más intensiva: extenderlo con subagentes, skills, hooks y comandos propios; automatizarlo sin interfaz; combinar modelos; y administrar el contexto como un recurso escaso. Cada una de estas piezas es un archivo de texto que puedes versionar y compartir con tu equipo, lo que convierte tu configuración en código revisable.

Paso 1 · crea un subagente

Objetivo: tener un agente especializado, con su propio contexto aislado, para una tarea concreta (revisar código, explorar, buscar bugs).

Un subagente vive en .claude/agents/<nombre>.md con un frontmatter (cabecera de metadatos en YAML, entre ---). Crea .claude/agents/code-reviewer.md:

---
name: code-reviewer
description: Revisor de código. Úsalo tras escribir o modificar código para detectar bugs y problemas de estilo.
tools: Read, Grep, Glob, Bash
model: claude-sonnet-4-6
---

Eres un revisor de código riguroso y conciso.

Cuando se te invoque:
1. Mira el diff actual (git diff).
2. Señala solo problemas reales de correctness, seguridad y estilo del proyecto.
3. No reescribas el código: explica el problema y propón el arreglo en una línea.
4. Ordena los hallazgos por gravedad.

Los campos del frontmatter: name (nombre), description (cuándo usarlo; Claude lo lee para decidir si delega), tools (qué herramientas puede usar; si lo omites, hereda las del padre), model (o inherit para usar el de la sesión). Dentro de claude, /agents los lista y gestiona. Por qué: un subagente trabaja en su propia ventana de contexto, así una exploración pesada no ensucia tu conversación principal.⁸

El mecanismo que sostiene a un subagente es el aislamiento de contexto. Cuando la conversación principal delega una tarea, el subagente arranca con una ventana de contexto independiente: no ve tu historial completo, sino el encargo concreto que se le pasa. Resuelve la tarea, puede leer decenas de archivos, lanzar búsquedas, ejecutar comandos, y de toda esa actividad solo devuelve al hilo principal un resultado sintetizado. Esa frontera es deliberada. La ventana de contexto de un modelo es finita, y cada token de exploración intermedia que se acumula en la conversación principal compite por espacio con la información que de verdad necesitas a mano. Al confinar el trabajo sucio dentro del subagente, evitas que tu hilo se sature de ruido y conservas su capacidad de razonar sobre lo que importa.

El campo description merece atención porque es el que gobierna la delegación automática: Claude lo lee para decidir, en cada momento, si una tarea encaja con este subagente y conviene invocarlo. Una descripción vaga produce un subagente que nunca se dispara o que se dispara cuando no toca; por eso conviene redactarla diciendo explícitamente en qué situaciones aplica. El campo tools impone el principio de menor privilegio: si un revisor de código solo necesita leer y buscar, no tiene sentido concederle permiso de escritura, porque acotar la superficie de acción reduce el margen de error. El riesgo a vigilar es el coste: como cada subagente abre su propia ventana, delegar en exceso multiplica el consumo de tokens, de modo que la herramienta rinde cuando la tarea es voluminosa y lateral, no cuando es trivial.

Paso 2 · crea una skill

Objetivo: empaquetar un workflow (flujo de trabajo) reutilizable que Claude carga solo cuando hace falta.

Una skill (habilidad) vive en .claude/skills/<nombre>/SKILL.md. Crea .claude/skills/release-notes/SKILL.md:

---
name: release-notes
description: Genera notas de versión a partir de los commits desde la última etiqueta.
disable-model-invocation: true
allowed-tools: Bash(git log:*), Read
---

# Notas de versión

1. Ejecuta `git log <última-tag>..HEAD --oneline` para listar los commits.
2. Agrúpalos en Añadido, Cambiado, Arreglado y Seguridad.
3. Escribe un CHANGELOG en formato Keep a Changelog.
4. No publiques ni hagas push: solo genera el texto.

El frontmatter admite name, description, allowed-tools, context (main o fork) y disable-model-invocation. Esta última, en true, evita que Claude la dispare por su cuenta: la lanzas tú a propósito. Por qué: la doc recomienda disable-model-invocation: true para workflows con efectos secundarios (despliegues, publicaciones), de modo que nunca se ejecuten sin que tú lo pidas. Las skills usan divulgación progresiva: Claude solo carga el detalle cuando la necesita.⁹ Desde la versión 2.1, comandos y skills convergen en el mismo modelo.⁹

La divulgación progresiva (progressive disclosure) es el principio que distingue a una skill de otras formas de extender Claude. En lugar de cargar el procedimiento completo en el contexto desde el primer momento, Claude conoce de entrada solo el nombre y la descripción de la skill; el cuerpo, los pasos detallados, los archivos auxiliares, los ejemplos, se incorpora únicamente cuando la situación los reclama. El efecto es que puedes acumular docenas de skills sin que su contenido pese sobre cada conversación: solo paga el coste de contexto la skill que de verdad se usa, y solo mientras se usa. Esto convierte a las skills en el mecanismo idóneo para empaquetar procedimientos largos y especializados que no necesitas tener presentes a todas horas.

Conviene situar la skill frente a sus dos parientes cercanos. A diferencia del CLAUDE.md, que se carga siempre y en su totalidad, y por eso debe reservarse para lo que aplica a todo el proyecto, una skill se carga bajo demanda, lo que la hace apta para conocimiento voluminoso y de uso ocasional. Y a diferencia de un subagente, que se ejecuta en su propio contexto aislado y devuelve solo un resumen, una skill por defecto opera dentro de tu conversación principal (salvo que declares context: fork): no delega la tarea a otro hilo, sino que inyecta en el tuyo las instrucciones para llevarla a cabo. La regla práctica es clara: usa una skill cuando quieras enseñarle a Claude cómo hacer algo paso a paso dentro de tu sesión, y un subagente cuando quieras que otro lo haga aparte sin contaminarte el contexto.

Paso 3 · añade un hook determinista que bloquee comandos peligrosos

Objetivo: garantizar que algo siempre pase (o nunca pase), sin depender de que Claude se acuerde.

Un hook (gancho) es código determinista que se dispara en ciertos eventos. Se declara dentro de settings.json, no en una carpeta suelta.¹⁰ El conjunto de eventos bien asentado para empezar es PreToolUse (antes de usar una herramienta), PostToolUse (después), SessionStart (al arrancar la sesión), Stop (al terminar de responder) y PreCompact (antes de compactar). Hay más eventos disponibles; consulta la guía de hooks para la lista completa de tu versión antes de apoyarte en ellos.¹⁰ El hook recibe por stdin un JSON con {tool_name, tool_input}; si sale con exit 2, bloquea la acción y manda su stderr a Claude; con exit 0, la permite.¹⁰

Este PreToolUse bloquea cualquier rm -rf. Guárdalo en .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.command' | grep -qE 'rm -rf' && { echo 'Bloqueado: rm -rf no permitido.' >&2; exit 2; } || exit 0"
          }
        ]
      }
    ]
  }
}

jq extrae el comando del JSON de entrada; si encuentra rm -rf, escribe el aviso en stderr y sale con exit 2 (bloquea); si no, exit 0 (permite). Por qué: lo que es innegociable no se confía a un prompt, se hace determinista con un hook. El propio Claude puede escribirte hooks si se lo pides.⁴

La clave conceptual aquí es el determinismo. Un modelo de lenguaje es probabilístico: ante la misma instrucción puede comportarse de un modo casi siempre y de otro de vez en cuando, y esa pequeña varianza es justo lo inaceptable cuando hablas de algo que jamás debe pasar, como un borrado destructivo. Un hook no es texto que Claude interpreta y puede ignorar bajo presión del contexto; es código que el propio Claude Code ejecuta fuera del modelo, en cada evento del tipo declarado, sin excepción. Esa es la diferencia entre escribir en el CLAUDE.md «nunca ejecutes rm -rf», una súplica que el modelo cumplirá la mayoría de las veces, y un hook que lo impide siempre. Cuando una garantía debe ser absoluta, sácala del lenguaje natural y métela en un mecanismo determinista.

El protocolo de comunicación explica por qué el hook puede decidir con fiabilidad. Antes de ejecutar la herramienta, Claude Code serializa la acción propuesta, nombre de la herramienta y sus argumentos, en un JSON y se lo entrega al hook por la entrada estándar (stdin). El hook inspecciona esos datos con las utilidades de siempre (jq para leer el JSON, grep para buscar un patrón) y comunica su veredicto a través del código de salida: exit 0 deja pasar la acción, mientras que exit 2 la bloquea y, además, reenvía a Claude lo que el hook haya escrito en la salida de error (stderr). Ese mensaje de stderr no es decorativo: es el canal por el que el hook le explica a Claude por qué se ha denegado la acción, de modo que el modelo pueda corregir el rumbo en lugar de reintentar a ciegas. El riesgo a vigilar es la fragilidad del patrón: un matcher mal escrito no se dispara nunca, y una comprobación demasiado laxa o demasiado estricta puede bloquear comandos legítimos o dejar pasar variantes peligrosas, así que conviene probar el hook con casos reales antes de confiar en él.

Paso 4 · un hook PostToolUse que formatea al guardar

Objetivo: que cada archivo editado quede formateado, automáticamente.

Amplía tu settings.json con un PostToolUse que pase Prettier tras cada edición, y aprovecha para fijar permisos de allow/deny:

{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(npm run lint:*)",
      "Read"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Read(.env)"
    ]
  },
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs -r npx prettier --write"
          }
        ]
      }
    ]
  }
}

Mientras PreToolUse actúa como una puerta que decide antes de obrar, PostToolUse se dispara después de que la herramienta haya hecho su trabajo, y por eso es el lugar natural para reaccionar a un cambio ya consumado. El patrón canónico es el formateo automático: cada vez que Claude edita o escribe un archivo, el hook recibe la ruta del archivo modificado en el JSON de entrada, la extrae con jq y se la pasa a Prettier para que lo deje formateado. El valor de hacerlo aquí, y no pidiéndoselo a Claude en cada cambio, es doble: el formato se aplica de manera uniforme y sin negociación, y liberas al modelo de tener que acordarse de una tarea mecánica que una herramienta determinista hace mejor y más barato. El antipatrón a evitar es montar en PostToolUse operaciones lentas o que disparen a su vez nuevas ediciones, porque se ejecutan tras cada cambio y pueden ralentizar el flujo o realimentarse.

La precedencia de settings.json se aplica por capa completa, de mayor a menor: configuración gestionada por el sistema → flags del CLI → .claude/settings.local.json → .claude/settings.json → ~/.claude/settings.json. Casi todo se recarga en caliente, salvo model y outputStyle.¹¹ Por qué: con un hook de formato dejas de discutir estilo en cada cambio; pasa siempre, sin pedirlo.⁴

Que la precedencia se aplique por capa completa, y no campo a campo, tiene una consecuencia práctica que conviene interiorizar: la capa de mayor prioridad que defina una sección la gana entera, no se fusionan los valores individuales de cada nivel. Esto explica la división del trabajo entre archivos. El ~/.claude/settings.json global guarda tus preferencias personales, válidas en todos los proyectos; el .claude/settings.json del proyecto recoge lo que el equipo comparte y versiona en Git; y el .claude/settings.local.json, que no se versiona, es para tus ajustes locales y tus secretos, los que no deben viajar al repositorio. La recarga en caliente, que reaplica casi todos los cambios sin reiniciar la sesión, agiliza la iteración sobre permisos y hooks; las dos excepciones, model y outputStyle, requieren reiniciar para surtir efecto, un detalle que evita desconciertos cuando un cambio «no parece aplicarse».

Paso 5 · crea un slash command propio con argumentos y bash

Objetivo: encapsular una orden que repites en un comando /tuyo.

Un comando vive en .claude/commands/<nombre>.md y se invoca como /<nombre>. Crea .claude/commands/deploy.md:

---
argument-hint: <entorno>
allowed-tools: Bash(git status:*), Bash(git log:*)
model: claude-sonnet-4-6
---

Despliega a `$ARGUMENTS`.

Estado actual del repositorio:
!`git status --short`

Últimos commits:
!`git log -5 --oneline`

Pasos:
1. Verifica que no hay cambios sin commitear.
2. Comprueba que estamos en la rama correcta para `$ARGUMENTS`.
3. Resume qué se desplegaría y pídeme confirmación antes de actuar.

$ARGUMENTS recoge lo que escribas tras el comando (/deploy staging → staging). El prefijo ! ejecuta bash y mete la salida en el contexto; @ruta insertaría un archivo. El frontmatter admite argument-hint, allowed-tools y model.⁹ Por qué: un comando propio convierte un procedimiento de varios pasos en una sola orden repetible y compartible con el equipo.

El mecanismo que da potencia a un comando propio es que su cuerpo no es un texto estático, sino una plantilla que se expande en el momento de invocarla. Cuando escribes /deploy staging, Claude Code sustituye $ARGUMENTS por staging y, antes de entregar el resultado al modelo, ejecuta cada línea marcada con ! e inserta su salida en el sitio. Así, lo que llega al modelo no es la orden «despliega», sino esa orden ya enriquecida con el estado real del repositorio y los últimos commits, capturados al vuelo. Esta expansión convierte un comando en una forma de inyectar contexto fresco y pertinente sin que tú tengas que copiar y pegar nada: el procedimiento y los datos sobre los que opera se ensamblan en un solo gesto.

Aquí es donde allowed-tools cobra importancia de seguridad. Como el prefijo ! ejecuta bash de verdad, restringir el comando a una lista mínima, en el ejemplo, solo git status y git log de lectura, acota lo que ese comando puede hacer en tu sistema y evita que una plantilla compartida con el equipo se convierta en un vector para ejecutar cualquier cosa. El error típico es olvidar esa restricción y dejar el comando con acceso amplio «por comodidad», lo que traslada el riesgo a quien lo instale después. Frente a una skill, que Claude puede invocar por su cuenta según la situación, un slash command es algo que disparas tú a propósito tecleando su nombre, lo que lo hace idóneo para procedimientos que quieres lanzar de forma deliberada y con parámetros explícitos.

Paso 6 · reglas con alcance por ruta

Objetivo: aplicar instrucciones solo cuando se tocan ciertos archivos, sin cargar memoria de más.

Lo nativo no es una carpeta .claude/rules/ (eso es solo una convención), sino el frontmatter paths: en un archivo de memoria. Sin paths, la regla se aplica siempre; con paths, solo al abrir archivos que casan el glob (patrón de rutas).³ Ejemplo de archivo de regla:

---
paths:
  - "src/api/**/*.ts"
---

En la capa de API: valida toda entrada con Zod y nunca devuelvas el stack trace al cliente.

Por qué: meter esto en el CLAUDE.md global lo cargaría siempre, gastando contexto; con paths solo aparece cuando trabajas en la API. El blog oficial recomienda mover de CLAUDE.md a reglas path-scoped todo lo que solo aplica a una parte del código.¹²

El mecanismo es la carga condicional. Una regla con paths permanece inerte, no ocupa contexto ni influye en el comportamiento, hasta que entra en juego un archivo cuya ruta casa con el glob declarado; en ese instante, y solo entonces, sus instrucciones se incorporan al contexto activo. El glob es el patrón que decide la coincidencia: src/api/**/*.ts cubre cualquier archivo TypeScript bajo el árbol de la API, a cualquier profundidad. La consecuencia es una correspondencia natural entre la instrucción y el lugar donde aplica: las reglas de validación de entrada acompañan al código de la API, las convenciones de los tests acompañan a los tests, y ninguna estorba cuando trabajas en otra parte.

El porqué de fondo es la economía del contexto. Todo lo que vive en el CLAUDE.md se carga en cada conversación, de principio a fin, compita o no con la tarea en curso; un CLAUDE.md que crece sin freno acaba diluyendo sus propias instrucciones, porque cuanto más texto compite por la atención del modelo, menos peso relativo tiene cada línea. Las reglas con alcance por ruta atacan ese problema de raíz: reducen el ruido de contexto al presentar cada norma únicamente en su contexto pertinente, lo que mantiene el CLAUDE.md corto y deja que cada parte del código traiga consigo sus propias reglas. El criterio de reparto es sencillo: lo que aplica a todo el proyecto va al CLAUDE.md; lo que solo aplica a una zona concreta va a una regla con paths.

Paso 7 · automatiza con modo headless

Objetivo: ejecutar Claude sin interfaz, para scripts y CI (headless: sin interfaz interactiva).

La forma básica con -p (de print, imprime la respuesta y termina):

claude -p "Resume los cambios del último commit"

Para que la salida sea procesable por una máquina, pide JSON:

claude -p "Lista los archivos con TODOs pendientes" --output-format json

También existe --output-format stream-json para recibir la respuesta por trozos en tiempo real. Y limitas qué herramientas puede usar con --allowedTools. Estos formatos son la vía documentada para CI; verifica los nombres exactos con claude --help en tu versión.⁴ Por qué: en CI no hay nadie para aprobar diffs; el modo headless con salida estructurada y herramientas acotadas te da control y resultados parseables.

El modo headless (sin interfaz) cambia el modelo de interacción de raíz. En la sesión interactiva, Claude conversa, pide permisos y espera tus aprobaciones; en modo headless con -p, recibe un encargo, lo resuelve, imprime la respuesta y termina, sin nadie al otro lado. Esa diferencia es justo lo que lo hace apto para la automatización: un script o un trabajo de integración continua (CI) no puede pulsar «aprobar» en un diálogo, así que necesita un Claude que arranque, produzca un resultado y devuelva un código de salida, todo de un tirón. Por eso headless es la pieza que conecta a Claude Code con tuberías de automatización, ganchos de Git y trabajos programados.

Pedir la salida en JSON con --output-format json no es un capricho de formato, sino lo que vuelve la respuesta consumible por otra máquina: un programa posterior puede leer ese JSON, extraer el campo que le interesa y decidir en consecuencia, algo imposible si la respuesta llega como prosa libre. La variante stream-json entrega la respuesta por trozos a medida que se genera, útil cuando quieres reaccionar antes de que termine. El acompañante imprescindible es --allowedTools: como en automatización nadie supervisa cada acción, acotar de antemano lo que el agente puede hacer sustituye al control humano que existía en la sesión interactiva. El peligro es evidente, un Claude headless con permisos amplios y sin vigilancia puede causar estragos, de modo que la regla es conceder lo mínimo imprescindible para la tarea y nada más.

Paso 8 · procesa muchos archivos en paralelo (fan-out)

Objetivo: aplicar la misma transformación a un montón de archivos, uno por proceso.

for file in src/legacy/*.js; do
  claude -p "Migra $file a TypeScript. No toques otros archivos." \
    --allowedTools "Edit,Bash(git commit:*)"
done

El bucle lanza un Claude por archivo, cada uno con su contexto limpio y permiso solo para editar y confirmar en Git. Por qué: dividir el trabajo en encargos pequeños e independientes rinde mejor que un único encargo de gran tamaño que satura el contexto. Conviene una advertencia de coste: los equipos de agentes en paralelo consumen más tokens (la documentación de comunidad estima un factor de tres a cuatro), de modo que su uso se justifica solo cuando existe paralelismo real que lo compense.⁶

El fan-out (despliegue en abanico) es la aplicación al trabajo de agentes de una idea vieja en computación: cuando una tarea grande se descompone en subtareas independientes, procesarlas por separado suele rendir más que abordarlas en bloque. La razón, aquí, vuelve a ser el contexto. Migrar cincuenta archivos en una sola sesión obliga al modelo a mantener en su ventana el rastro de los cincuenta a la vez, y esa carga acumulada degrada la calidad de cada conversión a medida que avanza. Al darle a cada archivo su propio proceso con contexto limpio, cada migración se razona sin el lastre de las anteriores, y el resultado es más fiable y más fácil de revisar archivo por archivo. La condición es que las subtareas sean de verdad independientes: si la migración de un archivo depende de cómo se haya migrado otro, el aislamiento rompe esa dependencia y el patrón deja de aplicar.

La advertencia de coste no es menor y conviene razonarla. Cada proceso paralelo arranca su propio contexto y repite parte del trabajo de arranque, de manera que el consumo total de tokens crece muy por encima del de una sola sesión, la estimación de comunidad lo sitúa en un factor de tres a cuatro. El cálculo, por tanto, es de compensación: el paralelismo solo merece la pena cuando el ahorro de tiempo o la ganancia de calidad justifican ese gasto extra, lo que ocurre con volúmenes grandes de trabajo genuinamente troceable, no con un puñado de archivos que un único Claude resolvería sin saturarse.

Paso 9 · patrón escritor/revisor con git worktrees

Objetivo: que un Claude escriba y otro revise, sin pisarse, trabajando en copias aisladas del repo.

Un worktree (árbol de trabajo de Git) es una segunda copia de tu repositorio vinculada a otra rama y ubicada en otra carpeta, pero que comparte el mismo historial. Creas uno y lanzas allí un segundo Claude:

git worktree add ../proyecto-review revision
cd ../proyecto-review
claude

La idea: el Claude «escritor» implementa contra un PLAN.md; el «revisor», en el worktree, ve solo el diff frente al plan y marca únicamente problemas de correctness. Puedes pedir esa revisión adversarial con /code-review o con un subagente que solo reciba el diff. Por qué: separar quien escribe de quien revisa, en contextos aislados, encuentra más fallos que pedirle a uno solo que se autoevalúe.⁴

El fundamento de este patrón es que un revisor con contexto fresco juzga sin el sesgo de quien escribió el código. El Claude escritor arrastra en su ventana todo el razonamiento que lo llevó hasta esa solución: las decisiones que tomó, los caminos que descartó, las suposiciones que dio por buenas. Pedirle que se autoevalúe es pedirle que dude de su propio hilo de pensamiento, y un modelo tiende a racionalizar lo que acaba de producir igual que lo hace una persona. Un segundo Claude que solo recibe el diff frente al plan no carga ninguno de esos supuestos: lee el cambio como lo leería alguien ajeno, y por eso detecta incoherencias entre lo que el plan prometía y lo que el código hace, que al autor se le pasan por estar demasiado cerca.

El git worktree es el mecanismo que hace esto práctico sin duplicar el repositorio entero ni arriesgar conflictos. Un worktree es una segunda copia de trabajo vinculada al mismo repositorio, comparte su historial y sus objetos, pero situada en otra carpeta y anclada a otra rama, de modo que el escritor y el revisor operan sobre el mismo proyecto sin pisarse los archivos. Que la revisión sea adversarial, que el revisor busque problemas en lugar de confirmar aciertos, y que se limite a la correctness (que el código haga lo correcto, no a discutir estilo) concentra el esfuerzo donde más fallos esconde el trabajo de un agente. El coste es el de cualquier paralelismo: dos contextos en marcha consumen más tokens que uno, así que el patrón se reserva para cambios cuya corrección importe de verdad.

Paso 10 · mezcla modelos y gobierna el contexto

Objetivo: gastar menos y rendir más combinando modelos y cuidando el contexto. Estos son dos recursos distintos, el coste por token y la ventana de contexto, y los dos se administran.

Una estrategia de modelos sencilla y efectiva, por orden de potencia y precio:

• Haiku (claude-haiku-4-5) para explorar. Barato y rápido: ideal para mirar archivos, buscar, resumir y entender, donde no hace falta el músculo grande.
• Sonnet (claude-sonnet-4-6) para implementar. El equilibrio para el día a día: escribir y modificar código.
• Opus (claude-opus-4-8) para el razonamiento arquitectónico. Resérvalo para lo difícil de verdad: diseñar un refactor grande, decidir una arquitectura, desenredar un bug profundo. Es el más caro; no lo gastes en tareas mecánicas.

La lógica que justifica mezclar modelos es que las tareas de una sesión no tienen todas la misma dificultad, y pagar el precio del modelo más potente para las más sencillas es desperdicio. Explorar un repositorio, abrir archivos, buscar una función, resumir qué hace un módulo, exige sobre todo lectura y rastreo, no razonamiento profundo, y ahí un modelo rápido y barato como Haiku rinde tan bien como uno grande a una fracción del coste. Implementar pide el equilibrio de Sonnet, capaz de escribir y modificar código con criterio sin el precio del modelo mayor. Y reservar Opus para el razonamiento arquitectónico, diseñar un refactor de envergadura, decidir una arquitectura, desenredar un bug que cruza varias capas, concentra tu gasto donde la capacidad extra de verdad cambia el resultado. Asignar a cada tarea el modelo más barato que la resuelve bien es el principio que sostiene esta práctica.

La práctica citada por la comunidad es justo esa mezcla, Haiku para exploración y Sonnet para implementación, con ahorros reportados del 40-50%.⁶ Y para refactors grandes, el modo opusplan deja que Opus planifique y Sonnet ejecute, que es lo mejor de cada uno (práctica de comunidad; verifica que tu versión lo ofrece). Cambias de modelo en caliente con /model.

En cuanto al contexto, trátalo como recurso escaso: /compact dirigido conservando la lista de archivos tocados, @imports para traer solo lo necesario, y /clear entre tareas. La regla práctica: tras dos intentos fallidos, no insistas; /clear y reescribe un mejor prompt.⁴

El contexto merece tratarse como un recurso escaso porque lo es: la ventana de un modelo tiene un tamaño fijo, y todo lo que entra en ella compite por ese espacio. Más aún, la calidad de las respuestas no mejora de forma indefinida al añadir información; pasado cierto punto, una ventana abarrotada de exploración vieja, archivos ya irrelevantes y vueltas en falso diluye la atención del modelo y empeora lo que produce. Por eso el gobierno del contexto es una palanca de rendimiento tan importante como la elección de modelo, y de ahí la distinción entre las dos herramientas: /clear vacía la ventana por completo para empezar limpio cuando cambias de tarea, mientras que /compact la resume conservando lo esencial cuando quieres seguir con la misma tarea sin arrastrar el peso muerto. La clave de un /compact dirigido es decirle qué preservar, la lista de archivos tocados, la decisión de arquitectura, para que el resumen no descarte justo lo que necesitabas a mano. Y la regla de los dos intentos fallidos tiene la misma raíz: cuando un hilo se ha enredado, insistir solo añade más contexto contaminado; conviene limpiar y reformular el problema con lo aprendido.

Paso 11 · construye tu propio agente con el Agent SDK

Objetivo: lo más avanzado de todo: dejar la terminal y meter la potencia de Claude Code dentro de tu propio programa. El Agent SDK (kit de desarrollo de agentes) es la librería oficial para ello, en TypeScript y en Python.¹³

Instálalo según tu lenguaje:

npm install @anthropic-ai/claude-agent-sdk     # TypeScript / Node
pip install claude-agent-sdk                    # Python 3.10+

Autentícate por variable de entorno con tu clave de API:

export ANTHROPIC_API_KEY=tu-clave

Un ejemplo mínimo en TypeScript que lanza una consulta y recorre la respuesta en streaming, limitando las herramientas que el agente puede usar:

import { query } from "@anthropic-ai/claude-agent-sdk";

for await (const m of query({
  prompt: "Resume el README y sugiere tres mejoras",
  options: { allowedTools: ["Read", "Edit", "Bash"] },
})) {
  console.log(m);
}

query devuelve un flujo de mensajes que recorres con for await; allowedTools acota qué puede hacer el agente, igual que --allowedTools en headless. Por qué: el SDK es lo que usan los equipos para construir agentes a medida (bots, integraciones, productos) sobre el mismo motor de Claude Code, sin depender de la terminal.¹³

El salto conceptual del Agent SDK (kit de desarrollo de agentes) es que invierte la relación con la herramienta. Hasta aquí, Claude Code era el programa y tú interactuabas con él desde la terminal; con el SDK, tu programa es el que manda y Claude Code pasa a ser una librería que invocas desde dentro. Eso significa que el mismo motor, el bucle de agente, el uso de herramientas, la gestión de contexto, queda disponible para incrustarlo en un bot de Slack, en un servicio web, en un trabajo programado o en cualquier producto que escribas, sin que medie una persona tecleando. Que exista en TypeScript y en Python no es un detalle menor: cubre los dos ecosistemas donde más se construyen integraciones y agentes hoy.

El patrón del ejemplo revela cómo se programa contra el SDK. La función query no devuelve una respuesta única, sino un flujo asíncrono de mensajes que recorres con for await, lo que te permite reaccionar a cada paso del agente, cada llamada a herramienta, cada fragmento de respuesta, a medida que sucede, en lugar de esperar a un resultado final opaco. La opción allowedTools cumple aquí el mismo papel de seguridad que --allowedTools en el modo headless: como el agente corre sin supervisión humana dentro de tu programa, acotar de antemano sus capacidades es la línea de defensa que sustituye a las aprobaciones interactivas. La autenticación por la variable de entorno ANTHROPIC_API_KEY sigue la práctica habitual de no incrustar la clave en el código, para que no acabe en el control de versiones por descuido.

Paso 12 · empaqueta todo en un plugin

Objetivo: cuando ya tienes comandos, skills, subagentes y hooks que funcionan, agruparlos en un plugin (paquete) para instalarlos de una vez y compartirlos.

Un plugin junta en un solo paquete varias de las piezas que hemos creado por separado: slash commands, skills, subagentes, hooks y servidores MCP. En vez de copiar carpetas a mano de proyecto en proyecto, instalas el plugin y lo tienes todo. Los plugins se distribuyen a través de marketplaces (catálogos), que pueden ser un repositorio de Git tuyo o de la comunidad.

Dentro de claude, el punto de entrada es:

/plugin

Desde ahí gestionas los plugins instalados y los marketplaces añadidos. Como los subcomandos exactos (añadir un marketplace, instalar un plugin concreto) pueden cambiar entre versiones, no me los invento aquí: abre /plugin y deja que el menú te guíe, o consulta la documentación oficial para la sintaxis vigente.¹⁴ Por qué: a partir de cierto punto acumulas configuración propia que quieres reutilizar; un plugin la convierte en algo instalable y versionado, en vez de un «copia y pega» frágil.

Un plugin es la unidad de empaquetado y distribución que cierra el nivel: agrupa en un solo paquete versionado las piezas que hasta ahora has creado por separado, slash commands, skills, subagentes, hooks y servidores MCP, de modo que instalar el plugin las trae todas a la vez y de forma coherente. La alternativa, copiar carpetas de .claude/ a mano de un proyecto a otro, es frágil por varias razones: se desincroniza en cuanto cambias algo en un sitio y no en el resto, no lleva número de versión que indique qué tienes instalado, y mezcla tus piezas con las de quien copió antes sin un registro claro. Un plugin resuelve eso al convertir tu configuración en un artefacto con identidad propia, que se actualiza, se versiona y se comparte como cualquier otra dependencia.

La distribución se apoya en los marketplaces (catálogos), que pueden ser un repositorio de Git tuyo, de tu equipo o de la comunidad: añades el catálogo una vez y desde él instalas los plugins que ofrece. Este es el escalón que transforma una colección de trucos personales en infraestructura compartible, y la razón por la que conviene llegar aquí solo cuando ya tienes piezas probadas que merece la pena reutilizar; empaquetar configuración a medio cocer no ahorra trabajo, lo multiplica.

Paso 13 · cambia el tono con output styles

Objetivo: ajustar cómo te habla Claude (no qué hace) eligiendo un output style (estilo de salida).

Hay estilos integrados que cambian el tono y la forma de responder:¹²

• Proactive. Se adelanta y propone siguientes pasos.
• Explanatory. Explica el porqué de lo que hace mientras lo hace.
• Learning. Pensado para aprender: va más despacio y te enseña por el camino.

Un detalle útil: los output styles no se compactan, así que sobreviven a /compact y el tono se mantiene aunque la sesión se alargue.¹² Y si lo que quieres es inyectar una instrucción puntual de comportamiento sin tocar la memoria, tienes el flag --append-system-prompt al arrancar:

claude --append-system-prompt "Responde siempre en español y explica cada comando antes de ejecutarlo."

La idea de fondo es que la forma y el contenido son palancas distintas, y conviene accionarlas con mecanismos distintos. Un output style (estilo de salida) no cambia qué hace Claude, qué archivos toca, qué comandos ejecuta, sino cómo te lo cuenta, y cada estilo integrado responde a una intención concreta: Proactive se adelanta y propone los siguientes pasos en lugar de esperar a que los pidas; Explanatory narra el porqué de cada decisión mientras trabaja, útil cuando quieres entender el razonamiento; y Learning baja el ritmo y enseña por el camino, pensado para quien usa la sesión también para aprender. Elegir uno es declarar qué tipo de acompañamiento quieres, no qué tareas se hacen.

El detalle de que los output styles no se compacten tiene una explicación práctica importante: como el tono se aplica fuera del contenido conversacional que /compact resume, sobrevive a la compactación y se mantiene aunque la sesión se alargue y la ventana se limpie varias veces. Frente a esto, el flag --append-system-prompt cubre el caso puntual: inyecta una instrucción de comportamiento al arrancar, sin tocar la memoria del proyecto. La razón para preferir cualquiera de los dos antes que llenar el CLAUDE.md de instrucciones sobre la forma de hablar es la misma que recorre todo el nivel: el CLAUDE.md se carga siempre y debe reservarse para lo que importa al trabajo, no malgastarse en indicaciones de estilo que un estilo de salida gestiona de manera más limpia y sin coste de contexto permanente.

Paso 14 · controla cuánto piensa Claude

Objetivo: subir o bajar el esfuerzo de razonamiento según lo difícil que sea la tarea, para no malgastar tiempo en lo trivial ni quedarte corto en lo complejo.

Los modelos actuales (de Opus 4.7 en adelante) usan razonamiento adaptativo: el propio modelo decide cuánto pensar en cada paso según la complejidad de lo que le pides, sin que tengas que fijar un presupuesto de tokens a mano.¹⁵ Lo que tú controlas es el techo de ese razonamiento, el llamado nivel de esfuerzo (effort), que va de menos a más: low, medium, high, xhigh (disponible en Opus 4.8 y 4.7; en otros modelos cae a high) y max. Cuanto más alto, más profundo razona y más cuesta en tiempo y en tokens; cuanto más bajo, más rápido y barato.

Para cambiarlo tienes cuatro vías, todas equivalentes.¹⁵ Dentro de una sesión, el comando:

/effort high

Al arrancar, con un flag:

claude --effort high

De forma permanente, con una variable de entorno o con la clave effortLevel en tu settings.json:¹¹

export CLAUDE_CODE_EFFORT_LEVEL=high

Además, al elegir modelo con /model y las flechas, el menú también ajusta el esfuerzo asociado. Y hay un interruptor aparte para el pensamiento extendido: Alt+T (en macOS, Option+T) lo activa o desactiva en caliente.¹⁶ En el modelo Fable 5 ese interruptor no hace nada, porque siempre razona en extendido.

Una aclaración para quien haya visto trucos por internet: hace un tiempo se pedía más razonamiento escribiendo palabras mágicas en el prompt, como «think», «think hard» o «ultrathink». Hoy ese camino ha quedado sustituido por el razonamiento adaptativo y el nivel de esfuerzo, que es explícito, predecible y se ajusta una vez en lugar de recordarlo en cada mensaje. La regla práctica es sencilla: sube a high, xhigh o max cuando le pidas diseño de arquitectura, depuración difícil o un plan delicado, y baja a low o medium para lo mecánico (renombrar, formatear, responder algo directo), donde pensar de más solo añade espera y coste sin mejorar el resultado.

Paso 15 · lanza tareas en segundo plano

Objetivo: tener procesos largos vivos (un servidor de desarrollo, un build, una batería de tests, un contenedor) sin que bloqueen la conversación.

Cuando un comando va a tardar, puedes mandarlo a segundo plano pulsando Ctrl+B mientras se ejecuta (en tmux, dos veces).¹⁶ Claude Code lo deja corriendo de forma asíncrona, te devuelve un identificador de tarea y sigue atendiendo tus mensajes mientras el proceso continúa por detrás. También puedes pedírselo en palabras:

Arranca el servidor de desarrollo con npm run dev y déjalo en segundo plano; cuando esté listo, dime en qué puerto escucha.

La salida del proceso se va escribiendo en un fichero, así que Claude puede leerla cuando la necesite, por ejemplo para diagnosticar un error del servidor sin pararlo.¹⁶ Eso habilita un patrón muy cómodo: dejas el dev server levantado y sigues pidiendo cambios, o lanzas unos tests largos y no te quedas mirando la terminal. Los candidatos típicos a segundo plano son justo esos: herramientas de build (webpack, vite, make), gestores de paquetes (npm, yarn, pnpm), test runners (jest, pytest), servidores de desarrollo y procesos pesados como docker o terraform.

Para no perderles la pista, Ctrl+T muestra u oculta la lista de tareas en la barra de estado de la terminal; y siempre puedes decir «muéstrame todas las tareas» o «para la tarea del servidor».¹⁶ Las tareas en segundo plano se limpian solas al cerrar Claude Code, y si alguna desborda (más de 5 GB de salida) se corta sola con un aviso. Si en algún entorno prefieres desactivar del todo esta función, la variable CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 la apaga.¹⁶ El cambio de fondo es de mentalidad: con el segundo plano, la sesión deja de ser una cola de «pide y espera» y se parece más a un panel de control, donde el servidor vive, los tests corren y tú sigues conversando sin esperar a que cada cosa termine.

Mini-proyecto: de principio a fin

Objetivo: atar los tres niveles en un único recorrido pequeño y real. Vas a añadir una función con un test que falla primero, planificando antes, con permisos a tu favor y un hook de formato vigilando. Si haces esto, has usado lo esencial del curso de una sentada.

El valor de un recorrido completo, por pequeño que sea, es que las piezas del curso no se entienden de verdad por separado, sino por cómo encajan. El flujo que vas a seguir, preparar el terreno, planificar antes de tocar, codificar con luz verde y confirmar en Git, reproduce a escala el ciclo que recomienda la documentación: explorar, planificar, codificar y confirmar. Cada paso apoya al siguiente: el test que falla primero te da una vara de medir objetiva antes de escribir nada; el plan evita que Claude se lance sobre una idea equivocada; los permisos a tu favor eliminan la fricción de aprobar lo repetitivo; y el hook de formato se ocupa de lo mecánico sin que tengas que pedirlo. Verlo funcionar de principio a fin fija lo aprendido mejor que cualquier explicación aislada.

Parte de un proyecto Node cualquiera (o crea uno de prueba como en el nivel 1). El recorrido:

1. Prepara el terreno (niveles 2 y 3). En .claude/settings.json, autoriza lo repetitivo y mete el hook de formato del paso 4. Así no te preguntará por los tests ni tendrás que formatear a mano:

   {
     "permissions": {
       "allow": ["Bash(npm test:*)", "Read"]
     },
     "hooks": {
       "PostToolUse": [
         {
           "matcher": "Edit|Write",
           "hooks": [
             { "type": "command", "command": "jq -r '.tool_input.file_path' | xargs -r npx prettier --write" }
           ]
         }
       ]
     }
   }
   

2. Planifica antes de tocar (nivel 2). Entra en modo plan con Shift+Tab hasta plan y pídele el plan:

   Quiero una función slugify(texto) que pase a minúsculas, quite acentos y cambie espacios por guiones. Hazme primero un test que falle y luego el plan. No escribas código todavía.
   

   Deberías ver un test propuesto y un plan, sin ediciones aplicadas. Por qué: el test que falla primero es tu vara de medir; el plan evita que se lance sobre una idea equivocada.

3. Codifica con luz verde (niveles 1 y 2). Cuando el plan te convenza, sal del modo plan y dale permiso:

   Adelante: implementa slugify para que el test pase. Ejecuta `npm test` y enséñame la salida.
   

   Verás el diff (lo apruebas en la puerta de permisos), el hook formateará el archivo al guardar, y los tests deberían quedar en verde. Pide evidencia: la salida de npm test, no un «ya está».

4. Confirma en Git (nivel 2). Cierra el círculo:

   Haz commit con un mensaje claro que explique qué añade esta función y por qué.
   

Checkpoint del mini-proyecto: tienes una función nueva, cubierta por un test que antes fallaba y ahora pasa, formateada automáticamente y confirmada en Git, y has tocado plan mode, allowlist, hooks y verificación. Eso es Claude Code de verdad, en pequeño.

Checkpoint del nivel 3

Ahora ya puedes:

• Crear subagentes (.claude/agents/*.md), skills (.claude/skills/<n>/SKILL.md) y comandos propios (.claude/commands/*.md).
• Declarar hooks deterministas en settings.json, incluido uno que bloquea con exit 2 y otro que formatea en PostToolUse.
• Definir permisos allow/deny y reglas con alcance paths:.
• Ejecutar headless con -p, --output-format json|stream-json y --allowedTools, y hacer fan-out con un bucle.
• Montar el patrón escritor/revisor con worktrees y revisión adversarial.
• Mezclar modelos (Haiku, Sonnet, Opus, opusplan) y gestionar el contexto a conciencia.
• Construir tu propio agente con el Agent SDK en TypeScript o Python.
• Empaquetar tu configuración en un plugin y ajustar el tono con output styles.
• Graduar el esfuerzo de razonamiento (/effort, de low a max) sobre razonamiento adaptativo, y activar o desactivar el pensamiento extendido.
• Lanzar procesos largos en segundo plano con Ctrl+B y seguir la lista de tareas con Ctrl+T.
• Recorrer el mini-proyecto de principio a fin atando plan mode, permisos, hooks y verificación.

Si todo esto te sale, dominas Claude Code en el estado del arte de la fecha de corte.

Trucos y atajos

Los atajos que siguen no son adornos, sino aplicaciones concretas de los principios del nivel: casi todos consisten en alimentar a Claude con el contexto justo por la vía más corta, o en cortar a tiempo un hilo que se ha torcido. Conviene leerlos con esa clave, porque así se recuerdan mejor y se trasladan a situaciones nuevas.

• Plantillas listas. El repo claude-howto trae plantillas de comandos preparadas; copiarlas es instantáneo:⁶

  cp 01-slash-commands/*.md .claude/commands/
  

• Pipe de errores. Mete cualquier log directo en Claude sin abrir editores:

  cat error.log | claude -p "explica el error y dame el arreglo"
  

• Corrige pronto. Si una respuesta va mal, no la dejes correr: Esc para parar, Esc+Esc para retroceder, y /clear al cambiar de tarea.⁴

• /compact con instrucciones. No compactes a ciegas: dile qué conservar (/compact mantén la lista de archivos y la decisión de arquitectura).⁴

• Onboarding por entrevista. Para arrancar en un proyecto nuevo, pídele a Claude que te entreviste, genera un SPEC.md con lo que salga y empieza luego en una sesión limpia.⁴

• /btw a media sesión. Para añadir contexto sobre la marcha sin romper el flujo.⁴

• Mueve lo repetitivo a hooks. Todo «cada vez que pase X, haz Y» vive mejor como hook que como línea de CLAUDE.md.¹²

• Esfuerzo a demanda. Sube el razonamiento para lo difícil y bájalo para lo trivial con /effort (de low a max); el modelo ya razona de forma adaptativa, tú solo pones el techo.¹⁵

• Procesos en segundo plano. Ctrl+B manda un comando o un servidor a segundo plano y te deja seguir hablando; Ctrl+T muestra la lista de tareas.¹⁶

Buenas prácticas y antipatrones

Las buenas prácticas que recogen las guías oficiales comparten un hilo conductor: casi todas se derivan de dos hechos sobre cómo funciona un agente de código. El primero es que el contexto es finito y su saturación degrada las respuestas; de ahí la insistencia en mantener la ventana limpia y en repartir las instrucciones entre el mecanismo adecuado en lugar de amontonarlas. El segundo es que un modelo acierta mucho más cuando puede comprobar su propio trabajo; de ahí que darle tests, build, linter y diffs no sea opcional, sino la palanca que más eleva la calidad. Leídas con esa clave, las recomendaciones dejan de ser una lista que memorizar y se convierten en consecuencias de un par de principios.

Lo que dicen las guías oficiales:⁴¹²

• El cuello de botella es el contexto. Mantén la ventana limpia y enfocada.
• Dale forma de verificar. Tests, build, linter y diffs: si Claude puede comprobar su trabajo, acierta más.
• CLAUDE.md corto (el blog sugiere menos de 200 líneas) y siete mecanismos para «dirigir» a Claude, cada uno para lo suyo: CLAUDE.md para lo siempre-presente, reglas path-scoped para lo local, skills para workflows, subagentes para tareas laterales aisladas, hooks para lo determinista, output styles para el tono, y el flag --append-system-prompt para inyectar instrucciones puntuales.¹²
• Permisos a tu favor. Construye tu allowlist, usa Auto mode y sandbox para lo arriesgado.
• Skills on-demand con disable-model-invocation para lo que tenga efectos secundarios.

Los antipatrones son la cara negativa de esos mismos principios: cada uno describe una forma de ignorar que el contexto es escaso o de renunciar a verificar el trabajo. Reconocerlos importa porque suelen instalarse poco a poco, sin que un solo paso parezca un error, hasta que la sesión rinde mal y cuesta saber por qué. Estos son los cinco que la doc te pide evitar:⁴

1. Sesión cajón de sastre (kitchen-sink): mezclar diez tareas en una conversación. Usa /clear.
2. Corregir en bucle: insistir tras varios fallos en vez de parar, limpiar y reescribir el prompt.
3. CLAUDE.md sobre-especificado: tanta regla que ninguna se respeta.
4. Brecha de confianza: aceptar diffs sin mirarlos porque «suele acertar».
5. Exploración infinita: dejarle explorar sin un objetivo ni un plan.

Y un apunte de seguridad: usa reglas deny para proteger secretos (por ejemplo Read(.env)) y el sandbox para comandos con efectos.⁴

Errores comunes

La tabla siguiente agrupa los fallos por su causa real, no por su síntoma, porque un mismo síntoma puede esconder problemas distintos y el arreglo correcto depende del mecanismo subyacente. Verás que la mayoría caen en tres familias: problemas de entorno (el PATH, la versión de Node, la carpeta desde la que arrancas), problemas de contexto saturado (respuestas que empeoran o errores que vuelven) y problemas de configuración mal declarada (hooks, subagentes o servidores MCP que no se activan donde esperabas). Identificar a qué familia pertenece un síntoma te lleva al arreglo más rápido que probar a ciegas.

Síntoma	Causa probable	Arreglo
claude: command not found tras instalar	La terminal no ha recargado el PATH	Cierra y reabre la terminal; revisa que la instalación global de npm está en el PATH
node: command not found	Node.js no instalado o por debajo de la 18	Instala Node 18+ desde nodejs.org y verifica con node --version
Claude «no ve» tus archivos	Lo arrancaste fuera de la carpeta del proyecto	Sal, cd a la raíz del proyecto y vuelve a abrir claude
Respuestas cada vez peores en una sesión larga	Ventana de contexto saturada	/compact con instrucciones, o /clear si cambias de tarea
Claude repite errores ya corregidos	Arrastra contexto viejo de la conversación	/clear y reformula el prompt con lo aprendido
Pregunta permiso por todo, todo el rato	Allowlist vacía	Autoriza lo repetitivo en /permissions o activa Auto mode
El hook no se dispara	Declarado fuera de settings.json o matcher mal puesto	Decláralo en settings.json con el evento y matcher correctos10
El subagente no se usa nunca	description poco clara sobre cuándo invocarlo	Reescribe description diciendo explícitamente cuándo aplica8
Un cambio aceptado rompió algo y no hay vuelta atrás fácil	Confiaste en checkpoints como si fueran Git	Usa Git de verdad; los checkpoints no lo sustituyen4
El comando MCP no aparece	El servidor no se registró en el scope esperado	Revisa .mcp.json y vuelve a claude mcp add con el --scope correcto7

Estado del arte y fecha de corte

Una herramienta que evoluciona rápido obliga a separar tres cosas que es fácil confundir: lo que está consolidado en la documentación oficial, lo que circula por la comunidad sin respaldo formal, y lo que directamente es ruido. Esta sección hace esa separación de forma explícita, y conviene tratarla como parte del método, no como un apéndice: ante cualquier afirmación sobre Claude Code, la pregunta correcta no es «¿suena plausible?» sino «¿está confirmada y para qué versión?». Lo marcado como práctica de comunidad puede ser cierto y útil, pero exige que lo verifiques contra tu instalación antes de apoyar trabajo serio en ello.

• Fecha de corte: 28 de junio de 2026. Fuentes oficiales consultadas entre el 26 y el 28 de junio de 2026.
• Modelos vigentes citados: claude-opus-4-8, claude-sonnet-4-6, claude-haiku-4-5.
• Qué está consolidado en la doc oficial: el instalador nativo más las alternativas (Homebrew, winget, npm) y claude doctor; la jerarquía de CLAUDE.md que concatena; la precedencia por capas de settings.json; los hooks declarados en settings.json con exit 2 para bloquear; los subagentes con contexto aislado; las skills con divulgación progresiva y disable-model-invocation; las reglas con paths:; el modo headless con --output-format y --allowedTools; los plugins que agrupan comandos, skills, subagentes, hooks y MCP; los output styles integrados; el Agent SDK en TypeScript y Python; y los siete mecanismos de «dirección» del blog del 18 de junio de 2026.
• Funciones recientes (verifica que tu versión las tiene): Auto mode, /sandbox, plan mode con Ctrl+G, los checkpoints/retroceso (Esc+Esc o /rewind), el control del razonamiento por niveles de esfuerzo (/effort, de low a max) sobre razonamiento adaptativo, y las tareas en segundo plano (Ctrl+B para enviarlas, Ctrl+T para listarlas).
• Reportado por la comunidad, sin confirmar en la doc oficial (trátalo con cautela y verifica tu versión): el modo opusplan (Opus planifica, Sonnet ejecuta), los ahorros del 40-50% al mezclar Haiku y Sonnet, y el prompt caching abaratando lecturas. No incluyo afirmaciones que circulan sin respaldo oficial, como números de versión concretos del CLI, «subagentes recursivos de cinco niveles», «/workflows orquestando cientos de agentes» o multiplicadores de rendimiento de modelos; si los ves por ahí, contrástalos antes de creerlos.

Chuleta

Acción	Comando o atajo
Instalar (nativo, recomendado)	curl -fsSL https://claude.ai/install.sh | bash
Instalar (Windows PowerShell)	irm https://claude.ai/install.ps1 | iex
Instalar (alternativa npm)	npm install -g @anthropic-ai/claude-code
Verificar versión	claude --version
Chequeo de salud	claude doctor
Abrir en el proyecto	claude
Encargo de una sola vez (sale al terminar)	claude "tarea"
Reanudar la última sesión	claude --continue (o claude -c)
Elegir sesión a reanudar	claude --resume (o claude -r)
Headless (una respuesta)	claude -p "..."
Headless con JSON	claude -p "..." --output-format json
Limitar herramientas	claude -p "..." --allowedTools "Edit,Bash(git commit:*)"
Añadir servidor MCP	claude mcp add --transport http nombre --scope project <url>
Ayuda / lista de comandos	/help
Generar memoria del proyecto	/init
Editar memoria	/memory
Permisos	/permissions
Sandbox	/sandbox
Limpiar contexto	/clear
Compactar (con instrucciones)	/compact <qué conservar>
Ver contexto consumido	/context
Esfuerzo de razonamiento	/effort low|medium|high|xhigh|max
Pensamiento extendido (on/off)	Alt+T (Option+T en mac)
Cambiar modelo	/model
Entrar en modo plan	/plan
Gestionar subagentes	/agents
Gestionar plugins	/plugin
Ver conexiones MCP	/mcp
Reanudar / re-autenticar	/resume · /login
Añadir contexto a media sesión	/btw
Parar a Claude	Esc
Retroceder (conversación/código)	Esc, Esc
Ciclar modo de permisos	Shift+Tab
Abrir el plan en el editor	Ctrl+G
Enviar a segundo plano	Ctrl+B
Lista de tareas en segundo plano	Ctrl+T
Salir	/exit o Ctrl+D
Referenciar archivo	@ruta/al/archivo

Siguiente nivel

Cuando domines lo de aquí, profundiza así:

• Móntate tu propio repo de configuración. Versiona .claude/ con tus comandos, agentes, skills y settings.json, y compártelo con tu equipo. Es la mejor forma de fijar lo aprendido.
• Lee el repo claude-howto. Diez módulos (slash commands, memory, skills, subagents, MCP, hooks, plugins, checkpoints, avanzado y referencia de CLI) con plantillas listas para copiar.⁶
• Estudia los siete mecanismos de dirección del blog oficial y decide, para cada cosa que quieras automatizar, cuál encaja: memoria, regla, skill, subagente, hook, output style o --append-system-prompt.¹²
• Empieza secuencial, escala con cabeza. Usa headless para CI y reserva los equipos de agentes en paralelo para cuando haya paralelismo real que justifique el coste extra de tokens.⁶

Fuentes

Documentación oficial de Claude Code (Anthropic), consultada el 26-28 de junio de 2026:

Notas

1. Instalación: instalador nativo (install.sh / install.ps1), Homebrew, winget, npm, y claude doctor. https://code.claude.com/docs/en/setup, Consultado el 27 de junio de 2026. ↩ ↩² ↩³

2. Guía rápida: primer arranque y login, atajos del REPL (Shift+Tab para modos de permiso, ↑/↓, /), doble Esc. https://code.claude.com/docs/en/quickstart, Consultado el 27 de junio de 2026. ↩ ↩² ↩³

3. Memoria y CLAUDE.md (jerarquía, imports con @, /init, reglas con paths:). https://code.claude.com/docs/en/memory, Consultado el 26-27 de junio de 2026. ↩ ↩² ↩³ ↩⁴

4. Best practices: flujo explorar→planificar→codificar→confirmar, contexto como cuello de botella, permisos y sandbox, checkpoints, headless, worktrees, cinco antipatrones. https://code.claude.com/docs/en/best-practices, Consultado el 26-27 de junio de 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹ ↩²² ↩²³ ↩²⁴ ↩²⁵ ↩²⁶ ↩²⁷ ↩²⁸ ↩²⁹

5. Referencia de slash commands (/context, /effort, /memory, /plan, /resume, /login, etc.). https://code.claude.com/docs/en/commands, Consultado el 27 de junio de 2026. ↩ ↩² ↩³

6. Repositorio comunitario claude-howto (luongnv89): manual de 10 módulos, plantillas, trucos de CLI y mezcla de modelos. Reputación media; verifica versiones contra tu instalación. https://github.com/luongnv89/claude-howto, Consultado el 26-27 de junio de 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

7. MCP: .mcp.json, claude mcp add, scopes. https://code.claude.com/docs/en/mcp, Consultado el 26-27 de junio de 2026. ↩ ↩²

8. Subagentes: .claude/agents/*.md, frontmatter, contexto aislado. https://code.claude.com/docs/en/sub-agents, Consultado el 26-27 de junio de 2026. ↩ ↩²

9. Skills y comandos: SKILL.md, frontmatter, disable-model-invocation, $ARGUMENTS, !bash, divulgación progresiva. https://code.claude.com/docs/en/skills, Consultado el 26-27 de junio de 2026. ↩ ↩² ↩³

10. Guía de hooks: eventos, entrada JSON por stdin, exit 2 para bloquear, declaración en settings.json. https://code.claude.com/docs/en/hooks-guide, Consultado el 26-27 de junio de 2026. ↩ ↩² ↩³ ↩⁴

11. Configuración: settings.json, precedencia por capas, hot reload, permisos. https://code.claude.com/docs/en/settings, Consultado el 26-27 de junio de 2026. ↩ ↩²

12. Blog oficial «Steering Claude Code: skills, hooks, rules, subagents and more» (18 de junio de 2026): siete mecanismos de dirección y cuándo usar cada uno. https://claude.com/blog/steering-claude-code-skills-hooks-rules-subagents-and-more, Consultado el 26-27 de junio de 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

13. Claude Agent SDK (visión general): instalación en TypeScript (@anthropic-ai/claude-agent-sdk) y Python (claude-agent-sdk, 3.10+), query, autenticación con ANTHROPIC_API_KEY. https://code.claude.com/docs/en/agent-sdk/overview, Consultado el 27 de junio de 2026. ↩ ↩²

14. Plugins y marketplaces: /plugin, paquetes que agrupan comandos, skills, subagentes, hooks y servidores MCP, y cómo añadir un marketplace. https://code.claude.com/docs/en/plugins, Consultado el 26-27 de junio de 2026. ↩

15. Configuración del modelo y razonamiento adaptativo: niveles de esfuerzo (low, medium, high, xhigh, max), comando /effort, flag --effort, variable CLAUDE_CODE_EFFORT_LEVEL y clave effortLevel. https://code.claude.com/docs/en/model-config, Consultado el 28 de junio de 2026. ↩ ↩² ↩³

16. Modo interactivo: atajos de teclado (Ctrl+B para pasar a segundo plano, Ctrl+T para la lista de tareas, Alt+T/Option+T para el pensamiento extendido, doble Esc para rebobinar), comandos Bash en segundo plano y shell mode con !. https://code.claude.com/docs/en/interactive-mode, Consultado el 28 de junio de 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶