Cómo empezar con loops

• En lugar de indicar cada prompt a un agente de coding, se está pasando a un patrón de operación de agentes que repite ciclos de trabajo hasta que se cumple una condición de detención
• El equipo de Claude Code clasifica los loops según cuatro criterios: cómo se disparan, cómo se detienen, qué primitives usan y para qué tipos de tareas son adecuados
• Los principales tipos de loops son cuatro: Turn-based, Goal-based, Time-based y Proactive
• No todas las tareas requieren loops complejos; conviene empezar por la solución más simple y aplicar patrones de forma selectiva
• La calidad de salida de los loops depende de los sistemas que los rodean, por lo que mantener la calidad del código y gestionar el uso de tokens es clave

---

Definición de loops y criterios de clasificación

• El equipo de Claude Code define un loop como un agente que repite un ciclo de trabajo hasta que se cumple una condición de detención
• Presenta cuatro criterios para clasificar loops
  • Cómo se dispara
  • Cómo se detiene
  • Qué primitive de Claude Code utiliza
  • Para qué tipo de tarea es más adecuado
• Los loops complejos no siempre son necesarios; se recomienda priorizar una solución simple y luego usar patrones de forma selectiva

Loops Turn-based

• Se disparan con un prompt del usuario y se detienen cuando Claude determina que la tarea está completa o necesita más contexto
• Son adecuados para tareas breves que no forman parte de procesos periódicos ni de una agenda
• Se gestionan mediante prompts concretos y usando skills para mejorar la verificación y reducir el número de turnos
• Todo prompt inicia un loop manual en el que el usuario dirige cada turno; esto se denomina agentic loop
  • Claude recopila contexto → ejecuta acciones → verifica la tarea → repite si es necesario → responde
  • Ejemplo: al pedir crear un botón de like, lee el código, lo edita, ejecuta pruebas y devuelve el resultado; luego el usuario revisa manualmente y escribe el siguiente prompt
• En la etapa de verificación, se pueden codificar procedimientos manuales en SKILL.md para ampliar el alcance de la autoverificación de Claude
  • Es necesario incluir herramientas o conectores para ver, medir o interactuar con el resultado
  • Cuanto más cuantitativa sea la verificación, más fácil será autoverificar

• Ejemplo de SKILL.md (verify-frontend-change)

  • Regla para verificar end-to-end un cambio de UI antes de declararlo completo
  • Prohibido reportar completado solo porque la edición fue exitosa; debe verificarse como lo haría un revisor humano
    • Iniciar el servidor de dev y abrir en el navegador la página editada
    • Manipular directamente los elementos modificados (hacer clic en botones, inputs, toggles), confirmar cambios de estado y tomar capturas de antes/después
    • Confirmar cero errores o advertencias nuevos en la consola del navegador
    • Ejecutar un trace de performance con Chrome Devtools MCP y auditar Core Web Vitals
  • Si algún paso falla, corregir y volver a ejecutar desde el paso 1; no devolver un estado de verificación parcial

Loops Goal-based (/goal)

• Se disparan con un prompt manual en tiempo real y se detienen al alcanzar el objetivo o llegar al número máximo de turnos
• Son adecuados para tareas con criterios de finalización verificables
• Se gestionan con criterios de completado concretos y un límite explícito de turnos, por ejemplo “detener después de 5 intentos”
• En tareas complejas para las que un solo turno no alcanza, el agente mejora su desempeño al iterar (iterate)
• Al definir el estado de completado con /goal, Claude no se detiene antes de tiempo juzgando por sí mismo que está “suficientemente bien”
  • Cada vez que Claude intenta detenerse, un modelo evaluador verifica las condiciones y lo hace retrabajar hasta alcanzar el objetivo o llegar al número de turnos especificado
  • Criterios determinísticos, como la cantidad de tests aprobados o un umbral específico de puntaje, funcionan bien
• Ejemplo
  • /goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

Loops Time-based (/loop y /schedule)

• Se disparan en un intervalo de tiempo especificado y se detienen cuando el usuario cancela o la tarea se completa (merge de PR, cola vacía)
• Son adecuados para tareas repetitivas o interfaces con entornos y sistemas externos
• Se gestionan configurando intervalos largos o con reacciones basadas en eventos en lugar de tiempo
• Algunas tareas agentic son repetitivas: la tarea es la misma y solo cambia la entrada, por ejemplo resumir mensajes de Slack cada mañana
• Las tareas que dependen de sistemas externos se integran revisando en cada intervalo y reaccionando a cambios, por ejemplo PRs donde aparecen code reviews o fallas de CI
• /loop vuelve a ejecutar el prompt en cada intervalo
  • /loop 5m check my PR, address review comments, and fix failing CI
