verification-before-completion

Présentation de la skill verification-before-completion

À quoi sert verification-before-completion

La skill verification-before-completion met en place un contrôle final strict au moment où vous êtes sur le point d’affirmer qu’un travail est terminé, corrigé, validé ou prêt pour review. Son rôle est simple : bloquer les déclarations de réussite non étayées et exiger une preuve fraîche avant toute conclusion.

Elle est particulièrement utile pour le développement assisté par IA, les workflows d’agents, la préparation de commits et les handoffs de PR. Si vous avez déjà vu des messages du type « les tests devraient passer », « le bug est corrigé » ou « le build a l’air bon » sans que la bonne commande ait réellement été exécutée, cette skill cible précisément ce mode d’échec.

Qui devrait installer cette skill

Profils pour lesquels elle est la plus pertinente :

• les développeurs qui utilisent des agents IA pour modifier du code
• les reviewers qui veulent des mises à jour d’état plus propres et appuyées par des preuves
• les équipes lassées des messages de fin de tâche optimistes mais non vérifiés
• toute personne utilisant des patterns de Skill Validation où la preuve compte plus que la confiance affichée

Si vous cherchez surtout de la génération de code, de la planification ou une aide de debug généraliste, cette skill ne remplace pas ces usages. La skill verification-before-completion est un garde-fou, pas un workflow de livraison complet.

Le vrai besoin couvert

Le vrai sujet n’est pas simplement « lancer les tests ». Il s’agit de :

1. identifier quelle preuve validerait réellement l’affirmation
2. exécuter maintenant cette vérification précise
3. lire la sortie réelle
4. ne formuler que l’affirmation que la preuve permet de soutenir

Cela paraît évident, mais c’est exactement là que beaucoup de workflows assistés par IA se dégradent. Cette skill transforme cette attente en barrière explicite avant toute formulation de fin de tâche.

Ce qui distingue cette skill

Son principal atout, c’est sa spécialisation. verification-before-completion n’essaie pas de comprendre intelligemment l’ensemble de votre repository. Elle applique une seule règle à forte valeur :

aucune déclaration d’achèvement sans preuve de vérification fraîche

C’est ce qui en fait une excellente skill de dernière couche. Par rapport à un prompt générique du type « sois prudent et vérifie », elle est plus facile à déclencher de façon cohérente, car elle fournit une logique de décision répétable : identifier, exécuter, lire, vérifier, puis parler.

Quand cette skill est particulièrement adaptée

Utilisez la skill verification-before-completion quand vous êtes sur le point d’écrire des choses comme :

• « les tests passent »
• « le bug est corrigé »
• « le build réussit »
• « c’est prêt à être mergé »
• « le linter est clean »

Chacune de ces affirmations demande une preuve différente. La skill aide à éviter une erreur fréquente : prouver quelque chose d’approchant, puis surinterpréter le résultat.

Comment utiliser la skill verification-before-completion

Contexte d’installation de verification-before-completion

Installez-la depuis le repository obra/superpowers :

npx skills add https://github.com/obra/superpowers --skill verification-before-completion

Comme cette skill tient dans un unique fichier SKILL.md, son adoption est légère. Il n’y a ni scripts auxiliaires ni fichiers de ressources supplémentaires à comprendre au préalable.

Commencez par lire ce fichier

Commencez par :

• skills/verification-before-completion/SKILL.md

Ce fichier contient l’intégralité du contrat de comportement. Comme la structure de support du repository est minimale ici, lire SKILL.md en premier suffit pour comprendre si la skill correspond à votre workflow.

Quelles entrées fournir à la skill

La skill verification-before-completion fonctionne au mieux si vous fournissez trois éléments :

• l’affirmation que vous vous apprêtez à formuler
• la commande qui permettrait réellement de la prouver
• les limites d’environnement qui empêchent éventuellement cette vérification

Exemples d’entrées :

• « Je veux dire que le correctif fonctionne. La commande qui le prouve est pytest tests/api/test_login.py -q. »
• « Je veux dire que le build passe. La vérification attendue est npm run build. »
• « Je pense que le lint est clean, mais je n’ai pas encore exécuté ruff check .. »

Sans affirmation concrète ni commande précise, la skill ne peut fournir qu’une mise en garde générique.

Transformer un objectif flou en prompt exploitable

Prompt faible :

• « Est-ce que je peux dire que c’est terminé ? »

Meilleur prompt :

• « Avant que j’affirme que c’est terminé, applique la skill verification-before-completion. L’affirmation est : “le bug de login est corrigé”. La meilleure commande de preuve est pytest tests/auth/test_login_bug.py -q. Si cela ne suffit pas, indique-moi quelle vérification supplémentaire est nécessaire. »

Pourquoi c’est mieux :

