hunt

Vue d’ensemble de hunt

À quoi sert hunt

hunt est un skill de débogage d’abord, qui impose de raisonner sur la cause racine avant d’appliquer le moindre correctif. Il est particulièrement adapté aux erreurs, crashs, régressions, tests en échec, problèmes de cache obsolète, bugs de capture d’écran et cas du type « ça marchait avant », quand il faut une hypothèse vérifiable plutôt qu’un patch rapide.

Qui devrait l’installer

Installez le skill hunt si vous déboguez régulièrement du code applicatif, des tests, des artefacts de build ou du comportement à l’exécution, et que vous voulez un guide reproductible pour cerner vite le problème. Il est surtout utile lorsque les symptômes sont bruités, que les correctifs déjà essayés échouent sans cesse, ou que le bug traverse à la fois les logs, l’état de l’interface et les sorties générées.

Ce qui le différencie

Sa vraie valeur, c’est la discipline : identifier un fichier, une fonction, une ligne ou une condition précise, puis rassembler des preuves jusqu’à ce que la cause racine soit défendable. Les références associées couvrent la journalisation, les schémas d’échec, les cas limites IME/Unicode et les bugs de rendu ; le skill ne vous dit donc pas seulement de « mieux déboguer », il vous oriente vers la bonne catégorie de diagnostic.

Comment utiliser le skill hunt

Installation et préparation du contexte

Suivez le flux d’installation normal du skill dans votre environnement, puis ouvrez les fichiers du skill dans cet ordre : SKILL.md, references/failure-patterns.md, references/logging-techniques.md, references/ime-unicode.md et references/rendering-debug.md. Commencez par la référence qui correspond au symptôme ; ne lisez pas tout d’un bloc sauf si le problème traverse plusieurs domaines.

Comment formuler une demande pour utiliser hunt

Pour tirer le meilleur parti de hunt, demandez d’abord un diagnostic avant une réparation et donnez le plus petit symptôme reproductible possible. Une bonne demande ressemble à : « hunt this regression: clicking Save no longer persists after refresh; latest change touched src/hooks/user.ts; logs show cache hit. » Une mauvaise demande ressemble à : « save is broken, please fix. »

Le workflow attendu par le skill

Le guide hunt attend que vous formuliez une hypothèse en une phrase, que vous la vérifiiez par des preuves, puis que vous ne corrigiez qu’une fois la cause testable. En pratique : reproduisez, resserrez le périmètre, collectez un log ou un contrôle discriminant, confirmez le chemin de propagation, puis écrivez le correctif le plus petit possible et, si possible, un test de non-régression.

Parcours de lecture pratique

Utilisez references/failure-patterns.md si le bug évoque un problème de cache, de file d’attente, de garde ou de frontière de build. Utilisez references/logging-techniques.md quand il vous faut des preuves instrumentées. Utilisez references/ime-unicode.md pour les bugs de saisie CJK ou de composition. Utilisez references/rendering-debug.md pour les échecs liés au PDF, à l’impression, aux polices ou à la mise en page.

FAQ sur le skill hunt

hunt est-il réservé aux bugs de code ?

Non. Le skill hunt sert à déboguer toute défaillance concrète : erreurs d’exécution, tests en échec, artefacts générés cassés, régressions UI et écarts de sortie. En revanche, il n’est pas adapté à la revue de code pure ni à la conception de fonctionnalités.

Dois-je connaître la cause racine exacte dès le départ ?

Non, mais vous devez avoir une hypothèse réfutable. Le skill est conçu pour vous faire passer de « quelque chose ne va pas » à « je pense que la cause racine est X parce que Y ».

hunt est-il meilleur qu’un prompt normal ?

En général oui, quand la défaillance est ambiguë ou récurrente. Un prompt générique peut produire un patch ; hunt cherche d’abord à réduire les suppositions, ce qui diminue le risque d’un correctif qui casse un autre chemin.

Quand ne faut-il pas utiliser hunt ?

Évitez-le si vous ajoutez une nouvelle fonctionnalité, si vous refactorez sans bug, ou si vous avez déjà un correctif minimal confirmé et que vous avez seulement besoin d’aide pour l’implémentation. Ce n’est pas non plus le meilleur choix pour un brainstorming architectural de haut niveau.

Comment améliorer le skill hunt

Fournissez des preuves plus solides dès le départ

Donnez le symptôme, le dernier changement, l’environnement exact et une ou deux observations concrètes. Par exemple : « fails only on cold start », « passes after cache clear », « breaks on macOS with CJK input », ou « PDF renders locally but not in CI ». Cela aide hunt à choisir immédiatement le bon schéma d’échec.

Évitez les écueils les plus courants

L’erreur la plus fréquente consiste à demander un correctif avant d’avoir borné la cause. Un autre échec classique est une observabilité trop vague : des logs qui montrent seulement le message d’erreur, sans la branche, la séquence ou la transition d’état qui permet de distinguer une hypothèse d’une autre. Ajoutez des preuves discriminantes, pas simplement plus de bruit.

Itérez après le premier passage

Si le premier diagnostic est incomplet, répondez avec la nouvelle observation au lieu de repartir de zéro avec tout le prompt. Le skill hunt fonctionne le mieux comme une boucle de réduction : hypothèse, vérification, contre-exemple, hypothèse plus solide. C’est ainsi qu’on passe d’une installation du skill hunt à un workflow de débogage fiable.