IDD Skill: plantilla de flujo de trabajo de desarrollo guiado por issues

Para quién es

• Desarrolladores y equipos pequeños que llevan su desarrollo diario en su propio repositorio Git y quieren convertir «de la issue al merge» en un proceso repetible: tras la importación, el agente de código con IA del repositorio sigue el flujo descrito oficialmente — descubrir issues listas, reclamar su propiedad, implementar en una rama, abrir un PR, atender los comentarios de revisión, esperar a la CI, fusionar según la política de merge elegida en el repositorio y limpiar. El proyecto describe este flujo como «portable»: llega junto con el repositorio en lugar de quedar atado a una sola herramienta.
• Desarrolladores que usan varias herramientas de código con IA y no quieren encerrar el proceso en un único cliente: según la documentación oficial, el bucle principal funciona en GitHub Copilot, Claude Code, OpenAI Codex CLI, OpenCode y Antigravity CLI (antes Gemini CLI).
• Equipos que necesitan varias sesiones de trabajo avanzando issues distintas en paralelo: la documentación oficial indica que la política por defecto del modo distribuido es fully_autonomous_merge, que permite a las sesiones de trabajo llegar hasta la fusión; cómo se coordinan las sesiones y cómo evitan conflictos no está explicado oficialmente.
• Qué conviene confirmar antes de adoptarlo: la página oficial no dice si se admiten plataformas de alojamiento distintas de GitHub — sin confirmar; si el equipo no acepta la fusión totalmente automática, habrá que evaluar o ajustar antes esa política por defecto, y cómo ajustarla no se explica oficialmente.

Primer intento en 3 minutos

• Requisitos previos: un repositorio Git donde tengas permiso para crear ramas y abrir PR; y un entorno con las dependencias completas del bucle que enumera la documentación oficial — git, un gh CLI autenticado (o una integración de GitHub MCP equivalente, basta con una de las dos), jq y un cliente REST como curl.
• Dónde y cómo se instala: no hay que copiar archivos a mano. La vía oficial consiste en dar directamente la instrucción de importación al agente de IA dentro del repositorio destino; la guía de onboarding se encarga de copiar la plantilla.
• Activación: abre un agente compatible en el repositorio e introduce literalmente esta instrucción oficial:

Import and onboard github:kurone-kito/idd-skill's IDD into this repository.

• Limita el primer intento a acciones de bajo riesgo: pide al agente que lea la guía del flujo, liste las issues listas existentes y explique su plan para el siguiente paso, sin reclamar nada ni tocar código. El punto de partida oficial del bucle es precisamente «leer la guía, descubrir una issue lista, reclamarla»; mientras no haya reclamación puedes detenerlo en cualquier momento.
• Señal de éxito: si el agente repite las claves del flujo y enumera con precisión las issues existentes, la importación y la lectura de la guía funcionan; que los archivos de la plantilla se hayan copiado al repositorio significa que el onboarding terminó. La documentación oficial no da una ruta concreta: guíate por la salida real del agente (sin confirmar).

Casos de uso

Caso 1: llevar una issue lista hasta el final. Escenario: el backlog ya tiene issues marcadas como listas y quieres verificar el ciclo cerrado de la reclamación a la fusión. Ordena al agente: «Reclama una issue lista y completa la implementación.» Recorrerá el bucle oficial completo: leer la guía del flujo, reclamar la issue, implementar en una rama, abrir un PR, atender los comentarios de revisión, esperar a la CI, fusionar según la política elegida en el repositorio y limpiar. Los hitos observables, en orden: aparece una rama, se crea el PR, cambia el estado de la CI, fusión y limpieza de la rama; cada paso corresponde a una fase fija del bucle oficial. Con la política por defecto fully_autonomous_merge, la sesión de trabajo puede avanzar hasta la fusión; antes de la primera ejecución, comprueba que las compuertas de CI y la protección de ramas están en su sitio, o indica en la orden que esta vez se detiene en el PR.

Caso 2: solo descubrir y planificar, sin cambiar nada. Escenario: quieres evaluar primero si el proceso encaja en el repositorio y todavía no piensas dejarle actuar. Ordena al agente: «Lee la guía del flujo, lista todas las issues listas con una idea de implementación para cada una y no reclames ninguna.» Solo se usa la primera mitad del bucle (leer la guía, descubrir issues); no se crean ramas ni PR. Cómo se marca una issue como «lista» no está explicado oficialmente: si el agente informa de una lista vacía, comprueba antes cómo están etiquetados los estados de las issues en el repositorio. El resultado esperable es una lista de issues y un plan de implementación en texto; tu siguiente orden decide si se pasa a implementar. Cuando el plan te parezca sólido, elige una issue y sigue el caso 1 para el bucle completo.

Límites de uso

• Efectos secundarios y puntos de confirmación: la importación copia archivos de la plantilla al repositorio; si solo añade archivos o también modifica los existentes no está dicho oficialmente, así que tras importar revisa primero la lista de cambios que entregue el agente. El bucle completo crea ramas, hace commits, abre PR y avanza hasta la fusión bajo la política por defecto fully_autonomous_merge. No se detalla oficialmente qué acciones piden confirmación previa: delimita explícitamente el alcance permitido en cada orden.
• Acceso a red y comandos: el bucle completo exige un gh CLI autenticado o una integración de GitHub MCP equivalente, y menciona clientes REST como curl; es decir, el agente accede a las API de GitHub a través de esas herramientas durante el bucle (leer issues, crear y fusionar PR, etc.). Qué endpoints exactamente y si hay más accesos de red no se detalla oficialmente.
• Entorno de ejecución y requisitos de cliente: la lista oficial dice que el bucle principal funciona en GitHub Copilot, Claude Code, OpenAI Codex CLI, OpenCode y Antigravity CLI (antes Gemini CLI); si sirven agentes fuera de la lista, si hay requisitos adicionales de sistema operativo o si degrada al faltar dependencias, no está explicado.
• Límites oficiales y desconocidos: el material oficial no menciona la compatibilidad con plataformas de alojamiento distintas de GitHub, ni qué otras políticas de merge existen además de fully_autonomous_merge ni cómo cambiarlas; el comportamiento de reintento del agente tras un fallo de CI tampoco está confirmado. Para estos detalles manda el texto de la guía del flujo importada en el repositorio.