investigate

Vue d’ensemble du skill investigate

Ce que fait le skill investigate

Le skill investigate sert au débogage systématique et à l’analyse des causes profondes lorsqu’un élément est cassé, instable ou se comporte autrement que prévu. Il est conçu pour les utilisateurs qui ont besoin de plus qu’un correctif rapide : si vous voulez comprendre pourquoi une erreur se produit, ce qui a changé et quelle correction est sûre, investigate aide à structurer ce travail.

À qui il s’adresse

Utilisez le skill investigate pour les revues de code, le triage d’incidents, la correction de bugs et les situations du type « ça marchait hier ». Il est particulièrement adapté quand vous voulez qu’un agent arrête de supposer, rassemble des preuves et parte des symptômes pour aller vers une cause confirmée avant de modifier le code.

Ce qui le distingue

Son principal avantage, c’est la règle « pas de correctif sans cause racine ». Cela rend le skill investigate plus rigoureux qu’une simple invite de débogage : au lieu d’aller directement vers des modifications, il pousse le flux de travail vers l’investigation, l’analyse, l’hypothèse puis l’implémentation. Il prend aussi en charge le déclenchement proactif, ce qui est utile dans les flux d’agents où le skill doit s’activer dès qu’apparaissent des erreurs ou des stack traces.

Comment utiliser le skill investigate

L’installer et le lancer

Installez le skill investigate avec :

npx skills add garrytan/gstack --skill investigate

Utilisez-le lorsque votre invite décrit clairement un état d’échec, par exemple une stack trace, une erreur 500, une régression ou une sortie inattendue. Pour de meilleurs résultats, nommez le symptôme, l’endroit où il apparaît et ce à quoi « ça fonctionne » devrait ressembler.

Donner la bonne information de départ

Une bonne invite pour utiliser investigate inclut :

• le message d’erreur exact ou un extrait de log
• la commande, l’endpoint ou l’action utilisateur qui le déclenche
• ce qui a changé récemment
• ce que vous avez déjà vérifié
• l’impact et le niveau d’urgence

Exemple : « Investigate why npm test now fails in CI after the last merge. Compare main vs. HEAD, inspect recent changes in auth middleware, and do not propose code changes until the root cause is confirmed. »

Lire d’abord les bons fichiers

Commencez par SKILL.md, puis examinez SKILL.md.tmpl pour le comportement basé sur des templates ou la logique de routage. Comme ce dépôt ne contient pas de dossiers distincts rules/, resources/ ou scripts/, la valeur principale se trouve dans le fichier du skill lui-même et dans toutes les références inline qu’il contient. Pour investigate pour Code Review, prêtez une attention particulière au langage de déclenchement et aux limites des opérations sûres avant toute édition.

Conseils de workflow qui améliorent le résultat

Traitez investigate comme un flux de décision, pas comme une conversation libre. Demandez à l’agent de :

1. identifier le mode de défaillance,
2. rassembler des preuves à l’appui,
3. formuler une ou deux hypothèses testables,
4. vérifier la cause la plus probable,
5. appliquer le correctif minimal et sûr.

Si vous sautez l’étape 1, le skill peut quand même produire une analyse, mais elle sera moins utile pour une revue de code ou une réponse à incident.

FAQ du skill investigate

investigate sert-il uniquement aux bugs ?

Non. Le skill investigate convient aussi aux régressions, aux déploiements ratés, aux intégrations cassées et aux changements de comportement difficiles à expliquer. Si la tâche consiste à « comprendre pourquoi cela arrive », investigate est généralement le bon point de départ.

En quoi diffère-t-il d’une invite normale ?

Une invite classique peut demander un correctif immédiatement. Le skill investigate est plus structuré : il impose d’abord une réflexion sur la cause racine, ce qui réduit les modifications fragiles et rend le changement final plus facile à défendre en revue de code.

investigate est-il adapté aux débutants ?

Oui, si l’utilisateur peut fournir un symptôme et un peu de contexte. Les débutants en tirent souvent parti, car le skill réduit les suppositions, mais ils doivent tout de même partager des preuves concrètes comme des logs, des étapes de reproduction ou une commande en échec.

Quand ne faut-il pas l’utiliser ?

N’utilisez pas investigate si vous connaissez déjà exactement le changement souhaité, ou si vous faites une simple modification de contenu sans panne à diagnostiquer. Dans ces cas-là, une invite de tâche plus simple sera plus rapide.

Comment améliorer le skill investigate

Fournir des preuves, pas seulement une plainte

Le plus gros gain de qualité vient d’entrées plus précises. Au lieu de dire « l’application est cassée », fournissez la requête en échec, le texte de l’erreur, le chemin du fichier, l’environnement et le dernier état connu fonctionnel. Le skill investigate donne ses meilleurs résultats quand il peut rattacher chaque hypothèse à des preuves observables.

Réduire le champ de recherche

Si le problème se situe dans Code Review, identifiez le sous-système probable et la fenêtre de changement. Par exemple : « Concentre-toi sur auth, uniquement les changements des deux derniers commits, et vérifie si le bug est reproductible en staging. » Cela évite à investigate de partir dans trop de directions et augmente les chances d’identifier rapidement la cause racine.

Itérer après le premier passage

Si la première réponse n’est pas concluante, demandez une investigation plus ciblée plutôt qu’une réécriture plus large. De bons suivis sont par exemple : « Liste les trois hypothèses principales avec leur niveau de confiance », « Montre quelles preuves infirmeraient chacune d’elles » ou « Retrace l’échec de l’entrée à la sortie et arrête-toi avant d’écrire du code ».