autonomous-loops

Compétence Boucles Autonomes

Note de compatibilité (v1.8.0) : autonomous-loops est conservé pour une version. Le nom canonique de la compétence est désormais continuous-agent-loop. Les nouvelles directives de boucle doivent être rédigées là-bas, tandis que cette compétence reste disponible pour éviter de 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 pipelines simples claude -p à l'orchestration DAG multi-agents complète pilotée par RFC.

Quand l'utiliser

• Mettre en place des workflows de développement autonomes qui fonctionnent 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 parallèles avec coordination de fusion
• Implémenter la persistance du contexte entre les itérations de boucle
• Ajouter des contrôles 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 parallèle de contenu, travail piloté par spécifications
Boucle PR Continue Claude	Moyenne	Projets itératifs multi-jours avec contrôles CI
Modèle Anti-Désordre	Complément	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 claude -p non interactifs. Chaque appel est une étape ciblée avec une invite claire.

Idée centrale

Si vous ne pouvez pas configurer une boucle comme celle-ci, cela signifie que vous ne pouvez même pas piloter le LLM pour corriger votre code en mode interactif.

Le flag 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 spécification dans docs/auth-spec.md. Implémentez la connexion OAuth2 dans src/auth/. Écrivez d'abord les tests (TDD). NE créez AUCUN nouveau fichier de documentation."

# Étape 2 : Anti-désordre (passe de nettoyage)
claude -p "Passez en revue tous les fichiers modifiés par le commit précédent. Supprimez 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). Conservez 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 stagées. Utilisez le message 'feat: add OAuth2 login flow'."

Principes de conception clés

1. Chaque étape est isolée — Une nouvelle fenêtre de contexte par appel claude -p signifie aucune fuite de contexte entre les étapes.
2. L'ordre compte — Les étapes s'exécutent séquentiellement. Chacune se base sur l'état du système de fichiers laissé par la précédente.
3. 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 Anti-Désordre).
4. Les codes de sortie se propagent — set -e arrê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 mise en cache selon le plan dans docs/caching-plan.md..."

# Révision avec Opus (approfondie)
claude -p --model opus "Passez en revue tous les changements pour les problèmes de sécurité, les conditions de concurrence et les cas limites..."

Avec contexte d'environnement :

# Passez le contexte via des fichiers, pas 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 :

# Passe d'analyse en lecture seule
claude -p --allowedTools "Read,Grep,Glob" "Auditez ce codebase pour les vulnérabilités de sécurité..."

# Passe 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 de l'ECC. Un REPL conscient de la session qui appelle claude -p de manière synchrone avec l'historique complet de la conversation.

# Démarrez 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

1. Charge l'historique de la conversation depuis ~/.claude/claw/{session}.md
2. Chaque message utilisateur est envoyé à claude -p avec l'historique complet comme contexte
3. Les réponses sont ajoutées au fichier de session (Markdown comme base de données)
4. 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	Nouveau à chaque étape
Intégration CI/CD	Faible	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 la 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 de spec│             │ Recevoir le contexte complet │
│ Scanner le répertoire de sortie│  déploie   │ Lire le numéro assigné      │
│ Planifier l'itération  │────────────│ Suivre la spec exactement   │
│ Assigner les directions │  N agents  │ Générer une sortie unique   │
│ Gérer les vagues       │             │ Sauvegarder dans le répertoire│
└─────────────────────┘             └──────────────────────┘

Le Modèle

1. Analyse de la spec — L'orchestrateur lit un fichier de spécification (Markdown) définissant quoi générer
2. Reconnaissance du répertoire — Scanne la sortie existante pour trouver le numéro d'itération le plus élevé
3. 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é)
4. 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 fichier de spécification Markdown
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é du répertoire actuel
  - Leur numéro d'itération assigné
  - 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 Lot

Nombre	Stratégie
1-5	Tous les agents simultanément
6-20	Lots de 5
infini	Vagues de 3 à 5, sophistication progressive

Idée clé : Unicité par Assignation

Ne comptez pas sur les agents pour se différencier eux-mêmes. L'orchestrateur assigne à chaque agent une direction créative spécifique et un numéro d'itération. Cela empêche les concepts en double entre les agents parallèles.

---

