Déploiement de la technique Ralph Wiggum : Tutoriel pas à pas

La technique Ralph Wiggum, pionnière par Geoff Huntley, transforme un grand modèle linguistique en un développeur logiciel entièrement autonome. Au lieu d’écrire le code ligne par ligne, vous donnez au LLM un ensemble clair de prompts, une base spec, et une boucle extérieure qui engage et pousse automatiquement le travail. Ci‑dessous, un guide complet que vous pouvez appliquer à n’importe quel dépôt GitHub—idéalement un projet open‑source qui souhaite livrer des fonctionnalités plus rapidement et avec moins d’erreurs humaines.

1. Qu’est‑ce que Ralph Wiggum ?

• Objectif : Réduire le coût du développement logiciel à moins qu’un salaire de cuisinier de restauration rapide.
• Idée centrale : Un prompt en boucle qui alterne entre les étapes planification et conception. Chaque tour lit la base de code existante, lit le spec, décide de la prochaine tâche en point‑délicat, l’implémente, lance les tests et engage le commit.
• Pourquoi ça marche : La boucle exploite le raisonnement du LLM (Opus ou Sonnet) pour les tâches de haut niveau et des sous‑agents locaux bon marché pour les opérations sur les fichiers et tests. La surcharge des tests assure qu’un seul changement valide est engagé.

2. Structure du projet

/project-root/
├── loop.sh                # Boucle Bash qui pilote Claude
├── PROMPT_build.md        # Prompt mode build
├── PROMPT_plan.md         # Prompt mode plan
├── AGENTS.md              # Guide opérationnel (build, test, lint)
├── IMPLEMENTATION_PLAN.md # Liste priorisée des tâches (générée par Ralph)
├── specs/                 # Un fichier par sujet JTBD (exigences)
└── src/                   # Code source qui va changer

Astuce : Gardez AGENTS.md court (≈60 lignes). Il ne doit contenir que les commandes que Ralph doit exécuter pour valider son travail.

3. Le flux de travail à trois phases

Comment fonctionne la boucle

