Agentic Loop Github

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").

Si la tâche mélange les deux (ex. fix CI + réécriture de doc), traiter chaque partie séparément avec son propre critère.

Cadrage d'itération (garde-fou anti-dérive)

Avant de lancer une boucle de correction :

• Fixer un nombre max de tentatives (3–5 pour un fix CI ciblé ; ne pas dépasser sans repasser par l'utilisateur).
• Détecter la stagnation : si la même erreur réapparaît après 2 tentatives différentes, ce n'est probablement pas un problème de syntaxe mais de compréhension — s'arrêter et exposer le blocage plutôt que de continuer à deviner.
• Ne jamais silencieusement dépasser la limite convenue ; si elle est atteinte, rapporter l'état et demander comment procéder.

Rollback

Si une tentative aggrave l'état (nouvelle erreur CI, conflit introduit) :

• Revenir à l'état stable connu avant de retenter (git checkout -- , ou reset de la branche de travail si plusieurs commits sont impliqués).
• Ne jamais empiler des correctifs sur un état déjà cassé sans comprendre pourquoi il l'est.

Mémoire à deux niveaux

• Mémoire de tâche (le fil de la PR/session en cours) : ce qui a déjà été tenté et pourquoi ça a échoué — évite de retenter la même chose.
• Mémoire long terme (patterns réutilisables entre repos) : les erreurs récurrentes déjà connues (ex. MD013/MD033 à désactiver systématiquement, actions/checkout@v5 requis avant la dépréciation Node 20 de septembre 2026, ordre git operation correct pour éviter les conflits d'encodage) devraient être consignées une fois résolues, pas redécouvertes à chaque repo.

Exemple appliqué

Tâche : "CI markdownlint échoue sur ce repo, corrige-la."

• Critère d'arrêt objectif : gh pr checks passe au vert.
• Boucle : lire l'erreur exacte → corriger la ligne concernée → push → re-vérifier CI → si échec différent, recommencer ; si échec identique après 2 essais, arrêter et signaler.
• Pas de rollback nécessaire si chaque commit est un fix isolé et vérifié avant le suivant.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: valorisa
• Source: valorisa/Claude-Skills
• License: MIT
• Homepage: https://resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf

Install and usage instructions live in the source repository linked above.