Choose your loop

<!-- Skill générique de la "vague 2" — intervient en amont des templates goals/, workflows/, routines/ -->

Choisir et valider son mécanisme de boucle (avant de rédiger le prompt)

Ce skill s'exécute en amont de goals/goal-templates.md, workflows/workflow-prompts.md et routines/routine-templates.md. Il ne remplace pas ces fichiers : il aide à déterminer lequel piocher, et si le critère de succès de l'utilisateur est réellement exploitable, avant qu'un prompt final ne soit écrit.

1. Identifier le mécanisme visé (ou son absence)

• Si l'utilisateur a déjà nommé un mécanisme précis (/goal, "workflow", "routine", /loop, /schedule), le confirmer explicitement à voix haute ("tu veux dire : ...") avant de poursuivre.
• Si l'utilisateur arrive sans idée précise ("je veux automatiser un truc", "j'aimerais que Claude fasse ça tout seul"), basculer en mode découverte : l'aider à identifier une tâche candidate avant de choisir un mécanisme. Reprendre l'esprit de la méthode de démarrage de docs/guide-complet.md (Partie 1.8) :
  • Quelle tâche répétitive vous fait perdre du temps aujourd'hui ?
  • Pouvez-vous écrire son critère de vérification ?
  • Cette tâche arrive-t-elle selon un planning régulier ? Une fois une tâche candidate identifiée, reprendre à l'étape 2 avec le mécanisme qui semble a priori le plus proche (voir l'arbre de décision à l'étape 4) — sans encore l'annoncer comme définitif.

2. Rappeler le concept en 2-3 phrases maximum

Avant de poser la moindre question, rappeler brièvement ce que fait (et ne fait pas) le mécanisme identifié, en reprenant fidèlement les définitions déjà présentes dans docs/glossaire.md et docs/commandes-utiles.md — ne jamais reformuler une définition différente de celle du guide. Exemples de rappels attendus :

