IDD Skill : workflow de développement piloté par les issues

À qui ça s'adresse

• Développeurs et petites équipes qui mènent leur développement quotidien dans leur propre dépôt Git et veulent inscrire « de l'issue au merge » dans un processus répétable : après l'import, l'agent de code IA présent dans le dépôt suit le workflow décrit officiellement — découvrir les issues prêtes, revendiquer la responsabilité, implémenter sur une branche, ouvrir une PR, traiter les retours de revue, attendre la CI, fusionner selon la politique de merge choisie dans le dépôt, puis nettoyer. Le projet décrit ce workflow comme « portable » : il s'importe avec le dépôt au lieu d'être lié à un seul outil.
• Développeurs qui utilisent plusieurs outils de code IA et ne veulent pas enfermer le processus dans un seul client : d'après la documentation officielle, la boucle principale fonctionne sur GitHub Copilot, Claude Code, OpenAI Codex CLI, OpenCode et Antigravity CLI (anciennement Gemini CLI).
• Équipes qui ont besoin de plusieurs sessions de travail faisant avancer des issues différentes en parallèle : la documentation officielle indique que la politique par défaut du mode distribué est fully_autonomous_merge, qui laisse les sessions de travail aller jusqu'à la fusion ; la façon dont les sessions se coordonnent et évitent les conflits n'est pas documentée.
• Ce qu'il faut vérifier avant d'adopter : la page officielle ne dit pas si les plateformes d'hébergement autres que GitHub sont prises en charge — point non confirmé ; si l'équipe n'accepte pas la fusion entièrement automatique, il faut d'abord évaluer ou ajuster cette politique par défaut, et les méthodes d'ajustement ne sont pas documentées.

Premier essai en 3 minutes

• Prérequis : un dépôt Git où vous avez le droit de créer des branches et d'ouvrir des PR ; un environnement pourvu des dépendances officiellement listées pour la boucle complète — git, un gh CLI authentifié (ou une intégration GitHub MCP équivalente, l'un des deux suffit), jq, et un client REST comme curl.
• Lieu et méthode d'installation : aucune copie manuelle de fichiers. La méthode officielle consiste à donner directement l'instruction d'import à l'agent IA dans le dépôt cible ; le guide d'onboarding se charge de copier le modèle.
• Déclenchement : ouvrez un agent pris en charge dans le dépôt et saisissez mot pour mot l'instruction officielle ci-dessous :

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

• Limitez le premier essai à des actions à faible risque : demandez à l'agent de lire le guide du workflow, de lister les issues prêtes existantes et d'exposer son plan pour la suite — sans rien revendiquer ni modifier le code. Le point de départ officiel de la boucle est précisément « lire le guide, découvrir une issue prête, la revendiquer » ; tant qu'aucune revendication n'a lieu, vous pouvez l'interrompre à tout moment.
• Signal de réussite : l'agent restitue les points clés du workflow et liste correctement les issues existantes — l'import et la lecture du guide sont opérationnels ; les fichiers du modèle copiés dans le dépôt signifient que l'onboarding est terminé. Aucun chemin précis n'est donné officiellement : fiez-vous à la sortie réelle de l'agent (non confirmé).

Cas d'usage

Cas 1 : mener une issue prête jusqu'au bout. Scénario : le backlog contient déjà des issues marquées prêtes et vous voulez vérifier la boucle fermée de la revendication à la fusion. Donnez pour consigne : « Revendique une issue prête et mène l'implémentation à terme. » L'agent parcourt la boucle officielle complète — lecture du guide, revendication de l'issue, implémentation sur branche, ouverture d'une PR, traitement des retours de revue, attente de la CI, fusion selon la politique choisie dans le dépôt, puis nettoyage. Les jalons observables, dans l'ordre : apparition d'une branche, création de la PR, changement d'état de la CI, fusion et nettoyage de la branche — chaque étape correspond à une phase fixe de la boucle officielle. Avec la politique par défaut fully_autonomous_merge, la session de travail peut aller jusqu'à la fusion ; avant la première exécution, vérifiez donc que les gardes CI et la protection des branches sont en place, ou précisez dans la consigne que cette fois on s'arrête à la PR.

Cas 2 : seulement découvrir et planifier, ne rien modifier. Scénario : vous voulez d'abord évaluer si le processus convient au dépôt, sans encore le laisser agir. Consigne : « Lis le guide du workflow, liste toutes les issues prêtes avec une piste d'implémentation pour chacune, ne revendique rien. » Seule la première moitié de la boucle est utilisée (lecture du guide, découverte des issues) ; aucune branche ni PR n'est créée. La façon dont une issue est marquée « prête » n'est pas documentée : si l'agent renvoie une liste vide, vérifiez d'abord comment les statuts des issues sont posés dans le dépôt. Le résultat attendu est une liste d'issues et un plan d'implémentation textuel ; c'est votre consigne suivante qui décide si l'on passe à l'implémentation. Une fois le plan jugé solide, choisissez une issue et suivez le cas 1 pour la boucle complète.

Limites d'utilisation

• Effets de bord et points de confirmation : l'import copie les fichiers du modèle dans le dépôt ; s'il se limite à ajouter des fichiers ou modifie aussi des fichiers existants, la documentation ne le dit pas — après l'import, consultez d'abord la liste des changements fournie par l'agent. La boucle complète crée des branches, committe du code, ouvre des PR et va jusqu'à la fusion sous la politique par défaut fully_autonomous_merge. Les actions qui déclenchent au préalable une confirmation ne sont pas listées officiellement : délimitez donc explicitement le périmètre autorisé dans chaque consigne.
• Accès réseau et commandes : la boucle complète exige un gh CLI authentifié ou une intégration GitHub MCP équivalente, et nomme des clients REST comme curl — l'agent accède donc aux API GitHub via ces outils pendant la boucle (lecture des issues, création et fusion de PR, etc.) ; quels endpoints exactement et s'il existe d'autres accès réseau ne sont pas détaillés officiellement.
• Environnement d'exécution et prérequis clients : la liste officielle indique que la boucle principale fonctionne sur GitHub Copilot, Claude Code, OpenAI Codex CLI, OpenCode et Antigravity CLI (anciennement Gemini CLI) ; le fonctionnement avec des agents hors liste, d'éventuelles exigences OS supplémentaires et un éventuel mode dégradé en cas de dépendances manquantes ne sont pas documentés.
• Limites officielles et inconnues : le matériau officiel ne mentionne pas la prise en charge de plateformes d'hébergement autres que GitHub, ni quelles autres politiques de merge existent en plus de fully_autonomous_merge ni comment basculer ; le comportement de relance de l'agent après un échec de CI n'est pas confirmé non plus — pour ces détails, le texte du guide du workflow importé dans le dépôt fait foi.