Automatización con Claude Code: Hooks, Skills y Rules Explicados

Llevas un tiempo usando Claude Code. Lee tus archivos, escribe código, ejecuta comandos. Funciona bien. Pero seamos sinceros: sigues haciendo a mano cosas que podrían pasar solas — formatear código después de cada edición, revisar que nadie lance un rm -rf / por accidente, seguir el mismo proceso de deploy de cinco pasos una y otra vez.

Claude Code tiene tres sistemas que automatizan todo eso: hooks, skills y rules. Solo el 12% de los setups en nuestro análisis usan hooks, pero los que lo hacen sacan 6.8/10 de media, frente a 2.1 sin ellos. La diferencia es enorme — y la configuración toma diez minutos.

Empecemos con algo concreto, ahora mismo.

Tu primer hook: formatear automáticamente cada archivo que Claude toca

El escenario: Claude edita un archivo TypeScript. El código funciona, pero el formato está mal — indentación rara, puntos y coma faltantes, lo que sea que tu Prettier dicte. Le pides a Claude que arregle el formato. Eso es un turno desperdiciado.

En lugar de eso, hagamos que el formateo pase solo después de cada edición.

Crea este archivo en .claude/hooks/format-on-save.sh:

#!/bin/bash
# Se ejecuta después de que Claude edita o crea un archivo

INPUT=$(cat)
FILE=$(echo "$INPUT" | jq -r '.input.file_path // empty')

if [ -z "$FILE" ]; then
  exit 0
fi

# Formatear según tipo de archivo
case "$FILE" in
  *.ts|*.tsx|*.js|*.jsx)
    npx prettier --write "$FILE" 2>/dev/null
    ;;
  *.py)
    ruff format "$FILE" 2>/dev/null
    ;;
  *.go)
    gofmt -w "$FILE" 2>/dev/null
    ;;
esac

Hazlo ejecutable:

chmod +x .claude/hooks/format-on-save.sh

Ahora regístralo en .claude/settings.json:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "command": ".claude/hooks/format-on-save.sh"
      }
    ]
  }
}

Eso es todo. La próxima vez que Claude toque un archivo, Prettier (o ruff, o gofmt) pasa automáticamente. Cero prompts extra, cero limpieza manual.

Pruébalo ahora. Pídele a Claude que cree una función simple en cualquier archivo TypeScript. Mira la salida — el archivo se formatea automáticamente después de la edición. Nunca más tienes que pensar en formateo.

Hooks, skills y rules: ¿cuál es la diferencia?

Antes de seguir, aclaremos el concepto. Las tres confunden a casi todos al principio, así que aquí va la versión sencilla:

• Los hooks ejecutan código antes o después de cada llamada de herramienta. Son automáticos — tú no los disparas, simplemente se ejecutan. Piensa en event listeners.
• Los skills son comandos slash que tú escribes: /deploy, /review, /ticket PROJ-123. Cada uno empaqueta un workflow de varios pasos que puedes lanzar por nombre.
• Las rules son instrucciones que se cargan automáticamente según en qué archivos trabaja Claude. Cuando toca un .tsx, aparecen tus convenciones de frontend. Cuando toca SQL, aparecen tus reglas de base de datos.

Ahora veamos cada uno en detalle.

Hooks: tu red de seguridad y tu piloto automático

Un hook es un script shell que Claude Code ejecuta en un momento concreto. Hay cuatro tipos:

• PreToolUse — se ejecuta antes de una llamada de herramienta. Puede bloquearla.
• PostToolUse — se ejecuta después de una llamada de herramienta. Puede transformar la salida.
• Stop — se ejecuta cuando Claude termina su turno.
• SessionStart — se ejecuta una vez al iniciar la sesión.

Ya viste PostToolUse con el formateador. Ahora vamos con el más importante: un guard de seguridad.

El guard de seguridad PreToolUse

Este hook atrapa comandos peligrosos antes de que se ejecuten. Copia esto en .claude/hooks/pre-tool-guard.sh:

#!/bin/bash
# Bloquear comandos shell destructivos

INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool')
COMMAND=$(echo "$INPUT" | jq -r '.input.command // empty')

if [ "$TOOL" = "Bash" ]; then
  if echo "$COMMAND" | grep -qE 'rm -rf /|git push --force|git reset --hard|DROP TABLE'; then
    echo '{"blocked": true, "reason": "Comando destructivo bloqueado por el guard de seguridad"}'
    exit 0
  fi
fi

echo '{"blocked": false}'

chmod +x .claude/hooks/pre-tool-guard.sh

Regístralo en settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "command": ".claude/hooks/pre-tool-guard.sh"
      }
    ]
  }
}

A partir de ahora, si Claude intenta ejecutar rm -rf / o git push --force, el hook lo intercepta, devuelve blocked: true, y Claude ve la razón. El comando nunca se ejecuta.

Puedes probarlo ahora mismo, sin ni siquiera abrir Claude:

echo '{"tool":"Bash","input":{"command":"rm -rf /"}}' | .claude/hooks/pre-tool-guard.sh

