103kaz/claude-code-loops

review-loop

Exécute la boucle de développement sur la branche actuelle : vérification, relecture du diff, correction, et répète jusqu'à ce qu'un tour ne trouve rien. Le périmètre est limité au diff uniquement, pas à l'ensemble du code. Cette compétence ne pousse pas ni n'ouvre de pull request ; ces actions restent à la charge de l'utilisateur.

Étapes

1. Exécute .claude/verify.sh. S'il échoue, corrige-le en premier. Si le fichier n'existe pas, informe l'utilisateur et pointe vers /code-loops:init-verify, puis poursuit sans vérification et le mentionne dans le rapport.
2. Détermine le diff. Premier tour : la branche par rapport à sa base (git diff origin/HEAD...HEAD, plus git diff HEAD pour les changements non commités, plus les fichiers non suivis de git status --short, que tu lis directement). Si origin/HEAD n'est pas défini, essaie origin/main ou origin/master ; si aucun n'existe, demande à l'utilisateur la base. Si le diff est vide (par exemple tu es sur la branche de base elle-même), signale qu'il n'y a rien à relire et arrête-toi. Si des changements non commités semblent sans rapport avec le travail de la branche, ne les corrige pas ; mentionne-les dans le rapport. Tours suivants : seulement ce que tu as modifié au tour précédent.
3. Relit le diff.
   • S'il modifie du code, utilise la compétence code-review avec un effort moyen. Si cette compétence n'est pas disponible, lis le diff toi-même pour détecter les bogues : résultats erronés, chemins d'erreur manquants, et appelants que la modification casse.
   • S'il ne modifie que de la documentation (.md et similaires), utilise /code-loops:doc-code-consistency sur le diff à la place.
4. Corrige les constatations. Ne commite pas ; laisse cela à l'utilisateur. Après chaque correction, retourne à l'étape 1. Répète jusqu'à ce qu'un tour ne trouve rien. Une constatation que tu décides de ne pas corriger reçoit une raison en une ligne. Si trois tours consécutifs produisent encore des constatations (un échec de verify.sh compte), arrête-toi et signale ce qui reste au lieu de continuer.
5. Si le diff a modifié du code que la documentation décrit, exécute /code-loops:doc-code-consistency sur le diff une fois à la fin et corrige ce qu'il trouve.
6. Propose une relecture indépendante, une fois, sauf si le diff ne concerne que de la documentation. Demande à l'utilisateur (AskUserQuestion) s'il souhaite l'exécuter, avec une note d'une ligne sur la pertinence de ce diff (taille, zones risquées) ; la réponse par défaut est non. Si oui, démarre un sous-agent qui ne voit que le diff, pas comment il a été construit. Utilise un type d'agent en lecture seule s'il existe (par exemple Explore) ; sinon, dis-lui de ne pas modifier les fichiers. Demande-lui de rechercher les entrées, états et ordonnancements qui cassent la modification, et de signaler chaque cas avec preuve fichier:ligne ; si .claude/review/checklist.md existe, demande-lui de vérifier aussi par rapport à cela. Corrige ce qu'il trouve, puis exécute les étapes 1 et 3 sur ces corrections uniquement. Si les sous-agents ne sont pas disponibles, ignore cette étape et le mentionne dans le rapport.
7. Rapporte en quelques lignes : "Résultat : aucune constatation", ou "Résultat : constatations conservées" avec chaque constatation et sa raison. Ajoute si verify.sh a réussi, combien de tours cela a pris, et si une relecture indépendante a eu lieu.

Garde chaque tour discret : lis le diff, pas le dépôt, et ne répète pas les constatations d'un tour antérieur.