1. Boucle extérieure (loop.sh) alimente le fichier prompt à Claude.
2. Le prompt demande à Claude d’étudier PROMPT.md, AGENTS.md, specs/*, et src/*.
3. Selon le mode (plan/build), le prompt indique à Ralph de :
4. Planifier : produire une analyse d’écart et écrire un plan en points‑délicat.
5. Construire : choisir la prochaine tâche, l’implémenter, tester, commit.
6. Quand le LLM termine la tâche, la boucle extérieure redémarre avec un nouveau contexte.

Étant donné que l’unique état partagé est le fichier IMPLEMENTATION_PLAN.md sur disque, la boucle ne nécessite aucun orchestration complexe.

4. Les modèles de prompt

4.1 PROMPT_plan.md

0a. Étudier `specs/*` avec jusqu’à 250 sous‑agents Sonnet parallèles.
0b. Étudier @IMPLEMENTATION_PLAN.md (s’il est présent).
0c. Étudier `src/lib/*` avec jusqu’à 250 sous‑agents Sonnet parallèles.

1. Réaliser une analyse d’écart entre les specs et le code.
   Utiliser un sous‑agent Opus pour prioriser les tâches et créer / mettre à jour @IMPLEMENTATION_PLAN.md.
   **NE DOIVENT PAS être implémentées** ; se limiter à la planification.

4.2 PROMPT_build.md

0a. Étudier `specs/*` (jusqu’à 500 sous‑agents Sonnet).
0b. Étudier @IMPLEMENTATION_PLAN.md.

1. Choisir la tâche incomplète la plus importante du plan.
2. Rechercher la base de code pour confirmer son absence.
3. Implémenter la tâche, commit et push.
4. Exécuter tous les tests définis dans AGENTS.md comme surcharge.
5. Mettre à jour @IMPLEMENTATION_PLAN.md pour marquer la tâche comme terminée.

Note : Les garde‑fous 99999 dans PROMPT_build.md imposent les bonnes pratiques comme le commit avec un message informatif et la mise à jour des tags.

5. La boucle Bash (loop.sh)

#!/bin/bash
# Exemples d’utilisation :
#   ./loop.sh          # Mode build, itérations infinies
#   ./loop.sh 20       # Mode build, s’arrête après 20 tâches
#   ./loop.sh plan     # Mode complet de planification, illimité
#   ./loop.sh plan 5   # Planification, max 5 itérations

MODE=${1:-build}
PROMPT_FILE=()
MAX_ITER=${2:-0}

if [[ "$MODE" == "plan" ]]; then
  PROMPT_FILE="PROMPT_plan.md"
elif [[ "$MODE" =~ ^[0-9]+$ ]]; then
  PROMPT_FILE="PROMPT_build.md"
  MAX_ITER=$MODE
else
  PROMPT_FILE="PROMPT_build.md"
fi

ITERATION=0
while true; do
  [[ $MAX_ITER -gt 0 && $ITERATION -ge $MAX_ITER ]] && exit 0
  cat "$PROMPT_FILE" | claude -p \
    --dangerously-skip-permissions \
    --output-format=stream-json \
    --model opus \
    --verbose
  git push
  ITERATION=$((ITERATION+1))
  echo "--- Boucle $ITERATION Complète ---"
do

Ce que ça fait - Démarre une session Claude sans tête. - Approuve automatiquement les appels d’outil (--dangerously-skip-permissions). - Diffuse du JSON pour une surveillance facile. - Pousse à chaque itération pour pouvoir revenir avec git reset --hard si quelque chose va mal.

6. Surcharge hydraulique et tests

Le fichier AGENTS.md liste les commandes exactes à exécuter pour tester, lint, et type‑check. Par exemple :

## Validation
- Exécuter les tests : `npm test`
- Lint : `npm run lint`
- Vérification de type : `npm run tsc --noEmit`

Lorsque Ralph implémente une tâche, il exécutera automatiquement ces tests. Si l’un d’eux échoue, la boucle redémarre et Ralph réenters la phase de construction jusqu’à ce que les tests passent. Cela garantit que chaque commit est prêt pour la production.

7. Améliorations et personnalisation

Mode plan‑work – Lorsque vous avez besoin d’un sprint ciblé, le script de boucle prend désormais plan-work "<description>" pour créer un IMPLEMENTATION_PLAN.md restreint sur une nouvelle branche. Surcharge axée sur l’acceptation – Dans les futures versions, vous pouvez spécifier que chaque tâche planifiée doit inclure un test associé basé sur les critères d’acceptation du spec. Surcharge non déterministe – Utilisez le fixture llm-review pour laisser le LLM juger le ton, la hiérarchie visuelle ou la cohérence de la marque.

N’hésitez pas à ajuster les prompts ou ajouter des garde‑fous, mais souvenez‑vous : laissez le plan séparé de la construction. Ralph fonctionne mieux lorsqu’il décide quelle tâche de faire ensuite, pas quelle sous‑tâche en faire.

8. Mettre tout ensemble

1. Fork du dépôt et clonage.
2. Ajoutez vos fichiers projet dans src/ et créez un specs/*.md par sujet JTBD.
3. Exécutez ./loop.sh plan pour produire un plan initial.
4. Lancez l’infrastructure : ./loop.sh.
5. Observez les logs ; quand le plan est vide, le projet est construit.
6. Ouvrez une PR, mergez, et répétez pour la prochaine fonctionnalité.

Ce flux de travail transforme un LLM en assistant‑développeur qui gère le travail de base — boucle sur les tâches, teste en vol, et engage du code propre, tout en restant transparent et sous contrôle de version.

9. Points clés

• La boucle est le cœur : un seul fichier (IMPLEMENTATION_PLAN.md) relie tout.
• Séparer la planification et la construction : les deux utilisent la même infrastructure de prompt mais diffèrent dans l’action et la sortie.
• La surcharge n’est pas optionnelle : tests, lint, et type‑check imposent la qualité.
• Vous pouvez évoluer : utilisez la planification ciblée pour des fonctionnalités lourdes, ou conservez le fichier complet pour de petits projets.
• Le LLM ne vaut que vos prompts : gardez les prompts concis, utilisez study plutôt que read, et clôturez avec des instructions de haut niveau.

Avec ce guide, vous disposez désormais d’une feuille de route complète pour lancer la technique Ralph Wiggum dans n’importe quel projet — transformer une IA en un développeur autonome qui fonctionne à une fraction du coût.