• /loop se ejecuta en la computadora del usuario y se interrumpe al cerrarse; con /schedule se puede crear una routine y moverla a la nube

Loops Proactive

• Se disparan por eventos o schedules, sin intervención humana en tiempo real
• Cada tarea termina al alcanzar su objetivo; la routine en sí se ejecuta hasta que el usuario la desactiva
• Son adecuados para flujos de trabajo repetitivos y bien definidos, como reportes de bugs, clasificación de issues, migraciones y upgrades de dependencias
• Se gestionan ruteando la routine a modelos más pequeños y rápidos, y usando el modelo más potente solo en las partes que requieren juicio
• Combinando las primitives anteriores con auto mode, dynamic workflows (research preview), etc., se construyen loops de larga ejecución

• Ejemplo de configuración para procesar feedback

  • Ejecutar una routine para revisar reportes nuevos con /schedule (research preview)
  • Definir el completado con /goal y documentar el método de verificación con skills
  • Orquestar agentes de clasificación, corrección y revisión para cada reporte con Dynamic workflows
  • Ejecutar la routine con Auto mode, sin confirmar permisos
  • Ejemplo de prompt integrado: /schedule every hour: check the project-feedback channel for bug reports. /goal: don't stop until every report found this run is triaged, actioned, and responded to. When fixing a bug, use a workflow to explore three solutions in parallel worktrees and have a judge adversarially review them.

Mantener la calidad del código

• La calidad de salida de los loops depende de los sistemas que los rodean, por lo que el diseño del sistema es importante
• Mantener limpio el codebase: Claude sigue los patrones y convenciones del codebase existente
• Proveer medios de autoverificación: codificar en skills los criterios del equipo sobre qué es un “buen estado”
• Facilitar el acceso a la documentación: la documentación de frameworks y librerías contiene best practices actualizadas
• Usar un segundo agente para code review: un revisor con contexto nuevo tiene menos sesgos y no se ve influido por el razonamiento del agente principal; usar el skill integrado /code-review o Code Review para Github
• Cuando un resultado individual no cumple el estándar, no limitarse a corregir el issue puntual: codificar mejoras para mejorar el sistema en sí

Gestionar el uso de tokens

• Los loops deben tener límites claros y aplicar los siguientes principios
• Elegir la primitive y el modelo adecuados: para tareas pequeñas no hacen falta múltiples agentes ni loops; algunas tareas pueden usar modelos más baratos y rápidos
• Definir criterios claros de éxito y detención: concretar el estado de completado para no llegar demasiado pronto a una salida anticipada
• Hacer un piloto antes de ejecutar a gran escala: dynamic workflows puede crear cientos de agentes; medir primero el uso en un alcance pequeño
• Usar scripts para tareas determinísticas: ejecutar un script es más barato que razonar los pasos; por ejemplo, un PDF skill puede proveer un script para completar formularios y ejecutarlo, en lugar de regenerar código cada vez
• No ejecutar routines más de lo necesario: ajustar el intervalo a la frecuencia de cambios de lo que se está monitoreando
• Revisar el uso: /usage analiza el uso por skills, subagents y MCPs; /goal sin argumentos muestra el número de turnos y el uso de tokens actuales; /workflows muestra el uso de tokens de cada agente y permite detenerlos en cualquier momento

Cómo empezar

• Resumen por tipo de loop
  • Turn-based: delega la verificación (check), úsalo para exploración y decisiones, y aprovecha skills de verificación personalizados
  • Goal-based: delega la condición de detención, úsalo cuando conoces el estado de completado y aprovecha /goal
  • Time-based: delega el disparador, úsalo cuando el trabajo llega por schedule desde fuera del proyecto, y aprovecha /loop y /schedule
  • Proactive: delega el prompt, úsalo para tareas repetitivas y bien definidas, y aprovecha todo lo anterior junto con dynamic workflows
• Para empezar, mira el trabajo que ya haces y elige una tarea en la que tú seas el cuello de botella; luego determina qué partes se pueden delegar
  • ¿Puedes escribir checks de verificación?
  • ¿El objetivo es lo suficientemente claro?
  • ¿La tarea llega por schedule?
• Cuando surja una idea, ejecuta un loop y observa dónde se atasca o se ejecuta en exceso; no temas mejorarlo iterativamente