Skills, MCPs y Hooks: las tres patas de Claude Code que nadie te explica juntas

Llevo tres meses sin escribir acá. No fue por falta de material — fue exactamente lo contrario. Estuve tan metido construyendo que no paré a documentar. Pero hoy quiero escribir sobre algo que me queda claro después de trabajar con Claude Code de forma intensiva: no existe una receta mágica para configurarlo. Cada persona termina armandosu propio arsenal según su forma de trabajar, sus proyectos, y lo que necesita resolver. Lo que sigue es mi experiencia, no un tutorial definitivo.

Hay algo que me llama la atención en las conversaciones que veo online: todo el mundo habla de MCPs y Skills, y casi nadie habla de Hooks. Y resulta que Hooks es la tercera pata del sistema, la más silenciosa, y para mí una de las más poderosas.

MCPs: menos es más

Los MCPs son, en esencia, herramientas extra que le das al modelo para que ejecute acciones. Son especialmente útiles para conectar cosas externas: un software de diseño, una base de datos, un servicio que no tiene integración nativa. Son como darle manos nuevas al modelo para interactuar con el mundo exterior. Pero hay un detalle que poca gente menciona: cada MCP carga toda su definición de API en el contexto — todas las funciones, todos los parámetros, todas las descripciones. Aunque solo vayas a usar una llamada de diez disponibles, las diez se cargan. Y el contexto en un LLM no es infinito.

Claude Code tiene una mitigación para esto: Tool Search. Si tienes muchos MCPs activos, el modelo puede buscar entre ellos en lugar de cargarlos todos de golpe. Pero en mi opinión, incluso con Tool Search, un MCP ocupa significativamente más contexto que una skill bien armada.

Mi enfoque personal: uso muy pocos MCPs. Tengo uno que me resulta fundamental, una especie de memoria cross-proyecto — un MCP que conecta con una base de lecciones aprendidas, y cada vez que resuelvo algo interesante en cualquier proyecto, esa lección queda disponible para todos los demás. Es el tipo de cosa que necesita ser un MCP porque el modelo tiene que poder consultarlo y escribir en él por iniciativa propia, sin que yo le diga "busca en tus lecciones". El resto de lo que necesito lo resuelvo con skills.

Skills: la navaja suiza liviana

Las skills son, para mí, donde está la verdadera magia de la personalización de Claude Code. Y la razón es simple: son mucho más livianas que los MCPs. Cuando inicias una sesión, Claude Code solo carga una descripción mínima de cada skill — estamos hablando de muy pocos tokens por skill, lo justo para que el modelo sepa que existe y cuándo usarla. El contenido completo de la skill se carga recién cuando se necesita, no antes. Compáralo con un MCP: toda la definición de API, cada función, cada parámetro, todo se carga aunque no lo uses. La skill, en cambio, hace lazy loading y solo consume contexto cuando realmente la necesitas.

Yo las uso mucho. Algunas las invoco manualmente con /skill, y otras se cargan automáticamente cuando forman parte de un flujo. Por ejemplo, al momento de subir cambios a git, las skills correspondientes se activan solas y el proceso funciona sin que tenga que pensar en ello.

La clave para que esto funcione bien es la estructura. Yo separo cada skill en múltiples archivos:

• SKILL.md: Una descripción corta de alto nivel. Esto es lo único que siempre está cargado, y en promedio gasta menos de 80 tokens.
• references.md: La explicación en profundidad de cómo funciona la skill, sus reglas, sus restricciones.
• examples.md: Ejemplos concretos del uso correcto.

Claude recomienda esta separación, y tiene sentido: el modelo lee la descripción corta, entiende para qué sirve la skill, y cuando la necesita va a buscar los detalles. No carga todo desde el principio.

Hooks: la pata silenciosa

Y llegamos a lo que para mí es la pieza menos discutida y más interesante: los Hooks. Son comandos que se ejecutan automáticamente en puntos específicos del ciclo de vida de Claude Code — cuando edita un archivo, antes o después de ejecutar una herramienta, al iniciar una sesión. Son eventos que disparan acciones sin que tengas que pedirlas. Se pueden usar para muchas cosas: formatear código automáticamente después de cada edición, bloquear archivos protegidos para que el modelo no los toque, re-inyectarcontexto cuando la sesión se extiende.

