Claude Code avanzado: subagentes, hooks y slash commands (guía power-user 2026)

Más allá de lo básico: cuatro funciones que convierten a Claude Code en un compañero

Una vez que instalas Claude Code y ejecutas claude dentro de un proyecto, cuatro funciones lo transforman de asistente útil en compañero configurado. CLAUDE.md y la memoria automática guían cada sesión; los subagentes corren en su propia ventana de contexto con herramientas acotadas y un modelo más barato como Haiku para controlar el costo; los hooks son comandos de shell que se ejecutan en puntos del ciclo de vida y pueden bloquear una herramienta; y las skills o slash commands empaquetan flujos repetibles que tu equipo comparte. Si vienes llegando, primero repasa qué es Claude Code y cómo usarlo; esta guía sube de nivel.

Guía cada sesión con CLAUDE.md y la memoria automática

CLAUDE.md es un archivo markdown en la raíz de tu proyecto que Claude Code lee al INICIO de cada sesión. Ahí pones tus estándares de código, decisiones de arquitectura, librerías preferidas y listas de verificación para revisión. Es la forma más barata de que cada sesión arranque ya sabiendo cómo trabaja tu equipo.

# CLAUDE.md
## Estándares
- TypeScript estricto; nada de `any`.
- Tests con Vitest; cada PR agrega o actualiza tests.
## Arquitectura
- Astro para el sitio; contenido en MDX bajo src/content/.
## Checklist de revisión
- Sin secretos escritos en el código. Sin console.log en producción.

