GitHub CLI ya maneja sub-issues y dependencias: una pieza simple para dividir trabajo entre agentes

GitHub anunció el 10 de junio de 2026 una mejora que suena administrativa: la GitHub CLI ahora permite manejar sub-issues, tipos de issue y dependencias desde terminal. Para un equipo que solo usa GitHub como tablero, eso es cómodo. Para builders que ya asignan tareas a agentes, es más interesante: vuelve programable el desglose del trabajo.

La mayoría de fallos con coding agents no nacen porque el modelo no sepa escribir código. Nacen porque la tarea llega demasiado grande, sin bloqueos explícitos y sin una forma clara de partir el PR. Sub-issues y dependencias atacan justo esa capa.

Qué trae la novedad

El changelog de GitHub dice que la CLI puede crear y gestionar sub-issues, issue types y dependencias. La página de releases de cli/cli y el manual de gh issue son las superficies primarias para seguir la disponibilidad exacta de comandos y flags.

Lo útil para agentes no es memorizar un flag. Es poder montar una convención como esta:

• un issue padre define el objetivo y el criterio de aceptación;
• sub-issues separan módulos, pruebas, docs o migraciones;
• dependencias marcan qué no debe empezar hasta que otra pieza cierre;
• el agente recibe una unidad pequeña, no una épica ambigua;
• el revisor ve una cadena de decisión, no una montaña de cambios.

La intención de búsqueda es práctica: gh issue sub-issues, GitHub CLI issue dependencies, GitHub sub-issues CLI, coding agents GitHub issues. No hay herramienta SEO disponible aquí; la demanda se infiere por el changelog oficial, releases de la CLI y la necesidad visible de orquestar trabajo de agentes sin abrir la UI.

Por qué importa para agentes

Un buen agente necesita contexto, pero también necesita límites. Cuando todo vive en un solo issue, el agente puede mezclar investigación, implementación, pruebas y documentación en un PR enorme. Cuando el trabajo se parte bien, puedes asignar agentes distintos, correrlos en paralelo y revisar cada resultado con menos ruido.

Esto también ayuda a evitar una mala práctica común: pedirle a un agente que "arregle todo lo pendiente" porque el backlog no está estructurado. Ese prompt parece productivo, pero suele producir cambios difíciles de revisar.

Con sub-issues y dependencias desde CLI, puedes generar estructura antes de lanzar agentes:

1. crear el issue padre desde un template;
2. crear sub-issues por módulo;
3. marcar bloqueos reales;
4. iniciar una tarea de agente por sub-issue;
5. cerrar el ciclo solo cuando los checks y la revisión pasen.

El riesgo: burocracia automática

También hay una trampa obvia. Si automatizas la creación de sub-issues sin criterio, solo fabricas más backlog. Una jerarquía útil debe reducir ambigüedad, no esconderla.

Yo pondría tres reglas:

• cada sub-issue debe tener una salida verificable;
• ninguna dependencia debe existir solo por ansiedad;
• si dos sub-issues siempre se revisan juntos, probablemente no eran dos unidades reales.

Para agentes, la métrica no es cuántos issues creaste. Es cuántos PRs pequeños, revisables y testeados salen de esa estructura.

Un flujo mínimo que sí usaría

Imagina una migración de SDK. En vez de lanzar un agente sobre todo el repo, un script crea:

• issue padre: migrar SDK;
• sub-issue 1: actualizar cliente y tipos;
• sub-issue 2: adaptar tests;
• sub-issue 3: actualizar docs;
• dependencia: docs espera a que cliente y tests estén verdes.

Después puedes usar Copilot cloud agent, Codex, Claude Code u otro agente con cada pieza. El valor no está en "usar más IA"; está en que el trabajo queda chico y auditable.

Si todavía estás definiendo cómo escribir instrucciones para agentes, empieza por el curso gratis. La CLI puede crear estructura, pero no decide por ti qué es una unidad de trabajo sana.

La conclusión corta: sub-issues y dependencias en GitHub CLI son una función de project management que se vuelve infraestructura para agentes cuando la usas para partir trabajo, marcar bloqueos y sostener revisión humana.