En Ivy Tendril, un issue de GitHub se convierte en una pull request a través de una secuencia estructurada de etapas: el issue llega a la Inbox mediante un webhook, un agente redacta un plan, un desarrollador revisa y aprueba el plan, un agente lo ejecuta en un git worktree aislado, se ejecuta la verificación automática, el desarrollador revisa el diff resultante y un agente abre la pull request. La intervención humana tiene lugar exactamente en dos puntos: el plan y el diff. Todo lo demás lo gestionan los agentes, permitiendo que múltiples tareas avancen en paralelo por la cadena. Este artículo acompaña a un ticket en cada una de sus fases.
El ciclo de vida en resumen
Ivy denomina a este flujo de trabajo una «fábrica de software»: una secuencia fija de fases en la que los agentes realizan el trabajo operativo y los desarrolladores inspeccionan los resultados en puntos de control claramente delimitados. A continuación se detallan las fases, los actores y las condiciones de salida. La referencia técnica completa se encuentra en la documentación del ciclo de vida.
| Fase | Quién actúa | Condición de salida |
|---|---|---|
| Inbox | Agente (webhook) | El issue queda almacenado con su título, descripción, etiquetas y enlace |
| Draft plan | Agente (CreatePlan) | Existe un borrador con objetivo, alcance, archivos afectados y pasos de verificación |
| Plan review, punto de control 1 | Humano | El desarrollador aprueba el plan, tras posibles anotaciones y correcciones |
| Execute | Agente (ExecutePlan) | El agente reporta el plan como completado dentro de su worktree |
| Verify | Agente | Se ejecutan las pruebas y el linter, y el diff queda listo para revisión (puertas de verificación) |
| Diff review, punto de control 2 | Humano | El desarrollador aprueba el diff |
| Pull request | Agente (CreatePr) | Se crea una pull request en GitHub para la rama del plan a través de la API REST de pull requests |
| Merge y limpieza | Humano fusiona, agente limpia | Se elimina el worktree y los aprendizajes se registran en la memoria |
Del issue al plan aprobado
Llegada del issue
Un usuario reporta el issue #418 en el repositorio: "Export to CSV drops rows with commas in the description field." La integración con GitHub lo entrega en la Inbox de Tendril mediante un webhook. En este punto no se ejecuta nada. La Inbox es una bandeja de entrada donde el desarrollador decide cuáles asuntos se convierten en planes. Los reportes de errores provenientes de jam.dev llegan exactamente del mismo modo.
CreatePlan elabora el borrador del plan
El desarrollador selecciona el issue y pulsa Create plan. El promptware CreatePlan analiza el issue, su propia memoria contextual del repositorio y el código fuente pertinente, redactando un borrador estructurado. Un borrador típico especifica el objetivo, los archivos que prevé modificar (src/export/csv.ts y su archivo de pruebas), la estrategia de solución (entrecomillar campos que incluyan el delimitador según RFC 4180) y los pasos de verificación (añadir un caso de prueba con comas en la descripción y ejecutar la suite existente de exportación). El borrador pasa a la sección Drafts.
Punto de control 1: El desarrollador revisa el plan
Este es el primero de los dos puntos de control humano. El desarrollador revisa el borrador y detecta una carencia: el plan propone entrecomillar únicamente el campo de descripción, pero el mismo fallo afecta a cualquier columna de texto libre. En lugar de reescribir el plan a mano, el desarrollador selecciona ese párrafo e introduce una anotación: "Apply the quoting to all string columns, not just description." El promptware UpdatePlan reescribe el plan incorporando la corrección, y la versión revisada queda lista para una nueva lectura.
Si el borrador carece de detalle, el desarrollador puede ejecutar ExpandPlan. Si las anotaciones evidencian que el ticket abarca en realidad dos tareas distintas —por ejemplo, la corrección del fallo y una migración independiente del módulo de exportación a una librería CSV compartida—, SplitPlan lo divide en dos planes independientes. Cuando el desarrollador está satisfecho, aprueba el plan. A partir de ese momento, el plan constituye la especificación vinculante para la ejecución, sin necesidad de que el agente vuelva a interpretar el issue original.
Ejecución y verificación
ExecutePlan se ejecuta en un worktree aislado
Tras la aprobación, Tendril crea un git worktree dedicado para el plan en una rama propia e inicia el agente seleccionado en su interior. El desarrollador elige el agente por cada plan: Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode u otro agente de CLI. El flujo de trabajo permanece inalterado independientemente del agente escogido.
El uso de worktrees es esencial porque otros planes se ejecutan de manera concurrente. Cada plan dispone de su propio directorio de trabajo y su propia rama, por lo que un cambio a medio terminar jamás interfiere con otro, y la rama principal permanece intacta hasta la revisión final. Las razones de esta arquitectura se detallan en git worktrees para agentes paralelos de IA.
Mientras el agente trabaja, la vista Jobs transmite en directo sus salidas y llamadas a herramientas: archivos leídos, comandos ejecutados, tests lanzados y los tokens y costes acumulados. El desarrollador puede supervisarlo o avanzar en la revisión de otro plan. Con un Cloudflare Quick Tunnel configurado, este mismo stream se puede seguir desde el móvil.
Ejecución de la verificación
Cuando el agente marca el plan como completado, la verificación arranca dentro del worktree: se ejecutan la suite de pruebas y el linter, y el diff resultante se recopila para su examen. Los resultados se organizan en la interfaz Review en tres pestañas: tests, lint y diff. Cualquier test fallido o error de estilo queda a la vista antes de que una persona invierta tiempo en leer el código. Los planes Pro y Enterprise permiten además importar resultados de verificación desde la integración continua (CI). Los motivos para concebir la verificación como una puerta estricta en lugar de una sugerencia se exponen en puertas de verificación para código generado por IA.
Revisión, pull request y limpieza
Punto de control 2: El desarrollador revisa el diff
Este es el segundo punto de control humano. En Review, el desarrollador examina el diff junto al plan y a los informes de verificación. En el caso del issue #418, el diff modifica src/export/csv.ts, incorpora una función auxiliar de escape y amplía el archivo de tests con tres casos: una coma, unas comillas y un salto de línea dentro de un campo. Las pruebas pasan con éxito y el linter no arroja advertencias. El desarrollador aprueba el diff.
Si el diff no resulta admisible, el desarrollador rechaza la aprobación, actualiza el plan con los requisitos omitidos y solicita una nueva ejecución. Nada llega a GitHub sin este visto bueno explícito.
CreatePr abre la pull request
El promptware CreatePr abre la pull request directamente desde la rama del plan. A partir de este momento se aplica el proceso ordinario de revisión y fusión del equipo en GitHub. La vista Pull Requests de Tendril realiza el seguimiento del estado de cada PR abierta por este cauce.
Tras la fusión (merge)
Una vez fusionada la PR, Tendril elimina automáticamente el worktree. El promptware ExecutePlan registra los aprendizajes obtenidos en la memoria del proyecto. Para este ticket, se guarda un registro como: "The export module has an integration test that needs the fixtures in test/fixtures/export/; run it with pnpm test:export", permitiendo que futuros planes sobre el módulo de exportación lean dicha indicación antes de arrancar.
Toda la secuencia, para una tarea de esta escala, requiere escasos minutos de procesamiento de agente y dos breves revisiones humanas. El equipo de Ivy reporta haber pasado de aproximadamente 10 a más de 100 pull requests al día tras adoptar este flujo, conservando rigurosamente intactos ambos puntos de control.
Cómo empezar
Instala Tendril, conecta la integración de GitHub para recibir issues en la Inbox y haz avanzar un primer ticket por toda la secuencia con un solo agente antes de ejecutar planes en paralelo.
curl -sSf https://cdn.ivy.app/install-tendril.sh | sh
En Windows, ejecuta irm https://cdn.ivy.app/install-tendril.ps1 | iex. La edición gratuita, con código disponible bajo la Functional Source License, comprende el ciclo de vida completo. Pro y Enterprise añaden funcionalidades para equipos, importación de verificaciones desde CI y alojamiento on-premise.
Preguntas frecuentes
¿Puede el agente saltarse un punto de control si el cambio es pequeño?
No. Los dos puntos de control se aplican rigurosamente a cada plan. Un ajuste de una sola línea pasa por la aprobación del plan y del diff con las mismas garantías que cualquier otro plan. Los planes pequeños simplemente requieren menos tiempo de revisión.
¿Qué sucede si dos planes paralelos modifican el mismo archivo?
Cada plan opera en su propio worktree y en una rama aislada, por lo que no se produce ningún conflicto durante la ejecución. El conflicto se manifiesta al rebasar o fusionar la segunda pull request, y se resuelve mediante los mecanismos estándar de Git. Descomponer los planes por módulos reduce sensiblemente la frecuencia de estos solapamientos.
¿El issue debe provenir obligatoriamente de GitHub?
No. Los planes pueden originarse a partir de una idea escrita, un reporte de error en jam.dev, la CLI, la API REST o el servidor MCP. El webhook de GitHub constituye únicamente una de las múltiples vías de entrada a la Inbox.
Primeros pasos con Ivy Tendril
¿Listo para la orquestación paralela de agentes a nivel de desarrollador?
- Explora el código: Conoce Ivy Tendril en GitHub (Código abierto).
- Consulta la documentación: Encuentra guías de integración en tendril.ivy.app.
- Agenda una sesión técnica: Contacta a renco@ivy.app para una consulta de arquitectura de 30 minutos.