← ClaudeAtlas

debuglisted

Diagnostique un bug qui résiste — construit d'abord une commande qui passe au rouge, puis réduit, hypothétise, corrige et verrouille. Use when un test casse sans raison évidente, un comportement surprend, une correction a déjà échoué une fois, ou l'utilisateur dit « débugge », « ça plante », « pourquoi ça marche pas ».
OQIODev/oqio-tool-starter · ★ 0 · Code & Development · score 75
Install: claude install-skill OQIODev/oqio-tool-starter
Un bug qui résiste ne se résout pas en lisant du code. Il se résout en construisant une commande qui passe au **rouge** sur ce bug précis — après quoi tout le reste est mécanique. Chaque phase porte sa condition de fin. La phase 1 est une porte : rien ne commence avant elle. ## 1. Une commande qui passe au rouge **C'est tout le skill.** Avec un signal rouge/vert fiable, on trouve la cause ; sans, on peut fixer l'écran pendant une heure sans rien apprendre. Y mettre un effort disproportionné. Les moyens dans ce projet, du plus serré au moins serré : 1. **Un test unitaire au bon seam** — `npx vitest run tests/unit/<nom>.test.ts`. Le plus serré : quelques centaines de millisecondes. 2. **Un test jetable qui reproduit** — écrire `tests/unit/repro.test.ts` qui appelle la fonction en isolation, sans passer par l'interface, et le lancer de la même façon. Vitest exécute déjà le TypeScript du projet : pas de runner à installer, et à la phase 5 ce fichier devient le test de régression au lieu d'être jeté. 3. **Un test d'intégration** contre le vrai Postgres — `npm run test:integration` (`tests/integration/`), base dédiée, jamais celle du dev. C'est le moyen pour tout ce qui touche Prisma ou une session. 4. **`curl` contre le dev server** qui tourne, en lisant **les logs serveur en même temps** — une page qui s'affiche avec une 500 derrière n'est pas verte. 5. **Playwright** — `npm run test:e2e` (`tests/e2e/`). En dernier recours : lent, et il faut arrêter `npm run dev` avant, Next