Transformez les sessions de débogage frustrantes en résolution systématique de problèmes en utilisant des techniques éprouvées, des outils puissants et des approches méthodiques qui fonctionnent avec n'importe quelle pile technologique.
Télécharger le ZIP du skill
Importer dans Claude
Allez dans Paramètres → Capacités → Skills → Importer un skill
Activez et commencez à utiliser
Tester
Utilisation de "debugging-strategies". My API is returning 500 errors intermittently. The logs show 'connection refused' but only sometimes.
Résultat attendu:
Cela ressemble à un problème de connectivité intermittent. Appliquons un débogage systématique :
**1. Collecter des informations :** Vérifiez quelles requêtes spécifiques échouent, les modèles de timing, et comparez les requêtes qui fonctionnent vs celles qui échouent.
**2. Formuler des hypothèses :** Cela pourrait être l'épuisement du pool de connexions, des délais de résolution DNS, des problèmes de load balancer, ou des paramètres de timeout.
**3. Recherche binaire :** Commencez par vérifier si cela corrèle avec les périodes de trafic élevé. Examinez les métriques du pool de connexions.
**4. Prochaines étapes :** Vérifiez les fuites de connexions dans votre code, examinez les configurations de timeout, et inspectez les journaux du load balancer pendant les périodes d'erreur.
Utilisation de "debugging-strategies". My Node.js app memory keeps growing until it crashes. How do I find the memory leak?
Résultat attendu:
Utilisons le profilage mémoire pour trouver la fuite :
**1. Activer le suivi mémoire :** Ajoutez des instantanés périodiques du tas avec v8.writeHeapSnapshot() ou utilisez clinic.js
**2. Reproduire avec surveillance :** Exécutez votre application et déclenchez les opérations suspectées tout en surveillant l'utilisation du tas
**3. Comparer les instantanés :** Prenez des instantanés avant et après les opérations suspectées, cherchez les comptes d'objets qui augmentent
**4. Coupables courants :** Vérifiez les gestionnaires d'événements non supprimés, les fermetures conservant des références, ou les caches qui grossissent
Audit de sécurité
SûrSecurity scanner flagged 48 potential issues in markdown documentation. After evaluation, all findings are false positives. The flagged patterns are code examples and documentation within markdown files, not executable code. External commands shown are educational CLI examples (git bisect, etc.). Network references are localhost debugging endpoints. This is a legitimate debugging education skill with no security concerns.
Score de qualité
Ce que vous pouvez construire
Déboguer les incidents de production
Enquêter et diagnostiquer des bugs de production en utilisant des approches systématiques, collecter des preuves en toute sécurité sans effectuer de modifications, et identifier les causes racines pour une résolution rapide.
Corriger les goulots d'étranglement de performance
Profiler les applications pour identifier les opérations lentes, analyser les modèles d'utilisation de la mémoire, et optimiser le code en se basant sur des données de performance réelles plutôt que sur des suppositions.
Traquer les bugs insaisissables
Appliquer la recherche binaire, le débogage différentiel et l'analyse de traces pour trouver des bugs qui n'apparaissent que dans des conditions spécifiques ou dans des environnements de production.
Essayez ces prompts
Je rencontre cette erreur : [ERROR_MESSAGE]. L'erreur se produit lorsque [WHAT_TRIGGERS_IT]. Pouvez-vous m'aider à appliquer des étapes de débogage systématiques pour trouver la cause racine ?
Mon [APPLICATION/COMPONENT] fonctionne lentement. Il prend [TIME] pour compléter [OPERATION]. J'ai essayé [WHAT_YOU_TRIED]. Aidez-moi à utiliser des outils de profilage pour trouver le goulot d'étranglement.
J'ai un bug qui se produit [FREQUENCY] mais je ne peux pas le reproduire de manière fiable. Il semble affecter [WHAT_IT_AFFECTS]. Quelles stratégies puis-je utiliser pour le traquer ?
Aidez-moi à déboguer un problème de production en toute sécurité. Je peux voir [ERROR/SYMPTOM] dans [WHERE_YOU_CAN_SEE_IT]. Que dois-je vérifier en premier et comment éviter d'aggraver les choses ?
Bonnes pratiques
- Toujours reproduire le problème localement avant de tenter des correctifs pour s'assurer de comprendre le problème
- Changer une chose à la fois pendant le débogage pour isoler ce qui corrige réellement le problème
- Documenter vos découvertes et hypothèses au fur et à mesure pour aider les futures sessions de débogage
- Utiliser l'historique de contrôle de version (git bisect) pour trouver quand les régressions ont été introduites
Éviter
- Effectuer plusieurs modifications à la fois sans suivre ce qui a corrigé le problème
- Supposer que le problème est complexe alors qu'il pourrait s'agir d'une simple faute de frappe ou d'un problème de configuration
- Ignorer les messages d'erreur et les traces de pile - ils contiennent généralement des indices précieux
- Déboguer en production sans surveillance appropriée ou plans de retour arrière