Loop It

Que fait Loop It ?

Transformez un objectif de codage ouvert en une boucle vérifiable et limitée. Loop It est aussi une bibliothèque de boucles : choisissez la boucle de démarrage adaptée, adaptez-la au contexte de l'utilisateur et suivez la progression pour que la boucle suivante soit évidente.

Décision

D'abord, déterminez le mode dont l'utilisateur a besoin :

• Trouver dans la bibliothèque : sélectionnez une boucle préintégrée pour l'objectif de l'utilisateur.
• Suite de la progression : inspectez .loop-it/progress.json ou .loop-it/LOOP.md et recommandez la boucle suivante.
• Conception uniquement : produisez un prompt de boucle réutilisable ou un fichier de boucle local au projet.
• Exécuter maintenant : effectuez une itération limitée à la fois, vérifiez-la et décidez si une autre itération est justifiée.
• Exporter/installer : adaptez la même boucle pour Codex, Claude Code, Cursor ou un autre agent compatible SKILL.md.

Si la tâche est vague, ne posez pas un vaste questionnaire de découverte. Recommandez d'abord la meilleure boucle de la bibliothèque et énoncez l'hypothèse. Ne posez que trois questions ciblées au maximum lorsque l'objectif, le critère de succès, le périmètre du dépôt ou la limite d'approbation est vraiment bloquant.

Contrat

Chaque boucle nécessite ces champs avant l'exécution :

• Objectif : le résultat concret, pas un thème.
• Périmètre : dépôt, fichiers, zone fonctionnelle, source de données ou environnement.
• Vérification de succès : commande, benchmark, inspection manuelle, critère de revue ou seuil mesurable.
• Limite d'itérations : nombre maximal de passes ou budget de temps.
• Conditions d'arrêt : succès, absence d'amélioration significative, échec répété, accès bloqué, action dangereuse ou nécessité d'approbation.
• Preuve : ce qui doit être enregistré après chaque passe.
• Palier d'approbation : écritures en production, messages externes, paiements, opérations git destructrices, identifiants, déploiements ou modifications irréversibles des données.

Opposez-vous lorsque la boucle demandée se résume à "continuer à améliorer" sans vérification. Proposez plutôt une boucle plus petite avec une vérification claire.

Sélectionner une boucle

Préférez la bibliothèque préintégrée plutôt que d'inventer une boucle de toutes pièces.

Utilisez le script de sélection lorsqu'il est disponible :

node <skill-dir>/scripts/select-loop.mjs list
node <skill-dir>/scripts/select-loop.mjs search "ci en échec"
node <skill-dir>/scripts/select-loop.mjs recommend --goal "corriger le test de checkout qui échoue"
node <skill-dir>/scripts/select-loop.mjs next --cwd <projet>

Résolvez <skill-dir> vers le dossier de cette compétence. Dans Claude Code, ${CLAUDE_SKILL_DIR} peut être disponible. Dans d'autres agents, localisez le répertoire qui contient ce SKILL.md.

Lors de la sélection :

1. Vérifiez d'abord .loop-it/progress.json lorsque l'utilisateur demande quoi faire ensuite.
2. Si aucune progression n'existe, faites correspondre l'objectif de l'utilisateur avec references/library/loops.json.
3. Recommandez une boucle, plus au maximum deux alternatives.
4. Expliquez la correspondance en une phrase.
5. Ne posez les questions principales de la boucle que si nécessaire.
6. Si aucune boucle de la bibliothèque ne convient, concevez une boucle personnalisée et dites qu'elle devrait être envisagée pour la bibliothèque après s'être avérée utile.

Lisez references/library/loops.json uniquement lorsque le script de sélection n'est pas disponible ou qu'une inspection manuelle est nécessaire. Lisez references/loop-template.md lorsque la tâche nécessite le format générique d'état persistant.

Les catégories actuelles de la bibliothèque incluent :

