diagnosing-bugs (Matt Pocock)

Avis

Codex CLI 0.166 (gpt-6-astra, low reasoning) sur un Mac de test, un projet temporaire neuf et des HOME/TMPDIR/caches temporaires à chaque exécution, skill installé (traitement) ou absent (contrôle) ou absent avec l'exigence centrale du skill compressée en une phrase ajoutée au prompt (groupe « prompt d'une phrase »), 2 exécutions par groupe et par tâche, réseau coupé, écritures dans /tmp bloquées. Les prompts ne mentionnent jamais le skill. La notation est programmatique (tests cachés / rappel d'éléments plantés / vérifications de contraintes / rendu+OCR le cas échéant), de 0 à 5 par exécution. Aucun juge LLM n'a décidé d'un score.

Comparaison à trois bras

Mesuré avec Codex CLI sur 18 exécutions, noté par des contrôles basés sur des règles, sans juge LLM. Total 22.9 / 30, verdict Selon les cas.

Verdict : Selon le cas (22.9 / 30). Source : mattpocock/skills, skills/engineering/diagnosing-bugs, épinglé au commit 4ae2317. Installation : npx skills@latest add mattpocock/skills --skill diagnosing-bugs. Licence : MIT (LICENSE du dépôt).

Présentation

Le skill diagnosing-bugs du dépôt de skills de Matt Pocock (engineering). Une discipline pour les bugs difficiles : la phase 1 consiste à « construire une boucle de retour pass/fail serrée » (test qui échoue, script curl, diff en CLI, navigateur headless, trace rejouée), puis des hypothèses classées testées une par une, de l’instrumentation, un test de régression et un nettoyage. Environ 1 000 mots de Markdown, un modèle d’aide hitl-loop.template.sh, et une règle pour masquer les secrets avant d’afficher une sortie. Il se déclenche sur « diagnose », « debug this » ou « something is broken/failing ».

Méthode de test

Codex CLI 0.166 (gpt-6-astra, raisonnement faible) sur une machine de test Mac, un projet temporaire neuf et des HOME/TMPDIR/caches temporaires à chaque exécution, skill installé (groupe avec skill), absent (groupe témoin), ou absent avec l’exigence centrale du skill compressée en une phrase ajoutée au prompt (groupe « prompt en une phrase »), 2 exécutions par groupe et par tâche, réseau désactivé, écritures dans /tmp bloquées. Les prompts ne mentionnent jamais le skill.

1. Décalage d’un indice dans une petite fonction — moving_average dans movavg.py renvoie des nombres faux : moving_average([2, 4, 6, 8, 10], 3) devrait donner [2, 3, 4, 6, 8] mais les valeurs suivantes sont fausses. Trouve la cause et corrige-la. Tests : python3 -m unittest.
2. Bug de dates entre fichiers — Les en-têtes de notre rapport hebdomadaire affichent des dates fausses autour du Nouvel An, par exemple header('2026-W01') devrait donner 'Week 2026-W01: Dec 29 - Jan 04, 2026'. Trouve la cause et corrige-la.
3. Échec de test dépendant de l’ordre — Les tests de tests/test_settings.py passent isolément mais test_b échoue quand tout le fichier s’exécute, et les configurations semblent conserver des tags d’appels précédents. Diagnostique et corrige.

Le scoring est programmatique (tests cachés / détection des problèmes implantés / vérifications de contraintes / rendu + OCR le cas échéant), de 0 à 5 par exécution. Aucun juge LLM n’a attribué de score.

Résultats

Le prompt en une phrase donné au troisième groupe : « Construis d’abord une boucle de retour pass/fail rapide et déterministe qui passe au rouge sur ce bug précis (un test qui échoue est l’idéal), puis formule des hypothèses classées et teste-les une par une avec des preuves avant de corriger, et relance la boucle pour confirmer la correction. »

Score moyen : 4.31 sans le skill contre 4.58 avec (écart +0.28). Tokens par exécution : 77k contre 133k (1.71x) ; temps 38s contre 51s. Groupe « prompt en une phrase » : 4.72 (gain du skill sur ce prompt : -0.14 ; gain du prompt par rapport à l’absence de skill : +0.42) ; tokens du prompt : 126k par exécution, donc le skill coûte 1.05x le prompt en une phrase.

Ce qui s’est passé

• L’exactitude finale était identique dans les trois groupes : les tests cachés ont réussi dans 18/18 exécutions et chaque diff est resté dans la limite de petit diff. Ces trois bugs implantés (décalage d’indice, logique de dates entre fichiers, pollution de tests dépendante de l’ordre) sont assez simples pour que Codex seul les corrige.
• La seule chose qui a bougé est la vérification de processus « a lancé les tests avant de modifier le code », autrement dit reproduire d’abord. Sans le skill, 1/6 exécutions l’ont fait ; avec la version en une phrase de la première règle du skill, 4/6 ; avec le skill installé, 4/6. La phrase a donc reproduit tout l’effet.
• Le skill a été lu dans 6/6 exécutions avec skill alors qu’aucun prompt ne le mentionnait (il se déclenche sur « debug this »). Il a fait travailler l’agent davantage : 18 commandes par exécution contre 8 sans le skill et 13 avec le prompt.
• Coût : 133k tokens par exécution avec le skill contre 77k sans (1.71x) et 126k avec le prompt (1.05x). Le groupe « prompt en une phrase » a lui-même coûté 1.64x le témoin, car demander à l’agent de construire d’abord une boucle le fait exécuter plus d’étapes.
• Une exécution avec skill (tâche de l’état partagé) a corrigé le bug et réussi les tests cachés, mais sa réponse ne correspondait pas à notre vérification de cause racine (qui cherche la cause nommée) ; c’est la seule exécution de tous les groupes à l’avoir manquée.

Scores par dimension

Limites de ce test

• Trois petits bugs Python dans un seul fichier, trouvables en lisant le code. Le skill est conçu pour les bugs difficiles (instables, régressions de performance, bugs nécessitant un banc de test) ; rien de tout cela n’a été testé.
• Les autres outils du skill (boucles HTTP/navigateur, rejeu de trace, bissection, balises d’instrumentation) ne peuvent pas tourner dans un sandbox sans réseau et sans application à piloter.
• La vérification « a lancé les tests avant de modifier » compare l’ordre de la première commande de test et de la première écriture dans le journal d’événements ; elle ne juge pas la qualité de la reproduction.
• n = 2 par groupe et par tâche : un écart inférieur à ~1 point relève du bruit.
• Le scoring par règles mesure ce que les vérifications peuvent voir ; il ne peut juger du goût ni du caractère optimal d’un résultat.

Sécurité

Voir security.md. Scan : 0 CRITICAL / 0 HIGH / 0 MEDIUM. Verdict : exécution sans danger (sandbox sans réseau). Un scan propre ne prouve pas qu’un skill est sûr.

En résumé

L’idée principale du skill est une bonne habitude et Codex la suit quand on le lui dit ; mais une phrase de ce skill a obtenu le même comportement « reproduire d’abord » et le même taux de réussite pour un coût à peu près identique, et sur des bugs faciles l’agent corrige de toute façon. Gardez-le installé si vous déboguez des bugs difficiles et instables et voulez la discipline complète ; sur de petits bugs, mettre sa première règle dans votre prompt suffit à en retirer le bénéfice.