Deberías ver {"blocked": true, "reason": "Comando destructivo bloqueado por el guard de seguridad"}. Tu red de seguridad funciona.

SessionStart: dar contexto a Claude desde el primer momento

Este hook se ejecuta una vez al abrir Claude Code. Inyecta contexto para que Claude se oriente inmediatamente:

#!/bin/bash
# .claude/hooks/session-start.sh

echo "## Estado Git Actual"
echo "Rama: $(git branch --show-current)"
echo "Último commit: $(git log --oneline -1)"
echo "Archivos modificados:"
git status --short
echo ""
echo "## TODOs recientes"
grep -r "TODO\|FIXME\|HACK" src/ --include="*.ts" -l 2>/dev/null | head -10

Cada sesión empieza con Claude sabiendo en qué rama estás, cuál fue el último commit y qué archivos tienen TODOs pendientes. Se acabó el "¿en qué rama estoy?" como primera pregunta.

Skills: tus comandos slash personales

Aquí es donde la cosa se pone divertida. Escribes un archivo markdown que describe un workflow, y se convierte en un comando slash que puedes lanzar cuando quieras.

Tu primer skill: un comando de deploy

Crea .claude/skills/deploy.md:

---
name: deploy
description: Desplegar la rama actual a staging o producción
---

# Workflow de Despliegue

1. Ejecutar `npm run build` para verificar que el build pasa
2. Ejecutar `npm run test` para confirmar que todos los tests pasan
3. Verificar la rama actual: `git branch --show-current`
4. Si en `main`:
   - Desplegar a producción: `railway up --service production`
   - Verificar health check: `curl -s https://api.example.com/health`
5. Si en otra rama:
   - Desplegar a staging: `railway up --service staging`
   - Mostrar la URL de staging para revisión

Siempre reportar el estado del despliegue y la URL.

Escribe /deploy en Claude Code. Claude construye, testea, verifica la rama, despliega al entorno correcto y verifica el health check. Un comando en lugar de cinco pasos manuales.

Un skill de revisión de código

Este lo vas a usar todos los días. Guárdalo como .claude/skills/review.md:

---
name: review
description: Revisar cambios staged antes de hacer commit
---

# Revisión de Código

1. Ejecutar `git diff --staged` para ver todos los cambios
2. Para cada archivo, verificar:
   - Manejo de errores: ¿las operaciones async están en try/catch?
   - Seguridad: ¿secrets hardcodeados, inyección SQL o XSS?
   - Tipos: ¿algún `any` que debería ser específico?
   - Tests: ¿las funciones modificadas tienen actualizaciones de tests?
3. AUTO-CORREGIR problemas mecánicos (formateo, tipos faltantes, bugs obvios)
4. Reportar issues CRÍTICAS (debe corregir) e INFORMATIVAS (vale considerar)
5. Si no hay issues críticas: sugerir un mensaje de commit

Escribe /review antes de hacer commit y Claude revisa tu trabajo. Los problemas mecánicos se corrigen solos. Las decisiones ambiguas se marcan para que tú decidas.

Skills que aceptan argumentos

Los skills pueden recibir parámetros. Guárdalo como .claude/skills/ticket.md:

---
name: ticket
description: Empezar trabajo en un ticket específico
---

El usuario proporcionará un ID de ticket (ej. `/ticket PROJ-123`).

1. Obtener los detalles del ticket del tracker de issues
2. Crear una nueva rama: `git checkout -b feat/PROJ-123-descripcion`
3. Leer los archivos relevantes mencionados en el ticket
4. Proponer un plan de implementación antes de escribir código
5. Esperar aprobación antes de continuar

Escribe /ticket PROJ-123 y Claude lee el ticket, crea una rama, encuentra los archivos relevantes y propone un plan — todo antes de escribir una sola línea de código.

Rules: instrucciones que se cargan en el momento justo

Ya conoces las rules de la guía de configuración. Aquí está por qué son cruciales para la automatización: mantienen el contexto de Claude limpio y ligero.

Imagina que tienes 200 líneas de convenciones de frontend, 150 de reglas de backend y 100 de estándares de base de datos. Si metes las 450 líneas en CLAUDE.md, Claude carga todo en cada interacción — incluso cuando solo editas un archivo CSS.

Con rules, Claude carga las convenciones de frontend solo cuando toca archivos .tsx, las reglas de base de datos solo al editar migraciones, y las advertencias de seguridad solo cerca de archivos sensibles.

Aquí hay una rule de seguridad que marca la diferencia:

<!-- .claude/rules/security.md -->
---
globs: [".env*", "*.pem", "*.key", "*secret*", "*credential*"]
---

- NUNCA hacer commit de este archivo al control de versiones
- NUNCA loguear su contenido
- NUNCA incluir estos valores en mensajes de error o respuestas API
- Si este archivo necesita modificación, explicar los cambios necesarios pero no mostrar los valores actuales

Cuando Claude toca cualquier archivo que coincida con esos patrones, estas rules aparecen automáticamente. Cuando trabaja en código no relacionado, se quedan fuera del camino.

