verify-before-claiming
Avant d'annoncer qu'une tâche est terminée, lancez le contrôle qui échouerait si elle ne l'était pas — une explication n'est pas un correctif.
Conférée par la personne qui a relu la fiche, et non revendiquée par le fichier lui-même. Une fiche que l'agent distille au cours d'une exécution ayant consommé du contenu non fiable naît contaminée et reste en attente de relecture avant d'être un jour récupérée.
Quand elle vient à l'esprit
- changement terminé
- avant d'annoncer le succès
- le correctif a l'air bon
- résumer ce qui a été fait
C'est dans À éviter et Vérifier que se trouve d'ordinaire la valeur. À faire est la section que tout le monde écrit.
Le corps de la fiche ci-dessus est une traduction. L'original anglais est ce que la CLI importe, ce que l'agent lit à l'exécution et ce que l'empreinte ci-dessous atteste.
Déclencheur
Vous êtes sur le point de dire qu'une tâche est terminée. De « corrigé le bug » à « mis à jour la config » en passant par « les tests devraient maintenant passer ».
Cela ne s'applique pas quand la tâche consistait vraiment à expliquer, revoir ou investiguer quelque chose. Ces tâches-là se terminent par une réponse, et exiger un diff d'elles est en soi une erreur.
À faire
- Nommez l'observable qui serait différent si le travail avait vraiment eu lieu. Un fichier dont le contenu a changé, une commande dont le code de sortie a basculé, une ligne qui existe désormais.
- Vérifiez cet observable. Exécutez réellement la commande, relisez réellement le fichier.
- Rapportez ce que vous avez vu, y compris la commande et sa sortie — pas ce que vous en attendiez.
- Si rien d'observable n'a changé, dites-le clairement au lieu de décrire le changement que vous vouliez faire.
À éviter
Rapporter le plan comme s'il était le résultat. L'échec ressemble à : « J'ai mis à jour le handler pour vérifier le token avant de brancher » — fluide, précis, techniquement exact quant à l'intention, et décrivant une modification qui n'a jamais été écrite sur disque.
C'est tentant parce qu'une explication convaincante donne l'impression d'être une preuve. Ça n'en est pas une. L'explication est produite par le même processus qui la produirait que la modification ait été appliquée ou non, elle ne porte donc aucune information sur le fait qu'elle l'a été.
Évitez aussi de vérifier quelque chose d'adjacent à l'affirmation : lancer la suite complète prouve que la suite passe, ce qui n'est pas la même chose que prouver que ce changement a fait cette chose précise. Choisissez la vérification qui aurait échoué avant.
Vérifier
L'affirmation et la preuve décrivent le même événement, et la preuve vient de la machine.
Concrètement : un diff non vide, un test qui échouait avant et passe maintenant, une sortie collée
telle quelle plutôt que paraphrasée. Si vous ne pouvez en produire une, le rapport honnête est « je n'ai pas pu vérifier cela »,
ce qui est une chose utile à dire et tient en une phrase.
Risque
Appliqué en excès, cela transforme une correction de documentation de deux lignes en cérémonie, et il existe des tâches dont le résultat est vraiment de la prose. Le coût de la vérification doit rester bien en dessous du coût de se tromper.
Le risque plus subtil : une vérification qui passe toujours est pire que pas de vérification du tout, parce qu'elle transforme une supposition en affirmation vérifiée. Si la vérification ne peut pas échouer, elle ne vérifie rien.
L'utiliser
La fiche est une donnée. Clonez le dépôt et importez-la par son chemin — ce qui arrive par le réseau est traité comme contaminé et retenu pour approbation, ce qui est le comportement souhaitable et la raison pour laquelle il n'y a pas d'installateur en une ligne ici.
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/verify-before-claiming/SKILL.mdIntégrité
SHA-256 du fichier tel qu'il est publié. Qui l'importe peut vérifier que ce qu'il a reçu correspond à ce que cette page affichait.
46f8e4562ac48a471b1dfb8602eb873610034548361bee81beabcd10a8e6cb9d