Synthèse automatique
Ce skill impose une démarche de débogage méthodique en six étapes — reproduire, isoler, formuler une hypothèse unique, instrumenter, corriger, vérifier — plutôt que de procéder par essais erronés.
Points forts
- Cadre explicite qui interdit le guess-and-check et exige la lecture du chemin de code avant toute modification
- Étape d'hypothèse unique et testable, formulée avec fichier et ligne, ce qui évite l'empilement de théories concurrentes
- Tableau des catégories de bugs fréquentes (type mismatch, race async, désynchronisation d'état, violation de frontière, chemin null) avec le premier point à vérifier
- Contraintes de qualité : correction minimale à la bonne couche, suppression de l'instrumentation temporaire, lint et type-check avant clôture
Limites
- Les outils autorisés (Read, Grep, Glob, Bash) ne couvrent pas le navigateur ni les débogueurs interactifs, ce qui limite le diagnostic des bugs purement front-end
- Suppose que l'utilisateur peut fournir des étapes de reproduction précises ; les bugs intermittents ne sont traités que par ajout de logs
- Ne décrit pas de stratégie de rédaction de test de non-régression au-delà de « lancer les tests s'ils existent »
À utiliser dès qu'un comportement inattendu ou un bug est signalé et qu'il faut en trouver la cause racine plutôt que corriger un symptôme.
À éviter pour une demande de refonte architecturale ou d'ajout de fonctionnalité, où il n'existe pas encore de comportement défaillant à reproduire.
Analyse de sécurité
PrudenceThe skill is a debugging methodology with no destructive, exfiltrating, or obfuscated instructions; all guidance is about reading code, forming hypotheses, and verifying fixes. The only risk surface is the declared Bash tool, which is used for legitimate purposes (reproducing, running tests/linters, appending a learnings entry). That is powerful but not malicious, so it warrants 'caution' rather than 'risky'.
- •Bash is in allowed-tools, granting arbitrary shell execution (e.g., running linters/tests); no commands are hard-coded, but scope is project-tooling only by convention, not restriction
- •Step 6 instructs running linter/type-checker/tests via Bash, meaning the agent will execute project scripts that could themselves be untrusted
- •The 'append an entry to learnings.md' instruction requires write access not covered by Read/Grep/Glob, likely forcing shell redirection/tee through Bash
Exemples
Quand je rafraîchis la page /dashboard, j'obtiens « Cannot read properties of undefined ». Aide-moi à trouver la cause racine au lieu de contourner le problème.Le total du panier est parfois faux, mais seulement si je clique sur Payer deux fois très vite. Débogue ça méthodiquement.This endpoint returns 500 only in staging — the same code works locally. Figure out why it's broken and fix the real cause.name: debug description: Systematically diagnose and resolve a bug or unexpected behavior — reproduce, isolate, hypothesize, instrument, and verify. Use when the user reports a bug, says "this doesn't work", "why is this broken", or encounters unexpected behavior. allowed-tools: Read, Grep, Glob, Bash
Systematic Debugging
Read learnings.md beside this file before starting; append an entry when a bug's root cause defied a category below.
Governing Principle
Bugs are information gaps. Debugging is not guessing — it is a systematic process of narrowing the gap between expected and actual behavior until the root cause is isolated and verifiable.
Procedure
-
Reproduce — confirm the bug exists and is deterministic. If the user hasn't described exact steps, ask. If it's intermittent, instrument logging before proceeding.
-
Isolate — narrow the scope:
- Discover the entry point: which route, server function, or component is involved?
- Trace the data flow from trigger to symptom. Read the code path, don't guess.
- Identify the boundary where expected behavior diverges from actual behavior.
-
Hypothesize — form exactly ONE testable hypothesis. State it as: "The bug occurs because [X] causes [Y] at [file:line]." Never hold multiple hypotheses simultaneously — test one, discard or confirm, then move to the next.
-
Instrument — add the minimum observation needed to confirm or reject the hypothesis:
- Console.log at the divergence point (remove after)
- Read error output carefully — the first error in a stack is usually the root cause
- Check types: is the runtime value what the type signature claims?
- Check timing: is an async operation completing before it's consumed?
-
Fix — apply the narrowest possible change that addresses the root cause, not the symptom. Constrain the fix:
- Does it match the project's established patterns? (
/patterns) - Does it introduce a new failure mode?
- Is the fix in the right layer? (data bug → fix in service, not in component rendering)
- Does it match the project's established patterns? (
-
Verify — confirm the fix resolves the original reproduction AND doesn't break adjacent behavior:
- Run the project's linter and type-checker
- If tests exist, run them
- Manually trace the fixed code path once more
Common Bug Categories
| Category | First thing to check |
|---|---|
| Type mismatch | Runtime value vs declared type — look for as any casts hiding the real type |
| Async race | Missing await, check-then-act without atomicity (TOCTOU) |
| State desync | Cache not invalidated after mutation, stale closure in a hook |
| Boundary violation | Server code imported client-side, env variable missing at runtime |
| Null path | Optional field accessed without guard, empty array not handled |
Constraints
- Never guess-and-check. Read the code path before changing anything.
- Remove all debugging instrumentation (console.log, temp vars) before considering the fix complete.
- If the bug reveals a missing pattern or architectural gap, flag it — don't silently patch around it.
Handoffs
- Bug reveals a design problem →
/system-design. - Fix needs to follow an established pattern →
/patterns. - User wants to understand why the bug existed →
/teach. - Fix complete →
/full-reviewto validate.
Du fichier au premier essai
Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.
Consulter la source et ses fichiers annexesCe téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.
1. Télécharger le fichier
Télécharger SKILL.mdDepuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/systematic-debugging-mrzxuoux/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.
Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.
mkdir -p '.skill-downloads/systematic-debugging-mrzxuoux' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/systematic-debugging-mrzxuoux/download' --output '.skill-downloads/systematic-debugging-mrzxuoux/SKILL.md.part' && mv '.skill-downloads/systematic-debugging-mrzxuoux/SKILL.md.part' '.skill-downloads/systematic-debugging-mrzxuoux/SKILL.md'2. Vérifier les prérequis
Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.
Outils déclarés par l’auteur (à vérifier dans votre agent) : Read, Grep, Glob, Bash
Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.
Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.
3. Charger la skill
Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.
Claude Code
test -f '.skill-downloads/systematic-debugging-mrzxuoux/SKILL.md' && test -s '.skill-downloads/systematic-debugging-mrzxuoux/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/debug' && cp -R '.skill-downloads/systematic-debugging-mrzxuoux' '.claude/skills/debug'Cursor
test -f '.skill-downloads/systematic-debugging-mrzxuoux/SKILL.md' && test -s '.skill-downloads/systematic-debugging-mrzxuoux/SKILL.md' && mkdir -p '.cursor/skills' && test ! -e '.cursor/skills/debug' && cp -R '.skill-downloads/systematic-debugging-mrzxuoux' '.cursor/skills/debug'Codex
test -f '.skill-downloads/systematic-debugging-mrzxuoux/SKILL.md' && test -s '.skill-downloads/systematic-debugging-mrzxuoux/SKILL.md' && mkdir -p '.agents/skills' && test ! -e '.agents/skills/debug' && cp -R '.skill-downloads/systematic-debugging-mrzxuoux' '.agents/skills/debug'OpenSkills
OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.
Installation officielle d’OpenSkillsopenskills install './.skill-downloads/systematic-debugging-mrzxuoux'openskills read 'systematic-debugging-mrzxuoux'La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.
Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.
openskills syncMode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.
4. Faire un premier essai
Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :
Lis .skill-downloads/systematic-debugging-mrzxuoux/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.
Bonnes pratiques React Hook Form
Developpement
Maîtrisez React Hook Form : évitez les anti-patterns, gérez les abonnements, et traitez correctement reset, dirty state et entrées contrôlées.
Migration Emotion vers Mantine
Developpement
Migrer les styled-components Emotion vers des composants Mantine avec style props et modules CSS. Pour convertir .styled.tsx ou supprimer les imports @emotion.
Détecteur de dérive de périmètre
Developpement
Analyse les diffs git par rapport à une intention pour détecter la dérive de périmètre, fichiers non liés et PR trop larges, puis suggère de garder, diviser ou justifier.