« /feature-loop Ajoute la pagination cursor-based à l'endpoint /api/posts »
L'agent mère évalue la difficulté, puis délègue à trois sous-agents distincts : un pour le code, un autre qui rédige les tests depuis la spec (sans voir l'implémentation), un relecteur aveugle. Avant toute revue LLM, un gate objectif vérifie build, lint, typecheck, tests, et que les tests savent bien échouer. La boucle tourne jusqu'à ce que chaque axe atteigne 8/10, avec un rapport final et la meilleure version conservée.
Ce que ça fait
Un agent mère évalue la difficulté puis délègue à des sous-agents SÉPARÉS : celui qui écrit le code n'est ni celui qui écrit les tests (rédigés depuis la spec), ni le relecteur aveugle. Un gate objectif (build, lint, typecheck, tests, plus une vérification que les tests savent échouer) tombe AVANT toute revue par un LLM. Toute feature exécutable passe un smoke test live obligatoire avant le moindre « testé ».
Quand l'utiliser
Pour une vraie feature où la qualité prime sur la vitesse brute. La boucle tourne jusqu'à ce que chaque axe de qualité atteigne 8/10 sans critique (3 itérations max), garde la meilleure version et émet un rapport. Pas pour une retouche rapide (fais-la directement) ni une simple relecture (utilise senior-review).
Le parti pris : un agent qui écrit le code ne peut pas le juger objectivement. D'où la séparation stricte (writer, test-writer et relecteur sont trois agents différents) et le gate objectif AVANT toute revue par un LLM. Les tests doivent prouver qu'ils savent échouer, sinon un test toujours vert passe pour une garantie.
Installer ce skill
$ /plugin marketplace add ohugonnot/claude-skills
$ /plugin install feature-loop@web-developpeur-skills
Questions fréquentes
Quand est-ce que j'utilise /feature-loop plutôt que de coder directement ?
Quand la qualité prime sur la vitesse : feature non triviale, logique critique, code qui doit tenir dans la durée. Pour une retouche rapide ou un rename, fais-le directement.
En quoi est-ce différent de /senior-review ?
/feature-loop construit la feature en boucle itérative avec gate objectif et sous-agents séparés. /senior-review relit du code déjà écrit avant un merge. Les deux ne se substituent pas.
Pourquoi les tests doivent-ils savoir échouer avant la revue LLM ?
Un test qui passe quoi qu'il arrive ne prouve rien. Le gate vérifie explicitement qu'en cassant l'implémentation, les tests deviennent rouges, sinon ils sont rejetés avant même la revue.
Retours & discussion · 0
Aucun retour pour l'instant. Tu l'as essayé ? Dis ce que tu en penses.