Agentic Loop for GitHub Workflows

Une tâche itérative sur un repo (CI cassée, lint à corriger, PR à faire passer) n'est pas juste "corriger et réessayer" — c'est une boucle avec un objectif vérifiable et des limites explicites. Cette skill structure la boucle pour éviter deux échecs classiques : (1) tourner indéfiniment sans savoir si on avance, (2) déclarer "terminé" sur un critère flou.

La boucle

1. Observer — lire l'état réel avant d'agir : gh pr checks, logs CI, diff courant, fichiers concernés. Ne jamais supposer l'état ; le vérifier.
2. Décider — une action ciblée, pas une réécriture large. Préférer le fix minimal qui adresse la cause identifiée dans les logs.
3. Exécuter — appliquer l'action (edit, commit).
4. Vérifier — contrôler contre le critère d'arrêt (voir ci-dessous), pas contre une impression.
5. Décider la suite — continuer, corriger différemment, rollback, ou stop.
6. Stop — dès que le critère vérifiable est atteint. Ne pas continuer "pour être sûr".

Vérification objective vs subjective

C'est le point qui détermine si la boucle peut tourner seule ou doit impliquer l'humain :

• Objectif (l'agent peut juger seul) : CI verte, tests passants, markdownlint sans erreur, build qui compile, PR mergeable sans conflit. → boucler jusqu'au critère.
• Subjectif (l'agent ne peut pas juger seul) : qualité d'une doc bilingue, pertinence d'un roadmap, ton d'un README. → ne pas boucler sans critère ; demander à l'utilisateur quel test appliquer ("est-ce que la structure en 3 phases te convient ?"), ou proposer un critère proxy vérifiable (ex. "présence des sections X, Y, Z" plutôt que "qualité perçue").