Que fait Review Loop ?

Cycle itératif travailleur-reviseur au sein d'une session unique. Vous effectuez le travail, engendrez un sous-agent réviseur pour le critiquer, révisez selon les retours, et répétez jusqu'à atteindre un seuil de qualité.

Principe fondamental : Les premières ébauches ne sont jamais définitives. La critique itérative produit un meilleur résultat qu'un passage unique.

Remarque sur la plateforme : Cette compétence fonctionne mieux avec des agents supportant le spawn de sous-agents. Sur les plateformes sans cette capacité, simulez l'étape de révision en ouvrant un nouveau contexte de discussion, en collant uniquement le livrable (sans le raisonnement antérieur), et en demandant une note de 1 à 10 avec des commentaires spécifiques.

Démarrage rapide

Dites : « implémente X, utilise review-loop » ou « exécute review-loop sur le fichier que je viens d'écrire »
L'agent effectue le travail (ou lit le travail existant)
Un sous-agent critique distinct note le travail de 1 à 10 avec des commentaires spécifiques
L'agent révise et répète jusqu'à ce que la note soit >= 8 (seuil de qualité par défaut)
Un résumé de la boucle est fourni avec le résultat final

Quand l'utiliser

L'utilisateur dit « utilise review-loop », « peaufine ceci », « itère sur ceci », « /review-loop »
Implémentations complexes où la qualité prime sur la vitesse
Documents de conception, spécifications ou écriture technique
Code nécessitant d'être robuste (sécurité, pipelines de données, logique financière)
Lorsque l'utilisateur souhaite une critique contradictoire intégrée au processus

Quand NE PAS l'utiliser

Correctifs simples, modifications rapides, changements en une ligne
Tâches où les tests sont le seuil de qualité (utilisez TDD + CI à la place)
Lorsque l'utilisateur souhaite simplement que ce soit fait rapidement
Travail exploratoire / de prototypage où l'objectif est l'apprentissage, pas la livraison
Tâches sans critères d'acceptation clairs — définissez-les d'abord, puis utilisez review-loop

Paramètres par défaut

Paramètre	Défaut
Boucles min	2
Boucles max	4
Seuil de qualité	8/10
Modèle travailleur	(votre modèle actuel)
Modèle réviseur	(votre modèle actuel ou alternative rapide/équilibrée)

Sélection du modèle

La tâche de révision évalue la logique et les contraintes. La tâche de travail écrit et modifie le code. Choisissez les capacités des sous-agents en conséquence.

RÈGLE CRITIQUE : Le réviseur doit toujours ÊTRE ÉGAL OU PLUS PUISSANT que le travailleur. Si le réviseur est plus faible que le travailleur, il ne peut pas critiquer correctement la logique complexe ou détecter des régressions subtiles.

Complexité de la tâche	Capacité du travailleur	Capacité du réviseur	Justification
Simple/mécanique (CRUD, formatage, code standard)	Rapide / Léger	Équilibré	Le travailleur léger est rapide, le réviseur équilibré détecte facilement les problèmes
Standard (fonctionnalités, refontes, documentation)	Équilibré	Équilibré	Bon compromis coût, vitesse et qualité
Complexe (multi-fichiers, intégration, conception)	Équilibré	Avancé / Raisonnement	Le réviseur avancé détecte les problèmes d'architecture subtils, le travailleur équilibré peut les implémenter
Très complexe (sécurité, quantitatif, systèmes distribués)	Avancé / Raisonnement	Avancé / Raisonnement	Les deux ont besoin d'un contexte complet et d'une capacité de raisonnement. Le réviseur DOIT correspondre à la puissance du travailleur.

La règle d'or : Le travailleur doit être suffisamment intelligent pour AGIR sur les commentaires du réviseur. Si le réviseur dit « corrigez la condition de concurrence avec un sémaphore basé sur les canaux » et que le travailleur ne peut pas raisonner sur la concurrence, la boucle ne convergera pas.

Signal d'escalade : Si la note ne s'améliore pas après 2 boucles consécutives avec les mêmes commentaires, le modèle du travailleur est trop faible. Escaladez :

Option A : Demandez à l'utilisateur de passer à un modèle plus performant
Option B : Abaissez temporairement le seuil de qualité et notez l'écart pour l'utilisateur
Option C : Divisez la tâche en sous-tâches plus petites et exécutez review-loop sur chacune

