Subagents, hooks, slash commands y tareas recurrentes: pon Claude Code en piloto automático y multiplica tu productividad.
Aprende a delegar tareas complejas a subagentes paralelos y multiplica la capacidad de Claude Code sin aumentar el tiempo de espera.
Un subagent es una instancia de Claude Code que el agente principal inicia para ejecutar una tarea específica de forma aislada. Recibe un prompt bien definido, trabaja de forma independiente y devuelve el resultado resumido al orquestador.
Con subagents paralelizas el trabajo: mientras uno investiga la documentación, otro escribe pruebas y un tercero revisa el código. Lo que tomaría horas en serie ocurre en minutos.
No todas las tareas merecen un subagent. Delegar tiene sentido cuando la tarea es independiente, tiene un alcance claro y el orquestador puede consumir el resultado de forma atómica.
Delegar de forma incorrecta aumenta el costo sin aportar beneficios. Saber cuándo delegar marca la diferencia entre una automatización eficiente y un exceso de trabajo innecesario.
Fan-out es el patrón en el que un orquestador activa N subagentes simultáneamente, cada uno resolviendo una parte del problema. Los resultados se recopilan e integran al final.
Fan-out es el patrón de automatización más potente con Claude Code. Las investigaciones que tomarían 1 hora en serie se completan en minutos al paralelizarlas con 4-8 subagentes.
Claude Code admite distintos perfiles de subagent: el tipo Explore se enfoca en leer y analizar (sin escribir); General puede ejecutar cualquier herramienta. La elección determina los permisos y el riesgo.
Usar el tipo incorrecto de subagent puede crear riesgos de seguridad (un agente de investigación con permiso de escritura) o limitar la funcionalidad (un agente de codificación sin permiso de exec).
El resultado de un subagent vuelve al orquestador como texto comprimido: un resumen de lo que se hizo, no el log completo de ejecución. Esto preserva el contexto del agente principal.
Entender cómo vuelve el resultado ayuda a formular mejores prompts: especificar el formato de salida esperado (JSON, markdown, lista) garantiza que el orquestador consuma el resultado sin tener que rehacer el trabajo.
Cada subagent consume tokens: el prompt de instrucción + la ejecución + el resultado. Con varios subagents en paralelo, el costo puede escalar rápidamente si no hay control.
Una automatización mal planificada puede costar más que el trabajo manual equivalente. Calcular el ROI antes de implementar subagents es una práctica profesional esencial.
Configura hooks de eventos para automatizar acciones antes y después de cada herramienta: lint, seguridad e inyección de contexto sin tocar el código del agente.
Los hooks son scripts externos que ejecuta el harness en momentos específicos del ciclo de vida del agente: antes de una herramienta (PreToolUse), después (PostToolUse), al iniciar una sesión (SessionStart) o al detenerse (Stop).
Con hooks agregas comportamiento sin modificar el prompt ni el código del agente. Es la forma más limpia de imponer políticas: lint siempre se ejecuta, los comandos prohibidos se bloquean automáticamente.
Los hooks se configuran en la clave hooks del archivo settings.json (global en ~/.claude/ o local en .claude/). Cada hook es un objeto con evento, matcher de herramienta y comando shell.
La configuración declarativa en settings.json permite versionar los hooks junto con el proyecto. Equipos enteros heredan las políticas automáticamente, sin onboarding manual.
Un hook PreToolUse puede devolver un código de salida distinto de cero para cancelar la herramienta antes de ejecutarla. Esto permite crear listas negras de comandos — por ejemplo, bloquear git push --force.
Comandos destructivos como rm -rf o un force push en main pueden causar daños irreversibles. Un hook de bloqueo es la última línea de defensa.
Un hook PostToolUse puede ejecutar lint o formato automáticamente cada vez que el agente guarda un archivo. El output de lint se inyecta de nuevo en el contexto, lo que permite que el agente corrija los errores en la siguiente iteración.
Sin lint automático, el agente puede generar código con errores de formato que solo aparecen en CI. Con el hook, cada guardado produce código limpio: un ciclo de retroalimentación instantáneo.
El hook SessionStart se ejecuta cuando comienza una nueva sesión. Su salida se inyecta como mensaje inicial en el contexto: es ideal para cargar metadatos del proyecto, la rama actual, variables de entorno o recuerdos relevantes.
En lugar de repetir el estado del proyecto en cada nuevo prompt, SessionStart lo inyecta automáticamente. El agente empieza cada sesión con el contexto necesario: menos tokens consumidos y más enfoque en el trabajo.
De forma predeterminada, si un hook falla (timeout, error de script), el harness continúa la ejecución: comportamiento "fail-open". En hooks de seguridad críticos, puedes configurar fail-closed para detenerlo todo.
Confiar demasiado en fail-open puede dejar brechas de seguridad. Entender el modelo de fallos de los hooks permite diseñar sistemas más robustos, donde las políticas críticas nunca se ignoran silenciosamente.
Crea atajos reutilizables y pipelines deterministas que orquestan múltiples agentes en secuencia o en paralelo con un solo comando.
Los comandos slash son atajos de texto que se expanden en prompts completos. Al escribir /review en Claude Code, el harness expande a un prompt de revisión de código preconfigurado.
En lugar de reescribir el mismo prompt largo una y otra vez, escribes 3 caracteres y obtienes total consistencia. Equipos enteros usan los mismos patrones sin memorizar instrucciones complejas.
Los comandos personalizados se definen como archivos .md dentro de la carpeta .claude/commands/. El nombre del archivo se convierte en el comando. El contenido es el prompt que se expandirá.
Cada proyecto tiene necesidades únicas. Un proyecto React puede tener /component, vale la pena crear un comando slash. Si vas a hacer /migrate. Personalizar es parte de la configuración profesional.
Un workflow determinista es una secuencia predefinida de pasos — cada paso puede ser un agente, un comando shell o una transformación de datos. El resultado de un paso alimenta el siguiente, sin variaciones aleatorias.
Cuando el proceso debe ser auditable y reproducible (CI/CD, releases, revisiones obligatorias), la determinación vale más que la creatividad. Los workflows garantizan que cada paso ocurra siempre.
Pipeline: pasos encadenados en los que la salida de A es la entrada de B. Paralelo: varios agentes que se ejecutan al mismo tiempo sin depender unos de otros. Muchos workflows combinan ambos patrones.
Elegir el patrón equivocado puede duplicar el tiempo de ejecución (cuando debería paralelizarse) o producir resultados inconsistentes (cuando debería serializarse). El diseño del workflow es tan importante como el contenido.
Los workflows son más adecuados cuando la tarea se repite con frecuencia, involucra varios agentes o necesita auditabilidad. Las tareas únicas y creativas se resuelven mejor con prompts libres.
Diseñar workflows demasiado complejos para tareas simples es un desperdicio. Diseñarlos de forma insuficiente para tareas críticas es un riesgo. Saber cuál es el punto justo es la habilidad más valiosa en automatización.
Un metaagente (u orquestador de nivel superior) puede invocar workflows completos como subtareas. Esto crea una jerarquía: orquestador → workflow → subagents — cada nivel con responsabilidades bien definidas.
En proyectos grandes, un solo agente monolítico se pierde entre tanta complejidad. La jerarquía de orquestadores divide el problema en capas manejables: cada capa está bien probada y se puede reemplazar.
Programa agentes para que se ejecuten en intervalos definidos: revisiones diarias, informes automáticos y monitoreo continuo sin intervención humana.
Cron permite programar tareas para que se ejecuten en horarios específicos (diariamente, semanalmente, cada hora). Claude Code se integra con cron mediante la skill /schedule para crear rutinas de agente.
Las tareas recurrentes son la mayor pérdida de tiempo para los desarrolladores. Code review diario, actualización de dependencias, informe de métricas — todo puede ejecutarse sin intervención humana.
El comando /loop repite una tarea a intervalos definidos mientras la sesión está activa. Es ideal para consultar el estado, monitorear una compilación u observar continuamente un sistema.
/loop es más simple que cron para tareas de corta duración. No requiere configurar infraestructura: se ejecuta en la sesión actual y se detiene cuando cierras la terminal.
Los agentes remotos se ejecutan en la infraestructura de Claude sin necesidad de tener una terminal local abierta. Se activan por eventos (webhook, cron) y funcionan de forma completamente autónoma.
Los agentes remotos son la frontera entre la automatización local y la automatización en producción. Cuando no quieres (ni puedes) tener una laptop encendida las 24 h para ejecutar tareas, los agentes remotos son la solución.
Un agente de revisión diaria se ejecuta mediante cron todos los días a las 9h, analiza el código confirmado el día anterior, genera un informe de calidad y lo envía como notificación o lo guarda en un archivo.
La revisión automática del código no sustituye a la revisión humana, pero detecta el 80% de los errores mecánicos antes de la revisión humana. Quien revisa se enfoca en lo que importa: arquitectura y lógica de negocio.
Los agentes asíncronos no devuelven resultados de inmediato. El output puede recopilarse mediante PushNotification (webhook), un archivo generado o polling con Monitor, según el mecanismo de entrega configurado.
La automatización sin observabilidad es automatización a ciegas. Saber dónde y cómo llega el resultado es fundamental para confiar en la automatización y para depurar cuando algo sale mal a las 3 de la mañana.
Los agentes recurrentes acumulan costos con el tiempo. La idempotencia garantiza que ejecutar el agente dos veces produzca el mismo resultado, algo crucial cuando los fallos llevan a volver a ejecutarlo.
Una tarea cron que falla y se vuelve a ejecutar 5× puede crear 5 PR idénticos o cobrar 5× el costo esperado. La idempotencia no es un detalle — es un requisito de producción.