• /goal : étend une boucle turn-based avec un critère de sortie explicite et un plafond de tentatives ; un modèle évaluateur vérifie la condition à chaque tentative. Ne gère pas, seul, l'orchestration de plusieurs agents en parallèle.
• Workflow dynamique : Claude écrit un harnais sur mesure (script) pour découper/orchestrer la tâche en cours, potentiellement avec plusieurs agents et worktrees. Consomme plus de tokens que le mode par défaut — réservé aux tâches complexes à forte valeur ajoutée.
• /loop : relance un prompt à intervalle régulier, sur la machine locale (s'arrête si l'ordinateur s'éteint).
• /schedule (routine) : déplace une boucle time-based dans le cloud, tourne indépendamment de la machine de l'utilisateur.

3. Poser des questions de cadrage structurées

Utiliser des questions à choix structurées si l'outillage du harnais le permet (ex. AskUserQuestion), sinon poser les questions suivantes en une seule fois sous forme de liste claire. Adapter la liste selon le mécanisme déjà identifié à l'étape 1 (ne pas reposer une question déjà répondue explicitement par l'utilisateur) :

1. Le critère de réussite de cette tâche peut-il être vérifié objectivement (test qui passe, score, absence d'erreur), ou est-il actuellement plutôt qualitatif ?
2. Cette tâche est-elle ponctuelle (une seule fois) ou récurrente (elle se représente régulièrement) ?
3. Y a-t-il un déclencheur temporel ou événementiel identifiable (intervalle, arrivée d'un événement externe), ou l'utilisateur veut-il juste lancer quelque chose maintenant ?
4. Le travail peut-il se découper en plusieurs sous-tâches indépendantes qui bénéficieraient d'agents séparés, ou est-ce une tâche unique et linéaire ?
5. (Si le mécanisme envisagé est une routine) Cette routine doit-elle continuer de tourner même si l'utilisateur ferme son ordinateur, ou seulement pendant qu'il travaille dessus activement ?

4. Appliquer un arbre de décision explicite

Ne jamais trancher "au feeling" — appliquer les règles suivantes dans l'ordre, en citant explicitement quelle réponse a mené à quelle conclusion. Ces règles formalisent le tableau récapitulatif de docs/guide-complet.md Partie 1.8 et la distinction /goal vs workflow de la Partie 2 :

• Règle 1 (déclencheur) : si la réponse à Q3 est "aucun déclencheur, juste maintenant" → écarter d'emblée /loop//schedule. Passer à la Règle 2.
• Règle 2 (récurrence) : si la réponse à Q2 est "récurrente" et la réponse à Q3 identifie un intervalle ou un événement externe réel → mécanisme de base = boucle time-based / proactive (/loop si l'exécution doit rester liée à la machine locale d'après Q5, /schedule si elle doit continuer hors ligne). Sinon, passer à la Règle 3.
• Règle 3 (critère vérifiable) : si la réponse à Q1 indique un critère déjà objectivement vérifiable ou reformulable comme tel (voir étape 5) → mécanisme de base = /goal. Si le critère reste irréductiblement qualitatif après la reformulation de l'étape 5 → mécanisme de base = boucle turn-based simple (un bon prompt + un skill de vérification, pas de /goal).
• Règle 4 (découpabilité) : quel que soit le mécanisme de base retenu par les règles 1-3, si la réponse à Q4 indique que la tâche se découpe en sous-tâches indépendantes (plusieurs modules, plusieurs candidats à comparer, plusieurs étapes séquentielles distinctes) → ajouter un workflow dynamique par-dessus le mécanisme de base (ex. /goal + workflow, /schedule + workflow). Si la tâche est unique et linéaire → ne pas ajouter de workflow, le mécanisme de base suffit.
• Règle 5 (garde-fou anti-complaisance) : si le mécanisme réclamé initialement par l'utilisateur à l'étape 1 diverge du résultat des règles 1-4, ne jamais valider le choix initial par complaisance — rendre un verdict ❌ (étape 6) en citant précisément la règle qui contredit ce choix.

5. Détecter et reformuler un critère flou automatiquement

Si le critère de succès donné par l'utilisateur est qualitatif ("le code est propre", "ça doit bien marcher", "les tests passent" sans précision), ne pas se contenter de signaler que c'est flou : proposer activement une reformulation mesurable, dans l'esprit du tableau de docs/guide-complet.md (Tutoriel 2), adaptée au contexte réel décrit par l'utilisateur — par exemple :

Critère donné	Reformulation proposée (à adapter au contexte réel)
"Le code est propre"	"0 warning du linter détecté sur les fichiers modifiés"
"Les tests passent"	"100% des tests de <dossier concerné, à préciser avec l'utilisateur> passent"
"Ça doit bien marcher"	"Le scénario <à préciser> se déroule sans erreur console et produit <résultat observable attendu>"

Si l'utilisateur répond "oui c'est mesurable" sans donner de chemin, de seuil ou de commande précise, creuser une nouvelle fois avant de considérer le critère comme validé (voir Gotchas).

6. Rendre un verdict structuré en trois issues possibles

• ✅ Bon choix, réalisable tel quel — le mécanisme initial (ou identifié en mode découverte) correspond au résultat de l'arbre de décision, et le critère de succès est déjà mesurable. Passer directement à l'étape 7.
• ⚠️ Mécanisme correct mais critère ou déclencheur à ajuster — le mécanisme est validé par l'arbre de décision, mais le critère (étape 5) ou le déclencheur (intervalle, plafond de tentatives) doit être précisé. Présenter la correction proposée, et ne passer à l'étape 7 qu'une fois la correction acceptée explicitement par l'utilisateur.
• ❌ Mauvais mécanisme pour cette tâche — le mécanisme réclamé diverge du résultat de l'arbre de décision (Règle 5). Recommander l'alternative correcte, expliquer en une phrase pourquoi en citant la règle concernée (ex. "Règle 2 : ta tâche n'a pas de déclencheur temporel identifiable, une routine /schedule n'est donc pas adaptée ici"), puis reprendre le questionnement de l'étape 3 sur ce nouveau mécanisme si l'utilisateur est d'accord.

7. Proposer un prompt final à partir des templates existants

Une fois un verdict ✅ obtenu (directement ou après ajustement) :

1. Vérifier d'abord si goals/goal-templates.md, workflows/workflow-prompts.md ou routines/routine-templates.md contient déjà un template proche de la tâche décrite, et proposer de l'adapter (en remplaçant ses placeholders) plutôt que d'en écrire un nouveau intégralement.
2. Si aucun template existant ne correspond, rédiger un nouveau prompt en respectant le format déjà utilisé dans ces fichiers : contexte d'usage en une phrase, prompt complet, plafond de tentatives (/goal) ou budget de tokens explicite (workflow/routine).
3. Rappeler à l'utilisateur qu'un nouveau prompt qui fonctionne bien mérite d'être ajouté au fichier de templates correspondant (voir CONTRIBUTING.md) plutôt que de rester à usage unique.

Gotchas

• Un utilisateur qui répond "oui c'est mesurable" alors que son critère reste en réalité qualitatif une fois creusé (ex. "les tests passent" sans préciser lesquels, sur quel dossier) doit être requestionné plus précisément avant de valider la Règle 3 de l'étape 4 — ne jamais passer à l'étape 6 sur un critère encore ambigu.
• Un utilisateur qui veut absolument un mécanisme précis par habitude ou par name-dropping ("je veux faire un workflow") alors que sa tâche est en réalité une simple boucle turn-based doit recevoir un verdict ❌ clair (Règle 5), sans que le skill se contente de suivre l'intention initiale par complaisance.
• En l'absence de seuils propres à l'équipe, utiliser comme valeurs par défaut les plafonds des templates de goals/goal-templates.md (5 à 8 tentatives) et les budgets de tokens indiqués dans workflows/workflow-prompts.md — et toujours annoncer le seuil retenu explicitement dans le verdict plutôt que de le laisser implicite.