4. Boucle PR Continue 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 enrichie         │
│  3. (Optionnel) Passe de révision — claude -p séparé│
│  4. Commiter les modifications (claude génère le msg)│
│  5. Pousser + créer PR (gh pr create)                │
│  6. Attendre les vérifications CI (gh pr checks)     │
│  7. Échec CI ? → Passe de correction auto (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 directement des scripts externes 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ée par coût
continuous-claude --prompt "Corriger toutes les erreurs de linter" --max-cost 5.00

# Limitée dans le temps
continuous-claude --prompt "Améliorer la couverture de test" --max-duration 8h

# Avec passe 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 toute défaillance"

# Parallèle via les 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 critique : un fichier SHARED_TASK_NOTES.md persiste entre les itérations :

## Progression
- [x] Tests ajoutés pour le module d'authentification (itération 1)
- [x] Cas limite corrigé dans le rafraîchissement de jeton (itération 2)
- [ ] Reste à faire : tests de limitation de débit, tests de périmètre d'erreur

## Prochaines Étapes
- Se concentrer sur le module de limitation de débit ensuite
- La configuration simulée 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 en Cas d'Échec CI

Lorsque les vérifications de PR échouent, Continuous Claude automatiquement :

1. Récupère l'ID de l'exécution échouée via gh run list
2. Lance un nouveau claude -p avec le contexte de correction CI
3. Claude inspecte les logs via gh run view, corrige le code, commit, pousse
4. Ré-attend les vérifications (jusqu'à --ci-retry-max tentatives)

Signal d'Achèvement

Claude peut signaler "j'ai terminé" en produisant une phrase magique :

continuous-claude \
  --prompt "Corriger tous les bogues dans le gestionnaire de tickets" \
  --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, empêchant des exécutions gaspillées sur un travail terminé.

Configuration Clé

Flag	Objectif
--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 <name>	Exécution parallèle via git worktrees
--disable-commits	Mode test (pas d'opérations git)
--review-prompt "..."	Ajouter une passe de révision par itération
--ci-retry-max N	Correction auto des échecs CI (par défaut : 1)

---

5. Le Modèle Anti-Désordre

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 les 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 concernant TOUS les tests
• Il saute des tests de cas limites légitimes
• La qualité se dégrade de manière imprévisible

La Solution : Passe Séparée

Au lieu de contraindre l'implémenteur, laissez-le être minutieux. Ajoutez ensuite un agent de nettoyage ciblé :

# Étape 1 : Implémenter (laissez-le être minutieux)
claude -p "Implémentez la fonctionnalité avec TDD complet. Soyez minutieux avec les tests."

# Étape 2 : Anti-désordre (contexte séparé, nettoyage ciblé)
claude -p "Passez en revue tous les changements 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 trop défensive pour des états impossibles
- Les instructions console.log
- Le code commenté

Conservez tous les tests de logique métier. Exécutez la suite de tests après le nettoyage pour vous assurer que rien ne casse."

Dans un Contexte de Boucle

for feature in "${features[@]}"; do
  # Implémenter
  claude -p "Implémentez $feature avec TDD."

  # Anti-désordre
  claude -p "Passe de nettoyage : révisez les changements, supprimez le désordre de test/code, exécutez les tests."

  # Vérifier
  claude -p "Exécutez build + lint + tests. Corrigez toute défaillance."

  # Commiter
  claude -p "Commitez avec le message : feat: add $feature"
done

Idée Clé

Plutôt que d'ajouter des instructions négatives qui ont des effets sur la qualité en aval, ajoutez une passe anti-désordre séparée. Deux agents ciblés sont plus efficaces qu'un agent contraint.

---

6. Ralphinho / Orchestration DAG Pilotée par RFC

Le modèle le plus sophistiqué. Un pipeline multi-agents piloté par RFC qui décompose le travail en unités indépendantes, attribue chaque unité à un implémenteur, et fusionne via une file d'attente de fusion organisée.

Architecture : DAG de Tâches Piloté par RFC

┌───────────────────────────────────────────────────────┐
│  ÉTAPE 0 : L'UTILISATEUR DÉFINIT LE SCOPE             │
│  → Crée une RFC décrivant ce qu'il veut construire    │
└───────────────────────────────────────────────────────┘
                      ↓
┌───────────────────────────────────────────────────────┐
│  ÉTAPE 1 : CLAUDE DIVISE LA RFC                       │
│  → Décompose le problème en unités de travail (tâches)│
│  → Identifie les dépendances entre les unités         │
│  → Détecte également des chemins parallèles           │
└───────────────────────────────────────────────────────┘
                      ↓
┌───────────────────────────────────────────────────────┐
│  ÉTAPE 2 : EXÉCUTION DAG PARALLÈLE                    │
│  → 5-10 agents travaillent chacun sur une unité       │
│  → Chaque agent : apporte des changements dans sa propre branche│
│  → Aucun conflit de fusion car travail isolé par fichier│
└───────────────────────────────────────────────────────┘
                      ↓
┌───────────────────────────────────────────────────────┐
│  ÉTAPE 3 : FILE D'ATTENTE DE FUSION ORGANISÉE         │
│  → Les PR sont fusionnées dans l'ordre des dépendances │
│  → Résolution de conflits par lots                    │
│  → Tests CI après chaque fusion                       │
└───────────────────────────────────────────────────────┘

Fichier RFC

Un fichier de spécification Markdown structuré avec une décomposition claire des tâches :

# RFC : Système d'authentification OAuth2

## Résumé
Implémenter la connexion OAuth2 avec des fournisseurs Google et GitHub.

## Unités de Travail

### Unité 1 : Modèle de données
- Créer la table de base de données User
- Ajouter le champ auth_provider et external_id
- Fichier : server/src/models/User.ts

### Unité 2 : Intégration Google OAuth
- Implémenter l'écoulement OAuth2 avec Google
- Fichier : server/src/auth/google.ts
- Dépend de : Unité 1

### Unité 3 : Intégration GitHub OAuth
- Implémenter l'écoulement OAuth2 avec GitHub
- Fichier : server/src/auth/github.ts
- Dépend de : Unité 1

### Unité 4 : Gestion de session
- Gérer les jetons JWT et les cookies de session
- Fichier : server/src/auth/session.ts
- Dépend de : Unité 2, Unité 3

Implémentation de l'Orchestrateur

Créez un script d'orchestrateur qui automatise le pipeline :

#!/bin/bash
# orchestrator.sh — Orchestrateur DAG piloté par RFC

set -e

RFC_FILE="$1"

# Étape 1 : Claude divise la RFC en unités de travail
claude -p "Lisez $RFC_FILE. Identifiez chaque unité de travail, ses dépendances et les fichiers impliqués. Créez .task-plan.json avec la structure : [{id, description, files, dependencies, branch}]."

# Étape 2 : Exécution parallèle
for unit in $(jq -r '.[] | .id' .task-plan.json); do
  branch="feature/$unit"
  description=$(jq -r ".[] | select(.id == \"$unit\") | .description" .task-plan.json)
  files=$(jq -r ".[] | select(.id == \"$unit\") | .files | join(\" \")" .task-plan.json)

  git checkout -b "$branch"
  claude -p "Implémentez : $description. Les fichiers concernés sont : $files."
  git add .
  git commit -m "feat: $description"
  git push origin "$branch"
  gh pr create --base main --title "$description" --body "Implémente l'unité $unit de la RFC."
  git checkout main
done

# Étape 3 : Fusion ordonnée
for unit in $(jq -r '.[] | select(.dependencies == [] or .dependencies == null) | .id' .task-plan.json); do
  branch="feature/$unit"
  gh pr merge "$branch" --merge --auto
  wait_for_ci
  git pull origin main
done

Gestion des Dépendances

Identifiez les dépendances entre les unités et fusionnez dans l'ordre :

	Unité A	Unité B	Unité C	Unité D
Dépend de	-	-	A	A, B
Ordre de fusion	1er	2ème	3ème	4ème

Quand Utiliser Ralphinho

• Fonctionnalités volumineuses : Plus de 5 unités de travail
• Tâches indépendantes : Les unités peuvent être implémentées isolément
• Équipes multiples : Chaque agent travaille sur une zone différente
• Besoins de fusion complexes : Dépendances de fusion non triviales
• Longue files d'attente : Beaucoup de travail à traiter dans une session

Idée Clé

RafFhinho divise le problème en unités atomiques qui ne se chevauchent pas (par fichier), permettant aux agents de travailler en parallèle sans conflits de fusion. La file d'attente de fusion ordonnée par dépendances garantit l'intégrité du codebase.