5. Hooks y automatización — lo que el sistema recuerda cuando el operador olvida
La otra mitad de los skills. Procedimientos que el sistema dispara en eventos sin invocación del operador. Los momentos ciegos que cubren los hooks, criterios de promoción, hooks en rotación y las trampas a evitar.
Esta es la parte 5 de la serie Alice Way. La parte 4 Skills y slash commands condensó los movimientos mentales recurrentes en nombres de una línea. Este artículo trata de la otra mitad: hacer que los procedimientos se disparen incluso cuando el operador no invoca el nombre.
0. Un hook externaliza la mente olvidadiza al sistema
El operador olvida. Las decisiones de ayer, el estado justo antes de abrir una nueva sesión, la verificación que debería haber ocurrido justo antes de reportar — fácilmente una vez al día.
Los skills bloquean parte de este olvido — llama al nombre y el procedimiento se ejecuta. Pero si la propia llamada se olvida, el skill no se dispara. Hay momentos en los que incluso un nombre de una palabra no emerge.
Los hooks cubren esos momentos. Sin depender de la conciencia del operador, el sistema dispara automáticamente el procedimiento en un evento específico. Es el acto de externalizar parte de la mente del operador al sistema.
Lo que vale la pena externalizar está restringido: "no debe olvidarse pero es fácil de olvidar", "la condición es suficientemente clara para juzgarse automáticamente", "el momento de disparo puede anclarse a un evento." Este artículo es un registro de los criterios para esa externalización y los hooks reales en uso.
El mecanismo de hook en sí está tomado del sistema de hooks de Anthropic Claude Code. Este artículo es un registro de cómo se usa ese mecanismo, no una invención del mismo.
1. Hay momentos en que la conciencia se queda en blanco
Lo que el operador olvida con más frecuencia no es porque el procedimiento sea difícil. Es porque el procedimiento tiene que interrumpir un momento en que la atención está en otra cosa.
| Momento | Estado de conciencia | Procedimiento fácilmente olvidado |
|---|---|---|
| Justo después del inicio de sesión | Recordando "¿dónde estaba?" | Verificar estado de sincronización de memoria |
| Justo después de un cambio de código | Alivio — "listo" | Verificación de lint / build / test |
| Justo antes de redactar un reporte | Componiendo — "cómo expresarlo" | Verificar cambios fuera del área de trabajo |
| Justo antes del cierre de sesión | Terminando — "bien, por hoy" | Log de trabajo, HANDOFF, push |
| Justo antes de un comando peligroso | Ejecutando — "esto lo termina" | Re-verificar la intención real |
En todos estos momentos la mente del operador está en otro lugar. Un principio del tipo "no olvides" no puede evitarlo. Tiene que activarse a nivel del sistema.
Los hooks son el dispositivo de disparo. Interrumpen los momentos en que la conciencia está en blanco y fuerzan el procedimiento.
2. El límite entre skills y hooks
Estos dos se confunden a menudo. La distinción central es una sola cosa: quién lo llama.
| Llamador | Momento de disparo | Conciencia del operador | |
|---|---|---|---|
| Skill / slash command | Operador explícito | El operador decide | Consciente antes de llamar |
| Hook | Sistema automático | El evento decide | Solo ve el resultado (o no lo nota) |
Un skill necesita la decisión del operador "hacer esto" para dispararse. Un hook se dispara sin ella. Así que el mayor valor de un hook es — el procedimiento está garantizado incluso en momentos en que el operador no decidió.
El mismo procedimiento puede exponerse de ambas maneras. /verify puede invocarse directamente como slash command, o dispararse automáticamente justo antes de un reporte de "listo." Invocación consciente del operador = skill; auto-disparo del sistema = hook — dos entradas al mismo procedimiento.
3. Criterios de promoción — qué procedimientos se convierten en hooks
No todo procedimiento debería convertirse en un hook. Solo los que pasan todos estos cinco obtienen el privilegio de auto-disparo.
3.1 Alta pérdida al omitir, fácil de omitir
Un hook tiene un coste cognitivo: el sistema actúa mientras el operador no es consciente de ello. Para justificar ese coste, la pérdida de omitirlo tiene que ser suficientemente grande. Un push sin verificación, una sesión iniciada sin sincronización de memoria actualizada: estas situaciones muestran la pérdida de inmediato. Territorio de hook.
Los procedimientos de conveniencia se quedan como skills, no como hooks.
3.2 La condición de disparo es un evento claro
Un hook está vinculado a un evento específico. "Inicio de sesión," "antes de uso de herramienta," "antes de enviar salida," "fin de sesión" — ese tipo de cosa. Si el evento es vago — "cuando se sienta bien" — no es un hook.
3.3 La decisión es auto-juzgable
Una vez que el hook se dispara, la acción debe ser decidible automáticamente: "Si el cambio pasa lint, OK; de lo contrario, bloquear" — una bifurcación clara. Los procedimientos que requieren juicio adicional del operador se canalizan mediante invocaciones de skills, no mediante hooks.
3.4 El fallo es seguro
Si un hook falla, el sistema en su conjunto no debe romperse. Como los hooks operan fuera de la conciencia del operador, los fallos no se detectan de inmediato. Por eso su impacto debe estar aislado.
3.5 La salida es una señal
El resultado de un hook llega al operador como una línea. Señales claras del tipo "OK", "bloqueado", "advertencia". Una salida larga o vaga convierte el hook en ruido en el campo visual del operador.
4. Hooks en rotación real
Un subconjunto de los hooks en los que me apoyo cada día.
4.1 SessionStart — al inicio de la sesión
En el momento en que se inicia una sesión, imprime un estado de sincronización de memoria en una línea. "Memory sync: current" o "Memory sync: 5 min old — refresh needed." El operador lee esa línea y juzga al instante.
Sin este hook, el operador tiene que verificar conscientemente "¿está la memoria al día?" en cada ocasión. Cuando la atención está en otro lugar, la verificación se olvida y el trabajo simplemente comienza. Las decisiones se toman entonces sobre un estado obsoleto.
4.2 PreToolUse — justo antes de comandos peligrosos
Se dispara justo antes de comandos específicos como rm -rf, force push, SQL destructivo. O pide confirmación del usuario o bloquea por violación de política.
El valor de este hook: el sistema fuerza un momento de "¿realmente quiero esto?" Interrumpir el flujo de ejecución rápida es precisamente el objetivo.
4.3 PreToolUse → auto-disparo de /verify
Un hook que ejecuta automáticamente lint · build · test justo antes de un reporte de "listo." El sistema interviene justo cuando el operador está a punto de escribir "terminado" y fuerza la verificación. Si falla, el reporte se bloquea.
El momento de alivio del operador ("ya está listo") es el más peligroso. El hook fuerza una pausa justo en ese instante.
4.4 Stop — al cierre de la sesión
En el momento en que la sesión está a punto de terminar, verifica si el log de trabajo ha sido actualizado y si el HANDOFF contiene la información que necesita la siguiente sesión. Si falta algo, alerta al operador.
Sin este hook, el operador simplemente cierra en el estado "listo." La siguiente sesión comienza con contexto perdido.
4.5 El efecto acumulado
Cada uno de estos es un procedimiento pequeño por sí solo. Pero el efecto acumulado es grande: el sistema cubre 5–6 momentos diarios en que la conciencia del operador se queda en blanco. La mente del operador puede concentrarse solo en decisiones; el sistema se encarga de "los procedimientos que no deben saltarse."
5. Principios de diseño
Lo que encontré para el diseño de hooks.
5.1 Corto y rápido
Un hook interrumpe el flujo del operador. Si no es breve, el flujo se rompe. Los hooks que tardan más de un segundo deben ejecutarse de forma asíncrona o mostrar progreso claro. Si el operador empieza a pensar "¿por qué se ha pausado esto?", el valor del hook se vuelve negativo.
5.2 La salida es una línea
Cuando el hook termina, lo que el operador ve es una línea. Los logs detallados van a un archivo separado. "Memory sync: current," "Verification passed: 3 tests OK," "Blocked: 2 lint errors" — esa forma.
5.3 Fallo aislado
Un fallo de hook no debe romper el trabajo principal. Si la sincronización de memoria falla, la sesión igualmente comienza (con una advertencia). Si el hook de verificación falla, bloquea el reporte pero mantiene el trabajo activo.
5.4 Evitable
A veces el operador quiere saltarse intencionalmente un hook: depuración, trabajo ad-hoc. Debe existir una opción de bypass explícita. El bypass se registra, pero no se bloquea.
5.5 Idempotente
El mismo evento disparándose dos veces debería producir el mismo resultado, o al menos no romper nada. Los hooks se disparan automáticamente, por lo que la entrega duplicada de eventos no puede evitarse.
6. Qué no convertir en hook — trampas
El reverso de los criterios de promoción.
6.1 Reemplazar las decisiones del operador
Un hook que "corrige automáticamente el código cuando detecta un patrón" es peligroso. La autocorrección a menudo diverge de la intención. Los hooks deben limitarse a notificar y bloquear; la corrección ocurre cuando el operador invoca un skill.
6.2 Dispararse demasiado a menudo
Los hooks que se disparan en cada pulsación de tecla o en cada guardado de archivo se convierten en ruido. La frecuencia natural del evento debe ser del orden de minutos como mínimo. El disparo en intervalos de sub-segundo rompe el flujo del operador.
6.3 Salida larga
Si un hook genera 30 líneas de log, entierra la salida del trabajo principal. La información extensa va a archivos; la consola recibe solo una línea de señal.
6.4 Fallo que rompe el trabajo principal
Si los fallos de hook se propagan y rompen el trabajo principal, el operador desactiva el hook. Una vez desactivado, permanece así indefinidamente. El aislamiento del fallo no es negociable.
7. Componer skills y hooks
El efecto de red de la parte 4 — skills §5 se expande un paso más cuando se añaden los hooks.
El mismo procedimiento expuesto de ambas maneras:
| Procedimiento | Invocación de skill | Disparo de hook |
|---|---|---|
/verify | Cuando el operador quiere verificar explícitamente | Auto-disparo justo antes de un reporte de "listo" |
/start <proyecto> | Cuando el operador entra en un proyecto | (ninguno — la intención del operador es el inicio) |
/session-end | Cuando el operador declara el cierre | (el hook Stop solo verifica omisiones) |
| Sincronización de memoria | (sin skill dedicado) | SessionStart automático |
Combinados así — cuando el operador es consciente, el skill; cuando la conciencia está en blanco, el hook — el mismo procedimiento queda garantizado de cualquier manera. La autoridad de decisión permanece en el operador; la red de seguridad la sostiene el sistema.
Descarga — settings.json de ejemplo
El diseño de hooks de este artículo (SessionStart / UserPromptSubmit / PreToolUse / PostToolUse) más una lista de permisos allow/deny, en un solo archivo. Tómalo y adapta <project-root> a tu propio proyecto.
shasum -a 256 settings.json
# expected: 60b5bf7fec33f92d9ddcc6ab4696747df6bb3dab14e8287b696d45fbd6c1abde8. Comprimido en un principio
El núcleo del diseño de hooks se resume en una oración.
"Solo los procedimientos que el operador probablemente olvidará los dispara automáticamente el sistema. Todo lo demás permanece como un skill que el operador elige llamar."
Cuando esto se cumple, los hooks se convierten en un dispositivo de seguridad que alivia la carga de la mente del operador. Cuando se rompe, se convierten en ruido que secuestra la intención del operador.
El siguiente artículo cubre la estructura donde un agente no lo hace todo: delegación Multi-Agent, es decir, qué delegar a otros colaboradores y qué hacer uno mismo.