La guía rápida: cuándo usar qué

Esta es la pregunta que todos hacen. Así se decide:

Usa un hook cuando la acción debe ocurrir siempre, sin que nadie tenga que pensar en ello. Formateo al guardar. Bloquear comandos peligrosos. Loguear cada llamada de herramienta. Si un humano no debería tener que acordarse, es un hook.

Usa un skill cuando tienes un proceso de varios pasos que repites regularmente. Desplegar. Revisar código. Iniciar un ticket. Escribir una migración. Si escribirías una checklist para ello, es un skill.

Usa una rule cuando las instrucciones dependen de en qué archivo trabaja Claude. Convenciones de frontend para .tsx. Seguridad SQL para migraciones. Advertencias para .env. Si el consejo es "cuando trabajes en X, sigue estas directrices", es una rule.

Los tres juntos: un ejemplo real

Así es como hooks, skills y rules trabajan en equipo en un workflow de migración de base de datos:

1. Rule (.claude/rules/database.md) — cuando Claude toca archivos de migración, carga automáticamente tus convenciones: queries parametrizadas, requisitos de rollback, patrones de nombres.

2. Hook (PreToolUse en Bash) — si Claude intenta ejecutar un comando de migración, el hook verifica que existe un archivo de rollback. ¿No hay rollback? El comando se bloquea.

3. Skill (/migrate) — un comando slash que crea el archivo de migración desde un template, genera el rollback correspondiente, ejecuta contra una base de datos de prueba y reporta el resultado.

La rule proporciona el conocimiento. El hook impone la restricción. El skill empaqueta el workflow. Cada pieza hace un trabajo, y lo hace bien.

Cuando las cosas no funcionan

Si tus hooks, skills o rules no se activan, así es como se depura:

# Ejecutar Claude en modo verbose para ver la ejecución de hooks
claude --verbose

# Probar un hook independientemente
echo '{"tool":"Bash","input":{"command":"rm -rf /"}}' | .claude/hooks/pre-tool-guard.sh

Los sospechosos habituales:

• Script de hook sin permisos de ejecución. Corrige con chmod +x .claude/hooks/tu-hook.sh
• Patrón glob que no coincide. **/api/**/*.ts es diferente de api/**/*.ts. Prueba el tuyo contra rutas de archivos reales.
• Skill no encontrado. Asegúrate de que está en .claude/skills/ con el name: correcto en el frontmatter.

Lo que has construido

Si seguiste los pasos, ahora tienes:

• Un guard de seguridad que bloquea comandos destructivos antes de que se ejecuten
• Un auto-formateador que limpia cada archivo que Claude toca
• Un skill de deploy que empaqueta todo tu workflow de despliegue en un solo comando
• Un skill de revisión que verifica tu código antes de hacer commit
• Rules que inyectan las convenciones correctas en el momento justo

La mayoría de usuarios de Claude Code nunca llegan aquí. Acabas de construir un entorno de desarrollo personalizado que trabaja para ti automáticamente.

¿Listo para más? Aquí es adónde ir:

• Conectar Claude a tus herramientas — servidores MCP que permiten a Claude consultar tu base de datos, buscar en GitHub y obtener errores de Sentry
• Patrones de workflow avanzados — subagents, ejecución paralela y las estrategias de depuración de los power users
• Evaluar tu setup para ver exactamente dónde está tu automatización

Preguntas frecuentes

¿Los hooks ralentizan las cosas?

Un guard de seguridad basado en grep añade 10-50 milisegundos por llamada de herramienta — no lo notarás. Pero un hook PostToolUse que ejecuta Prettier añade 200-500ms por edición. Mantén los hooks rápidos. Si un hook necesita hacer trabajo pesado, lanza el proceso en segundo plano para que Claude no espere.

¿Puedo compartir hooks entre todos mis proyectos?

Sí. Coloca hooks compartidos en ~/.claude/hooks/ y referéncialos con rutas absolutas en tu ~/.claude/settings.json global. Los hooks específicos del proyecto van en .claude/hooks/ con rutas relativas en la configuración del proyecto.

¿Qué pasa si un hook falla?

Claude Code captura errores de hooks y continúa como si el hook no existiera — la llamada de herramienta se ejecuta normalmente. El error aparece en modo verbose. Es un diseño safety-first: un hook roto nunca impide que Claude trabaje. Pero prueba tus hooks a fondo — un guard de seguridad roto que falla en silencio es peor que no tener guard.

¿Un skill puede llamar a otro skill?

No directamente. No hay mecanismo de /deploy llamando a /review. Si necesitas un workflow compuesto, construye un solo skill que incluya todos los pasos. Otra opción: usa un hook para disparar lógica adicional después de que un skill termine.

¿Cómo interactúan las rules con CLAUDE.md?

Ambas se cargan en el contexto, y Claude sigue todas. Si una rule contradice algo en CLAUDE.md, la instrucción más específica generalmente gana. Pero evita contradicciones desde el principio — CLAUDE.md para instrucciones globales del proyecto, rules para sobrescrituras específicas de archivos.