[🤖] J’ai créé une skill pour ne plus demander chaque fois : “C’est vraiment terminé ?”

✨ Résumé de GPT-5.6 Sol

Le récit de la création d’une skill qui enchaîne audit, correction, vérification et nouvel audit jusqu’à un état propre, après avoir vu l’IA s’arrêter trop souvent au simple signalement des problèmes.

Je répétais toujours la même chose

Chaque fois que l’IA terminait une tâche, je devais ajouter les mêmes mots à la fin.

« C’est vraiment terminé ? Rien n’a été oublié ? Aucun problème ou erreur potentielle ? Revérifie, inspecte et analyse tout sous tous les angles, puis corrige ce qui doit l’être. »

Je ne l’ai pas écrit une ou deux fois seulement.

L’IA terminait l’implémentation, réussissait quelques tests et déclarait le travail fini. Ce n’est qu’après une nouvelle question qu’elle trouvait des cas limites oubliés, des incohérences documentaires ou des régressions. Parfois elle livrait les findings puis s’arrêtait.

Alors je le redisais.

« Alors corrige-le, XX. »

Après la correction, je demandais encore.

« Cette fois, tu as vraiment tout vérifié ? Il ne reste aucun problème ? »

Il était très stressant de devoir encore vérifier moi-même, un par un, tous les risques possibles à la fin.

Si tu as trouvé le problème, corrige-le : pourquoi me le rendre ?

Au début, je pensais que /review suffirait, mais ce n’était pas satisfaisant.

Je ne voulais ni rapport ni liste à traiter instruction par instruction. Si l’IA peut détecter et corriger un problème dans le périmètre approuvé, elle doit simplement le faire.

Le flux que je voulais était simple.

auditer → corriger → vérifier → réauditer depuis le début

Si un nouveau problème apparaît, on le corrige ; si les tests cassent, on cherche la cause ; si la première correction était mauvaise, on recommence. Rien de cela n’est une condition de sortie.

Il faut s’arrêter seulement lorsqu’il ne reste plus de problème important, ou uniquement des décisions exigeant vraiment mon intervention.

Répéter cette longue consigne était pénible. Les règles de persistance ne fonctionnaient pas et un Goal gaspillait des tokens sur des détails. C’était exaspérant.

Je n’avais pas besoin d’une skill d’audit seulement

Au début, j’ai pensé créer $audit séparément.

J’ai vite compris que c’était inutile : auditer et rendre des findings recoupait /review. C’était précisément le problème : les défauts étaient signalés, mais je devais encore ordonner leur correction.

Je l’ai donc nommé dès le départ $audit-and-fix-until-clean.

J’ai envisagé $audit-and-fix, mais cela évoquait un audit et une correction. Le cœur n’était ni audit ni fix.

Continue jusqu’à la fin.

Ce sens devait apparaître dans le nom.

Hier, j’en ai fait une vraie skill personnelle : elle corrige, vérifie puis réexamine tout le périmètre dans son nouvel état. Sur un code de test défectueux, elle a corrigé l’implémentation, ajouté un test limite, tout validé puis réaudité.

Au moins, la boucle voulue a fonctionné.

clean ne signifie pas parfait

En utilisant clean, j’ai précisé une chose.

On ne peut prouver l’absence absolue d’erreur latente. Demander si tout est parfait ne crée pas la perfection. Avec une imagination infinie, tout travail produit sans fin des problèmes seulement possibles.

Ici, clean signifie qu’aucun problème important étayé ne reste dans le périmètre inspecté et que les vérifications nécessaires passent.

Si un point exige mon choix ou une nouvelle autorisation, l’IA doit s’arrêter plutôt que deviner. Mais elle doit d’abord résoudre tout le reste. Je ne voulais pas qu’un seul blocage lui fasse tout abandonner avec un simple « Confirmation utilisateur requise ».

Exiger la perfection n’est pas exiger d’assumer jusqu’au bout les problèmes résolubles.

Je voulais la seconde chose.

J’ai transformé les reproches répétés en méthode de travail

J’ai déjà écrit que la culture de l’IA est finalement la capacité à donner des consignes. Il faut préciser le résultat, poser des contraintes, examiner l’intermédiaire et réorienter.

Si la même consigne revient, insister davantage ne suffit pas. Il faut transformer l’exigence récurrente en méthode de travail.

Dans Claude Code ou Codex, c’est un génie nul et sans intuition, j’ai écrit que l’IA a besoin d’un harnais. Cette skill transforme « vérifie bien » en condition de sortie définissant jusqu’où poursuivre.

Je n’ai plus besoin de recopier la longue phrase.

$audit-and-fix-until-clean

Cette ligne suffit.

La skill peut elle aussi être imparfaite : s’arrêter bizarrement, élargir trop le périmètre ou signaler de faux problèmes.

Alors j’appliquerai d’abord la skill à elle-même.