Compétence Boucles Autonomes
Note de compatibilité (v1.8.0) :
autonomous-loopsest conservé pour une version. Le nom canonique de la compétence est désormaiscontinuous-agent-loop. Les nouvelles directives pour les boucles doivent être rédigées dans cette dernière, tandis que cette compétence reste disponible pour ne pas casser les workflows existants.
Modèles, architectures et implémentations de référence pour exécuter Claude Code de manière autonome en boucles. Couvre tout, des simples pipelines claude -p aux systèmes d'orchestration DAG multi-agents pilotés par RFC.
Quand l'utiliser
- Mettre en place des workflows de développement autonomes qui s'exécutent sans intervention humaine
- Choisir la bonne architecture de boucle pour votre problème (simple vs complexe)
- Construire des pipelines de développement continu de type CI/CD
- Exécuter des agents en parallèle avec une coordination de fusion
- Implémenter la persistance du contexte entre les itérations de boucle
- Ajouter des portes de qualité et des passes de nettoyage aux workflows autonomes
Spectre des modèles de boucle
Du plus simple au plus sophistiqué :
| Modèle | Complexité | Meilleur pour |
|---|---|---|
| Pipeline séquentiel | Faible | Étapes de développement quotidiennes, workflows scriptés |
| REPL NanoClaw | Faible | Sessions persistantes interactives |
| Boucle agentique infinie | Moyenne | Génération de contenu parallèle, travail piloté par spécifications |
| Boucle PR continue de Claude | Moyenne | Projets itératifs sur plusieurs jours avec portes CI |
| Modèle de dé-gadgétisation | Ajout | Nettoyage de qualité après toute étape d'implémentation |
| Ralphinho / DAG piloté par RFC | Élevée | Fonctionnalités volumineuses, travail parallèle multi-unités avec file d'attente de fusion |
1. Pipeline séquentiel (claude -p)
La boucle la plus simple. Décomposez le développement quotidien en une séquence d'appels non interactifs claude -p. Chaque appel est une étape ciblée avec une invite précise.
Aperçu essentiel
Si vous ne pouvez pas concevoir une boucle comme celle-ci, cela signifie que vous ne pouvez même pas pousser le LLM à corriger votre code en mode interactif.
Le drapeau claude -p exécute Claude Code de manière non interactive avec une invite, puis se termine. Enchaînez les appels pour construire un pipeline :
#!/bin/bash
# daily-dev.sh — Pipeline séquentiel pour une branche de fonctionnalité
set -e
# Étape 1 : Implémenter la fonctionnalité
claude -p "Lisez la spec dans docs/auth-spec.md. Implémentez la connexion OAuth2 dans src/auth/. Écrivez les tests d'abord (TDD). NE créez AUCUN nouveau fichier de documentation."
# Étape 2 : Dé-gadgétiser (passage de nettoyage)
claude -p "Passez en revue tous les fichiers modifiés par le commit précédent. Supprimez tous les tests de type inutiles, les vérifications excessivement défensives, ou les tests de fonctionnalités du langage (par exemple, tester que les génériques TypeScript fonctionnent). Gardez les tests de logique métier réels. Exécutez la suite de tests après le nettoyage."
# Étape 3 : Vérifier
claude -p "Exécutez la build complète, le lint, la vérification de type et la suite de tests. Corrigez toute défaillance. N'ajoutez pas de nouvelles fonctionnalités."
# Étape 4 : Commiter
claude -p "Créez un commit conventionnel pour toutes les modifications en staging. Utilisez 'feat: ajouter le flux de connexion OAuth2' comme message."
Principes de conception clés
- Chaque étape est isolée — Une nouvelle fenêtre de contexte par appel
claude -psignifie aucune fuite de contexte entre les étapes. - L'ordre compte — Les étapes s'exécutent séquentiellement. Chacune repose sur l'état du système de fichiers laissé par la précédente.
- Les instructions négatives sont dangereuses — Ne dites pas "ne testez pas les systèmes de types". Ajoutez plutôt une étape de nettoyage séparée (voir Modèle de dé-gadgétisation).
- Les codes de sortie se propagent —
set -earrête le pipeline en cas d'échec.
Variantes
Avec routage de modèle :
# Recherche avec Opus (raisonnement profond)
claude -p --model opus "Analysez l'architecture du codebase et écrivez un plan pour ajouter la mise en cache..."
# Implémentation avec Sonnet (rapide, capable)
claude -p "Implémentez la couche de cache selon le plan dans docs/caching-plan.md..."
# Révision avec Opus (approfondi)
claude -p --model opus "Passez en revue toutes les modifications pour les problèmes de sécurité, les conditions de course et les cas limites..."
Avec contexte d'environnement :
# Passer le contexte via des fichiers, pas par la longueur de l'invite
echo "Domaines d'intérêt : module d'authentification, limitation de débit API" > .claude-context.md
claude -p "Lisez .claude-context.md pour les priorités. Travaillez-les dans l'ordre."
rm .claude-context.md
Avec restrictions --allowedTools :
# Passage d'analyse en lecture seule
claude -p --allowedTools "Read,Grep,Glob" "Auditez ce codebase pour les vulnérabilités de sécurité..."
# Passage d'implémentation en écriture seule
claude -p --allowedTools "Read,Write,Edit,Bash" "Implémentez les correctifs de security-audit.md..."
2. REPL NanoClaw
La boucle persistante intégrée d'ECC. Un REPL conscient de la session qui appelle claude -p de manière synchrone avec l'historique complet de la conversation.
# Démarrer la session par défaut
node scripts/claw.js
# Session nommée avec contexte de compétence
CLAW_SESSION=my-project CLAW_SKILLS=tdd-workflow,security-review node scripts/claw.js
Comment ça fonctionne
- Charge l'historique de conversation depuis
~/.claude/claw/{session}.md - Chaque message utilisateur est envoyé à
claude -pavec l'historique complet comme contexte - Les réponses sont ajoutées au fichier de session (Markdown comme base de données)
- Les sessions persistent entre les redémarrages
Quand NanoClaw vs Pipeline séquentiel
| Cas d'utilisation | NanoClaw | Pipeline séquentiel |
|---|---|---|
| Exploration interactive | Oui | Non |
| Automatisation scriptée | Non | Oui |
| Persistance de session | Intégrée | Manuelle |
| Accumulation de contexte | Croît par tour | Frais à chaque étape |
| Intégration CI/CD | Médiocre | Excellente |
Voir la documentation de la commande /claw pour tous les détails.
3. Boucle agentique infinie
Un système à deux invites qui orchestre des sous-agents parallèles pour une génération pilotée par spécification. Développé par disler (crédit : @disler).
Architecture : Système à deux invites
INVITE 1 (Orchestrateur) INVITE 2 (Sous-agents)
┌─────────────────────┐ ┌──────────────────────┐
│ Analyser le fichier spec │ Recevoir le contexte complet │
│ Scanner le répertoire de sortie │ Lire le numéro attribué │
│ Planifier l'itération │ Suivre la spec exactement │
│ Attribuer les directions créatives│ Générer une sortie unique │
│ Gérer les vagues │ Sauvegarder dans le répertoire│
└─────────────────────┘ └──────────────────────┘
Le modèle
- Analyse de la spécification — L'orchestrateur lit un fichier de spécification (Markdown) définissant quoi générer
- Reconnaissance du répertoire — Scanne la sortie existante pour trouver le numéro d'itération le plus élevé
- Déploiement parallèle — Lance N sous-agents, chacun avec :
- La spec complète
- Une direction créative unique
- Un numéro d'itération spécifique (pas de conflits)
- Un instantané des itérations existantes (pour l'unicité)
- Gestion des vagues — Pour le mode infini, déploie des vagues de 3 à 5 agents jusqu'à épuisement du contexte
Implémentation via les commandes Claude Code
Créez .claude/commands/infinite.md :
Analysez les arguments suivants de $ARGUMENTS :
1. spec_file — chemin vers le markdown de spécification
2. output_dir — où les itérations sont sauvegardées
3. count — entier 1-N ou "infinite"
PHASE 1 : Lire et comprendre profondément la spécification.
PHASE 2 : Lister output_dir, trouver le numéro d'itération le plus élevé. Commencer à N+1.
PHASE 3 : Planifier les directions créatives — chaque agent reçoit un thème/approche DIFFÉRENT.
PHASE 4 : Déployer les sous-agents en parallèle (outil Task). Chacun reçoit :
- Le texte complet de la spec
- L'instantané actuel du répertoire
- Leur numéro d'itération attribué
- Leur direction créative unique
PHASE 5 (mode infini) : Boucler en vagues de 3 à 5 jusqu'à ce que le contexte soit faible.
Invoquer :
/project:infinite specs/component-spec.md src/ 5
/project:infinite specs/component-spec.md src/ infinite
Stratégie de traitement par lots
| Nombre | Stratégie |
|---|---|
| 1-5 | Tous les agents simultanément |
| 6-20 | Lots de 5 |
| infini | Vagues de 3-5, sophistication progressive |
Aperçu essentiel : Unicité via l'attribution
Ne comptez pas sur les agents pour se différencier eux-mêmes. L'orchestrateur attribue à chaque agent une direction créative spécifique et un numéro d'itération. Cela empêche les concepts en double entre agents parallèles.
4. Boucle PR continue de Claude
Un script shell de qualité production qui exécute Claude Code en boucle continue, créant des PR, attendant le CI, et fusionnant automatiquement. Créé par AnandChowdhary (crédit : @AnandChowdhary).
Boucle centrale
┌─────────────────────────────────────────────────────┐
│ ITÉRATION CLAUDE CONTINUE │
│ │
│ 1. Créer une branche (continuous-claude/iteration-N)│
│ 2. Exécuter claude -p avec invite améliorée │
│ 3. (Optionnel) Passage de révision — claude -p séparé │
│ 4. Commiter les modifications (Claude génère le message) │
│ 5. Pousser + créer PR (gh pr create) │
│ 6. Attendre les vérifications CI (sondage gh pr checks) │
│ 7. Échec CI ? → Passage de correction automatique (claude -p) │
│ 8. Fusionner PR (squash/merge/rebase) │
│ 9. Revenir à main → répéter │
│ │
│ Limiter par : --max-runs N | --max-cost $X │
│ --max-duration 2h | signal d'achèvement │
└─────────────────────────────────────────────────────┘
Installation
Avertissement : Installez continuous-claude depuis son dépôt après avoir examiné le code. Ne pipez pas de scripts externes directement vers bash.
Utilisation
# Basique : 10 itérations
continuous-claude --prompt "Ajouter des tests unitaires pour toutes les fonctions non testées" --max-runs 10
# Limité par coût
continuous-claude --prompt "Corriger toutes les erreurs de lint" --max-cost 5.00
# Limité par temps
continuous-claude --prompt "Améliorer la couverture de test" --max-duration 8h
# Avec passage de révision de code
continuous-claude \
--prompt "Ajouter la fonctionnalité d'authentification" \
--max-runs 10 \
--review-prompt "Exécuter npm test && npm run lint, corriger les échecs"
# Parallèle via worktrees
continuous-claude --prompt "Ajouter des tests" --max-runs 5 --worktree tests-worker &
continuous-claude --prompt "Refactoriser le code" --max-runs 5 --worktree refactor-worker &
wait
Contexte inter-itération : SHARED_TASK_NOTES.md
L'innovation cruciale : un fichier SHARED_TASK_NOTES.md persiste entre les itérations :
## Progression
- [x] Ajouté des tests pour le module auth (itération 1)
- [x] Corrigé le cas limite dans le rafraîchissement du token (itération 2)
- [ ] Manque encore : tests de limitation de débit, tests de limites d'erreur
## Prochaines étapes
- Se concentrer sur le module de limitation de débit ensuite
- La configuration mock dans tests/helpers.ts peut être réutilisée
Claude lit ce fichier au début de l'itération et le met à jour à la fin de l'itération. Cela comble le fossé de contexte entre les invocations indépendantes de claude -p.
Récupération d'échec CI
Lorsque les vérifications PR échouent, Continuous Claude automatiquement :
- Récupère l'ID d'exécution échouée via
gh run list - Lance un nouveau
claude -pavec le contexte de correction CI - Claude inspecte les logs via
gh run view, corrige le code, commit, pousse - Attend à nouveau les vérifications (jusqu'à --ci-retry-max tentatives)
Signal d'achèvement
Claude peut signaler "j'ai fini" en produisant une phrase magique :
continuous-claude \
--prompt "Corriger tous les bugs dans le tracker d'issues" \
--completion-signal "CONTINUOUS_CLAUDE_PROJECT_COMPLETE" \
--completion-threshold 3 # S'arrête après 3 signaux consécutifs
Trois itérations consécutives signalant l'achèvement arrêtent la boucle, évitant les exécutions inutiles sur un travail terminé.
Configuration clé
| Drapeau | But |
|---|---|
--max-runs N | S'arrêter après N itérations réussies |
--max-cost $X | S'arrêter après avoir dépensé $X |
--max-duration 2h | S'arrêter après le temps écoulé |
--merge-strategy squash | squash, merge ou rebase |
--worktree <nom> | Exécution parallèle via git worktrees |
--disable-commits | Mode simulation (aucune opération git) |
--review-prompt "..." | Ajouter un passage de révision par itération |
--ci-retry-max N | Correction automatique des échecs CI (défaut : 1) |
5. Le modèle de dé-gadgétisation
Un modèle complémentaire pour toute boucle. Ajoutez une étape de nettoyage/refactorisation dédiée après chaque étape d'implémentation.
Le problème
Lorsque vous demandez à un LLM d'implémenter avec TDD, il prend "écrire des tests" trop littéralement :
- Tests qui vérifient que le système de types de TypeScript fonctionne (tester
typeof x === 'string') - Vérifications d'exécution excessivement défensives pour des choses que le système de types garantit déjà
- Tests pour le comportement du framework plutôt que pour la logique métier
- Gestion d'erreurs excessive qui obscurcit le code réel
Pourquoi pas des instructions négatives ?
Ajouter "ne testez pas les systèmes de types" ou "n'ajoutez pas de vérifications inutiles" à l'invite de l'implémenteur a des effets en aval :
- Le modèle devient hésitant sur TOUS les tests
- Il saute des tests de cas limites légitimes
- La qualité se dégrade de manière imprévisible
La solution : Passage séparé
Au lieu de contraindre l'implémenteur, laissez-le être approfondi. Ajoutez ensuite un agent de nettoyage ciblé :
# Étape 1 : Implémenter (laissez-le être approfondi)
claude -p "Implémentez la fonctionnalité avec TDD complet. Soyez approfondi avec les tests."
# Étape 2 : Dé-gadgétiser (contexte séparé, nettoyage ciblé)
claude -p "Passez en revue toutes les modifications dans l'arbre de travail. Supprimez :
- Les tests qui vérifient le comportement du langage/framework plutôt que la logique métier
- Les vérifications de type redondantes que le système de types impose déjà
- La gestion d'erreurs excessivement défensive pour des états impossibles
- Les instructions console.log
- Le code commenté
Gardez tous les tests de logique métier. Exécutez la suite de tests après le nettoyage pour garantir que rien ne casse."
Dans un contexte de boucle
for feature in "${features[@]}"; do
# Implémenter
claude -p "Implémentez $feature avec TDD."
# Dé-gadgétiser
claude -p "Passage de nettoyage : révisez les modifications, supprimez le désordre de test/code, exécutez les tests."
# Vérifier
claude -p "Exécutez build + lint + tests. Corrigez les échecs."
# Commiter
claude -p "Commitez avec le message : feat: ajouter $feature"
done
Aperçu essentiel
Plutôt que d'ajouter des instructions négatives qui ont des effets de qualité en aval, ajoutez une passe de dé-gadgétisation séparée. Deux agents ciblés surpassent un agent contraint.
6. Ralphinho / Orchestration DAG pilotée par RFC
Le modèle le plus sophistiqué. Un pipeline multi-agent piloté par RFC, avec des phases séquentielles et des agents parallèles coordonnés via des documents d'architecture partagés. Créé par ralphinho (crédit : @ralphinho).
Architecture DAG
┌────────────────────────────────────────────────────────────┐
│ PIPELINE DAG MULTI-AGENT │
│ │
│ PHASE 1 : Spécification │
│ ┌─────────────────┐ │
│ │ Plan de produit │ → RFC technique │
│ └─────────────────┘ │
│ ↓ │
│ PHASE 2 : Conception │
│ ┌─────────────────┐ │
│ │ Document archi │ → Plan d'implémentation │
│ └─────────────────┘ │
│ ↓ │
│ PHASE 3 : Implémentation (parallèle) │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Agent 1 │ │ Agent 2 │ │ Agent 3 │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ ↓ │
│ PHASE 4 : Intégration │
│ ┌─────────────────┐ │
│ │ File d'attente │ → Fusion, révision │
│ │ de fusion │ │
│ └─────────────────┘ │
└────────────────────────────────────────────────────────────┘
Les phases
Phase 1 : Spécification
Le premier agent lit les exigences et produit un RFC technique :
claude -p "Lisez le plan produit dans docs/product-plan.md. Générez un RFC technique couvrant :
- Architecture du système
- Modèles de données
- API endpoints
- Considérations de sécurité
- Stratégie de test
Écrivez dans docs/rfc-auth-system.md"
Phase 2 : Conception
Le deuxième agent transforme le RFC en un plan d'exécution détaillé :
claude -p "Lisez docs/rfc-auth-system.md. Créez un plan d'implémentation dans docs/implementation-plan.md avec :
- Unités de travail atomiques
- Dépendances entre unités
- Ordre d'implémentation
- Responsables des tests"
Phase 3 : Implémentation parallèle
Plusieurs agents implémentent des unités indépendantes simultanément :
# Agent 1 : Module d'authentification
claude -p "Implémentez le module auth selon docs/implementation-plan.md. Écrivez dans src/auth/" &
# Agent 2 : Modèles de données
claude -p "Implémentez les modèles de données selon docs/implementation-plan.md. Écrivez dans src/models/" &
# Agent 3 : API endpoints
claude -p "Implémentez les endpoints API selon docs/implementation-plan.md. Écrivez dans src/api/" &
wait
Phase 4 : Intégration et file d'attente de fusion
Un agent d'intégration fusionne les branches, exécute la suite de tests complète et coordonne les corrections :
# Fusionner toutes les branches d'implémentation dans une branche d'intégration
git merge --no-ff feature-auth feature-models feature-api -m "feat: intégration système auth"
# Exécuter la suite de tests et corriger les conflits
claude -p "Exécutez la suite de tests complète. Corrigez tous les conflits de fusion ou échecs de test.
Contexte :
- Module auth : src/auth/
- Modèles : src/models/
- API : src/api/
Assurez-vous que tous les composants fonctionnent ensemble."
Quand utiliser ce modèle
Ce modèle est préféré lorsque :
- La fonctionnalité est volumineuse — Plus de 5 unités de travail
- L'équipe a de l'expérience — Vous avez déjà utilisé les modèles plus simples
- La coordination est critique — Plusieurs composants doivent s'intégrer proprement
- La qualité est primordiale — Chaque phase a ses propres garde-fous de qualité
Pièges clés
- Zèle de spécification — Passer trop de temps à peaufiner les RFC et plans. Utilisez le modèle Pipeline Séquentiel ou Boucle Agentique Infinie pour les tâches plus petites.
- Désalignement de la file d'attente de fusion — Assurez-vous que l'agent d'intégration a les bons droits d'accès et la connaissance des dépendances.
- Fatigue de contexte — Chaque phase réinitialise le contexte, donc les décisions antérieures peuvent être perdues. Utilisez les RFC et plans persistants pour atténuer.
Guide de sélection
| Votre situation | Modèle de boucle à utiliser |
|---|---|
| "J'ai besoin d'automatiser mes étapes de dev quotidiennes" | Pipeline séquentiel claude -p |
| "Je veux un REPL interactif avec persistance de session" | NanoClaw REPL |
| "Je dois générer beaucoup de contenu créatif en parallèle" | Boucle agentique infinie |
| "Je veux un pipeline CI/CD continu avec fusion automatique" | Boucle PR continue de Claude |
| "Mon IA implémenteur écrit trop de tests inutiles" | Ajouter le modèle de dé-gadgétisation |
| "Je construis une fonctionnalité massive avec plusieurs composants" | Ralphinho / Orchestration DAG |
Prochaines étapes
Pour l'avenir, cette compétence sera remplacée par continuous-agent-loop. Migrez vos workflows existants lorsque vous le pouvez.