Hooks: automatización determinista
Un hook es una regla automática. No razona, no improvisa y no se olvida. Por eso es perfecto para todo lo que debe pasar siempre: formatear, bloquear secretos, registrar acciones o pedir confirmación ante comandos delicados.
Objetivos de aprendizaje
- Entender la diferencia entre un agente y una regla determinista.
- Diseñar hooks para calidad, seguridad y trazabilidad.
- Evitar hooks frágiles que bloquean el trabajo.
En cristiano: hook. Es un “cuando pase X, ejecuta Y”. Por ejemplo: antes de permitir un comando, comprueba si intenta leer
.env; después de editar código, ejecuta el formateador; al terminar una tarea, guarda un resumen.Tres hooks que sí cambian tu vida
- Bloqueo de secretos: impide leer o imprimir archivos sensibles.
- Calidad automática: ejecuta lint, formatter o tests cortos tras cambios.
- Registro de decisiones: añade un resumen a un log de trabajo.
Terminal
# Ejemplo conceptual: antes de ejecutar comandos, bloquea secretos if echo "$COMMAND" | grep -E '\.env|id_rsa|secret|token'; then echo "Bloqueado: posible secreto" exit 2 fi
Idea clave. Si algo es política de equipo, no lo dejes como sugerencia en un prompt. Ponlo en un hook o en CI. Los prompts educan; los hooks hacen cumplir.
Buen hook, mal hook
Buen hook: rápido, predecible, con mensaje claro y salida fácil. Mal hook: lento, opaco, toca archivos sin avisar o falla por detalles irrelevantes.
Orden recomendado
- Primero registra lo que pasa.
- Después avisa.
- Solo cuando estés seguro, bloquea.
Cuidado. Un hook que bloquea demasiado enseña al equipo a saltárselo. Empieza con warnings y sube el nivel cuando veas falsos positivos bajos.
Comprueba que funciona. Crea un hook de solo aviso que detecte
.env en comandos. Intenta leer un archivo falso llamado .env.example y ajusta la regla para no bloquear documentación legítima. Guardar y reabrir el proyecto.
Automatiza lo aburrido y lo peligroso. Lo que requiere juicio humano o contexto amplio, déjalo al agente o al PR.