Claude Code Hooks + Cursor Automations: Cobertura Total, por Dentro y por Fuera

Claude Code Hooks + Cursor Automations: Cobertura Total, por Dentro y por Fuera

Ya leíste sobre Claude Code Hooks. Ya leíste sobre Cursor Automations. Resuelven problemas distintos — pero si los usás juntos, cubren todo tu flujo de desarrollo con IA: uno desde adentro, el otro desde afuera.

Este artículo es sobre cómo combinarlos en un stack de gobernanza completo.


El Modelo Mental: Dos Capas, Cero Brechas

Antes que nada, la distinción:

Claude Code Hooks viven dentro de una sesión de agente. Se disparan en puntos específicos del ciclo de vida de Claude — antes de que corra una herramienta, después de que se edita un archivo, cuando termina la sesión. Controlan lo que Claude hace mientras trabaja. Son deterministas: si configurás un hook para bloquear comandos de shell peligrosos, ese bloqueo ocurre siempre, sin excepciones.

Cursor Automations viven por encima de las sesiones de agente. No controlan lo que hace un agente — deciden cuándo arranca y qué reporta. Un commit a main, un mensaje de Slack, una alerta de PagerDuty — estos disparan workflows completos sin que nadie esté frente al teclado.

Ponerlos juntos:

  • Automations lanza el agente cuando algo sucede en tu codebase o infraestructura
  • Hooks hace cumplir las reglas mientras ese agente corre
  • Los humanos revisan solo lo que requiere criterio humano

Eso no es solo productividad. Es un pipeline de desarrollo gobernado, auditable y con estándares aplicados automáticamente.


Dónde Opera Cada Capa

Claude Code Hooks Cursor Automations
Alcance Dentro de una sesión de Claude Code Por encima de las sesiones de agente
Trigger Eventos de herramientas, puntos del lifecycle Commits, Slack, timers, incidentes
Puede bloquear acciones :white_check_mark: Sí (PreToolUse) :cross_mark: No — lanza, no bloquea
Vive en .claude/settings.json Configuración del IDE de Cursor
Compartido con el equipo Commitealo al repo Configurado por workspace
Mejor para Enforcement, formatting, guardarraíles de seguridad Orquestación, revisiones programadas, respuesta a incidentes

Un Workflow Real: Revisión de Seguridad en Cada Push

Así es como las dos capas trabajan juntas en un escenario concreto:

Sin ninguna de las dos:
Un developer pushea a main. Alguien en el equipo eventualmente revisa el código — cuando tiene tiempo. Los problemas de seguridad pueden pasar desapercibidos por días.

Solo con Automations:
Una Automation dispara un agente de revisión de seguridad en cada push. El agente escanea vulnerabilidades, manda los hallazgos a Slack. Mejor — pero el agente en sí no tiene guardarraíles. Puede editar archivos, correr comandos de shell, proponer cambios sin restricciones.

Con ambas:
La Automation dispara el agente. Los Hooks hacen cumplir las reglas mientras corre:

  • PreToolUse bloquea al agente de correr rm -rf o escribir credenciales en archivos
  • PostToolUse auto-formatea cada archivo que toca el agente
  • Stop loguea el resumen de la sesión con timestamps para el audit trail
  • Si algo se marca como alto riesgo, el agente reporta via Slack — sin mergear nada de forma autónoma sin aprobación humana

La Automation decide cuándo ocurre el trabajo. Los Hooks deciden cómo ocurre.


Configurando el Stack

Paso 1 — Configurá tus Automations en Cursor

En tu workspace de Cursor, configurá una automation disparada por PRs mergeados a main:

Trigger: GitHub PR merged → branch: main
Agent task: "Revisá este diff buscando vulnerabilidades de seguridad, problemas de complejidad y gaps de cobertura de tests. Reportá los hallazgos de alto riesgo en el canal de Slack #code-review. No hagas cambios."

Esto te da cobertura permanente sin que nadie tenga que iniciar una revisión manualmente.

Paso 2 — Restringí el agente con Hooks