Además, Claude Code construye una memoria automática entre sesiones (por ejemplo, comandos de build o hallazgos de depuración) sin que tú escribas nada. Y si prefieres separar reglas por tema, pueden vivir en archivos bajo .claude/rules/*.md. La documentación de memoria detalla la jerarquía completa.

Subagentes: ventana de contexto propia, herramientas acotadas y modelos más baratos

Un subagente es un asistente especializado que se ejecuta en su PROPIA ventana de contexto, con un system prompt a la medida, acceso específico a herramientas y permisos independientes. Esto importa por tres razones: mantiene la exploración y los logs FUERA de tu conversación principal (preserva contexto), te deja imponer restricciones de herramientas, y controla el costo enrutando el trabajo a un modelo más barato.

No lo confundas con figuras cercanas: los background agents son muchas sesiones en paralelo, y los agent teams son sesiones que se hablan entre sí. Un subagente es una sola sesión delegada dentro de la tuya.

Escribe un subagente: name, description, tools y model

Defines un subagente como un archivo markdown con frontmatter bajo .claude/agents/ (a nivel proyecto) o ~/.claude/agents/ (a nivel usuario). Las claves del frontmatter son name, description, tools y model. Aquí un revisor de código de solo lectura que se ejecuta en Haiku:

---
name: code-reviewer
description: Revisa diffs en busca de bugs y fugas de secretos. Úsalo tras cambios de código.
tools: Read, Grep, Glob
model: haiku
---

Eres un revisor de código estricto. Lee solo el diff.
Reporta bugs de corrección y secretos escritos en el código.
No edites archivos: tu salida es una lista de hallazgos.

Fíjate en tools: Read, Grep, Glob: sin Edit ni Bash, este subagente físicamente no puede modificar nada ni ejecutar comandos. Esa restricción de herramientas es la garantía, no una sugerencia.

Cómo Claude delega automáticamente (y cómo enrutar el costo a Haiku)

Claude lee el description de cada subagente para decidir cuándo delegar automáticamente. Por eso el description debe decir QUÉ hace y CUÁNDO usarlo, en lenguaje de disparo (“Úsalo tras cambios de código”). Entre más claro el description, mejor enruta Claude sin que se lo pidas.

El model: haiku del ejemplo anterior es tu palanca de costo. Exploración, revisión y clasificación rara vez necesitan tu modelo más caro; mandarlas a Haiku baja el gasto sin tocar la calidad de tu hilo principal. Es la misma lógica de enrutamiento por modelo que cubro en ajustar Sonnet 5 por costo, calidad, effort y batch.

Hooks: ejecuta comandos de shell en los puntos del ciclo de vida

Los hooks son comandos de shell que defines tú (también pueden ser HTTP o prompts a un LLM) y que se ejecutan automáticamente en puntos del ciclo de vida. A diferencia de una instrucción en CLAUDE.md, un hook lo ejecuta el harness, no el modelo, así que es determinista: siempre se ejecuta.

Los eventos clave son PreToolUse (antes de que se ejecute una herramienta; puede BLOQUEAR), PostToolUse (después de que una herramienta tuvo éxito), UserPromptSubmit, SessionStart, SessionEnd, Stop, SubagentStart / SubagentStop, PreCompact / PostCompact y Notification. Para un command hook, los exit codes son la interfaz: 0 = éxito, 2 = error bloqueante (su stderr se le muestra a Claude), y cualquier otro = error no bloqueante.

La forma de settings.json: evento, matcher y command

Los hooks se configuran en JSON: ~/.claude/settings.json (todos los proyectos), .claude/settings.json (proyecto, se puede commitear) o .claude/settings.local.json (va en el .gitignore). La forma general es un evento que contiene un matcher y una lista de hooks:

{
  "hooks": {
    "<Event>": [
      {
        "matcher": "<filter>",
        "hooks": [
          { "type": "command", "command": "..." }
        ]
      }
    ]
  }
}

El matcher filtra por qué herramienta dispara el hook (por ejemplo Edit|Write o Bash). Todo esto está en la documentación de hooks.

Hook ejemplo 1: auto-formateo en PostToolUse Edit|Write

El caso más común: después de que Claude edita o escribe un archivo, se ejecuta tu formateador. Evento PostToolUse, "matcher": "Edit|Write":

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "pnpm exec prettier --write ." }
        ]
      }
    ]
  }
}

Como es PostToolUse, se ejecuta después de que la edición tuvo éxito, así que el archivo queda formateado sin que tú lo pidas ni Claude lo recuerde.

Hook ejemplo 2: bloquear rm -rf en PreToolUse Bash (exit code 2)

Una barrera real: bloquear comandos destructivos antes de que se ejecuten. Evento PreToolUse, "matcher": "Bash". Este script sale con 2 (error bloqueante) cuando detecta rm -rf, y su stderr le explica a Claude por qué se detuvo:

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

#!/usr/bin/env bash
# .claude/guard-rm.sh — lee el comando desde stdin (JSON) y bloquea rm -rf
input=$(cat)
if echo "$input" | grep -qE 'rm[[:space:]]+-[a-z]*r[a-z]*f'; then
  echo "Bloqueado: rm -rf está prohibido. Borra archivos de forma explícita." >&2
  exit 2
fi
exit 0

Con PreToolUse el hook se ejecuta ANTES del comando, así que el exit 2 impide de plano la ejecución. Ese es el patrón para convertir una política (“nunca borres recursivo”) en una barrera que el modelo no puede saltarse.

Skills y slash commands: empaqueta /review-pr para tu equipo

Las skills y slash commands empaquetan flujos repetibles que tu equipo comparte: /review-pr, /deploy-staging y comandos a la medida. En lugar de re-explicar tu proceso de revisión cada vez, lo escribes una vez y cualquiera en el repo escribe /review-pr y obtiene el mismo comportamiento. Es la diferencia entre un asistente que improvisa y un compañero con procedimientos.

Mantén el control: permisos y modo plan

Nada de esto significa soltar el control. Los permisos hacen que Claude Code pida autorización antes de actuar, con reglas de sintaxis clara como Bash(git *) (permite comandos git) o Edit(*.ts) (permite editar TypeScript). El modo plan es complementario: Claude te muestra el plan completo antes de tocar un solo archivo, tú lo revisas y ajustas, y solo entonces ejecuta. Úsalo para cambios grandes o código ajeno. Si estás comparando herramientas, en Claude Code vs Cursor contrasto justo este modelo de control.

Conecta tus propias herramientas con MCP

MCP (Model Context Protocol) conecta herramientas y datos externos: Google Drive, Jira, Slack o tu propio tooling interno. Un subagente con acceso a un servidor MCP de Jira puede leer tickets; uno conectado a tu base de datos puede consultarla, todo dentro de sus permisos acotados. Para el patrón completo revisa conectar un agente de IA a tus datos con MCP, y antes de exponer nada en producción, cómo asegurar servidores MCP.

Una configuración, todas las superficies

Lo mejor de configurar Claude Code así: todo esto —CLAUDE.md, tus settings.json y tus servidores MCP— se lleva entre superficies. Configuras una vez y el mismo comportamiento aparece en la terminal, en el IDE (VS Code / JetBrains), en la app de escritorio y en la web. Tu code-reviewer en Haiku y tu barrera de rm -rf no viven en una máquina: viven en el proyecto.

Tu checklist para configurar Claude Code como compañero

Empieza por lo más barato y sube: crea CLAUDE.md con tus estándares hoy mismo; agrega un subagente code-reviewer en Haiku para controlar costo; pon el hook de auto-formateo en PostToolUse Edit|Write y la barrera de rm -rf en PreToolUse Bash; y empaqueta tu primer slash command de equipo. Cada pieza es markdown o JSON versionado en el repo. Para seguir subiendo de nivel, mira cómo llevar todo esto a CI y modo headless en la guía de Claude Code en CI / headless, y para el fundamento de modelos y enrutamiento, cómo usar la API de Claude. Todo esto es parte del hub de agentes de IA.

Fuentes oficiales: subagentes, hooks y memoria en code.claude.com/docs.