Comportement par défaut : Puisque vous (l'agent principal) ÊTES le travailleur, engendrez un sous-agent réviseur qui correspond ou dépasse votre capacité actuelle en fonction de la tâche :

Tâches les plus courantes → Réviseur Standard/Équilibré
Tâches spécialisées/difficiles → Réviseur Avancé/Raisonnement
Vérifications rapides → Réviseur Rapide/Léger (uniquement si vous agissez également comme un travailleur léger)

Dérogations utilisateur

Les utilisateurs peuvent remplacer n'importe quel paramètre par défaut en ligne avec leur demande. Analysez-les naturellement :

« implémente X avec review-loop, qualité 9, utilise le modèle avancé pour la révision, max 5 boucles »
« peaufine ceci, 2 boucles minimum, seuil à 8 »
« exécute review-loop avec réviseur rapide, max 2 boucles »
« utilise review-loop, réviseur raisonnement, qualité 9, min 3 max 6 »

Règles d'analyse :

« qualité N » ou « seuil N » → quality_gate = N
« réviseur [modèle] » ou « révision avec [modèle] » → remplacement du modèle réviseur
« max N boucles » → max_loops = N
« min N boucles » → min_loops = N
Si l'utilisateur ne spécifie pas, utilisez les valeurs par défaut
Si l'utilisateur dit « approfondi » ou « strict » → interprétez comme quality_gate 8, min_loops 2
Si l'utilisateur dit « rapide » ou « vite fait » → interprétez comme max_loops 2, quality_gate 6

Le processus

flowchart TD
    A[Faire le travail] --> B[Engendrer sous-agent réviseur]
    B --> C{Boucles min atteintes ?}
    C -- non, continuer toujours --> E[Réviser selon les retours]
    C -- oui --> D{Note >= seuil de qualité ?}
    D -- oui --> F[Passage de polissage final]
    D -- non --> G{Boucles max atteintes ?}
    G -- oui, arrêter quand même --> F
    G -- non --> E
    E --> B
    F --> H([Fait])

Étape par Étape

Étape 1 : Faire le travail

Effectuez la tâche comme vous le feriez normalement. Écrivez le code, créez la spécification, implémentez la fonctionnalité. Ne vous retenez pas — produisez votre meilleure première tentative.

Étape 2 : Engendrer un sous-agent réviseur

Utilisez l'outil Agent pour envoyer un réviseur. Le réviseur doit :

Être un sous-agent séparé (contexte vierge, sans ancrage dans votre raisonnement)
Recevoir uniquement le livrable (fichiers, diffs) — pas votre processus de réflexion
Noter de 1 à 10 avec des commentaires spécifiques et exploitables
Utiliser un modèle équilibré/standard par défaut (ou un modèle de raisonnement avancé pour les tâches complexes/spécialisées)

Modèle d'invite réviseur :

Vous êtes un réviseur critique. Notez le travail suivant de 1 à 10 et fournissez des commentaires spécifiques et exploitables.

## Ce qui a été fait
{brief description of the task}

## Critères de révision
{task-specific criteria — what matters for THIS task}

Exemples de critères bien rédigés :
  Pour un point de terminaison d'API REST :
    - Codes d'état HTTP corrects utilisés
    - Validation des entrées présente sur tous les paramètres
    - Authentification appliquée ; pas d'accès non authentifié
    - Pas de modèles de requête N+1

  Pour un document de conception :
    - L'énoncé du problème est sans ambiguïté
    - Alternatives envisagées avec compromis
    - Pas d'approximations sur la complexité de l'implémentation
    - Les mesures de succès sont mesurables

  Pour un pipeline de données :
    - Idempotent — sûr à réexécuter
    - Les modifications de schéma sont gérées avec élégance
    - Les modes de défaillance documentés
    - Gestion des PII traitée

## Instructions
1. Lisez attentivement le travail
2. Notez de 1 à 10 où :
   - 1-3 : Fondamentalement cassé ou manquant d'exigences majeures
   - 4-6 : Fonctionne mais présente des problèmes significatifs
   - 7-8 : Bon, problèmes mineurs uniquement
   - 9-10 : Excellent, prêt à être livré
3. Listez les problèmes spécifiques avec les références fichier:ligne le cas échéant
4. Pour chaque problème, expliquez POURQUOI il est important et QUOI corriger
5. Ne soyez pas poli — soyez honnête et direct
6. Énoncez clairement votre note comme « Note : N/10 »

## Fichiers à réviser
{paste file contents or list file paths with relevant excerpts}

Étape 3 : Analyser les commentaires

À partir de la réponse du réviseur, extrayez :

Note (le nombre)
Problèmes (catégorisés en Critique / Important / Mineur)
Correctifs spécifiques (quoi modifier)

Rapportez à l'utilisateur :

Boucle {N}/{max} : Note {X}/10
- {résumé des principaux points de retour}

Étape 4 : Vérifier les conditions d'arrêt

Dans cet ordre :

Si les boucles effectuées < boucles_min → continuer (toujours)
Si la note >= seuil_qualité → arrêter, passer au polissage final
Si les boucles effectuées >= boucles_max → arrêter, passer au polissage final
Sinon → réviser et boucler

Étape 5 : Réviser

Répondre aux commentaires du réviseur. Corrigez les problèmes Critiques et Importants. Les problèmes Mineurs sont facultatifs. Revenez ensuite à l'Étape 2.

Important : Chaque révision doit être ciblée. Ne réécrivez pas tout — corrigez ce que le réviseur a signalé. Maintenez une liste mentale de TOUS les commentaires antérieurs pour éviter les régressions.

Étape 6 : Polissage final

Une fois la boucle terminée (seuil de qualité atteint ou boucles max atteintes) :

Corrigez tout problème mineur restant s'il est trivial
Vérifiez que le résultat final est cohérent (pas d'artefacts des cycles de révision)
Rapportez la note finale et le nombre de boucles à l'utilisateur

Adaptation des critères de révision par type de tâche

Type de tâche	Le réviseur doit se concentrer sur
Code	Exactitude, cas limites, gestion des erreurs, lisibilité, absence de problèmes de sécurité
Spécification/Conception	Complétude, faisabilité, pas d'approximations, capacité d'implémentation
Refonte	Aucun changement de comportement, aucune régression, plus propre qu'avant
Rédaction	Clarté, structure, adapté au public, pas de verbiage
Correction de bogue	Cause racine traitée, test de régression existant, pas d'effets secondaires
Infrastructure / IaC	Idempotence, moindre privilège, pas de secrets codés en dur, sécurité de destruction
Migration de base de données	Réversibilité, stratégie d'index, risque de perte de données, performance à l'échelle
Conception d'API	Rétrocompatibilité, authentification, versioning, contrat d'erreur
Suite de tests	Couverture des cas limites, pas d'interdépendance des tests, assertions significatives

Deux modes de fonctionnement

Mode A : « Faire et réviser » (cycle complet)

L'utilisateur donne une tâche + demande d'utiliser review-loop. Vous effectuez le travail ET exécutez la boucle de révision.

Utilisateur : « Implémente la couche de cache. Utilise review-loop, qualité 8. »

Vous :
1. Implémentez la couche de cache
2. Engendrez le réviseur → Note 6, retour : éviction manquante, pas de TTL
3. Révisez : ajoutez éviction + TTL
4. Engendrez le réviseur → Note 8, retour : critique mineure sur le nom
5. Polissage final, terminé

Mode B : « Réviser l'existant » (révision uniquement)

L'utilisateur a déjà fait le travail ou vous l'avez déjà fait. Exécutez simplement la boucle de révision sur ce qui existe.

Utilisateur : « Exécute review-loop sur le module d'authentification que je viens d'écrire »

Vous :
1. Lisez le module d'authentification
2. Engendrez le réviseur → Note 5, retour : injection SQL, pas de limitation de débit
3. Corrigez : paramétrez les requêtes, ajoutez un limiteur de débit
4. Engendrez le réviseur → Note 8, approuvé
5. Terminé

Drapeaux rouges

Ne jamais :

Faire une auto-révision au lieu d'engendrer un sous-agent (biais d'ancrage)
Sauter un cycle de révision parce que « les commentaires sont erronés » sans justification
Gonfler votre propre note (« Je pense que c'est en fait un 9 »)
Continuer au-delà du nombre maximum de boucles sans le consentement de l'utilisateur
Engendrer le réviseur avec votre raisonnement/historique complet (ils doivent réviser le TRAVAIL, pas votre intention)

Si le réviseur a tort :

Répondez avec des preuves (montrez du code/des tests qui infirment le retour)
Ignorez ce point spécifique dans la révision
Notez-le dans votre rapport à l'utilisateur
N'abaissez PAS la barre de qualité pour compenser

Exemple de format de rapport

--- Boucle de révision : {nom de la tâche} ---

Boucle 1/4 : Note 6/10
  Réviseur : Validation des entrées manquante, pas de gestion d'erreur pour le délai d'attente réseau,
             fonction trop longue (80 lignes).
  Action : Correction des trois problèmes.

Boucle 2/4 : Note 8/10
  Réviseur : Propre. Mineur : le nom de variable `d` pourrait être plus descriptif.
  Action : Seuil de qualité atteint (8 >= 8). Polissage final.

Résultat : 8/10 en 2 boucles. Terminé.

Limitations connues

Le sous-agent réviseur n'a pas de mémoire des boucles précédentes — incluez explicitement le contexte des retours antérieurs dans chaque invite réviseur pour éviter de répéter les problèmes résolus
L'inflation des notes est possible si les critères de l'invite réviseur sont trop vagues — investissez du temps dans la rédaction de critères spécifiques et mesurables
Cette compétence ne remplace pas la revue de code humaine pour le code critique pour la sécurité ou sensible à la conformité ; considérez le résultat comme un premier passage solide
La convergence de la boucle n'est pas garantie si la tâche est sous-spécifiée — définissez des critères d'acceptation clairs avant de commencer

Coût et rapidité

Chaque boucle = 1 appel de sous-agent réviseur
Budgetez environ 1 à 2 fois le temps d'un seul passage d'implémentation pour un cycle complet de 3 boucles
C'est peu coûteux par rapport à la livraison de code buggé, de spécifications vagues, ou au déclenchement d'un cycle de révision tardif
Utilisez votre modèle par défaut/standard pour la plupart des révisions ; passez aux modèles de raisonnement avancés uniquement pour les domaines spécialisés (audits de sécurité, systèmes distribués, finance quantitative)

Licence

MIT — libre à utiliser, adapter et redistribuer avec tout outil ou plateforme d'IA. Attribution appréciée. Contributions bienvenues.

Review Loop

Qu'est-ce que Review Loop ?

Demander à votre IA préférée

Documentation