En los cinco capítulos anteriores has instalado Claude Code, le has dado instrucciones, has salido de los atascos y has diseñado los permisos. Este capítulo va de modificar la herramienta en sí. Con las extensiones no basta con aprenderse los nombres. Lo que sirve es una tabla de correspondencias que responda a «cuál de ellas resuelve la molestia que tengo ahora».
El mapa para elegir: lo deciden cuatro preguntas
Hay seis extensiones, pero solo hay cuatro cosas que pensar: ¿basta con pedirlo? ¿quiero que se cumpla siempre? ¿quiero separarlo en otro contexto? ¿quiero conectarme al exterior? Preguntándotelo en ese orden, la respuesta suele quedar unívoca.
Si que se escape de vez en cuando no es grave, con las palabras basta. → CLAUDE.md (premisas generales) / Skills (procedimientos de un trabajo concreto)
Si que se escape una sola vez ya es un problema, detenlo con un mecanismo. → hooks. Se ejecutan sin pasar por el criterio del modelo.
Si no quieres enterrar el hilo principal bajo un montón de salida, que lo haga fuera y te devuelva solo la conclusión. → subagents
Si necesitas información que la IA no tiene forma de conocer (el valor actual de una base de datos, el contenido del gestor de incidencias). → MCP
La quinta pregunta es «¿voy a repartir esto a otras personas?»: si es que sí, plugins. Lo que más se confunde son Q1 y Q2, es decir, CLAUDE.md, Skills y hooks. Los tres parecen lo mismo, pero se diferencian en cuándo se leen y quién los ejecuta.
CLAUDE.md: memoria que persiste, hasta que se alarga demasiado
CLAUDE.md es un archivo que, colocado en la raíz del proyecto, se lee automáticamente en cada sesión (si vale para todos los proyectos, va en ~/.claude/CLAUDE.md). Como es un archivo, no le afecta el «cuando se alarga, olvida la primera parte» del capítulo 1. Es el sitio para lo que explicas una y otra vez.
El «dice que lo ha leído y no lo cumple» no es dejadez, sino un problema estructural, y tiene tres causas.
- La parte central se hunde: las instrucciones que quedan a media altura de un texto largo se pasan por alto con facilidad y, cuanto más lo alargues, más desaparecen en la práctica las reglas del medio
- La compresión lo resume: cuando entra la compresión, las reglas operativas de detalle quedan aplastadas. Por eso las infracciones aumentan hacia el final
- Gana la instrucción más reciente: un «venga, confirma los cambios» hace que se pase de largo el procedimiento de comprobación leído cientos de turnos antes
La solución es recortar. La regla empírica que funciona con seguridad es mantenerse en torno a las 100 o 150 líneas. Si te pasas, deja al principio solo los mandamientos críticos y lleva el detalle a otro archivo (los duplicados generan divergencias, así que que haya un único original). Marca con «CRITICAL» únicamente lo que no puedes permitirte perder, y escríbelo de forma que se pueda juzgar desde fuera: no «escribe con cuidado», sino «escribe en tres líneas o menos».
Un «lo he leído» no es una prueba. El único material de juicio es el comportamiento posterior a la ejecución. Una regla que no se cumple por más veces que la reescribas no es un problema de redacción: es trabajo del siguiente apartado.
hooks: no es una petición, es una certeza
«No reescribas el .env»: escrito en CLAUDE.md se cumple el 90% de las veces. Si que se escape un 10% no te causa problemas, con el texto basta. Si te los causa, hooks. Ese es el punto de bifurcación.
Los hooks son comandos de shell que se ejecutan automáticamente en momentos determinados. Quien los lanza no es el modelo, sino el propio Claude Code (el arnés), así que se ejecutan siempre, sin esperar a ningún criterio. La panorámica completa está en qué son los hooks de Claude Code. Los puntos de disparo habituales son nueve.
SessionStart al iniciar o reanudar
UserPromptSubmit justo después de enviar [puede bloquear]
PreToolUse justo antes de una herramienta = portero [puede bloquear]
PostToolUse tras el éxito de una herramienta = formateo [puede bloquear]
Notification esperando entrada o aprobación
Stop final de una respuesta [puede bloquear]
SubagentStop el subagente ha terminado [puede bloquear]
SessionEnd fin de la sesión
PreCompact antes de la compresión [puede bloquear]
«Puede bloquear» significa que en ese punto se puede detener la acción. Rechazar de plano los comandos peligrosos en PreToolUse y formatear automáticamente en PostToolUse: esas dos son la puerta de entrada habitual. La configuración va bajo la clave "hooks" de settings.json, y el lugar donde pongas el archivo decide el alcance (~/.claude/ = tú, .claude/ = compartido, settings.local.json = solo tú).
{ "hooks": {
"PostToolUse": [
{ "matcher": "Edit|Write",
"hooks": [ { "type": "command", "command": "..." } ] }
] } }
La estructura es nombre del evento → array de matcher y comando. El matcher es el nombre de la herramienta objetivo (separado por |, como "Edit|Write"; si lo omites, coincide con todas). Los hooks reciben un JSON por la entrada estándar y responden con el código de salida: 0 es éxito y 2 es bloqueo (la salida de error estándar se le pasa a Claude). Como la ruta del archivo afectado también se saca del JSON de entrada, puedes escribir un «si es esta ruta, detente».
Los hooks pueden endurecer las restricciones, pero no relajarlas. Aunque devuelvan una autorización, lo único que hacen es ahorrar la pregunta, y las reglas de denegación tienen siempre prioridad. Como el rechazo desde PreToolUse funciona incluso en el modo que se salta todas las aprobaciones, sirve de suelo para lo que aflojaste en el capítulo 5.
Y el precio, por delante. Los hooks ejecutan automáticamente comandos de shell arbitrarios con tus permisos. La documentación oficial también deja claro que la responsabilidad es enteramente tuya. Configura solo lo que sea de fiar y valida las entradas. La configuración queda fijada al iniciar la sesión, así que, si «lo has corregido y no surte efecto», abre una sesión nueva.
subagents: delegar en un contexto aparte
La salida completa de las pruebas, un log enorme: cuando se acumula una gran cantidad de texto que en realidad ibas a descartar, las premisas importantes acaban desplazadas. Los subagents son el mecanismo para ejecutar ese trabajo en otro contexto y recibir solo el resumen de la conclusión. Tienen su propia ventana de contexto, su propio prompt de sistema y sus propios permisos de herramientas, y como no ven tu historial de conversación, los restos de la investigación no vuelven a la sesión principal.
- Separar compensa: investigaciones amplias / comprobaciones que generan mucha salida / tareas autocontenidas de las que solo necesitas la conclusión
- Separar sale caro: procesos secuenciales / idas y venidas frecuentes / trabajos en paralelo que tocan el mismo archivo / correcciones que se resuelven en uno o dos pasos
Como es una función estándar, se puede usar sin configurar nada. Si quieres añadir definiciones, van en .claude/agents/<nombre>.md (para uso común, en ~/.claude/agents/), con name, description, tools y model escritos en el frontmatter YAML. Se gestionan con /agents y se invocan con @agent-<nombre>. Empieza por los estándar de exploración, de planificación y de uso general.
La clave de la invocación es el description. El agente principal decide si delega mirando eso, de modo que, si es ambiguo, no lo llamará ni una sola vez. Concreta qué hace y cuándo usarlo. La misma trampa existe en las Skills.
Los Agent Teams, fáciles de confundir, son el mecanismo por el que varias sesiones independientes se coordinan mediante una lista de tareas compartida. Son una opción experimental de activación explícita y están desactivados por defecto (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1). Como levantan instancias distintas, el consumo de tokens es alto, y tampoco se pueden anidar. Las diferencias las comparamos en las diferencias entre subagents y Agent Teams. Ante la duda, una sola sesión o subagents.
Skills: convertir los procedimientos en activos
Frente a las rutinas del tipo «esto siempre se hace así», lo bueno de las Skills es que solo se abren cuando hacen falta. En realidad son una carpeta articulada alrededor de un SKILL.md. Arriba van name y description, debajo el procedimiento en Markdown, y también puedes incluir un reference/ o un scripts/. Basta con colocarla en .claude/skills/ (del proyecto) o en ~/.claude/skills/ (común) para que se reconozca.
La clave es la divulgación progresiva. Al iniciar la sesión solo se lee el breve description de cada skill, y el cuerpo y los materiales se cargan únicamente cuando la petición encaja. Por eso puedes tener decenas sin que apenas llenen tu contexto habitual: es la diferencia decisiva con CLAUDE.md, que se carga siempre entero. La otra cara es que si no encaja, no se abre jamás. Con un description ambiguo, el procedimiento que escribiste es como si no existiera. Cómo redactarlo lo tratamos en qué son las Claude Agent Skills.
En una línea. CLAUDE.md = las premisas que se leen siempre; Skills = el manual que Claude decide abrir; hooks = el proceso que se ejecuta sin falta.
MCP: alcanzar los sistemas de fuera
Las tres anteriores eran extensiones que cambian la forma de hacer las cosas. MCP (Model Context Protocol) es la única que amplía lo que se puede tocar: es el estándar que permite llegar a cosas que la IA no puede conocer por su propia estructura, como el valor actual de una base de datos o los tickets del gestor de incidencias. Hay dos formas de conexión, y se atascan en sitios distintos.
- Local (stdio): el servidor se lanza como subproceso en tu propio ordenador. Lo que se atasca es el arranque en sí (rutas, variables de entorno, resolución del comando)
- Remota (HTTP): te conectas por URL a un servidor en la nube. Lo que se atasca es casi siempre la autenticación, es decir, que te devuelven un 401 o un 403
Por eso no metas todos los «no conecta» en el mismo saco: mira primero el estado con /mcp. Si es failed, es el arranque local; si es needs authentication, es la autenticación remota; si es pending approval, está esperando aprobación. El estado decide la jugada. Las soluciones las recopilamos en cómo arreglar los errores de conexión del servidor MCP.
También hay trampas propias. El .mcp.json de la configuración compartida va en la raíz del repositorio (ni dentro de .claude/ ni dentro de settings.json), y las claves de API van en el env de cada servidor. En Windows, como npx es en realidad un archivo por lotes, pasarlo a través de cmd con /c npx ... hace que funcione.
Los servidores que conectas consumen contexto. Solo con acumularse las definiciones de herramientas, el contexto se estrecha. Lo prudente es desactivar los servidores que no estés usando.
plugins: empaquetar un conjunto y repartirlo
Cuando se te empiecen a dispersar las skills, las definiciones de subagentes, los hooks y la configuración de MCP, los plugins son la forma de agruparlo todo en algo repartible. Lo que más se equivoca es la convención de directorios. El manifiesto es .claude-plugin/plugin.json, y es lo único que va dentro de .claude-plugin/. skills/, agents/, hooks/hooks.json y .mcp.json van en la raíz.
/plugin marketplace add owner/repo ← registrar el catálogo
/plugin install name@marketplace ← instalar desde ahí uno por uno
/plugin list ← comprobar lo que tienes instalado
La instalación tiene dos fases: registrar el catálogo y, sobre eso, instalar cada cosa por separado. Con solo añadirlo no se instala nada. Los alcances son user (todos los proyectos), project (todos los colaboradores), local (solo tú) y managed (distribuido por administración, no modificable); para unificar el equipo, project. Cómo crear los tuyos lo tratamos en qué son los plugins y el marketplace.
Un plugin puede ejecutar código arbitrario con tus permisos: así lo dice explícitamente la documentación oficial. Anthropic no verifica los plugins de terceros ni los servidores MCP que incluyan. Instala solo los de fuentes en las que confíes. El diseño de permisos del capítulo 5 vuelve aquí en forma de código escrito por otra persona.
Por dónde empezar: una palabra sobre el orden
Hemos enumerado seis, pero no hace falta instalarlas todas. Si las añades sin tener un problema que resolver, lo único que aumenta es la complejidad de la configuración. El orden va a partir del síntoma.
- Estás dando siempre la misma explicación → CLAUDE.md. Si es solo para un trabajo concreto, a Skills
- Lo has escrito y no se cumple → primero recorta. Solo lo que cause daño real, a hooks
- El contexto se llena enseguida → las investigaciones pesadas, a subagents; y desactiva los MCP que no uses
- La IA no llega a cierta información → MCP. Conecta de uno en uno y pasa al siguiente cuando veas que funciona
- Quieres repartir la misma configuración → plugins. Empaqueta solo lo que ya usas tú
- No tienes ningún problema concreto → no instales nada. Ese es el mejor estado posible
La última línea no es una broma. Las extensiones también aumentan las causas de atasco: es muy habitual que la raíz de un «Claude Code está raro» sea una capa que añadiste tú. Por eso el diagnóstico del capítulo 4 va primero.
Resumen
- El criterio de elección son cuatro preguntas: ¿basta con pedirlo? (CLAUDE.md, Skills) / ¿quiero que se cumpla siempre? (hooks) / ¿quiero separarlo en otro contexto? (subagents) / ¿quiero conectarme al exterior? (MCP). Para repartirlo, plugins
- CLAUDE.md es la memoria que atraviesa las sesiones. Si lo alargas, la parte central se hunde, la compresión lo diluye y pierde ante la instrucción más reciente. Recorta y deja explícitas las prioridades
- Los hooks los ejecuta el arnés, así que no media ningún criterio. Pueden endurecer las restricciones, pero no relajarlas
- Los subagents trabajan en otro contexto y solo devuelven el resumen. No sirven para procesos secuenciales ni para idas y venidas frecuentes
- Las Skills se abren solo cuando encaja su
description: es divulgación progresiva. Añadir muchas no pesa, pero con una descripción ambigua no se las llama - MCP es el estándar que amplía lo que se puede tocar. El estado que muestra
/mcpdecide la jugada - Los plugins son la caja de distribución. Como el código de otra persona corre con tus permisos, comprueba la procedencia
- El orden en el que añadirlas va a partir del síntoma. De una en una, y solo cuando surja el problema
Cuanto más lo amplías, más consume. Para terminar, hablaremos de cómo gestionarlo para usarlo mucho tiempo. Pasa al capítulo 7, «Coste y límites».