Pero lo que me parece más poderoso de los Hooks es algo que pocas personas mencionan: la capacidad de atrapar al modelo cuando se equivoca y darle un mensaje de error claro para que se auto-corrija. Piénsalo así: estás en medio de un proceso complejo y el modelo intenta hacer algo que no debería — usar un comando prohibido, saltarse un paso del flujo, editar un archivo que no le corresponde. Sin hooks, eso pasa desapercibido hasta que tú lo notas (si es que lo notas). Con hooks, el error se intercepta enel momento, el modelo recibe un mensaje explicando qué hizo mal y cómo corregirlo, y se auto-corrige sin que tengas que intervenir.

Es enforcement automático. No dependes de que el modelo "recuerde" las reglas. Las reglas se ejecutan como código, y cuando se violan, el modelo lo sabe inmediatamente.

Donde realmente se pone interesante es cuando combinas hooks con scripts propios. El hook detecta el evento, y tu script hace el trabajo pesado. Fui armando una colección de scripts que validan cosas antes de que el modelo toque ciertos archivos, otros que inyectan contexto automáticamente, otros que formatean o bloquean operaciones peligrosas. Todo determinístico — sin depender de que el LLM decida bien cada vez. El hook atrapa el momento, el script ejecuta la lógica. Para operaciones que deben funcionar siempre igual, esa es la combinación correcta.

Custom Commands: atajos que nadie usa

Otra pieza que poca gente aprovecha son los custom commands. Son triviales de definir y te ahorran repetir las mismas instrucciones. Si hay algo que le pides a Claude seguido — un proceso que arrancas siempre igual, un formato de salida específico, una verificación que haces después de cada cambio — lo conviertes en un comando y listo. Lo invocas cuando lo necesitas, sin tener que escribir la instrucción completa cada vez. Me sirven especialmente para cosas repetitivas donde no quiero pensar en cómo pedirlo: solo lo ejecuto.

Cuándo combinar: el caso de seguridad

Hay un caso donde la combinación de MCP + agente especializado tiene mucho sentido: seguridad. Si tienes una infraestructura compleja o quieres priorizar la seguridad almáximo, puedes tener un MCP de seguridad conectado a un agente especializado que lo use. La ventaja es que ese MCP con toda su definición pesada no te consume el contexto del agente principal — el agente de seguridad vive en su propio contexto, usa el MCP cuando lo necesita, y solo devuelve resultados relevantes. Es una forma elegante detener capacidades pesadas sin pagar el costo de contexto en tu flujo principal de trabajo.

Tips que me hubiera gustado saber al principio

Hay algo que me funcionó mucho para aprender todo esto: jugar. Hacer proyectos de mentira, maquetas que no vas a publicar nunca. No necesitas usar el modelo más caro para experimentar — puedes probar con Sonnet o Haiku para ahorrar, armar proyectos de juguete, romper cosas, y ver qué pasa. Aprendes rápido cuando no hay presión de producción.

Otro tip: en /config de Claude Code puedes activar el modo Explanatory, que hace que el modelo te explique cada tanto qué está haciendo y por qué. O mejor todavía, el modo Learning, donde va guiándote paso a paso y te saca dudas. Si estás empezando, Learning es invaluable.

No hay receta mágica

Al final del día, no existe la configuración perfecta de Claude Code. Lo que funciona para mí probablemente no funciona exactamente igual para ti — mis proyectos son diferentes de los tuyos, mis flujos de trabajo son distintos, mis prioridades no son las mismas. Pero sí hay un principio que me sirve como guía: mantener el contexto lo máslimpio posible. Cada token que carga el modelo es un token menos para pensar en tu problema real. Los MCPs cargan mucho, las skills cargan poco, y los hooks no cargan nada porque se ejecutan fuera del modelo. El arsenal se arma probando, descartando lo que no sirve, y refinando lo que sí. No es un destino, es un proceso.

Si te sirvió, vuelve cuando publique algo nuevo. No tengo calendario fijo, pero cuando encuentro algo que vale la pena compartir, lo escribo acá. Sin cursos, sin ventas,sin pretensiones. Solo experiencia real.