systematic-debugging

Par mkurman · zorai

npx skills add https://github.com/mkurman/zorai --skill systematic-debugging

name: systematic-debugging description: À utiliser lors de la rencontre de tout bug, échec de test ou comportement inattendu, avant de proposer des corrections

tags: [development, superpowers, systematic-debugging, debugging] -----|---------| | "Le problème est simple, pas besoin de processus" | Les problèmes simples ont aussi des causes profondes. Le processus est rapide pour les bugs simples. | | "C'est urgent, pas le temps pour le processus" | Le débogage systématique est PLUS RAPIDE que les essais au hasard. | | "Essaie juste ça en premier, puis on enquête" | Le premier correctif définit le modèle. Fais-le correctement dès le départ. | | "J'écrirai le test après avoir confirmé que le correctif fonctionne" | Les correctifs non testés ne tiennent pas. Tester en premier le prouve. | | "Plusieurs correctifs à la fois, ça gagne du temps" | On ne peut pas isoler ce qui a marché. Crée de nouveaux bugs. | | "La référence est trop longue, je vais adapter le modèle" | Une compréhension partielle garantit des bugs. Lis-la complètement. | | "Je vois le problème, laisse-moi le corriger" | Voir les symptômes ≠ comprendre la cause profonde. | | "Un autre essai de correctif" (après 2+ échecs) | 3+ échecs = problème architectural. Remet en question le modèle, ne corrige pas à nouveau. |

Référence rapide

Phase Activités clés Critères de succès
1. Cause profonde Lire les erreurs, reproduire, vérifier les modifications, rassembler les preuves Comprendre QUOI et POURQUOI
2. Modèle Trouver des exemples fonctionnels, comparer Identifier les différences
3. Hypothèse Formuler une théorie, tester minimalement Confirmée ou nouvelle hypothèse
4. Implémentation Créer un test, corriger, vérifier Bug résolu, tests passants

Quand le processus révèle « Aucune cause profonde »

Si l'enquête systématique révèle que le problème est vraiment environnemental, dépendant du timing ou externe :

  1. Tu as complété le processus
  2. Documente ce que tu as enquêté
  3. Implémente la gestion appropriée (retry, timeout, message d'erreur)
  4. Ajoute du monitoring/logging pour une enquête future

Mais : 95% des cas « aucune cause profonde » sont des enquêtes incomplètes.

Techniques de support

Ces techniques font partie du débogage systématique et sont disponibles dans ce répertoire :

  • root-cause-tracing.md - Trace les bugs à rebours dans la pile d'appels pour trouver le déclencheur original
  • defense-in-depth.md - Ajoute de la validation à plusieurs couches après avoir trouvé la cause profonde
  • condition-based-waiting.md - Remplace les timeouts arbitraires par le polling de conditions

Compétences associées :

  • superpowers:test-driven-development - Pour créer un cas de test défaillant (Phase 4, Étape 1)
  • superpowers:verification-before-completion - Vérifier que le correctif a marché avant de déclarer succès

Impact réel

À partir des sessions de débogage :

  • Approche systématique : 15-30 minutes pour corriger
  • Approche correctifs aléatoires : 2-3 heures de tâtonnement
  • Taux de correctif du premier coup : 95% vs 40%
  • Nouveaux bugs introduits : Quasi zéro vs courant

Skills similaires