• l’affirmation est explicite
• un chemin de preuve est proposé
• la skill peut contester une vérification trop faible

Comment appeler la skill en pratique

Utilisez verification-before-completion juste avant tout message de fin de tâche, résumé de commit ou note de PR. Un workflow concret ressemble à ceci :

1. terminer la modification du code
2. décider de l’affirmation exacte que vous voulez formuler
3. identifier la commande qui prouve cette affirmation
4. exécuter à nouveau la commande complète
5. examiner la sortie et le code de retour
6. atténuer ou qualifier l’affirmation si la preuve est incomplète

Cet enchaînement compte. La skill est la plus utile précisément au moment où l’on est tenté de résumer de façon trop optimiste.

Faire correspondre chaque affirmation à la bonne preuve

L’un des grands bénéfices pratiques de la skill verification-before-completion, c’est qu’elle évite les décalages entre affirmation et preuve.

Exemples :

• Affirmation : « Les tests passent »
  Preuve : la commande de test complète et pertinente, avec zéro échec

• Affirmation : « Le linter est clean »
  Preuve : la commande du linter indiquant zéro erreur

• Affirmation : « Le build réussit »
  Preuve : la commande de build qui se termine avec succès

• Affirmation : « Le bug est corrigé »
  Preuve : une étape de vérification qui reproduit le scénario d’échec initial et qui passe désormais

Un linter au vert ne prouve pas qu’un build réussit. Un fichier modifié ne prouve pas qu’un bug est corrigé. C’est précisément sur cette distinction que beaucoup de sorties d’agents échouent.

Ce qui compte comme preuve de vérification fraîche

« Fraîche » signifie que la commande a été exécutée pour l’état exact et actuel du travail, pas simplement retenue d’une tentative précédente. En pratique, cela veut dire :

• ne pas s’appuyer sur une ancienne sortie de terminal
• ne pas supposer que des fichiers inchangés impliquent des résultats inchangés
• ne pas déduire un succès à partir de signaux voisins
• ne pas utiliser une vérification partielle pour soutenir une affirmation plus large

Si vous avez modifié le code depuis le dernier run, ce dernier run est considéré comme obsolète pour une déclaration de fin de tâche.

Que faire quand vous ne pouvez pas lancer la vérification

Il arrive que l’environnement bloque l’exécution : dépendances manquantes, absence d’identifiants, services indisponibles, OS non pris en charge, ou simple contrainte de temps. Dans ce cas, il ne faut pas formuler l’affirmation la plus forte.

Préférez un langage appuyé sur les faits :

• « J’ai effectué la modification, mais je n’ai pas pu exécuter npm test dans cet environnement. »
• « Le correctif est implémenté, mais la vérification du build reste non confirmée. »
• « J’ai vérifié uniquement le formatting ; la suite complète de tests d’intégration n’a pas été lancée. »

Dans ce cas aussi, l’usage de verification-before-completion reste réussi, car la skill vise un reporting d’état honnête, pas une certitude forcée.

Modèle de prompt pratique pour les agents

Un bon prompt réutilisable :

« Utilise la skill verification-before-completion avant toute affirmation de réussite. Pour chaque affirmation, identifie la commande qui la prouve, exécute-la fraîchement si possible, lis la sortie complète, et ne formule que ce que les preuves confirment. Si la vérification est bloquée, signale la limite au lieu de laisser entendre que tout est validé. »

Cela fonctionne bien dans les consignes d’agents, les assistants de PR et les workflows de génération de commits.

Meilleur workflow pour les cas d’usage Skill Validation

Pour verification-before-completion for Skill Validation, considérez cette skill comme le validateur final, pas comme l’exécutant principal. Une bonne séquence est :

1. utiliser une autre skill pour implémenter ou débugger
2. basculer ensuite vers verification-before-completion
3. vérifier l’affirmation précise que vous voulez publier
4. produire un résumé avec la commande exécutée et le résultat observé

Cette séparation renforce la confiance, car l’implémentation et la validation ne sont pas mélangées.

FAQ sur la skill verification-before-completion

verification-before-completion est-elle seulement un rappel pour lancer les tests ?

Non. La skill verification-before-completion est plus stricte qu’un simple rappel. Elle impose une correspondance entre affirmation et preuve. L’objectif n’est pas simplement de « lancer quelque chose », mais d’exécuter la commande qui prouve exactement la phrase que vous vous apprêtez à écrire.

Cette skill est-elle utile pour les débutants ?

Oui, surtout pour les débutants qui apprennent encore ce que prouvent réellement les différents contrôles. Elle installe une habitude solide : ne pas généraliser au-delà de ce que montrent les preuves. Cette habitude améliore à la fois la précision technique et la confiance des reviewers.

