Site icon Tech-Connect

Prompts pour debugger du code avec l’aide d’i-have-adhd (Claude Code)

Prompts pour debugger du code avec l'aide d'i-have-adhd (Claude Code)

On a récemment présenté i-have-adhd, le skill open source qui force Claude Code ou autre IA à répondre directement, sans détour ni politesse superflue. Une fois ce skill activé, la façon dont vous formulez vos demandes de débogage change la donne : puisque les réponses seront volontairement courtes et actionnables, c’est à vous de fournir un contexte complet dès le départ. Voici six prompts pensés spécifiquement pour ce mode de fonctionnement.

1. Le rapport de bug complet en un seul message

« Bug : [décrivez le comportement observé]. Attendu : [décrivez le comportement attendu]. Fichier concerné : [chemin du fichier]. Message d’erreur exact : [collez le message complet]. Dernière modification avant l’apparition du bug : [décrivez-la si vous la connaissez]. »

💡 Pour les non-initiés : pourquoi tout donner dès le premier message : Avec un assistant en mode conversationnel classique, il est courant de décrire un problème vaguement, puis de préciser au fil des questions de l’IA. Avec i-have-adhd activé, l’assistant a justement pour consigne de supprimer les questions de clarification superflues et d’aller directement à l’action : mieux vaut donc regrouper toutes les informations utiles en un seul message dès le départ, plutôt que de compter sur un dialogue en plusieurs allers-retours pour préciser le contexte.

2. Demander uniquement la correction, sans explication

« Corrige ce bug : [collez le code et l’erreur]. Donne-moi uniquement le code corrigé, sans explication. »

Ce prompt exploite directement l’une des dix règles du skill, qui supprime par défaut les explications non sollicitées : le préciser explicitement renforce encore ce comportement, utile quand vous avez juste besoin d’avancer rapidement sur une erreur que vous savez déjà expliquer vous-même.

3. Séparer la correction de la pédagogie

« Corrige d’abord ce bug sans explication. Une fois la correction donnée, si je te demande « pourquoi », alors seulement explique la cause en 3 phrases maximum. »

Cette approche en deux temps évite de recevoir une explication non désirée quand vous êtes pressé, tout en gardant la possibilité de creuser ensuite si vous le souhaitez réellement, vous gardez le contrôle sur le moment où la pédagogie devient utile.

4. Le débogage pas à pas avec rappel d’état

« On va déboguer ce problème étape par étape : [décrivez le problème]. À chaque étape, rappelle en une ligne ce qui a été testé et son résultat avant de proposer l’étape suivante. »

📌 À noter : cette règle existe déjà par défaut dans le skill : Rappeler l’état d’avancement à chaque tour de conversation fait partie des dix règles natives d’i-have-adhd. Le préciser explicitement dans votre prompt n’est donc pas strictement nécessaire une fois le skill activé, mais peut aider à renforcer ce comportement sur une session de débogage particulièrement longue et complexe, où plusieurs pistes sont explorées successivement.

5. Demander un plan numéroté avant d’agir

« Avant de modifier quoi que ce soit, liste en 3 à 5 étapes numérotées ton plan pour résoudre ce bug : [décrivez le problème]. Attends ma validation avant de commencer à coder. »

Utile pour les bugs complexes ou les modifications qui touchent plusieurs fichiers : ce prompt vous permet de valider l’approche avant qu’elle ne soit exécutée, en gardant un contrôle humain sur les changements engageants, plutôt que de découvrir a posteriori une modification plus large que prévu.

6. Signaler un blocage et demander une seule prochaine étape

« Je suis bloqué : [décrivez précisément où vous en êtes et ce qui ne fonctionne pas]. Donne-moi une seule prochaine étape concrète à tester, pas une liste d’options. »

⚠️ Un point de vigilance à garder malgré le mode concis : Un mode de réponse volontairement direct et sans détour ne dispense jamais de comprendre ce que fait réellement une correction avant de l’appliquer, en particulier sur du code destiné à la production. La rapidité gagnée par ces prompts sert à éliminer le blabla inutile, pas la vérification humaine du résultat : relisez toujours une correction avant de la valider, surtout si elle touche à une logique métier sensible ou à la sécurité de l’application.

Note méthodologique

Quitter la version mobile