{"content_id":"z9qcc6lzi3","slug":"claude-code-loop-engineering-guide","locale":"es","schema_type":"TechArticle","category":"tutorial","category_name":"Tutorial","title":"Claude Guía de Code Loop Engineering: 4 tipos de bucles y diseño seguro de la automatización","summary":"⁣El bucle del código INJX12⁣ es una estructura de control que hace que el agente repita los procesos de observación, acción y verificación hasta que se cumplan las condiciones de finalización. Se explican las diferencias entre los cuatro tipos de bucles, junto con métodos de diseño prácticos que incluyen la evidencia de verificación, la parada forzada, la idempedancia, el coste y el principio de privilegios mínimos.","author":{"name":"Equipo editorial de Injoys","url":"https://injoys.com/ko/about"},"key_points":["⁣El «Loop» de INJX12⁣ Code no es un bucle de código, sino una estructura de ejecución de agentes que repite el ciclo de observación, acción y verificación hasta que se cumple la condición de finalización.","El modo «por turnos» se encarga de los procedimientos de verificación; el modo «por objetivos», de la decisión de finalización; el modo «por tiempo», del momento de la reejecución; y el modo «proactivo» del inicio de la tarea y la orquestación, que se delegan al sistema.","Un buen bucle debe contar con condiciones de finalización medibles, pruebas de verificación externas, finalización forzada, idéntica repetibilidad y privilegios mínimos.","Dado que el modelo de evaluación `/goal` solo tiene en cuenta las pruebas que se desprenden de la conversación, es necesario informar claramente sobre el resultado de la prueba, el código de salida y el alcance de los cambios.","Las transformaciones deterministas deben procesarse mediante scripts, mientras que el flujo de trabajo dinámico y el uso de múltiples agentes solo deben aplicarse a tareas a gran escala que requieran un paralelismo real."],"content_markdown":"⁣El bucle de INJX12⁣ Code no es simplemente una función que permite ejecutar el modelo durante más tiempo. La clave reside en colocar **un disparador (Trigger), un verificador (Verifier), una condición de éxito (Success condition), una parada forzada (Hard stop) y un límite de permisos (Permission boundary)** alrededor de un agente de IA que actúa de forma probabilística, con el fin de convertir las tareas repetitivas en un sistema controlable. Este artículo resume de un solo vistazo las diferencias entre los bucles por turnos (Turn-based), basados en objetivos (Goal-based), basados en el tiempo (Time-based) y proactivos (Proactive Loop), así como los principios de diseño prácticos.\n\n## 1. ¿Qué es el «Loop» en Claude Code?\n\nEn este contexto, el «Loop» no se refiere a las sentencias `for` o `while` de los lenguajes de programación. El «bucle» que describe el equipo de Claude Code es una estructura de ejecución en la que el agente observa el estado actual, actúa, verifica el resultado y, a continuación, repite la tarea hasta que se cumplan las condiciones de finalización.\n\n```text\nInicio de la tarea\n  ↓\nAnálisis del estado y del código\n  ↓\nElaboración del plan\n  ↓\nModificación del código o ejecución de herramientas\n  ↓\nPruebas y verificación\n  ↓\n¿Se cumplen las condiciones de finalización?\n  ├─ No: siguiente iteración\n  └─ Sí: finalización e informe de resultados\n```\n\nA la hora de identificar un bucle, resultan útiles las siguientes cuatro preguntas.\n\n1. ¿Qué inicia la tarea?\n2. ¿Qué finaliza la tarea?\n3. ¿Qué función de Claude Code controla la repetición?\n4. ¿Para qué tipo de tareas es adecuado?\n\nNo es necesario convertir todas las tareas en bucles complejos. Para tareas en las que el resultado se comprueba de inmediato, como corregir un error tipográfico en un archivo o un simple cambio de nombre, es más eficaz utilizar un indicador de comando normal. Solo se debe optar por un bucle cuando realmente se requieran varias rondas de observación, modificación y verificación.\n\n## 2. Comparación de los cuatro tipos de bucles\n\n| Tipo | Condición de inicio | Condición de finalización | Función principal | Tareas adecuadas | Responsabilidad del usuario |\n|---|---|---|---|---|---|\n| Por turnos | Indicación del usuario | Cuando Claude considere que ha finalizado o necesite información adicional | Conversación general, habilidades, herramientas de prueba y navegador | Implementaciones y modificaciones breves y puntuales | Procedimiento de verificación repetitivo |\n| Basado en objetivos | El usuario especifica las condiciones de finalización | Cuando el modelo de evaluación confirma que se cumplen las condiciones o el usuario lo interrumpe | `/goal`, modo automático si es necesario | Tareas cuyo estado de finalización es medible, como pruebas, compilaciones y migraciones | Decisión de finalización |\n| Basado en el tiempo | Tiempo, intervalo o calendario especificados | El usuario lo cancela o finaliza una tarea externa | `/loop`, `/schedule` | Supervisión de PR, CI y despliegues; resúmenes periódicos; sondeo de estado | Momento de la próxima ejecución |\n| Proactivo | Calendario, API, eventos de GitHub, etc. | Cumplimiento de los objetivos de tareas individuales, desactivación de rutinas | Rutinas, `/goal`, habilidades, flujos de trabajo dinámicos, modo automático | Clasificación de incidencias, gestión de errores, migraciones a gran escala y otras tareas continuas | Detección de tareas, ejecución de indicaciones, orquestación |\n\nLa clave de esta clasificación no es «cuán inteligente es la IA», sino **qué responsabilidad de control cede la persona al sistema**. En el modo «Turn-based», la persona crea el siguiente prompt; en el modo «Goal-based», delega la decisión de si la tarea está completada; y en el modo «Time-based», delega el momento de la reejecución. En la etapa «Proactive», la responsabilidad de detectar la aparición de una tarea y ejecutar el prompt adecuado pasa al sistema.\n\n## 3. Bucle por turnos: se cede el procedimiento de verificación\n\nEl bucle por turnos es la forma básica en la que la mayoría de los desarrolladores utilizan el código Claude.\n\n```text\nPersona → Claude → Persona → Claude\n```\n\nCuando el usuario realiza una solicitud, Claude busca los archivos pertinentes, modifica el código, lo prueba y comunica los resultados. Aunque internamente puedan producirse varias iteraciones de observación, acción y verificación, la autoridad para iniciar la siguiente tarea sigue recayendo en el usuario.\n\n### Modificar el código no es lo mismo que completar una funcionalidad\n\nAunque Claude informe de que «ha completado la implementación y las pruebas», en el producto real pueden persistir los siguientes problemas:\n\n- El estado no cambia al hacer clic en el botón.\n- Se produce un error en la consola del navegador.\n- El diseño para móviles se ve alterado.\n- Faltan atributos de accesibilidad.\n- Se superan las pruebas, pero el flujo real del navegador falla.\n- Se han modificado archivos que no guardan relación con el cambio.\n\nPor lo tanto, el criterio de finalización no debe ser «se ha modificado el código», sino «se ha verificado el funcionamiento mediante pruebas externas».\n\n### Reutilizar la verificación con `SKILL.md`\n\nSkill es un método que consiste en almacenar en `SKILL.md` las instrucciones y procedimientos que se utilizan repetidamente. Claude puede cargarlos automáticamente tras evaluar su relevancia, o bien se pueden ejecutar directamente mediante `/skill-name`. En lugar de incluir siempre los procedimientos operativos largos en `CLAUDE.md`, separarlos para que Skill se cargue solo cuando sea necesario permite utilizar el contexto de forma más eficiente.\n\n```markdown\n---\nname: verify-ui-change\ndescription: Verifica los cambios en la interfaz de usuario en el entorno de ejecución real antes de dar por finalizados dichos cambios.\n---\n\n# Verificación de cambios en la interfaz de usuario\n\n1. Ejecuta el servidor de desarrollo.\n2. Abre la pantalla modificada en el navegador.\n3. Manipula los nuevos controles de forma real.\n4. Comprueba si se produce el cambio de estado esperado.\n5. Comprueba si hay nuevos errores y advertencias en la consola del navegador.\n6. Comprueba la accesibilidad y los principales indicadores de rendimiento.\n7. Si falla, corrige el error y vuelve a verificar desde el principio.\n8. Informa de las pruebas realizadas, incluyendo los comandos ejecutados, los resultados y las capturas de pantalla.\n```\n\nUna buena «Skill» no contiene recomendaciones abstractas, sino una lista de comprobación viable. «Comprobar que `npm test` devuelva el código de salida 0» es una regla mucho más sólida que «revisar con más detenimiento».\n\n### Solidez de las pruebas de validación\n\n| Prueba | Fiabilidad | Motivo |\n|---|---:|---|\n| Explicación del agente: «Parece que funciona correctamente» | Baja | No es un resultado de ejecución, sino una mera deducción |\n| Diferencias de código y revisión estática | Media | Se ven los cambios, pero no se comprueba el comportamiento en tiempo de ejecución |\n| Salida real de la prueba y código de salida | Alta | Existen resultados externos reproducibles |\n| Interacción con el navegador, capturas de pantalla, resultados de la consola y del rendimiento | Muy alta | Verifica directamente el recorrido del usuario y el estado en tiempo de ejecución |\n| El agente de revisión independiente y la integración continua (CI) llegan a la misma conclusión | Muy alto | Reduce el sesgo de autoconfirmación del agente de implementación |\n\nClaude La documentación oficial de Code describe la habilidad «/run», que permite comprobar la aplicación en ejecución, y `/verify`, que verifica los cambios en el entorno de ejecución real. Si el método de ejecución del proyecto es complejo, es más seguro documentar en una Skill propia del equipo los comandos de inicio exactos, las variables de entorno y los procedimientos de preparación de datos.\n\n## 4. Bucle basado en objetivos: delega la decisión de finalización\n\nEn el bucle basado en objetivos, el usuario no tiene que decidir cada vez si «se debe realizar la tarea una vez más». El usuario define el estado de finalización y Claude continúa con varios turnos hasta que se cumplan dichas condiciones.\n\n```text\nEl usuario especifica el objetivo\n  ↓\nTurno de trabajo de Claude\n  ↓\nUn modelo de evaluación independiente comprueba la condición de finalización\n  ├─ No cumplida: se transmite el motivo al siguiente turno\n  └─ Cumplida: finalización del objetivo\n```\n\n`/goal` está documentado para su uso en Claude Code v2.1.139 o superior. Solo se puede activar un objetivo por sesión.\n\n### Lo que ve realmente el modelo de evaluación\n\nAl finalizar cada turno, un modelo pequeño y rápido independiente analiza las condiciones de finalización y el contenido de la conversación para determinar si se ha «cumplido» o «no se ha cumplido». La configuración predeterminada es un modelo de evaluación de la familia Haiku. Una limitación importante es que el modelo de evaluación no lee los archivos directamente ni ejecuta pruebas por separado.\n\nPor lo tanto, el Claude que ha realizado la tarea debe dejar claramente constancia de las siguientes pruebas en la conversación:\n\n- Los comandos ejecutados\n- El número de pruebas y los resultados (superadas o fallidas)\n- El código de salida\n- El resultado de la compilación\n- La lista de archivos modificados\n- Las causas de los fallos restantes\n- Resultados que confirmen que se han respetado las restricciones de alcance\n\nEl modelo de evaluación no juzga «qué ocurrió realmente», sino «qué pruebas se han revelado en la conversación».\n\n### Los cuatro elementos de un buen «Goal»\n\nUn buen «Goal» incluye los cuatro elementos siguientes:\n\n1. **Condiciones de éxito medibles**: superación de pruebas, éxito de la compilación, vaciado de la cola, consecución del umbral de puntuación\n2. **Método de verificación**: especificar con qué comando o herramienta se demostrará el éxito\n3. **Restricciones del alcance de las modificaciones**: directorios modificables, archivos prohibidos, efectos secundarios permitidos\n4. **Condiciones de finalización forzada**: número máximo de turnos, tiempo máximo, número de fallos consecutivos; interrupción en caso de error de permisos\n\n```text\n/goal: todas las pruebas y lints relacionadas con auth deben superarse,\ny git diff solo debe incluir src/auth y los archivos de prueba relacionados.\nEn cada turno se informará del resultado de la ejecución y del código de salida.\nSi se alcanza un máximo de 12 turnos o 45 minutos, se interrumpirá el proceso y se resolverán los fallos restantes.\n```\n\nLa condición de finalización clave de `/goal` en sí misma es la determinación de éxito del modelo de evaluación o el comando `/goal clear` del usuario. Para imponer un límite de turnos o de tiempo, debe especificarse dentro de las condiciones de Goal.\n\n### Condiciones adecuadas y inadecuadas\n\n| Condiciones adecuadas | Condiciones inadecuadas |\n|---|---|\n| `npm test` finaliza con un código de salida 0 | Perfeccionar el código |\n| Se superan las 48 pruebas relacionadas con la autenticación | Se mejora la experiencia del usuario al máximo |\n| Todos los puntos de llamada a la API se cambian a la nueva interfaz y la compilación se realiza con éxito | Se refactoriza con una estructura mejor |\n| La cola de incidencias pendientes está vacía y se registra el resultado de cada incidencia | Se resuelven tantas incidencias como sea posible |\n\nLos objetivos ambiguos pueden finalizar demasiado pronto o dar lugar a un ciclo interminable de mejoras.\n\n### Comprobación del estado y suspensión\n\n- `/goal`: comprueba las condiciones activas, el tiempo de ejecución, el número de turnos de evaluación, el consumo de tokens y el motivo de la última evaluación\n- `/goal clear`: suspende el objetivo activo\n- Configuración de un nuevo objetivo: sustituye al objetivo existente\n- `--resume` o `--continue`: permite reanudar un objetivo inconcluso\n\nAunque las condiciones se mantienen al reanudar, el número de turnos, el tiempo y el límite de tokens pueden reiniciarse, por lo que es recomendable gestionar las paradas forzosas junto con los indicadores de rendimiento.\n\n### `/goal` y los permisos son independientes\n\n`/goal` solo inicia automáticamente el siguiente turno, pero no amplía los permisos de la herramienta. Si la escritura de archivos, los comandos de prueba o las operaciones de Git requieren autorización, es posible que se necesite dicha autorización incluso durante el Goal.\n\nPara la ejecución sin supervisión se puede utilizar el modo «Auto», pero este no es una función que «permita todas las herramientas incondicionalmente». El clasificador bloquea las operaciones que sean destructivas, difíciles de revertir o que tengan como objetivo elementos fuera de los límites de confianza, y las reglas explícitas `ask` y `deny` se aplican antes que el clasificador.\n\n## 5. Bucle basado en el tiempo: supera el momento de reejecución\n\nSi el bucle basado en objetivos aborda «cuándo detenerse», el bucle basado en el tiempo aborda «cuándo volver a ejecutarse». Es adecuado para tareas en las que el estado de un sistema externo cambia con el paso del tiempo.\n\n- Comprobar si hay nuevas revisiones en las PR\n- Comprobar si la CI o la implementación han finalizado\n- Comprobar el estado de las compilaciones prolongadas\n- Resumen diario de mensajes de Slack\n- Comprobar si hay nuevas entradas en la cola de incidencias\n\n### `/loop`: ejecución repetida dentro de la sesión actual\n\n```text\n/loop 10m Comprueba las PR actuales e incorpora los nuevos comentarios;\nsi hay alguna CI fallida, analiza la causa y corrígelo.\n```\n\nLas principales formas descritas en este documento son las siguientes.\n\n| Entrada | Acción |\n|---|---|\n| `/loop 5m \u003cprompt\u003e` | Ejecuta el prompt a intervalos fijos especificados |\n| `/loop \u003cprompt\u003e` | Claude selecciona el intervalo en cada repetición |\n| `/loop` | Ejecuta el Prompt de mantenimiento integrado o el archivo `loop.md` del proyecto |\n| `/loop 20m /review-pr 1234` | Reejecuta la Skill permitida a intervalos especificados |\n\n`/loop` depende de la sesión actual de Claude Code. El ordenador y la sesión deben estar en ejecución; si se inicia una nueva conversación, las tareas de la sesión se perderán. Las tareas pendientes se pueden recuperar con `--resume` o `--continue`, pero las tareas recurrentes caducan, por defecto, 7 días después de su creación. Tampoco se ejecutan de forma retroactiva todos los ciclos perdidos.\n\nDado que el programador de la sesión puede estar sujeto a fluctuaciones (jitter), puede que no sea adecuado para requisitos operativos que exijan una «ejecución puntual a la hora exacta».\n\n### `/schedule`: Rutina gestionada por Anthropic\n\n`/schedule` agrupa un Prompt, un Repository, un Connector y un Trigger para crear una rutina que se ejecuta en la infraestructura gestionada por Anthropic. Se puede ejecutar incluso si se cierra el portátil; en la documentación oficial se presenta como «Research Preview».\n\nLos triggers que admite una rutina son los siguientes:\n\n- Programación recurrente\n- Programación única en un momento futuro específico\n- Llamadas a API autenticadas\n- Eventos de pull request o lanzamiento en GitHub\n\nSe pueden vincular varios «Trigger» a una misma «Routine». Por ejemplo, se puede configurar una «Routine» de revisión de pull requests para que se ejecute todas las noches y, al mismo tiempo, responda al evento `pull_request.opened`.\n\n### Comparación entre `/loop` y `/schedule`\n\n| Categoría | `/loop` | Rutina `/schedule` |\n|---|---|---|\n| Lugar de ejecución | Ordenador y sesión actuales | Nube gestionada por Anthropic |\n| Ejecución tras el apagado del ordenador | Normalmente no es posible | Sí |\n| Se requiere una sesión abierta | Sí | No |\n| Archivos locales sin confirmar | Accesibles | No accesibles; se clona el repositorio de nuevo en cada ejecución |\n| Intervalo mínimo | 1 minuto según la documentación oficial | 1 hora según la documentación oficial |\n| Persistencia | Centrada en la sesión; las tareas recurrentes caducan a los 7 días | Rutina almacenada en la cuenta |\n| Solicitud de permisos | Hereda la política de la sesión actual | Ejecución autónoma sin autorización interactiva |\n| Uso adecuado | Supervisión de PR y despliegues breves | Automatización de operaciones continuas |\n\n### Cuándo es mejor un evento que un sondeo\n\nSi se comprueban cada minuto las PR en las que rara vez se producen cambios, la mayoría de las ejecuciones finalizarán sin realizar ninguna acción. Si un sistema externo puede enviar eventos, la siguiente estructura resulta más eficiente.\n\n```text\nFallo de CI o actualización de PR\n  ↓\nGitHub Trigger o API de Routine\n  ↓\nEjecución de Claude solo cuando sea necesario\n```\n\nEl diseño basado en eventos reduce los retrasos y minimiza las llamadas innecesarias al modelo y el consumo de tokens. Si el sondeo es inevitable, es recomendable aumentar el intervalo para adaptarlo a la frecuencia real de los cambios y aplicar un «backoff» cuando no se produzcan cambios durante un periodo prolongado.\n\n### Requisitos imprescindibles para las tareas basadas en el tiempo\n\n1. **Idéntica**: aunque se reciba el mismo evento varias veces, no deben producirse comentarios, PR ni implementaciones duplicados.\n2. **Estado de procesamiento**: deben registrarse el ID del último evento procesado, el SHA de la confirmación y el ID del comentario de revisión, entre otros.\n3. **Estado de finalización**: debe poder determinarse la finalización, por ejemplo, fusión o cierre de una solicitud de incorporación de cambios, cola vacía, éxito o reversión de una implementación.\n4. **Ámbito de escritura**: deben limitarse los efectos secundarios, como permitir comentarios, prohibir la fusión o permitir el push únicamente en la rama `claude/*`.\n5. **Gestión de fallos**: se necesitan reglas de reintento y escalación en caso de fallos en servicios externos, caducidad de la autenticación, límite de frecuencia o falta de permisos.\n\n## 6. Proactive Loop: va más allá de la detección y la orquestación de tareas\n\nProactive Loop no es un simple comando, sino una arquitectura de automatización continua que combina varias funciones.\n\n```text\nDesencadenante\n+ Objetivo\n+ Habilidades\n+ Flujo de trabajo dinámico\n+ Modo automático\n+ Repositorio, conector, navegador y herramientas de CI\n```\n\nLas nuevas tareas se detectan, procesan, verifican y se informan de los resultados sin que una persona tenga que introducir comandos en tiempo real.\n\n### Ejemplo: gestión automática de comentarios sobre errores\n\n```text\nRecepción de incidencias de GitHub o comentarios de Slack\n  ↓\nClasificación por duplicados, prioridad y reproducibilidad\n  ↓\nCreación de pruebas de reproducibilidad\n  ↓\nBúsqueda de posibles soluciones\n  ↓\nImplementación de la solución elegida\n  ↓\nUn agente de revisión independiente busca contraejemplos\n  ↓\nVerificación de pruebas, compilación y seguridad\n  ↓\nBorrador de PR e informe de resultados\n```\n\nLas responsabilidades de cada componente son las siguientes.\n\n| Componente | Responsabilidad |\n|---|---|\n| Trigger o `/schedule` | Determinar el momento de iniciar una nueva tarea |\n| `/goal` | Definir qué se considera completado en esta ejecución |\n| Skill | Estandarización de los procedimientos de reproducción, implementación, verificación y presentación de informes |\n| Flujo de trabajo dinámico | Ejecución en paralelo de múltiples subagentes y ramificación condicional |\n| Modo automático | Ejecución de llamadas a herramientas permitidas sin espera de autorización |\n| Política de permisos | Establecer el alcance de lo prohibido, lo autorizado y lo permitido automáticamente |\n\n### Flujo de trabajo dinámico y árbol de trabajo\n\nEl flujo de trabajo dinámico es una estructura en la que el tiempo de ejecución ejecuta un script de orquestación en JavaScript escrito por Claude. En una llamada a un subagente normal, Claude selecciona el siguiente agente en cada turno, pero en el flujo de trabajo, los bucles, el procesamiento en paralelo, las ramificaciones y el almacenamiento de resultados intermedios se trasladan al script.\n\n```text\nScript de flujo de trabajo\n  ├─ Agente A: Análisis de requisitos\n  ├─ Agente B: Diseño de pruebas\n  ├─ Agente C: Búsqueda de opciones de implementación\n  ├─ Agente D: Revisión de seguridad\n  └─ Juez: Comparación basada en pruebas\n```\n\nDado que los resultados intermedios se guardan en variables del script y no en el contexto de la conversación principal, es posible organizar tareas a gran escala de forma más reproducible. La documentación actual especifica un límite de tiempo de ejecución de un máximo de 16 agentes simultáneos y 1.000 agentes por ejecución, aunque estas restricciones pueden cambiar durante la fase de vista previa del producto.\n\nSi es necesario probar varias opciones de implementación al mismo tiempo, se puede separar el espacio de trabajo mediante un «Git Worktree».\n\n```text\nrepo/\nworktree-solution-a/\nworktree-solution-b/\nworktree-solution-c/\n```\n\nSi cada agente trabaja en una rama y un directorio independientes, se pueden reducir los problemas derivados de la sobrescritura simultánea de los mismos archivos. El agente evaluador debe comparar las opciones basándose en el cumplimiento de los requisitos, los resultados de las pruebas, el riesgo de regresión, el alcance de los cambios, la complejidad, el rendimiento, la seguridad y la coherencia con la arquitectura existente.\n\n### No siempre es mejor contar con más agentes\n\nSi solo se aumenta el número de agentes en tareas que no admiten paralelismo, se incrementan los costes y los retrasos. Además, si varios agentes comparten la misma suposición errónea, los errores pueden propagarse.\n\nLos casos en los que un flujo de trabajo dinámico resulta adecuado son los siguientes:\n\n- Migraciones en las que se aplica la misma transformación a cientos de archivos\n- Auditorías de seguridad y calidad de todo el código fuente\n- Comparación de planes desde múltiples perspectivas independientes\n- Investigaciones en las que es necesario dividir el procesamiento de muchos elementos y realizar verificaciones cruzadas\n- Tareas en las que resulta difícil incluir todos los resultados intermedios en el contexto de un solo agente\n\nPara la corrección de pequeños errores, la refactorización de un solo archivo o la incorporación de pruebas sencillas, es mejor utilizar un bucle por turnos (Turn-based Loop) normal o `/goal`.\n\n## 7. Sistema para mantener la calidad del código en el bucle\n\nLa calidad de los resultados del bucle depende en gran medida no solo del modelo en sí, sino también del sistema de verificación que lo rodea.\n\n### 7.1 Ordenar el código base\n\nClaude sigue fielmente los patrones del código existente. Si hay API obsoletas, implementaciones duplicadas, estructuras de pruebas poco claras, módulos gigantescos o reglas de gestión de excepciones incoherentes, Loop puede replicar rápidamente esos problemas.\n\nLos requisitos básicos son los siguientes:\n\n- Formateador y lint\n- Límites claros entre directorios y módulos\n- Pruebas unitarias, de integración y de extremo a extremo (E2E) fiables\n- Distinción entre las API en uso y las API obsoletas\n- Normas de desarrollo específicas para cada proyecto\n- Entornos de compilación y desarrollo reproducibles\n\n### 7.2 Crear una «Definición de «hecho»» por tipo de cambio\n\n| Tipo de cambio | Verificación mínima |\n|---|---|\n| API | Pruebas de contrato, compatibilidad con versiones anteriores, actualización de esquemas y ejemplos de documentación |\n| Frontend | Manipulación real del navegador, errores de consola, accesibilidad, pantalla responsiva |\n| Base de datos | Migración (adelantada o revertida), ámbito de bloqueo, plan de ejecución |\n| Dependencias | Compilación, pruebas de regresión clave, verificación de licencias y seguridad |\n| Infraestructura | Diferencias entre planes, privilegios mínimos, reversión, comprobación de exposición de información confidencial |\n\nEs preferible fijar estos criterios en Skills, Hooks, scripts y reglas de CI, en lugar de repetirlos extensamente en el Prompt cada vez.\n\n### 7.3 Proporcionar documentación actualizada y versiones precisas\n\nUn bucle puede repetir varias veces suposiciones erróneas. Debe facilitarse el acceso a la versión exacta utilizada en el proyecto, la documentación oficial, la documentación interna de arquitectura, las especificaciones de la API, la guía de migración y los ejemplos aprobados.\n\n### 7.4 Separar el agente de implementación del agente de revisión\n\nEl agente de implementación ya se ve influido por el diseño y los razonamientos ya seleccionados. El agente de revisión, en un nuevo contexto, puede plantear las siguientes preguntas de forma más independiente:\n\n- ¿Se han suavizado las pruebas para que se superen?\n- ¿Se han modificado archivos que quedan fuera del alcance?\n- ¿Se han violado los límites de seguridad?\n- ¿Se han omitido las pruebas de rutas de fallo y de valores límite?\n- ¿Se ha producido alguna regresión en las funcionalidades existentes?\n\nEs más eficaz redactar la indicación de revisión (Review Prompt) de la siguiente manera: «Busca contraejemplos partiendo de la hipótesis de que la implementación es errónea y adjunta pruebas de reproducción para cada observación», en lugar de «Resume los aspectos positivos».\n\n### 7.5 Vincular los fallos individuales a la mejora del sistema\n\nSi se repite el mismo error, no basta con corregir solo ese resultado concreto. Para evitar que ese tipo de fallo vuelva a producirse, hay que modificar uno de los siguientes aspectos:\n\n- Añadir pruebas de regresión\n- Reforzar los procedimientos de verificación de habilidades\n- Añadir reglas a `CLAUDE.md`\n- Añadir reglas de hook o lint\n- Añadir reglas de denegación de permisos\n- Reforzar las condiciones de finalización del objetivo\n- Complementar la lista de comprobación de revisión\n\nUna buena ingeniería de bucles no consiste en corregir un único fallo, sino en **crear un sistema en el que sea difícil que vuelva a producirse ese tipo de fallo**.\n\n## 8. Gestión de tokens y costes\n\nEl coste de un bucle puede aumentar considerablemente en comparación con el de un único prompt.\n\n```text\nCoste total ≈\nCoste del turno del agente principal\n+ Coste de evaluación del objetivo\n+ Coste de los subagentes\n+ Coste de repetición del flujo de trabajo\n+ Coste del contexto para leer los resultados de las herramientas\n+ Frecuencia de ejecución basada en el tiempo\n```\n\nAunque la facturación exacta varía en función del plan, el modelo y el proveedor, el principio que determina la estructura de costes es el mismo.\n\n### Principios prácticos para reducir costes\n\n1. **No utilices Loop para tareas pequeñas.** Las erratas, los cambios de nombre y los errores de tipo en un solo archivo se gestionan en un único turno.\n2. **Establece condiciones de éxito y límites estrictos (hard stop) al mismo tiempo.** Ten en cuenta el éxito, el número máximo de turnos, el tiempo máximo, los fallos consecutivos y los errores de permisos.\n3. **Prueba los flujos de trabajo a gran escala en un ámbito reducido.** Verifica los costes y la calidad con 5 archivos, un directorio o algunas incidencias antes de ampliar la prueba.\n4. **Las tareas deterministas se procesan mediante scripts.** Para la sustitución de AST, la conversión a JSON, el formateo y la generación de formularios fijos, los scripts probados resultan más económicos y reproducibles.\n5. **Ajusta el ciclo de sondeo a la frecuencia real de los cambios.** Utiliza disparadores de eventos siempre que sea posible.\n6. **Se observa el uso durante el proceso.** Se comprueba el uso de habilidades, subagentes, MCP, turnos y tokens en `/usage`, `/goal` y `/workflows`.\n7. **Si se repite el mismo error, no se siguen realizando reintentos.** Se establece un límite de fallos consecutivos y se escala a una persona.\n\n### El modelo y el esfuerzo son palancas diferentes\n\n- **El modelo** modifica la capacidad de inferencia básica y el alcance de los problemas que se pueden resolver.\n- **El esfuerzo** modifica el número de archivos que se leen, el número de herramientas que se utilizan, el alcance de la verificación y hasta qué punto se llevan a cabo las tareas de varias etapas.\n\nSi Claude ha comprobado todos los archivos y pruebas necesarios, pero sigue tomando decisiones erróneas, es posible que se necesite un modelo más potente. Por el contrario, si no ha leído algún archivo importante, se ha saltado alguna prueba o ha interrumpido la refactorización a mitad de camino, puede que sea más adecuado aumentar el esfuerzo.\n\n## 9. Permisos y límites de seguridad\n\nEl diseño más peligroso en el «Proactive Loop» es otorgar amplios permisos al agente y establecer condiciones de éxito y de interrupción poco estrictas.\n\nEl modo automático reduce las solicitudes de permisos generales, pero el clasificador puede bloquear las llamadas a herramientas que sean difíciles de revertir, destructivas o que tengan como objetivo elementos fuera de los límites de confianza. Además, los permisos explícitos `permissions.ask` y `permissions.deny` tienen prioridad sobre el modo automático.\n\n### Ejemplo de jerarquía de permisos\n\n| Nivel | Ejemplos |\n|---|---|\n| Aceptación automática | Lectura de código, pruebas, lint, compilación, análisis, creación de ramas `claude/*`, creación de borradores de PR |\n| Aprobación humana | Incorporación a la rama por defecto, despliegue en producción, aplicación de migraciones de base de datos, envío de mensajes a clientes externos |\n| Siempre prohibido | Push forzado, publicación de secretos, eliminación de datos operativos, elusión de permisos, eliminación de registros de auditoría |\n\nEs más seguro establecer reglas permanentes de `ask` y `deny` que decir una sola vez en una conversación «No hagas un push». Esto se debe a que las reglas de la conversación pueden debilitarse debido a la compresión del contexto o a cambios en la sesión.\n\nCloud Routine clona un nuevo repositorio en cada ejecución y funciona con los permisos de GitHub y del conector asociados. Se deben minimizar los siguientes ámbitos:\n\n- Repositorios y ramas accesibles\n- Dominios de red permitidos\n- Conectores que se van a utilizar\n- Variables de entorno y secretos\n- Permisos de escritura en sistemas externos\n- Alcance de la creación, el push y la fusión de PR\n\nEl estado «Finalización normal» en el historial de ejecuciones de la rutina puede significar que la sesión ha finalizado sin errores de infraestructura, pero no garantiza que se haya alcanzado el objetivo del trabajo. Es necesario revisar por separado el transcrito, las pruebas y el diff generado.\n\n## 10. Plantilla de diseño de bucles para proyectos de desarrollo\n\nEl siguiente código YAML no es sintaxis real del código Claude, sino una plantilla para la revisión del diseño.\n\n```yaml\ntrigger:\n  type: manual | interval | schedule | github_event | api_event\n\nscope:\n  repositories:\n    - target-repository\n  allowed_paths:\n    - src/**\n    - tests/**\n  prohibited_paths:\n    - production/**\n    - secrets/**\n\ntask:\n  objective: objetivo que se desea modificar o procesar\n  input: nueva incidencia, evento, archivo o estado\n\nverification:\n  commands:\n    - unit-test\n    - integration-test\n    - lint\n    - build\n  runtime_checks:\n    - browser-interaction\n    - console-errors\n    - accessibility\n  evidence:\n    - command-output\n    - exit-code\n    - test-summary\n    - screenshots\n\nsuccess:\n  condition: Estado de finalización que puede evaluarse como verdadero o falso\n\nstop:\n  max_turns: 12\n  max_duration_minutes: 45\n  max_consecutive_failures: 3\n  stop_on_permission_error: true\n  escalate_on_external_outage: true\n\nefectos secundarios:\n  clave_de_idempotencia: id_del_evento-o-sha_de_la_confirmación\n  permitir_envío_de_rama: claude/*\n  requerir_intervención_humana_para_la_fusión: true\n  requerir_intervención_humana_para_la_implementación: true\n\nrevisión:\n  agente_independiente: true\n  revisión_adversaria: true\n\nobservabilidad:\n  informar_sobre_el_progreso: true\n  informar_sobre_el_uso_de_tokens: true\n  informar_sobre_los_archivos_modificados: true\n  informar_sobre_los_fallos_restantes: true\n```\n\nLos elementos más importantes son los cinco siguientes, más que la propia frase del prompt.\n\n```text\nTrigger\nVerifier\nCondición de éxito\nParada forzada\nLímite de permisos\n```\n\n## 11. ¿Qué bucle se debe elegir?\n\n| Situación | Método recomendado |\n|---|---|\n| Tareas que concluyen con una única modificación y verificación | Turn-based |\n| Tareas que requieren varios intentos, pero cuyo estado de finalización es claro | `/goal` |\n| Tareas que requieren esperar brevemente el estado externo de CI, PR o implementación | `/loop` |\n| Tareas que deben ejecutarse de forma repetida incluso si se cierra el portátil | `/schedule` Routine |\n| Tareas que requieren una respuesta inmediata a eventos o alertas de GitHub | Rutina activada por eventos |\n| Tareas que requieren el procesamiento en paralelo y la verificación cruzada de cientos de elementos | Flujo de trabajo dinámico |\n| Conversiones en las que las reglas de entrada y salida son totalmente deterministas | Script o tarea de CI |\n\nEl orden de selección no debe basarse en «la funcionalidad más potente», sino en «la estructura de control más sencilla para alcanzar el objetivo».\n\n## 12. Orden de implementación seguro\n\n1. Elige una tarea que suponga un cuello de botella y que requiera comprobaciones repetitivas por parte de una persona.\n2. En primer lugar, crea un procedimiento de verificación mediante una Skill, un Script o un trabajo de CI.\n3. Estabiliza la calidad de la verificación en el modo por turnos.\n4. Si el estado de finalización es claro, añade `/goal`.\n5. Utiliza `/loop` solo cuando sea necesario esperar un estado externo.\n6. Si se requiere una ejecución prolongada, trasládalo a una rutina `/schedule`.\n7. Amplía a flujos de trabajo dinámicos y bucles proactivos solo después de haber verificado la idempedancia, los permisos y los costes.\n\n## 13. Malentendidos frecuentes\n\n| Malentendido | Interpretación correcta |\n|---|---|\n| Un «Loop» es una ejecución infinita | Es una estructura de repetición limitada que cuenta con condiciones de éxito y una parada forzada |\n| El informe de finalización del agente es una verificación | Se necesitan la salida de comandos externos, el código de salida y los resultados de tiempo de ejecución |\n| «/goal» concede automáticamente todos los permisos | Solo inicia automáticamente el siguiente turno; la política de permisos es independiente |\n| `/loop` es un programador de ejecución a largo plazo | Se centra en las sesiones y tiene una caducidad de 7 días, además de restricciones en el entorno de ejecución |\n| Cuantos más agentes haya, mejores serán los resultados | La paralelización solo tiene valor cuando las funciones, los puntos de vista y la verificación son diferentes |\n| Todas las tareas repetitivas deben realizarlas los LLM | Para las partes deterministas, los scripts son más económicos y ofrecen mayor reproducibilidad |\n\n## Conclusión\n\nLa ingeniería de bucles (Loop Engineering) no es una tecnología para mantener la IA en ejecución durante mucho tiempo, sino **el diseño de un sistema de control que permite que la IA detecte por sí misma sus errores, los corrija dentro de los límites de coste y se detenga ante situaciones de riesgo**.\n\nLos LLM destacan en la exploración, la inferencia, la implementación, el análisis de excepciones y la comparación de alternativas. El sistema debe encargarse del momento de ejecución, el alcance de los cambios, los métodos de verificación, los criterios de finalización, los límites de coste y los límites de autorización. Cuanto más clara sea esta distribución de funciones, más se acercará la automatización del código Claude a un sistema de desarrollo y operaciones reproducible y auditable, más allá de una simple herramienta de generación de código.","content_html":"\u003cp\u003e⁣El bucle de INJX12⁣ Code no es simplemente una función que permite ejecutar el modelo durante más tiempo. La clave reside en colocar \u003cstrong\u003eun disparador (Trigger), un verificador (Verifier), una condición de éxito (Success condition), una parada forzada (Hard stop) y un límite de permisos (Permission boundary)\u003c/strong\u003e alrededor de un agente de IA que actúa de forma probabilística, con el fin de convertir las tareas repetitivas en un sistema controlable. Este artículo resume de un solo vistazo las diferencias entre los bucles por turnos (Turn-based), basados en objetivos (Goal-based), basados en el tiempo (Time-based) y proactivos (Proactive Loop), así como los principios de diseño prácticos.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#1-qué-es-el-loop-en-claude-code\" class=\"anchor\" id=\"1-qué-es-el-loop-en-claude-code\"\u003e\u003c/a\u003e1. ¿Qué es el «Loop» en Claude Code?\u003c/h2\u003e\n\u003cp\u003eEn este contexto, el «Loop» no se refiere a las sentencias \u003ccode\u003efor\u003c/code\u003e o \u003ccode\u003ewhile\u003c/code\u003e de los lenguajes de programación. El «bucle» que describe el equipo de Claude Code es una estructura de ejecución en la que el agente observa el estado actual, actúa, verifica el resultado y, a continuación, repite la tarea hasta que se cumplan las condiciones de finalización.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eInicio de la tarea\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eAnálisis del estado y del código\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eElaboración del plan\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eModificación del código o ejecución de herramientas\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003ePruebas y verificación\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e¿Se cumplen las condiciones de finalización?\n\u003c/span\u003e\u003cspan\u003e  ├─ No: siguiente iteración\n\u003c/span\u003e\u003cspan\u003e  └─ Sí: finalización e informe de resultados\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eA la hora de identificar un bucle, resultan útiles las siguientes cuatro preguntas.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e¿Qué inicia la tarea?\u003c/li\u003e\n\u003cli\u003e¿Qué finaliza la tarea?\u003c/li\u003e\n\u003cli\u003e¿Qué función de Claude Code controla la repetición?\u003c/li\u003e\n\u003cli\u003e¿Para qué tipo de tareas es adecuado?\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eNo es necesario convertir todas las tareas en bucles complejos. Para tareas en las que el resultado se comprueba de inmediato, como corregir un error tipográfico en un archivo o un simple cambio de nombre, es más eficaz utilizar un indicador de comando normal. Solo se debe optar por un bucle cuando realmente se requieran varias rondas de observación, modificación y verificación.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#2-comparación-de-los-cuatro-tipos-de-bucles\" class=\"anchor\" id=\"2-comparación-de-los-cuatro-tipos-de-bucles\"\u003e\u003c/a\u003e2. Comparación de los cuatro tipos de bucles\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eTipo\u003c/th\u003e\n\u003cth\u003eCondición de inicio\u003c/th\u003e\n\u003cth\u003eCondición de finalización\u003c/th\u003e\n\u003cth\u003eFunción principal\u003c/th\u003e\n\u003cth\u003eTareas adecuadas\u003c/th\u003e\n\u003cth\u003eResponsabilidad del usuario\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003ePor turnos\u003c/td\u003e\n\u003ctd\u003eIndicación del usuario\u003c/td\u003e\n\u003ctd\u003eCuando Claude considere que ha finalizado o necesite información adicional\u003c/td\u003e\n\u003ctd\u003eConversación general, habilidades, herramientas de prueba y navegador\u003c/td\u003e\n\u003ctd\u003eImplementaciones y modificaciones breves y puntuales\u003c/td\u003e\n\u003ctd\u003eProcedimiento de verificación repetitivo\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eBasado en objetivos\u003c/td\u003e\n\u003ctd\u003eEl usuario especifica las condiciones de finalización\u003c/td\u003e\n\u003ctd\u003eCuando el modelo de evaluación confirma que se cumplen las condiciones o el usuario lo interrumpe\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e, modo automático si es necesario\u003c/td\u003e\n\u003ctd\u003eTareas cuyo estado de finalización es medible, como pruebas, compilaciones y migraciones\u003c/td\u003e\n\u003ctd\u003eDecisión de finalización\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eBasado en el tiempo\u003c/td\u003e\n\u003ctd\u003eTiempo, intervalo o calendario especificados\u003c/td\u003e\n\u003ctd\u003eEl usuario lo cancela o finaliza una tarea externa\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e, \u003ccode\u003e/schedule\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eSupervisión de PR, CI y despliegues; resúmenes periódicos; sondeo de estado\u003c/td\u003e\n\u003ctd\u003eMomento de la próxima ejecución\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eProactivo\u003c/td\u003e\n\u003ctd\u003eCalendario, API, eventos de GitHub, etc.\u003c/td\u003e\n\u003ctd\u003eCumplimiento de los objetivos de tareas individuales, desactivación de rutinas\u003c/td\u003e\n\u003ctd\u003eRutinas, \u003ccode\u003e/goal\u003c/code\u003e, habilidades, flujos de trabajo dinámicos, modo automático\u003c/td\u003e\n\u003ctd\u003eClasificación de incidencias, gestión de errores, migraciones a gran escala y otras tareas continuas\u003c/td\u003e\n\u003ctd\u003eDetección de tareas, ejecución de indicaciones, orquestación\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eLa clave de esta clasificación no es «cuán inteligente es la IA», sino \u003cstrong\u003equé responsabilidad de control cede la persona al sistema\u003c/strong\u003e. En el modo «Turn-based», la persona crea el siguiente prompt; en el modo «Goal-based», delega la decisión de si la tarea está completada; y en el modo «Time-based», delega el momento de la reejecución. En la etapa «Proactive», la responsabilidad de detectar la aparición de una tarea y ejecutar el prompt adecuado pasa al sistema.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#3-bucle-por-turnos-se-cede-el-procedimiento-de-verificación\" class=\"anchor\" id=\"3-bucle-por-turnos-se-cede-el-procedimiento-de-verificación\"\u003e\u003c/a\u003e3. Bucle por turnos: se cede el procedimiento de verificación\u003c/h2\u003e\n\u003cp\u003eEl bucle por turnos es la forma básica en la que la mayoría de los desarrolladores utilizan el código Claude.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003ePersona → Claude → Persona → Claude\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eCuando el usuario realiza una solicitud, Claude busca los archivos pertinentes, modifica el código, lo prueba y comunica los resultados. Aunque internamente puedan producirse varias iteraciones de observación, acción y verificación, la autoridad para iniciar la siguiente tarea sigue recayendo en el usuario.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#modificar-el-código-no-es-lo-mismo-que-completar-una-funcionalidad\" class=\"anchor\" id=\"modificar-el-código-no-es-lo-mismo-que-completar-una-funcionalidad\"\u003e\u003c/a\u003eModificar el código no es lo mismo que completar una funcionalidad\u003c/h3\u003e\n\u003cp\u003eAunque Claude informe de que «ha completado la implementación y las pruebas», en el producto real pueden persistir los siguientes problemas:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eEl estado no cambia al hacer clic en el botón.\u003c/li\u003e\n\u003cli\u003eSe produce un error en la consola del navegador.\u003c/li\u003e\n\u003cli\u003eEl diseño para móviles se ve alterado.\u003c/li\u003e\n\u003cli\u003eFaltan atributos de accesibilidad.\u003c/li\u003e\n\u003cli\u003eSe superan las pruebas, pero el flujo real del navegador falla.\u003c/li\u003e\n\u003cli\u003eSe han modificado archivos que no guardan relación con el cambio.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003ePor lo tanto, el criterio de finalización no debe ser «se ha modificado el código», sino «se ha verificado el funcionamiento mediante pruebas externas».\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#reutilizar-la-verificación-con-skillmd\" class=\"anchor\" id=\"reutilizar-la-verificación-con-skillmd\"\u003e\u003c/a\u003eReutilizar la verificación con \u003ccode\u003eSKILL.md\u003c/code\u003e\u003c/h3\u003e\n\u003cp\u003eSkill es un método que consiste en almacenar en \u003ccode\u003eSKILL.md\u003c/code\u003e las instrucciones y procedimientos que se utilizan repetidamente. Claude puede cargarlos automáticamente tras evaluar su relevancia, o bien se pueden ejecutar directamente mediante \u003ccode\u003e/skill-name\u003c/code\u003e. En lugar de incluir siempre los procedimientos operativos largos en \u003ccode\u003eCLAUDE.md\u003c/code\u003e, separarlos para que Skill se cargue solo cuando sea necesario permite utilizar el contexto de forma más eficiente.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e---\n\u003c/span\u003e\u003cspan\u003ename: verify-ui-change\n\u003c/span\u003e\u003cspan\u003edescription: Verifica los cambios en la interfaz de usuario en el entorno de ejecución real antes de dar por finalizados dichos cambios.\n\u003c/span\u003e\u003cspan\u003e---\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# Verificación de cambios en la interfaz de usuario\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e1. Ejecuta el servidor de desarrollo.\n\u003c/span\u003e\u003cspan\u003e2. Abre la pantalla modificada en el navegador.\n\u003c/span\u003e\u003cspan\u003e3. Manipula los nuevos controles de forma real.\n\u003c/span\u003e\u003cspan\u003e4. Comprueba si se produce el cambio de estado esperado.\n\u003c/span\u003e\u003cspan\u003e5. Comprueba si hay nuevos errores y advertencias en la consola del navegador.\n\u003c/span\u003e\u003cspan\u003e6. Comprueba la accesibilidad y los principales indicadores de rendimiento.\n\u003c/span\u003e\u003cspan\u003e7. Si falla, corrige el error y vuelve a verificar desde el principio.\n\u003c/span\u003e\u003cspan\u003e8. Informa de las pruebas realizadas, incluyendo los comandos ejecutados, los resultados y las capturas de pantalla.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eUna buena «Skill» no contiene recomendaciones abstractas, sino una lista de comprobación viable. «Comprobar que \u003ccode\u003enpm test\u003c/code\u003e devuelva el código de salida 0» es una regla mucho más sólida que «revisar con más detenimiento».\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#solidez-de-las-pruebas-de-validación\" class=\"anchor\" id=\"solidez-de-las-pruebas-de-validación\"\u003e\u003c/a\u003eSolidez de las pruebas de validación\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003ePrueba\u003c/th\u003e\n\u003cth\u003eFiabilidad\u003c/th\u003e\n\u003cth\u003eMotivo\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eExplicación del agente: «Parece que funciona correctamente»\u003c/td\u003e\n\u003ctd\u003eBaja\u003c/td\u003e\n\u003ctd\u003eNo es un resultado de ejecución, sino una mera deducción\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDiferencias de código y revisión estática\u003c/td\u003e\n\u003ctd\u003eMedia\u003c/td\u003e\n\u003ctd\u003eSe ven los cambios, pero no se comprueba el comportamiento en tiempo de ejecución\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSalida real de la prueba y código de salida\u003c/td\u003e\n\u003ctd\u003eAlta\u003c/td\u003e\n\u003ctd\u003eExisten resultados externos reproducibles\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eInteracción con el navegador, capturas de pantalla, resultados de la consola y del rendimiento\u003c/td\u003e\n\u003ctd\u003eMuy alta\u003c/td\u003e\n\u003ctd\u003eVerifica directamente el recorrido del usuario y el estado en tiempo de ejecución\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eEl agente de revisión independiente y la integración continua (CI) llegan a la misma conclusión\u003c/td\u003e\n\u003ctd\u003eMuy alto\u003c/td\u003e\n\u003ctd\u003eReduce el sesgo de autoconfirmación del agente de implementación\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eClaude La documentación oficial de Code describe la habilidad «/run», que permite comprobar la aplicación en ejecución, y \u003ccode\u003e/verify\u003c/code\u003e, que verifica los cambios en el entorno de ejecución real. Si el método de ejecución del proyecto es complejo, es más seguro documentar en una Skill propia del equipo los comandos de inicio exactos, las variables de entorno y los procedimientos de preparación de datos.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#4-bucle-basado-en-objetivos-delega-la-decisión-de-finalización\" class=\"anchor\" id=\"4-bucle-basado-en-objetivos-delega-la-decisión-de-finalización\"\u003e\u003c/a\u003e4. Bucle basado en objetivos: delega la decisión de finalización\u003c/h2\u003e\n\u003cp\u003eEn el bucle basado en objetivos, el usuario no tiene que decidir cada vez si «se debe realizar la tarea una vez más». El usuario define el estado de finalización y Claude continúa con varios turnos hasta que se cumplan dichas condiciones.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eEl usuario especifica el objetivo\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eTurno de trabajo de Claude\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eUn modelo de evaluación independiente comprueba la condición de finalización\n\u003c/span\u003e\u003cspan\u003e  ├─ No cumplida: se transmite el motivo al siguiente turno\n\u003c/span\u003e\u003cspan\u003e  └─ Cumplida: finalización del objetivo\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003ccode\u003e/goal\u003c/code\u003e está documentado para su uso en Claude Code v2.1.139 o superior. Solo se puede activar un objetivo por sesión.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#lo-que-ve-realmente-el-modelo-de-evaluación\" class=\"anchor\" id=\"lo-que-ve-realmente-el-modelo-de-evaluación\"\u003e\u003c/a\u003eLo que ve realmente el modelo de evaluación\u003c/h3\u003e\n\u003cp\u003eAl finalizar cada turno, un modelo pequeño y rápido independiente analiza las condiciones de finalización y el contenido de la conversación para determinar si se ha «cumplido» o «no se ha cumplido». La configuración predeterminada es un modelo de evaluación de la familia Haiku. Una limitación importante es que el modelo de evaluación no lee los archivos directamente ni ejecuta pruebas por separado.\u003c/p\u003e\n\u003cp\u003ePor lo tanto, el Claude que ha realizado la tarea debe dejar claramente constancia de las siguientes pruebas en la conversación:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eLos comandos ejecutados\u003c/li\u003e\n\u003cli\u003eEl número de pruebas y los resultados (superadas o fallidas)\u003c/li\u003e\n\u003cli\u003eEl código de salida\u003c/li\u003e\n\u003cli\u003eEl resultado de la compilación\u003c/li\u003e\n\u003cli\u003eLa lista de archivos modificados\u003c/li\u003e\n\u003cli\u003eLas causas de los fallos restantes\u003c/li\u003e\n\u003cli\u003eResultados que confirmen que se han respetado las restricciones de alcance\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eEl modelo de evaluación no juzga «qué ocurrió realmente», sino «qué pruebas se han revelado en la conversación».\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#los-cuatro-elementos-de-un-buen-goal\" class=\"anchor\" id=\"los-cuatro-elementos-de-un-buen-goal\"\u003e\u003c/a\u003eLos cuatro elementos de un buen «Goal»\u003c/h3\u003e\n\u003cp\u003eUn buen «Goal» incluye los cuatro elementos siguientes:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eCondiciones de éxito medibles\u003c/strong\u003e: superación de pruebas, éxito de la compilación, vaciado de la cola, consecución del umbral de puntuación\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMétodo de verificación\u003c/strong\u003e: especificar con qué comando o herramienta se demostrará el éxito\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRestricciones del alcance de las modificaciones\u003c/strong\u003e: directorios modificables, archivos prohibidos, efectos secundarios permitidos\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCondiciones de finalización forzada\u003c/strong\u003e: número máximo de turnos, tiempo máximo, número de fallos consecutivos; interrupción en caso de error de permisos\u003c/li\u003e\n\u003c/ol\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e/goal: todas las pruebas y lints relacionadas con auth deben superarse,\n\u003c/span\u003e\u003cspan\u003ey git diff solo debe incluir src/auth y los archivos de prueba relacionados.\n\u003c/span\u003e\u003cspan\u003eEn cada turno se informará del resultado de la ejecución y del código de salida.\n\u003c/span\u003e\u003cspan\u003eSi se alcanza un máximo de 12 turnos o 45 minutos, se interrumpirá el proceso y se resolverán los fallos restantes.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eLa condición de finalización clave de \u003ccode\u003e/goal\u003c/code\u003e en sí misma es la determinación de éxito del modelo de evaluación o el comando \u003ccode\u003e/goal clear\u003c/code\u003e del usuario. Para imponer un límite de turnos o de tiempo, debe especificarse dentro de las condiciones de Goal.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#condiciones-adecuadas-y-inadecuadas\" class=\"anchor\" id=\"condiciones-adecuadas-y-inadecuadas\"\u003e\u003c/a\u003eCondiciones adecuadas y inadecuadas\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eCondiciones adecuadas\u003c/th\u003e\n\u003cth\u003eCondiciones inadecuadas\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003enpm test\u003c/code\u003e finaliza con un código de salida 0\u003c/td\u003e\n\u003ctd\u003ePerfeccionar el código\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSe superan las 48 pruebas relacionadas con la autenticación\u003c/td\u003e\n\u003ctd\u003eSe mejora la experiencia del usuario al máximo\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTodos los puntos de llamada a la API se cambian a la nueva interfaz y la compilación se realiza con éxito\u003c/td\u003e\n\u003ctd\u003eSe refactoriza con una estructura mejor\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eLa cola de incidencias pendientes está vacía y se registra el resultado de cada incidencia\u003c/td\u003e\n\u003ctd\u003eSe resuelven tantas incidencias como sea posible\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eLos objetivos ambiguos pueden finalizar demasiado pronto o dar lugar a un ciclo interminable de mejoras.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#comprobación-del-estado-y-suspensión\" class=\"anchor\" id=\"comprobación-del-estado-y-suspensión\"\u003e\u003c/a\u003eComprobación del estado y suspensión\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003e/goal\u003c/code\u003e: comprueba las condiciones activas, el tiempo de ejecución, el número de turnos de evaluación, el consumo de tokens y el motivo de la última evaluación\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003e/goal clear\u003c/code\u003e: suspende el objetivo activo\u003c/li\u003e\n\u003cli\u003eConfiguración de un nuevo objetivo: sustituye al objetivo existente\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003e--resume\u003c/code\u003e o \u003ccode\u003e--continue\u003c/code\u003e: permite reanudar un objetivo inconcluso\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAunque las condiciones se mantienen al reanudar, el número de turnos, el tiempo y el límite de tokens pueden reiniciarse, por lo que es recomendable gestionar las paradas forzosas junto con los indicadores de rendimiento.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#goal-y-los-permisos-son-independientes\" class=\"anchor\" id=\"goal-y-los-permisos-son-independientes\"\u003e\u003c/a\u003e\u003ccode\u003e/goal\u003c/code\u003e y los permisos son independientes\u003c/h3\u003e\n\u003cp\u003e\u003ccode\u003e/goal\u003c/code\u003e solo inicia automáticamente el siguiente turno, pero no amplía los permisos de la herramienta. Si la escritura de archivos, los comandos de prueba o las operaciones de Git requieren autorización, es posible que se necesite dicha autorización incluso durante el Goal.\u003c/p\u003e\n\u003cp\u003ePara la ejecución sin supervisión se puede utilizar el modo «Auto», pero este no es una función que «permita todas las herramientas incondicionalmente». El clasificador bloquea las operaciones que sean destructivas, difíciles de revertir o que tengan como objetivo elementos fuera de los límites de confianza, y las reglas explícitas \u003ccode\u003eask\u003c/code\u003e y \u003ccode\u003edeny\u003c/code\u003e se aplican antes que el clasificador.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#5-bucle-basado-en-el-tiempo-supera-el-momento-de-reejecución\" class=\"anchor\" id=\"5-bucle-basado-en-el-tiempo-supera-el-momento-de-reejecución\"\u003e\u003c/a\u003e5. Bucle basado en el tiempo: supera el momento de reejecución\u003c/h2\u003e\n\u003cp\u003eSi el bucle basado en objetivos aborda «cuándo detenerse», el bucle basado en el tiempo aborda «cuándo volver a ejecutarse». Es adecuado para tareas en las que el estado de un sistema externo cambia con el paso del tiempo.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eComprobar si hay nuevas revisiones en las PR\u003c/li\u003e\n\u003cli\u003eComprobar si la CI o la implementación han finalizado\u003c/li\u003e\n\u003cli\u003eComprobar el estado de las compilaciones prolongadas\u003c/li\u003e\n\u003cli\u003eResumen diario de mensajes de Slack\u003c/li\u003e\n\u003cli\u003eComprobar si hay nuevas entradas en la cola de incidencias\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#loop-ejecución-repetida-dentro-de-la-sesión-actual\" class=\"anchor\" id=\"loop-ejecución-repetida-dentro-de-la-sesión-actual\"\u003e\u003c/a\u003e\u003ccode\u003e/loop\u003c/code\u003e: ejecución repetida dentro de la sesión actual\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e/loop 10m Comprueba las PR actuales e incorpora los nuevos comentarios;\n\u003c/span\u003e\u003cspan\u003esi hay alguna CI fallida, analiza la causa y corrígelo.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eLas principales formas descritas en este documento son las siguientes.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eEntrada\u003c/th\u003e\n\u003cth\u003eAcción\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop 5m \u0026lt;prompt\u0026gt;\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eEjecuta el prompt a intervalos fijos especificados\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop \u0026lt;prompt\u0026gt;\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eClaude selecciona el intervalo en cada repetición\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eEjecuta el Prompt de mantenimiento integrado o el archivo \u003ccode\u003eloop.md\u003c/code\u003e del proyecto\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop 20m /review-pr 1234\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eReejecuta la Skill permitida a intervalos especificados\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e\u003ccode\u003e/loop\u003c/code\u003e depende de la sesión actual de Claude Code. El ordenador y la sesión deben estar en ejecución; si se inicia una nueva conversación, las tareas de la sesión se perderán. Las tareas pendientes se pueden recuperar con \u003ccode\u003e--resume\u003c/code\u003e o \u003ccode\u003e--continue\u003c/code\u003e, pero las tareas recurrentes caducan, por defecto, 7 días después de su creación. Tampoco se ejecutan de forma retroactiva todos los ciclos perdidos.\u003c/p\u003e\n\u003cp\u003eDado que el programador de la sesión puede estar sujeto a fluctuaciones (jitter), puede que no sea adecuado para requisitos operativos que exijan una «ejecución puntual a la hora exacta».\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#schedule-rutina-gestionada-por-anthropic\" class=\"anchor\" id=\"schedule-rutina-gestionada-por-anthropic\"\u003e\u003c/a\u003e\u003ccode\u003e/schedule\u003c/code\u003e: Rutina gestionada por Anthropic\u003c/h3\u003e\n\u003cp\u003e\u003ccode\u003e/schedule\u003c/code\u003e agrupa un Prompt, un Repository, un Connector y un Trigger para crear una rutina que se ejecuta en la infraestructura gestionada por Anthropic. Se puede ejecutar incluso si se cierra el portátil; en la documentación oficial se presenta como «Research Preview».\u003c/p\u003e\n\u003cp\u003eLos triggers que admite una rutina son los siguientes:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eProgramación recurrente\u003c/li\u003e\n\u003cli\u003eProgramación única en un momento futuro específico\u003c/li\u003e\n\u003cli\u003eLlamadas a API autenticadas\u003c/li\u003e\n\u003cli\u003eEventos de pull request o lanzamiento en GitHub\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eSe pueden vincular varios «Trigger» a una misma «Routine». Por ejemplo, se puede configurar una «Routine» de revisión de pull requests para que se ejecute todas las noches y, al mismo tiempo, responda al evento \u003ccode\u003epull_request.opened\u003c/code\u003e.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#comparación-entre-loop-y-schedule\" class=\"anchor\" id=\"comparación-entre-loop-y-schedule\"\u003e\u003c/a\u003eComparación entre \u003ccode\u003e/loop\u003c/code\u003e y \u003ccode\u003e/schedule\u003c/code\u003e\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eCategoría\u003c/th\u003e\n\u003cth\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/th\u003e\n\u003cth\u003eRutina \u003ccode\u003e/schedule\u003c/code\u003e\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eLugar de ejecución\u003c/td\u003e\n\u003ctd\u003eOrdenador y sesión actuales\u003c/td\u003e\n\u003ctd\u003eNube gestionada por Anthropic\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eEjecución tras el apagado del ordenador\u003c/td\u003e\n\u003ctd\u003eNormalmente no es posible\u003c/td\u003e\n\u003ctd\u003eSí\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSe requiere una sesión abierta\u003c/td\u003e\n\u003ctd\u003eSí\u003c/td\u003e\n\u003ctd\u003eNo\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eArchivos locales sin confirmar\u003c/td\u003e\n\u003ctd\u003eAccesibles\u003c/td\u003e\n\u003ctd\u003eNo accesibles; se clona el repositorio de nuevo en cada ejecución\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eIntervalo mínimo\u003c/td\u003e\n\u003ctd\u003e1 minuto según la documentación oficial\u003c/td\u003e\n\u003ctd\u003e1 hora según la documentación oficial\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePersistencia\u003c/td\u003e\n\u003ctd\u003eCentrada en la sesión; las tareas recurrentes caducan a los 7 días\u003c/td\u003e\n\u003ctd\u003eRutina almacenada en la cuenta\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSolicitud de permisos\u003c/td\u003e\n\u003ctd\u003eHereda la política de la sesión actual\u003c/td\u003e\n\u003ctd\u003eEjecución autónoma sin autorización interactiva\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eUso adecuado\u003c/td\u003e\n\u003ctd\u003eSupervisión de PR y despliegues breves\u003c/td\u003e\n\u003ctd\u003eAutomatización de operaciones continuas\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\u003ca href=\"#cuándo-es-mejor-un-evento-que-un-sondeo\" class=\"anchor\" id=\"cuándo-es-mejor-un-evento-que-un-sondeo\"\u003e\u003c/a\u003eCuándo es mejor un evento que un sondeo\u003c/h3\u003e\n\u003cp\u003eSi se comprueban cada minuto las PR en las que rara vez se producen cambios, la mayoría de las ejecuciones finalizarán sin realizar ninguna acción. Si un sistema externo puede enviar eventos, la siguiente estructura resulta más eficiente.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eFallo de CI o actualización de PR\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eGitHub Trigger o API de Routine\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eEjecución de Claude solo cuando sea necesario\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eEl diseño basado en eventos reduce los retrasos y minimiza las llamadas innecesarias al modelo y el consumo de tokens. Si el sondeo es inevitable, es recomendable aumentar el intervalo para adaptarlo a la frecuencia real de los cambios y aplicar un «backoff» cuando no se produzcan cambios durante un periodo prolongado.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#requisitos-imprescindibles-para-las-tareas-basadas-en-el-tiempo\" class=\"anchor\" id=\"requisitos-imprescindibles-para-las-tareas-basadas-en-el-tiempo\"\u003e\u003c/a\u003eRequisitos imprescindibles para las tareas basadas en el tiempo\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eIdéntica\u003c/strong\u003e: aunque se reciba el mismo evento varias veces, no deben producirse comentarios, PR ni implementaciones duplicados.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEstado de procesamiento\u003c/strong\u003e: deben registrarse el ID del último evento procesado, el SHA de la confirmación y el ID del comentario de revisión, entre otros.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEstado de finalización\u003c/strong\u003e: debe poder determinarse la finalización, por ejemplo, fusión o cierre de una solicitud de incorporación de cambios, cola vacía, éxito o reversión de una implementación.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eÁmbito de escritura\u003c/strong\u003e: deben limitarse los efectos secundarios, como permitir comentarios, prohibir la fusión o permitir el push únicamente en la rama \u003ccode\u003eclaude/*\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eGestión de fallos\u003c/strong\u003e: se necesitan reglas de reintento y escalación en caso de fallos en servicios externos, caducidad de la autenticación, límite de frecuencia o falta de permisos.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2\u003e\u003ca href=\"#6-proactive-loop-va-más-allá-de-la-detección-y-la-orquestación-de-tareas\" class=\"anchor\" id=\"6-proactive-loop-va-más-allá-de-la-detección-y-la-orquestación-de-tareas\"\u003e\u003c/a\u003e6. Proactive Loop: va más allá de la detección y la orquestación de tareas\u003c/h2\u003e\n\u003cp\u003eProactive Loop no es un simple comando, sino una arquitectura de automatización continua que combina varias funciones.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eDesencadenante\n\u003c/span\u003e\u003cspan\u003e+ Objetivo\n\u003c/span\u003e\u003cspan\u003e+ Habilidades\n\u003c/span\u003e\u003cspan\u003e+ Flujo de trabajo dinámico\n\u003c/span\u003e\u003cspan\u003e+ Modo automático\n\u003c/span\u003e\u003cspan\u003e+ Repositorio, conector, navegador y herramientas de CI\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eLas nuevas tareas se detectan, procesan, verifican y se informan de los resultados sin que una persona tenga que introducir comandos en tiempo real.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#ejemplo-gestión-automática-de-comentarios-sobre-errores\" class=\"anchor\" id=\"ejemplo-gestión-automática-de-comentarios-sobre-errores\"\u003e\u003c/a\u003eEjemplo: gestión automática de comentarios sobre errores\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eRecepción de incidencias de GitHub o comentarios de Slack\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eClasificación por duplicados, prioridad y reproducibilidad\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eCreación de pruebas de reproducibilidad\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eBúsqueda de posibles soluciones\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eImplementación de la solución elegida\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eUn agente de revisión independiente busca contraejemplos\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eVerificación de pruebas, compilación y seguridad\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eBorrador de PR e informe de resultados\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eLas responsabilidades de cada componente son las siguientes.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eComponente\u003c/th\u003e\n\u003cth\u003eResponsabilidad\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eTrigger o \u003ccode\u003e/schedule\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eDeterminar el momento de iniciar una nueva tarea\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eDefinir qué se considera completado en esta ejecución\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSkill\u003c/td\u003e\n\u003ctd\u003eEstandarización de los procedimientos de reproducción, implementación, verificación y presentación de informes\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eFlujo de trabajo dinámico\u003c/td\u003e\n\u003ctd\u003eEjecución en paralelo de múltiples subagentes y ramificación condicional\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eModo automático\u003c/td\u003e\n\u003ctd\u003eEjecución de llamadas a herramientas permitidas sin espera de autorización\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePolítica de permisos\u003c/td\u003e\n\u003ctd\u003eEstablecer el alcance de lo prohibido, lo autorizado y lo permitido automáticamente\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\u003ca href=\"#flujo-de-trabajo-dinámico-y-árbol-de-trabajo\" class=\"anchor\" id=\"flujo-de-trabajo-dinámico-y-árbol-de-trabajo\"\u003e\u003c/a\u003eFlujo de trabajo dinámico y árbol de trabajo\u003c/h3\u003e\n\u003cp\u003eEl flujo de trabajo dinámico es una estructura en la que el tiempo de ejecución ejecuta un script de orquestación en JavaScript escrito por Claude. En una llamada a un subagente normal, Claude selecciona el siguiente agente en cada turno, pero en el flujo de trabajo, los bucles, el procesamiento en paralelo, las ramificaciones y el almacenamiento de resultados intermedios se trasladan al script.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eScript de flujo de trabajo\n\u003c/span\u003e\u003cspan\u003e  ├─ Agente A: Análisis de requisitos\n\u003c/span\u003e\u003cspan\u003e  ├─ Agente B: Diseño de pruebas\n\u003c/span\u003e\u003cspan\u003e  ├─ Agente C: Búsqueda de opciones de implementación\n\u003c/span\u003e\u003cspan\u003e  ├─ Agente D: Revisión de seguridad\n\u003c/span\u003e\u003cspan\u003e  └─ Juez: Comparación basada en pruebas\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eDado que los resultados intermedios se guardan en variables del script y no en el contexto de la conversación principal, es posible organizar tareas a gran escala de forma más reproducible. La documentación actual especifica un límite de tiempo de ejecución de un máximo de 16 agentes simultáneos y 1.000 agentes por ejecución, aunque estas restricciones pueden cambiar durante la fase de vista previa del producto.\u003c/p\u003e\n\u003cp\u003eSi es necesario probar varias opciones de implementación al mismo tiempo, se puede separar el espacio de trabajo mediante un «Git Worktree».\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003erepo/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-a/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-b/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-c/\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eSi cada agente trabaja en una rama y un directorio independientes, se pueden reducir los problemas derivados de la sobrescritura simultánea de los mismos archivos. El agente evaluador debe comparar las opciones basándose en el cumplimiento de los requisitos, los resultados de las pruebas, el riesgo de regresión, el alcance de los cambios, la complejidad, el rendimiento, la seguridad y la coherencia con la arquitectura existente.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#no-siempre-es-mejor-contar-con-más-agentes\" class=\"anchor\" id=\"no-siempre-es-mejor-contar-con-más-agentes\"\u003e\u003c/a\u003eNo siempre es mejor contar con más agentes\u003c/h3\u003e\n\u003cp\u003eSi solo se aumenta el número de agentes en tareas que no admiten paralelismo, se incrementan los costes y los retrasos. Además, si varios agentes comparten la misma suposición errónea, los errores pueden propagarse.\u003c/p\u003e\n\u003cp\u003eLos casos en los que un flujo de trabajo dinámico resulta adecuado son los siguientes:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eMigraciones en las que se aplica la misma transformación a cientos de archivos\u003c/li\u003e\n\u003cli\u003eAuditorías de seguridad y calidad de todo el código fuente\u003c/li\u003e\n\u003cli\u003eComparación de planes desde múltiples perspectivas independientes\u003c/li\u003e\n\u003cli\u003eInvestigaciones en las que es necesario dividir el procesamiento de muchos elementos y realizar verificaciones cruzadas\u003c/li\u003e\n\u003cli\u003eTareas en las que resulta difícil incluir todos los resultados intermedios en el contexto de un solo agente\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003ePara la corrección de pequeños errores, la refactorización de un solo archivo o la incorporación de pruebas sencillas, es mejor utilizar un bucle por turnos (Turn-based Loop) normal o \u003ccode\u003e/goal\u003c/code\u003e.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#7-sistema-para-mantener-la-calidad-del-código-en-el-bucle\" class=\"anchor\" id=\"7-sistema-para-mantener-la-calidad-del-código-en-el-bucle\"\u003e\u003c/a\u003e7. Sistema para mantener la calidad del código en el bucle\u003c/h2\u003e\n\u003cp\u003eLa calidad de los resultados del bucle depende en gran medida no solo del modelo en sí, sino también del sistema de verificación que lo rodea.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#71-ordenar-el-código-base\" class=\"anchor\" id=\"71-ordenar-el-código-base\"\u003e\u003c/a\u003e7.1 Ordenar el código base\u003c/h3\u003e\n\u003cp\u003eClaude sigue fielmente los patrones del código existente. Si hay API obsoletas, implementaciones duplicadas, estructuras de pruebas poco claras, módulos gigantescos o reglas de gestión de excepciones incoherentes, Loop puede replicar rápidamente esos problemas.\u003c/p\u003e\n\u003cp\u003eLos requisitos básicos son los siguientes:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eFormateador y lint\u003c/li\u003e\n\u003cli\u003eLímites claros entre directorios y módulos\u003c/li\u003e\n\u003cli\u003ePruebas unitarias, de integración y de extremo a extremo (E2E) fiables\u003c/li\u003e\n\u003cli\u003eDistinción entre las API en uso y las API obsoletas\u003c/li\u003e\n\u003cli\u003eNormas de desarrollo específicas para cada proyecto\u003c/li\u003e\n\u003cli\u003eEntornos de compilación y desarrollo reproducibles\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#72-crear-una-definición-de-hecho-por-tipo-de-cambio\" class=\"anchor\" id=\"72-crear-una-definición-de-hecho-por-tipo-de-cambio\"\u003e\u003c/a\u003e7.2 Crear una «Definición de «hecho»» por tipo de cambio\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eTipo de cambio\u003c/th\u003e\n\u003cth\u003eVerificación mínima\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eAPI\u003c/td\u003e\n\u003ctd\u003ePruebas de contrato, compatibilidad con versiones anteriores, actualización de esquemas y ejemplos de documentación\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eFrontend\u003c/td\u003e\n\u003ctd\u003eManipulación real del navegador, errores de consola, accesibilidad, pantalla responsiva\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eBase de datos\u003c/td\u003e\n\u003ctd\u003eMigración (adelantada o revertida), ámbito de bloqueo, plan de ejecución\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDependencias\u003c/td\u003e\n\u003ctd\u003eCompilación, pruebas de regresión clave, verificación de licencias y seguridad\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eInfraestructura\u003c/td\u003e\n\u003ctd\u003eDiferencias entre planes, privilegios mínimos, reversión, comprobación de exposición de información confidencial\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eEs preferible fijar estos criterios en Skills, Hooks, scripts y reglas de CI, en lugar de repetirlos extensamente en el Prompt cada vez.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#73-proporcionar-documentación-actualizada-y-versiones-precisas\" class=\"anchor\" id=\"73-proporcionar-documentación-actualizada-y-versiones-precisas\"\u003e\u003c/a\u003e7.3 Proporcionar documentación actualizada y versiones precisas\u003c/h3\u003e\n\u003cp\u003eUn bucle puede repetir varias veces suposiciones erróneas. Debe facilitarse el acceso a la versión exacta utilizada en el proyecto, la documentación oficial, la documentación interna de arquitectura, las especificaciones de la API, la guía de migración y los ejemplos aprobados.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#74-separar-el-agente-de-implementación-del-agente-de-revisión\" class=\"anchor\" id=\"74-separar-el-agente-de-implementación-del-agente-de-revisión\"\u003e\u003c/a\u003e7.4 Separar el agente de implementación del agente de revisión\u003c/h3\u003e\n\u003cp\u003eEl agente de implementación ya se ve influido por el diseño y los razonamientos ya seleccionados. El agente de revisión, en un nuevo contexto, puede plantear las siguientes preguntas de forma más independiente:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e¿Se han suavizado las pruebas para que se superen?\u003c/li\u003e\n\u003cli\u003e¿Se han modificado archivos que quedan fuera del alcance?\u003c/li\u003e\n\u003cli\u003e¿Se han violado los límites de seguridad?\u003c/li\u003e\n\u003cli\u003e¿Se han omitido las pruebas de rutas de fallo y de valores límite?\u003c/li\u003e\n\u003cli\u003e¿Se ha producido alguna regresión en las funcionalidades existentes?\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eEs más eficaz redactar la indicación de revisión (Review Prompt) de la siguiente manera: «Busca contraejemplos partiendo de la hipótesis de que la implementación es errónea y adjunta pruebas de reproducción para cada observación», en lugar de «Resume los aspectos positivos».\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#75-vincular-los-fallos-individuales-a-la-mejora-del-sistema\" class=\"anchor\" id=\"75-vincular-los-fallos-individuales-a-la-mejora-del-sistema\"\u003e\u003c/a\u003e7.5 Vincular los fallos individuales a la mejora del sistema\u003c/h3\u003e\n\u003cp\u003eSi se repite el mismo error, no basta con corregir solo ese resultado concreto. Para evitar que ese tipo de fallo vuelva a producirse, hay que modificar uno de los siguientes aspectos:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eAñadir pruebas de regresión\u003c/li\u003e\n\u003cli\u003eReforzar los procedimientos de verificación de habilidades\u003c/li\u003e\n\u003cli\u003eAñadir reglas a \u003ccode\u003eCLAUDE.md\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003eAñadir reglas de hook o lint\u003c/li\u003e\n\u003cli\u003eAñadir reglas de denegación de permisos\u003c/li\u003e\n\u003cli\u003eReforzar las condiciones de finalización del objetivo\u003c/li\u003e\n\u003cli\u003eComplementar la lista de comprobación de revisión\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eUna buena ingeniería de bucles no consiste en corregir un único fallo, sino en \u003cstrong\u003ecrear un sistema en el que sea difícil que vuelva a producirse ese tipo de fallo\u003c/strong\u003e.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#8-gestión-de-tokens-y-costes\" class=\"anchor\" id=\"8-gestión-de-tokens-y-costes\"\u003e\u003c/a\u003e8. Gestión de tokens y costes\u003c/h2\u003e\n\u003cp\u003eEl coste de un bucle puede aumentar considerablemente en comparación con el de un único prompt.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eCoste total ≈\n\u003c/span\u003e\u003cspan\u003eCoste del turno del agente principal\n\u003c/span\u003e\u003cspan\u003e+ Coste de evaluación del objetivo\n\u003c/span\u003e\u003cspan\u003e+ Coste de los subagentes\n\u003c/span\u003e\u003cspan\u003e+ Coste de repetición del flujo de trabajo\n\u003c/span\u003e\u003cspan\u003e+ Coste del contexto para leer los resultados de las herramientas\n\u003c/span\u003e\u003cspan\u003e+ Frecuencia de ejecución basada en el tiempo\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eAunque la facturación exacta varía en función del plan, el modelo y el proveedor, el principio que determina la estructura de costes es el mismo.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#principios-prácticos-para-reducir-costes\" class=\"anchor\" id=\"principios-prácticos-para-reducir-costes\"\u003e\u003c/a\u003ePrincipios prácticos para reducir costes\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eNo utilices Loop para tareas pequeñas.\u003c/strong\u003e Las erratas, los cambios de nombre y los errores de tipo en un solo archivo se gestionan en un único turno.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEstablece condiciones de éxito y límites estrictos (hard stop) al mismo tiempo.\u003c/strong\u003e Ten en cuenta el éxito, el número máximo de turnos, el tiempo máximo, los fallos consecutivos y los errores de permisos.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrueba los flujos de trabajo a gran escala en un ámbito reducido.\u003c/strong\u003e Verifica los costes y la calidad con 5 archivos, un directorio o algunas incidencias antes de ampliar la prueba.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLas tareas deterministas se procesan mediante scripts.\u003c/strong\u003e Para la sustitución de AST, la conversión a JSON, el formateo y la generación de formularios fijos, los scripts probados resultan más económicos y reproducibles.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAjusta el ciclo de sondeo a la frecuencia real de los cambios.\u003c/strong\u003e Utiliza disparadores de eventos siempre que sea posible.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSe observa el uso durante el proceso.\u003c/strong\u003e Se comprueba el uso de habilidades, subagentes, MCP, turnos y tokens en \u003ccode\u003e/usage\u003c/code\u003e, \u003ccode\u003e/goal\u003c/code\u003e y \u003ccode\u003e/workflows\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSi se repite el mismo error, no se siguen realizando reintentos.\u003c/strong\u003e Se establece un límite de fallos consecutivos y se escala a una persona.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch3\u003e\u003ca href=\"#el-modelo-y-el-esfuerzo-son-palancas-diferentes\" class=\"anchor\" id=\"el-modelo-y-el-esfuerzo-son-palancas-diferentes\"\u003e\u003c/a\u003eEl modelo y el esfuerzo son palancas diferentes\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eEl modelo\u003c/strong\u003e modifica la capacidad de inferencia básica y el alcance de los problemas que se pueden resolver.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEl esfuerzo\u003c/strong\u003e modifica el número de archivos que se leen, el número de herramientas que se utilizan, el alcance de la verificación y hasta qué punto se llevan a cabo las tareas de varias etapas.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eSi Claude ha comprobado todos los archivos y pruebas necesarios, pero sigue tomando decisiones erróneas, es posible que se necesite un modelo más potente. Por el contrario, si no ha leído algún archivo importante, se ha saltado alguna prueba o ha interrumpido la refactorización a mitad de camino, puede que sea más adecuado aumentar el esfuerzo.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#9-permisos-y-límites-de-seguridad\" class=\"anchor\" id=\"9-permisos-y-límites-de-seguridad\"\u003e\u003c/a\u003e9. Permisos y límites de seguridad\u003c/h2\u003e\n\u003cp\u003eEl diseño más peligroso en el «Proactive Loop» es otorgar amplios permisos al agente y establecer condiciones de éxito y de interrupción poco estrictas.\u003c/p\u003e\n\u003cp\u003eEl modo automático reduce las solicitudes de permisos generales, pero el clasificador puede bloquear las llamadas a herramientas que sean difíciles de revertir, destructivas o que tengan como objetivo elementos fuera de los límites de confianza. Además, los permisos explícitos \u003ccode\u003epermissions.ask\u003c/code\u003e y \u003ccode\u003epermissions.deny\u003c/code\u003e tienen prioridad sobre el modo automático.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#ejemplo-de-jerarquía-de-permisos\" class=\"anchor\" id=\"ejemplo-de-jerarquía-de-permisos\"\u003e\u003c/a\u003eEjemplo de jerarquía de permisos\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eNivel\u003c/th\u003e\n\u003cth\u003eEjemplos\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eAceptación automática\u003c/td\u003e\n\u003ctd\u003eLectura de código, pruebas, lint, compilación, análisis, creación de ramas \u003ccode\u003eclaude/*\u003c/code\u003e, creación de borradores de PR\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAprobación humana\u003c/td\u003e\n\u003ctd\u003eIncorporación a la rama por defecto, despliegue en producción, aplicación de migraciones de base de datos, envío de mensajes a clientes externos\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSiempre prohibido\u003c/td\u003e\n\u003ctd\u003ePush forzado, publicación de secretos, eliminación de datos operativos, elusión de permisos, eliminación de registros de auditoría\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eEs más seguro establecer reglas permanentes de \u003ccode\u003eask\u003c/code\u003e y \u003ccode\u003edeny\u003c/code\u003e que decir una sola vez en una conversación «No hagas un push». Esto se debe a que las reglas de la conversación pueden debilitarse debido a la compresión del contexto o a cambios en la sesión.\u003c/p\u003e\n\u003cp\u003eCloud Routine clona un nuevo repositorio en cada ejecución y funciona con los permisos de GitHub y del conector asociados. Se deben minimizar los siguientes ámbitos:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eRepositorios y ramas accesibles\u003c/li\u003e\n\u003cli\u003eDominios de red permitidos\u003c/li\u003e\n\u003cli\u003eConectores que se van a utilizar\u003c/li\u003e\n\u003cli\u003eVariables de entorno y secretos\u003c/li\u003e\n\u003cli\u003ePermisos de escritura en sistemas externos\u003c/li\u003e\n\u003cli\u003eAlcance de la creación, el push y la fusión de PR\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eEl estado «Finalización normal» en el historial de ejecuciones de la rutina puede significar que la sesión ha finalizado sin errores de infraestructura, pero no garantiza que se haya alcanzado el objetivo del trabajo. Es necesario revisar por separado el transcrito, las pruebas y el diff generado.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#10-plantilla-de-diseño-de-bucles-para-proyectos-de-desarrollo\" class=\"anchor\" id=\"10-plantilla-de-diseño-de-bucles-para-proyectos-de-desarrollo\"\u003e\u003c/a\u003e10. Plantilla de diseño de bucles para proyectos de desarrollo\u003c/h2\u003e\n\u003cp\u003eEl siguiente código YAML no es sintaxis real del código Claude, sino una plantilla para la revisión del diseño.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003etrigger\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003etype\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003emanual | interval | schedule | github_event | api_event\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003escope\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erepositories\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etarget-repository\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eallowed_paths\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003esrc/**\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etests/**\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eprohibited_paths\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eproduction/**\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003esecrets/**\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003etask\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eobjective\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eobjetivo que se desea modificar o procesar\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003einput\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003enueva incidencia, evento, archivo o estado\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003everification\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ecommands\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eunit-test\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eintegration-test\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003elint\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ebuild\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eruntime_checks\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ebrowser-interaction\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003econsole-errors\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eaccessibility\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eevidence\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ecommand-output\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eexit-code\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etest-summary\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003escreenshots\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003esuccess\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003econdition\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eEstado de finalización que puede evaluarse como verdadero o falso\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003estop\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_turns\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e12\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_duration_minutes\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e45\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_consecutive_failures\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e3\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003estop_on_permission_error\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eescalate_on_external_outage\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eefectos secundarios\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eclave_de_idempotencia\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eid_del_evento-o-sha_de_la_confirmación\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003epermitir_envío_de_rama\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eclaude/*\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erequerir_intervención_humana_para_la_fusión\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erequerir_intervención_humana_para_la_implementación\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003erevisión\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eagente_independiente\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erevisión_adversaria\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eobservabilidad\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003einformar_sobre_el_progreso\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003einformar_sobre_el_uso_de_tokens\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003einformar_sobre_los_archivos_modificados\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003einformar_sobre_los_fallos_restantes\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eLos elementos más importantes son los cinco siguientes, más que la propia frase del prompt.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eTrigger\n\u003c/span\u003e\u003cspan\u003eVerifier\n\u003c/span\u003e\u003cspan\u003eCondición de éxito\n\u003c/span\u003e\u003cspan\u003eParada forzada\n\u003c/span\u003e\u003cspan\u003eLímite de permisos\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003ch2\u003e\u003ca href=\"#11-qué-bucle-se-debe-elegir\" class=\"anchor\" id=\"11-qué-bucle-se-debe-elegir\"\u003e\u003c/a\u003e11. ¿Qué bucle se debe elegir?\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eSituación\u003c/th\u003e\n\u003cth\u003eMétodo recomendado\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eTareas que concluyen con una única modificación y verificación\u003c/td\u003e\n\u003ctd\u003eTurn-based\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTareas que requieren varios intentos, pero cuyo estado de finalización es claro\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTareas que requieren esperar brevemente el estado externo de CI, PR o implementación\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTareas que deben ejecutarse de forma repetida incluso si se cierra el portátil\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/schedule\u003c/code\u003e Routine\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTareas que requieren una respuesta inmediata a eventos o alertas de GitHub\u003c/td\u003e\n\u003ctd\u003eRutina activada por eventos\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTareas que requieren el procesamiento en paralelo y la verificación cruzada de cientos de elementos\u003c/td\u003e\n\u003ctd\u003eFlujo de trabajo dinámico\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eConversiones en las que las reglas de entrada y salida son totalmente deterministas\u003c/td\u003e\n\u003ctd\u003eScript o tarea de CI\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eEl orden de selección no debe basarse en «la funcionalidad más potente», sino en «la estructura de control más sencilla para alcanzar el objetivo».\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#12-orden-de-implementación-seguro\" class=\"anchor\" id=\"12-orden-de-implementación-seguro\"\u003e\u003c/a\u003e12. Orden de implementación seguro\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eElige una tarea que suponga un cuello de botella y que requiera comprobaciones repetitivas por parte de una persona.\u003c/li\u003e\n\u003cli\u003eEn primer lugar, crea un procedimiento de verificación mediante una Skill, un Script o un trabajo de CI.\u003c/li\u003e\n\u003cli\u003eEstabiliza la calidad de la verificación en el modo por turnos.\u003c/li\u003e\n\u003cli\u003eSi el estado de finalización es claro, añade \u003ccode\u003e/goal\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eUtiliza \u003ccode\u003e/loop\u003c/code\u003e solo cuando sea necesario esperar un estado externo.\u003c/li\u003e\n\u003cli\u003eSi se requiere una ejecución prolongada, trasládalo a una rutina \u003ccode\u003e/schedule\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eAmplía a flujos de trabajo dinámicos y bucles proactivos solo después de haber verificado la idempedancia, los permisos y los costes.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2\u003e\u003ca href=\"#13-malentendidos-frecuentes\" class=\"anchor\" id=\"13-malentendidos-frecuentes\"\u003e\u003c/a\u003e13. Malentendidos frecuentes\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eMalentendido\u003c/th\u003e\n\u003cth\u003eInterpretación correcta\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eUn «Loop» es una ejecución infinita\u003c/td\u003e\n\u003ctd\u003eEs una estructura de repetición limitada que cuenta con condiciones de éxito y una parada forzada\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eEl informe de finalización del agente es una verificación\u003c/td\u003e\n\u003ctd\u003eSe necesitan la salida de comandos externos, el código de salida y los resultados de tiempo de ejecución\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e«/goal» concede automáticamente todos los permisos\u003c/td\u003e\n\u003ctd\u003eSolo inicia automáticamente el siguiente turno; la política de permisos es independiente\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e es un programador de ejecución a largo plazo\u003c/td\u003e\n\u003ctd\u003eSe centra en las sesiones y tiene una caducidad de 7 días, además de restricciones en el entorno de ejecución\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eCuantos más agentes haya, mejores serán los resultados\u003c/td\u003e\n\u003ctd\u003eLa paralelización solo tiene valor cuando las funciones, los puntos de vista y la verificación son diferentes\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTodas las tareas repetitivas deben realizarlas los LLM\u003c/td\u003e\n\u003ctd\u003ePara las partes deterministas, los scripts son más económicos y ofrecen mayor reproducibilidad\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\u003ca href=\"#conclusión\" class=\"anchor\" id=\"conclusión\"\u003e\u003c/a\u003eConclusión\u003c/h2\u003e\n\u003cp\u003eLa ingeniería de bucles (Loop Engineering) no es una tecnología para mantener la IA en ejecución durante mucho tiempo, sino \u003cstrong\u003eel diseño de un sistema de control que permite que la IA detecte por sí misma sus errores, los corrija dentro de los límites de coste y se detenga ante situaciones de riesgo\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eLos LLM destacan en la exploración, la inferencia, la implementación, el análisis de excepciones y la comparación de alternativas. El sistema debe encargarse del momento de ejecución, el alcance de los cambios, los métodos de verificación, los criterios de finalización, los límites de coste y los límites de autorización. Cuanto más clara sea esta distribución de funciones, más se acercará la automatización del código Claude a un sistema de desarrollo y operaciones reproducible y auditable, más allá de una simple herramienta de generación de código.\u003c/p\u003e\n","tags":["Claude Code","Ingeniería de bucles","Agente de IA","Automatización del desarrollo","Flujo de agentes"],"faqs":[{"question":"⁣¿En qué se diferencia el bucle de INJX12⁣ Code de los bucles «for» y «while» habituales?","answer":"Los bucles normales repiten de forma determinista las instrucciones definidas en el código. Claude Code: «Loop» es una estructura de control de agentes en la que el agente observa el código y el estado externo, deduce la siguiente acción, ejecuta la herramienta, verifica el resultado y, a continuación, vuelve a realizar la tarea según las condiciones de finalización."},{"question":"¿Cuándo es más adecuado el bucle por turnos?","answer":"Es ideal para tareas breves y puntuales en las que el usuario puede revisar los resultados al instante. No obstante, si los procedimientos de verificación son repetitivos —como en el caso de la interfaz de usuario, la API o la base de datos—, es recomendable crear dichos procedimientos en forma de «Skill» o «Script» para que Claude los verifique por sí mismo siguiendo los mismos criterios."},{"question":"¿El modelo de evaluación `/goal` comprueba directamente los archivos y los resultados de las pruebas?","answer":"No. El modelo de evaluación no recurre a herramientas ni lee los archivos directamente, sino que evalúa las condiciones del objetivo y las pruebas que se desprenden de la conversación. La tarea Claude debe dejar constancia clara en los resultados de los comandos de prueba, los códigos de salida, los archivos modificados y las causas del fallo."},{"question":"¿Qué debe incluir una buena condición `/goal`?","answer":"Se necesita un estado de finalización medible, un comando o una herramienta que lo acredite, los límites de lo que se puede modificar y lo que está prohibido, así como «puntos de parada» (hard stop) como el número máximo de turnos, el tiempo máximo o el número de fallos consecutivos. Es mejor que «las pruebas y el lint den un código de salida 0 y no haya diferencias fuera de la ruta especificada» que una «refactorización limpia»."},{"question":"¿Hay un número máximo de turnos o un límite de tiempo en `/goal`?","answer":"El «Goal» continúa hasta que el modelo de evaluación determine que se ha alcanzado el éxito o hasta que el usuario lo interrumpa con el comando `/goal clear`. Para limitar el presupuesto de ejecución, es necesario incluir directamente en las condiciones del «Goal» cláusulas relativas a los turnos o al tiempo, como «interrumpir tras un máximo de 12 turnos o 45 minutos»."},{"question":"¿Al utilizar `/goal`, también se conceden automáticamente los permisos de la herramienta?","answer":"No. Aunque `/goal` inicia automáticamente el siguiente turno, las políticas de permisos para la escritura en archivos, el shell, Git y los conectores externos se mantienen sin cambios. Si necesitas una ejecución sin supervisión, considera el modo automático, pero debes controlar por separado las tareas de riesgo mediante reglas `ask` y `deny`."},{"question":"¿Cuál es la principal diferencia entre `/loop` y `/schedule`?","answer":"`/loop` es un método de sondeo a corto plazo que se ejecuta de forma repetida en la sesión actual de Claude Code y en el ordenador. `/schedule` permite guardar el Prompt, el Repository, el Connector y el Trigger como una rutina en la nube (Cloud Routine) para que se ejecuten en la infraestructura de gestión de Anthropic, por lo que no es necesario tener una sesión abierta ni el portátil encendido."},{"question":"¿Sigue ejecutándose `/loop` cuando se apaga el ordenador?","answer":"Por lo general, no se ejecuta de forma continua. `/loop` es una operación de ámbito de sesión y Claude Code debe estar en ejecución. Para la automatización a largo plazo, se debe utilizar un programador sostenible, como Cloud Routine, una tarea programada de escritorio o GitHub Actions."},{"question":"¿Por qué es mejor el desencadenador de eventos que el sondeo por tiempo?","answer":"Esto se debe a que, al no producirse cambios, no se generan llamadas innecesarias al modelo y se puede ejecutar inmediatamente después de que se produzca un cambio real. En el caso de sistemas que pueden generar eventos —como fallos en la integración continua (CI), actualizaciones de PR o alertas—, resulta más ventajoso en términos de coste y latencia conectarlos mediante GitHub Trigger o la API de Routine."},{"question":"¿Por qué se incluyen los procedimientos de verificación en `SKILL.md` y no en `CLAUDE.md`?","answer":"El archivo `CLAUDE.md` es ideal para reglas breves que se aplican en todo el proyecto, mientras que las «Skills» son adecuadas para agrupar los procedimientos y archivos de apoyo necesarios solo para tareas específicas. Si se separan las largas listas de comprobación en «Skills», estas solo se cargarán en las tareas relevantes y se podrán volver a ejecutar directamente."},{"question":"¿En qué se diferencia el flujo de trabajo dinámico de una llamada normal a un subagente?","answer":"En el método Subagent convencional, Claude selecciona al siguiente trabajador en cada turno y los resultados se acumulan en el contexto. El flujo de trabajo dinámico permite organizar migraciones, auditorías y verificaciones cruzadas a gran escala de forma más reproducible, ya que un script de JavaScript gestiona la ejecución en paralelo, las ramificaciones, las iteraciones y los resultados intermedios."},{"question":"¿El uso de varios agentes mejora siempre la calidad?","answer":"No. Si las funciones y los puntos de vista se solapan, se pueden repetir los mismos errores y los costes no harán más que aumentar. Para que los agentes paralelos aporten valor, es necesario separar las responsabilidades —como en el caso de la implementación, el diseño de pruebas, la revisión de seguridad, el análisis de regresión y el Judge— y exigir pruebas independientes para cada conclusión."},{"question":"¿Cómo se evitan las tareas duplicadas en un bucle basado en el tiempo o proactivo?","answer":"Se deben almacenar claves de idempotencia, como el ID del evento, el SHA del commit y el ID del comentario de revisión, así como el estado final del procesamiento. Se debe incluir en la fase de verificación una regla que impida volver a procesar mensajes a los que ya se ha respondido, PR que ya se han creado o commits que ya se han procesado."},{"question":"¿Qué tarea es la más adecuada para automatizar en el primer bucle?","answer":"Es recomendable optar por tareas que, aunque requieran comprobaciones repetidas, presenten pocos efectos secundarios peligrosos y cuyo estado de finalización se pueda medir con claridad. Por ejemplo, resulta seguro empezar por resumir las causas de los fallos de CI en las PR, detectar discrepancias entre la documentación y el código, y realizar las verificaciones establecidas de pruebas y lint, para luego ampliar gradualmente los permisos de corrección y publicación."}],"sources":[{"url":"https://claude.com/blog/getting-started-with-loops","title":"Ingeniería de bucles: Introducción a los bucles | Claude por Anthropic","type":"source"},{"url":"https://code.claude.com/docs/en/skills","title":"Amplía Claude con habilidades - Documentación del código de Claude","type":"source"},{"url":"https://code.claude.com/docs/en/goal","title":"Mantener Claude trabajando para alcanzar un objetivo - Documentación del código de Claude","type":"source"},{"url":"https://code.claude.com/docs/en/scheduled-tasks","title":"Ejecutar comandos según una programación - Claude Code Docs","type":"source"},{"url":"https://code.claude.com/docs/en/routines","title":"Automatizar el trabajo con rutinas - Claude Documentación del código","type":"source"},{"url":"https://code.claude.com/docs/en/workflows","title":"Coordina subagentes a gran escala con flujos de trabajo dinámicos - Claude Documentación de código","type":"source"},{"url":"https://claude.com/blog/claude-model-and-effort-level-in-claude-code","title":"Cómo elegir un modelo Claude y un nivel de esfuerzo en el código Claude | Claude por Anthropic","type":"source"},{"url":"https://code.claude.com/docs/en/auto-mode-config","title":"Configurar el modo automático - Claude Documentación de código","type":"source"}],"images":[{"id":195,"url":"https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg3OSwicHVyIjoiYmxvYl9pZCJ9fQ==--cac49ec584371c2261bd3272e7574ca38ecc1f85/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2006_56_28.webp","is_representative":true,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 06_56_28.png","translations":{"ko":{"alt":"AI 로봇과 코드 화면을 중심으로 반복 화살표, 목표·시간·보안·비용 아이콘이 연결된 자동화 구조","caption":"관찰·실행·검증을 반복하는 AI 에이전트와 목표, 일정, 권한, 강제 종료, 비용 제어 요소를 함께 보여준다.","description":null},"en":{"alt":"AI robot and code dashboard surrounded by loop arrows, goal, schedule, security, and cost control icons","caption":"The illustration shows an AI agent repeating observation, action, and verification within goal, timing, permission, stop, and cost controls.","description":null},"ja":{"alt":"AIロボットとコード画面を中心に、循環矢印、目標、時間、安全、コスト管理のアイコンが連結された構成","caption":"観察・実行・検証を繰り返すAIエージェントを、目標、実行時期、権限、停止、コストの制御要素とともに示している。","description":null},"es":{"alt":"Robot de IA y panel de código rodeados por flechas de ciclo e iconos de objetivo, tiempo, seguridad y coste","caption":"La ilustración muestra un agente de IA que repite observación, acción y verificación bajo controles de objetivo, tiempo, permisos, parada y coste.","description":null},"id":{"alt":"Robot AI dan dasbor kode dikelilingi panah loop serta ikon tujuan, waktu, keamanan, dan biaya","caption":"Ilustrasi menampilkan agen AI yang mengulang observasi, tindakan, dan verifikasi dengan kontrol tujuan, waktu, izin, penghentian, dan biaya.","description":null},"pt":{"alt":"Robô de IA e painel de código cercados por setas de ciclo e ícones de meta, tempo, segurança e custo","caption":"A ilustração mostra um agente de IA repetindo observação, ação e verificação sob controles de objetivo, tempo, permissão, parada e custo.","description":null},"zh-hant":{"alt":"AI 機器人與程式碼面板置於循環箭頭中央，周圍連結目標、時間、安全與成本控制圖示","caption":"圖中呈現 AI 代理在目標、排程、權限、強制停止與成本控制下反覆觀察、執行與驗證。","description":null}}},{"id":196,"url":"https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg4NiwicHVyIjoiYmxvYl9pZCJ9fQ==--e5ead4b7a604375b9c6a192eb3a981cf4c93b3c9/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2007_02_56.webp","is_representative":false,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 07_02_56.png","translations":{"ko":{"alt":"보호 울타리 안의 AI 에이전트가 검증, 중단 장치, 권한 게이트와 비용 계측을 거쳐 작업하는 자동화 구조","caption":"트리거부터 검증과 강제 중단, 자원 관리, 승인된 결과 출력까지 안전하게 통제되는 에이전트 워크플로를 보여준다.","description":null},"en":{"alt":"AI agent inside a guarded workspace with verification, stop controls, permission gates, and resource monitoring","caption":"The illustration shows an agent workflow controlled from triggers through validation, hard stops, resource checks, and approved output.","description":null},"ja":{"alt":"検証、強制停止、権限ゲート、資源監視に囲まれた保護領域内のAIエージェント","caption":"トリガーから検証、停止制御、コスト管理、承認済み出力まで安全に統制されたエージェント処理を表している。","description":null},"es":{"alt":"Agente de IA en un entorno protegido con verificación, parada forzada, permisos y control de recursos","caption":"La ilustración muestra un flujo de agente controlado desde los disparadores hasta la validación, los límites y la salida aprobada.","description":null},"id":{"alt":"Agen AI dalam area terlindungi dengan verifikasi, penghentian paksa, gerbang izin, dan pemantauan sumber daya","caption":"Ilustrasi ini menunjukkan alur agen yang dikendalikan dari pemicu hingga validasi, batas aman, pemantauan biaya, dan keluaran yang disetujui.","description":null},"pt":{"alt":"Agente de IA em área protegida com verificação, parada forçada, controle de permissões e monitoramento de recursos","caption":"A ilustração mostra um fluxo de agente controlado desde os gatilhos até a validação, os limites de segurança e a saída aprovada.","description":null},"zh-hant":{"alt":"受保護工作區中的AI代理，周圍設有驗證、強制停止、權限閘門與資源監控","caption":"圖中呈現從觸發、驗證、停止控制與成本監測，到核准輸出的安全代理工作流程。","description":null}}}],"published_at":"2026-07-17T09:40:17+09:00","updated_at":"2026-07-17T09:40:17+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant"],"url":"https://injoys.com/es/articles/claude-code-loop-engineering-guide"}