• Ticket vers correctif vérifié : reproduire, diagnostiquer, corriger, ajouter une couverture de régression, vérifier.
• Réparation CI en échec : inspecter la sortie en échec, reproduire, corriger, relancer la vérification.
• Révision de documentation : comparer la documentation à l'implémentation, mettre à jour la documentation obsolète, vérifier les exemples ou les liens.
• Évaluation de produit : définir des scénarios et des critères, tester, corriger les lacunes, relancer les vérifications concernées et complètes.
• Boucle de performance : mesurer la baseline, faire un changement ciblé, remesurer, ne conserver que les gains prouvés.
• Boucle de réparation de revue : examiner la diff, corriger les problèmes bloquants, relancer les vérifications, répéter jusqu'à ce qu'il ne reste que des risques acceptés.
• Boucle de configuration initiale : partir d'un environnement propre, suivre la configuration documentée, corriger les hypothèses cachées, recommencer proprement.
• Préparation à la publication : vérifier le package, le déploiement ou les chemins d'installation publique avant publication.
• Polissage UX, mise à jour de dépendances, durcissement de sécurité, confinement de refactorisation et boucles de couverture de tests.

Rédiger la boucle

Utilisez cette structure pour les prompts et les fichiers d'état de boucle :

1. Énoncez l'objectif et les non-objectifs.
2. Définissez l'action répétée en un cycle serré : inspecter, agir, vérifier, enregistrer, décider.
3. Nommez la commande de vérification exacte ou l'inspection manuelle.
4. Définissez la limite d'itérations et les conditions d'arrêt.
5. Définissez ce que le rapport final doit inclure.

Gardez la version 1 étroite : un dépôt, un rôle principal, une vérification de succès principale. Reportez la planification, les tableaux de bord, l'orchestration multi-agents et l'automatisation de production jusqu'à ce qu'une boucle manuelle se soit avérée utile.

Lorsqu'un fichier d'état persistant est utile, créez .loop-it/LOOP.md à partir de references/loop-template.md ou exécutez :

node <skill-dir>/scripts/create-loop.mjs --name "Nom de la boucle" --objective "Résultat concret" --check "Commande de vérification ou critère"
node <skill-dir>/scripts/create-loop.mjs --from reparation-ci-en-echec

Les fichiers de boucle basés sur la bibliothèque créent également .loop-it/progress.json sauf si --no-progress est passé.

Exécuter la boucle

Pour chaque itération :

1. Relisez l'objectif, la vérification de succès, la limite et les paliers d'approbation.
2. Inspectez uniquement le contexte nécessaire pour la prochaine action limitée.
3. Faites le plus petit changement crédible.
4. Exécutez d'abord la vérification la plus étroite pertinente, puis des vérifications plus larges uniquement si nécessaire.
5. Enregistrez les preuves dans .loop-it/LOOP.md lorsqu'un fichier d'état existe et mettez à jour .loop-it/progress.json lorsqu'il est présent.
6. Décidez : arrêter, continuer, demander une approbation ou signaler un blocage.

Arrêtez immédiatement lorsque continuer nécessiterait des hypothèses implicites sur la sécurité, les identifiants, les données de production, la facturation, les messages utilisateur, les opérations git destructrices ou l'approbation de déploiement.

Ne décrivez pas une boucle épuisée, bloquée ou partiellement vérifiée comme terminée. Dites exactement quelle condition l'a arrêtée et quelles preuves existent.

Exporter

Utilisez le même texte de boucle pour tous les outils, en ne changeant que l'invocation :

• Codex : installez sous .agents/skills/loop-it/ ou comme plugin Codex, puis invoquez avec $loop-it.
• Claude Code : installez sous .claude/skills/loop-it/, puis invoquez avec /loop-it.
• Cursor : installez sous .cursor/skills/loop-it/, puis invoquez depuis le Chat Agent avec /loop-it ou en demandant une boucle. Utilisez les règles Cursor pour les conventions de projet toujours actives, pas pour cette boucle procédurale.

Lors de l'exportation, conservez un corps de boucle canonique et évitez la syntaxe spécifique à un outil, sauf si cet outiel l'exige.