En .claude/settings.json en la raíz de tu repo (commitealo para que todo el equipo lo herede):

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "handler": {
          "type": "command",
          "command": ".claude/hooks/security-guard.sh"
        }
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write|MultiEdit",
        "handler": {
          "type": "command",
          "command": ".claude/hooks/auto-format.sh"
        }
      }
    ],
    "Stop": [
      {
        "matcher": "*",
        "handler": {
          "type": "command",
          "command": ".claude/hooks/audit-log.sh"
        }
      }
    ]
  }
}

Tu security-guard.sh bloquea patrones peligrosos. Tu auto-format.sh mantiene el código consistente. Tu audit-log.sh escribe el resumen de cada sesión en un archivo de log con timestamps.

Cada agente que Automations lanza — y cada developer que corre Claude Code manualmente — opera bajo estas mismas reglas.

Paso 3 — Definí tus checkpoints humanos

No todo debería automatizarse de punta a punta. Decidí de antemano:

  • Hallazgos de seguridad por encima de cierta severidad → alerta en Slack, humano revisa antes del merge
  • PRs de bajo riesgo (docs, refactors menores) → el agente puede comentar, el humano igual mergea
  • Incidentes de PagerDuty → el agente investiga y propone un PR de fix, el humano aprueba antes del deploy

Automations maneja la detección y la respuesta inicial. Hooks maneja los guardarraíles. Los humanos manejan las decisiones de criterio.


Para Equipos: El Argumento de Gobernanza

Cuando commiteás .claude/settings.json a tu repositorio, cada developer del equipo hereda tu configuración de Hooks automáticamente. Cuando configurás Automations en tu workspace de Cursor, cada push dispara el mismo pipeline de revisión.

Para tech leads y CTOs, esto significa:

Estándares consistentes sin tener que vigilar a nadie. No necesitás recordarles a los developers que corran el linter, chequeen vulnerabilidades o actualicen la documentación después de un refactor. El stack lo hace automáticamente, siempre.

Audit trails por defecto. Tu hook Stop loguea cada sesión de Claude Code. Tus Automations loguean cada workflow disparado en Cursor. Tenés un registro completo de qué corrió, cuándo, y qué encontró — sin que nadie tenga que mantener eso manualmente.

Onboarding que funciona. Un developer nuevo clona el repo, abre Claude Code, y los hooks ya están configurados. Abre Cursor y las automations ya están corriendo. No hay “acordate de configurar X” — la configuración es parte del codebase.

Separación de responsabilidades a escala. A medida que agregás más agentes — más automations, más developers usando Claude Code — la capa de gobernanza escala con ellos. Las reglas se definen una vez, se aplican en todos lados.


Los Tradeoffs Honestos

Los Hooks requieren mantenimiento. Tus scripts de shell necesitan funcionar correctamente o van a bloquear operaciones legítimas. Testeálos bien antes de commitearlos al repo del equipo. Empezá con PostToolUse (no bloqueante) antes de agregar hooks PreToolUse (bloqueantes).

El pricing de Automations no está completamente publicado. Esperá que los costos escalen con el volumen de triggers. Empezá con los triggers de mayor valor y menor frecuencia (PRs mergeados a main, incidentes de PagerDuty) antes de agregar los de alta frecuencia (cada commit).

Ambas requieren calibración. Demasiados hooks crean fricción. Demasiadas automations crean ruido. El objetivo es automatización específica — los guardarraíles correctos en los lugares correctos, no máxima automatización en todos lados.


La Versión Corta

Claude Code Hooks responden: ¿qué debería ocurrir siempre dentro de una sesión de agente?

Cursor Automations responden: ¿cuándo debería arrancar una sesión de agente?

Juntos, responden: ¿cómo corremos desarrollo asistido por IA a escala de equipo, con estándares y sin babysitting constante?

Ese es el stack.


¿Ya usás alguna de las dos herramientas en tu equipo? ¿O las dos? Contanos cómo las configuraste. :backhand_index_pointing_down:

Artículos relacionados en yoDEV: