Hooks en Cursor: guardianes automáticos para tu código

Los hooks en Cursor son herramientas que te permiten observar, controlar y ampliar el ciclo de trabajo de un agente o subagente mientras programa por ti. Si estás construyendo software con IA y te preocupa que un agente tome decisiones peligrosas, aquí aprendes a poner guardianes automáticos alrededor de tu código antes de implementar un sistema de autenticación con usuario y contraseña.

La idea es simple pero poderosa: a veces los agentes van más allá de lo que les pedimos, y los hooks existen para proteger los caminos críticos de tu proyecto para que no se rompan.

Qué son los hooks y para qué sirven en un flujo agéntico

Un hook es un punto de control que se dispara en momentos específicos del ciclo de un agente. Piénsalo como un guardián que valida lo que tú quieras antes o después de una acción.

Con ellos puedes hacer tareas concretas como estas:

• Ejecutar formatters después de las ediciones.
• Agregar analíticas para eventos.
• Escanear el código en busca de información personal o secretos.
• Restringir operaciones riesgosas en la base de datos, como deletes.

Y la pregunta clave es cuándo se ejecuta un hook. La respuesta te da el control total del ciclo [00:39].

¿Cuándo se ejecuta un hook? Cuando una sesión empieza, cuando se llama una tool, cuando un subagente inicia o antes de ejecutar una shell. En cualquiera de esos momentos puedes correr una validación.

Dónde viven los hooks dentro de Cursor

Los hooks se crean dentro de la carpeta .cursor/hooks [01:14]. Y aquí viene lo interesante: .cursor no solo guarda las reglas y el MCP, también soporta hooks. Por detrás, cada hook es simplemente un comando de bash que corre en el background y protege las acciones que tú definas.

Cómo construir dos hooks para proteger tu proyecto

En la clase construimos dos guardianes con un prompt directo al agente, pidiendo ver los comandos exactos y la condición de bloqueo antes de escribir el hooks.json [02:04].

Estos fueron los dos hooks:

1. Un hook de tipo stop: al terminar cada turno corre el check-types y los tests del evaluador en el dominio. Si algo falla, devuelve un mensaje de error en la salida.
2. Un hook de tipo before shell: bloquea comandos destructivos, como borrar una carpeta con rm -rf, para que ningún agente elimine nada de tu sistema de archivos.

Después de generar la primera versión, el agente pidió confirmar cinco puntos de configuración [03:34]:

• Aplicar los hooks a todo el monorepo, no solo al dominio.
• Usar glob para los tests del evaluador en lugar de esperar un script.
• Definir un loop limit de 3 reintentos antes de marcar el error en la terminal.
• Permitir migraciones sin database.
• Bloquear cualquier borrado de folders, incluyendo node_modules y dist.

Ese loop limit es un detalle útil: si el hook stop encuentra un error, reintenta hasta tres veces antes de rendirse.

Qué archivos crea el agente

Al revisar el control de versiones, dentro de .cursor/hooks aparecieron dos comandos de bash: block_destructive y stop_check_domain [04:48]. Ambos protegen tu código de daños que no habrías notado, sobre todo en los paths críticos.

¿Qué es un hook de tipo stop? Es un guardián que se ejecuta al terminar cada turno del agente y valida tu código con check-types y tests. Si falla, reintenta según el loop limit y luego reporta el error.

Cómo implementar el login con usuario y contraseña usando hooks

Con los guardianes listos, ejecutamos el spec del login referenciándolo en el prompt [05:24]. Le pedimos al agente que use un usuario demo, cree la pantalla de login, use el endpoint, valide por token y trabaje con los hooks activos.

El resultado del agente incluyó varias piezas conectadas:

• Autenticación configurada a través de un middleware.
• Login, dashboard, middleware y proxies construidos.
• Un seed para loguearse con usuario y contraseña.
• El type check disparado automáticamente desde el hook que creamos.

Una nota técnica importante para tu aprendizaje: las cookies firmadas son stateless, así que al borrar la cookie invalidas el token [06:33].

Cómo probar que la autenticación funciona

El agente levantó el proyecto con la web en el puerto 3000 y la API en el 3001 [06:52]. Al entrar a localhost:3000/dashboard, el sistema te redirige al login, y puedes acceder con el usuario admin y la contraseña demo123.

¿Por qué el dashboard me redirige al login? Porque el middleware valida tu token antes de dar acceso. Sin una cookie firmada válida, la ruta protegida te envía de vuelta al login.

Como tarea, en los recursos encuentras la documentación de los hooks. Léela, entiende cómo funciona a profundidad e imagina en qué punto de tu proceso de software debería vivir un hook para construir un programa cada vez más seguro. ¿En qué parte de tu flujo pondrías el primer guardián? Cuéntame en los comentarios.