Quand ne faut-il pas utiliser verification-before-completion ?

Ne l’utilisez pas comme votre seule skill de code ou de debug. Elle ne concevra pas l’architecture, ne trouvera pas la cause racine et ne rédigera pas à votre place un plan de test complet. C’est un checkpoint de fin de parcours, à associer de préférence à des skills orientées implémentation.

En quoi est-ce mieux qu’un prompt ordinaire ?

Un prompt ordinaire dit souvent « vérifie avant de répondre », mais les agents glissent quand même vers des affirmations molles. La verification-before-completion skill est plus efficace si vous voulez une barrière cohérente avant conclusion, avec des conséquences explicites quand une affirmation n’est pas étayée.

Cette skill exige-t-elle une stack ou une toolchain spécifique ?

Non. Cette skill est agnostique vis-à-vis de la stack, car sa logique porte sur la preuve, pas sur le langage ou le framework. C’est vous qui fournissez la commande de validation adaptée à votre environnement, qu’il s’agisse de pytest, npm test, go test, cargo test ou d’un autre outil de vérification.

Puis-je l’utiliser quand la vérification complète coûte trop cher ?

Oui, mais votre affirmation doit alors être resserrée en conséquence. Si vous n’avez exécuté qu’un test ciblé, dites que ce test ciblé passe. Ne transformez pas cela en « tout passe » tant que vous n’avez pas exécuté la preuve plus large.

Comment améliorer la skill verification-before-completion

Donner l’affirmation avant de demander une validation

La meilleure amélioration possible de la qualité de sortie consiste à formuler exactement la phrase que vous êtes tenté d’écrire. Par exemple :

• faible : « valide ça »
• fort : « Je veux dire : “le bug de paiement est corrigé et les tests passent” »

Cela aide la skill à séparer les affirmations composées et à associer une preuve à chaque partie.

Nommer explicitement la meilleure commande de preuve

Ne forcez pas la skill à deviner les conventions de votre repository si vous les connaissez déjà. Entrée plus solide :

• « Le contrôle canonique du projet est make test. »
• « Le bug est prouvé par pytest tests/payments/test_refund.py -q plus npm run build. »

Cela réduit les faux sentiments de confiance fondés sur des contrôles incomplets.

Séparer l’état d’implémentation de l’état vérifié

Un échec fréquent consiste à mélanger « j’ai modifié le code » et « le problème est résolu ». Pour améliorer l’usage de verification-before-completion, demandez une réponse en deux parties :

• ce qui a changé
• ce qui a réellement été vérifié

Cela permet de garder des résumés honnêtes même quand l’exécution est bloquée.

Éviter les affirmations larges à partir de contrôles étroits

Si vous avez exécuté un seul test ciblé, ne demandez pas à la skill de certifier l’ensemble du repository. Formulation préférable :

• « Puis-je dire que le test de régression ciblé passe maintenant ? »
• et non « Puis-je dire que le système est entièrement corrigé ? »

C’est l’une des habitudes les plus utiles que cette skill encourage.

Demander une formulation dégradée quand les preuves sont partielles

Une manière très pratique d’améliorer le verification-before-completion guide dans le travail réel consiste à demander une formulation de repli :

• « Si l’affirmation est trop forte au regard des preuves, réécris-la dans sa version la plus forte qui reste exacte. »

La skill devient alors un outil de qualité de communication, pas seulement un bloqueur.

Relancer après des changements significatifs

Si vous modifiez du code après une exécution de vérification réussie, utilisez à nouveau la skill verification-before-completion. Une preuve fraîche est liée à l’état courant, pas à la version précédente. C’est particulièrement important dans les boucles rapides avec agent, où une « petite retouche finale » peut invalider les contrôles antérieurs.

Utiliser les preuves dans le résumé final

Pour inspirer davantage confiance, incluez directement la preuve dans la note de fin :

• commande exécutée
• résultat succès/échec
• éventuelles limites ou omissions

Exemple :

• « Vérifié avec pytest tests/auth/test_login_bug.py -q : succès, 1 test, 0 échec. »
• « La suite complète d’intégration n’a pas été vérifiée dans cet environnement. »

Ce style rend la skill plus utile pour les reviewers comme pour vous plus tard.

Surveiller le mode d’échec le plus fréquent

Le mauvais usage le plus courant de verification-before-completion for Skill Validation consiste à déclarer un succès à partir de l’intention, des changements de code ou d’une attente, plutôt qu’à partir de la sortie observée. Si vous voulez de meilleurs résultats, posez une dernière question avant chaque message de fin :

« Quelle sortie de commande rendrait cette affirmation vraie ? »

Si vous ne pouvez pas répondre clairement à cette question, l’affirmation n’est probablement pas prête.