Pon una barrera de seguridad: los hooks

El riesgo: publicar un error

Tu skill redacta y publica. Pero ¿qué pasa si un post contiene una raya larga que detestas, supera el límite de caracteres de la plataforma, o sale en Instagram sin imagen? Por ahora, nada lo detiene. Podrías releer cada post a mano — pero entonces ¿de qué sirve automatizar? Podrías añadir «verifica bien antes de publicar» en la skill — pero una instrucción en un prompt sigue siendo probabilística: el modelo la sigue casi siempre, y «casi» no basta cuando el error es público e instantáneo.

Necesitas una barrera de otra naturaleza: una verificación que se ejecute sistemáticamente, que Claude no pueda ni olvidar ni eludir. Eso es exactamente lo que son los hooks.

¿Qué es un hook?

Un hook ejecuta código en momentos clave del ciclo de vida de Claude Code. Se activa automáticamente: no tienes que pensar en llamarlo, y Claude no tiene que pensar en respetarlo — se le impone. Un hook puede formatear archivos tras una modificación, bloquear un comando antes de su ejecución, inyectar contexto al inicio de una sesión, o notificar cuando una tarea termina.

Los momentos de activación (los «eventos») cubren todo el ciclo de vida: antes de que una herramienta se ejecute (el evento PreToolUse — es el que nos interesa para bloquear una publicación), después de su ejecución (PostToolUse — perfecto para reformatear un archivo modificado), al enviar tu mensaje, al inicio de la sesión, o cuando Claude termina su respuesta. Cada hook se asocia a un evento y, opcionalmente, a un filtro (por ejemplo: solo los comandos Bash que contienen «publish»).

Las tres formas de validar

La regla de elección: toma el menos potente que baste. Verificar un límite de caracteres con un agent hook es sacar la excavadora para plantar una lechuga — lento, caro y más frágil. Nuestro quality gate combina reglas simples y objetivas: un command hook es la herramienta adecuada.

Dónde viven los hooks

Los hooks se configuran en tus archivos de ajustes (.claude/settings.json para compartirlos con el proyecto, o settings.local.json solo para ti). La estructura asocia un evento, un filtro («matcher») y el comando a lanzar. Esta es la forma general de un hook que se activa antes de los comandos Bash:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "node .claude/hooks/quality-gate.js"
          }
        ]
      }
    ]
  }
}

El mecanismo de bloqueo es de una simplicidad elegante: el script del hook recibe los detalles de la acción como entrada, y su código de salida decide lo que sigue. Salida 0: todo bien, la acción continúa. Salida 2: la acción queda bloqueada, y lo que el script escribió en la salida de error se devuelve a Claude — que lo lee y corrige. El hook no se limita por tanto a decir no: explica por qué, y Claude usa esa explicación para reparar.

Construir el quality gate

Creamos un hook que se activa antes de toda publicación y verifica el contenido. Si falla, el comando se bloquea y Claude ve con precisión qué corregir:

crea un command hook que se active antes de todo comando Bash de publicación.

el hook verifica el contenido del post:
- rayas largas (a reemplazar por « ... »)
- superación del límite de caracteres de la plataforma
- media faltante para las plataformas que exigen uno
- palabras prohibidas de mi guía de voz de marca

si una verificación falla: bloquea el comando y muestra con precisión qué corregir.

flowchart TD
  P["Intento de publicación"] --> H{"Hook: quality gate"}
  H -->|"Conforme"| OK["Publicación"]
  H -->|"No conforme"| KO["Bloqueado + lista de correcciones"]
  KO --> F["Claude corrige el contenido"]
  F --> P

Observa el bucle en el diagrama: bloqueado no significa muerto. Claude lee el mensaje de error, corrige el contenido y lo reintenta — la mayoría de las veces sin ninguna intervención por tu parte. La barrera no ralentiza el sistema: lo hace autocorrector.

Probar el hook (provocando el fallo)

Una barrera no probada es una barrera decorativa. El método: provocar voluntariamente cada tipo de fallo y verificar el bloqueo. Es el mismo reflejo de un desarrollador que prueba sus casos de error, no solo su camino feliz:

prueba el hook con un tuit que supere el límite de caracteres

prueba el hook con un post de instagram sin imagen

prueba el hook con un post que contenga la palabra "revolucionario"

Para cada prueba, la salida debe indicar que la acción fue bloqueada («validación fallida») con la razón exacta. Si un caso pasa cuando debería bloquear, lo aprendemos ahora — no el día en que un post no conforme salga a producción. Perfecto: tu pipeline nunca publicará un contenido no conforme.

Más allá del quality gate

Una vez entendido el mecanismo, los hooks se convierten en un reflejo para todo lo que debe ser sistemático. Algunos usos clásicos: reformatear automáticamente cada archivo modificado (PostToolUse), prohibir todo comando que toque una carpeta sensible, cargar el estado del proyecto al inicio de la sesión, o enviar una notificación cuando una tarea larga termina. La pregunta a hacerse es siempre la misma: «¿quiero que esto ocurra cada vez, sin depender de la memoria de nadie?» Si la respuesta es sí, es un hook.

Para Lea, este capítulo cambia la naturaleza de su sistema: antes, la automatización era rápida pero exigía su relectura; ahora es rápida y digna de confianza. Eso es lo que hará posible el escalado de los dos próximos capítulos — solo se paraleliza lo que se ha asegurado.