sentry

Vue d’ensemble de sentry

Le skill sentry est un outil d’Observability en lecture seule pour explorer rapidement les données Sentry : issues, events, signaux de santé et impact probable en production. Il convient particulièrement à celles et ceux qui veulent répondre vite à la question « qu’est-ce qui casse, où, et à quel point ? », sans cliquer manuellement dans Sentry. Par rapport à une requête générique, le skill sentry est calibré pour l’inspection via CLI, ce qui le rend plus fiable quand il faut des données à jour, des requêtes reproductibles et une sortie structurée.

Utilisez ce skill quand vous savez déjà que vous avez besoin d’un insight propre à Sentry et que vous cherchez un guide sentry pratique pour le triage, pas une vue d’ensemble trop large de l’observability. C’est un bon choix pour les personnes en charge d’incident, les ingénieurs qui vérifient un régressions, et les analystes qui ont besoin de résumés courts et vérifiables à partir de données Sentry en direct.

Ce que le skill sentry fait bien

Il prend en charge l’investigation en lecture seule via la commande sentry, avec des réglages par défaut pensés pour un triage rapide : fenêtres temporelles récentes, filtrage orienté production et sortie JSON pour les traitements en aval. Le skill est particulièrement utile quand il faut lister les issues non résolues, inspecter une issue précise à partir de son short ID, ou récupérer des données structurées sans perdre la pagination ni la gestion de l’authentification.

Dans quels cas ce skill est un bon choix

Choisissez le skill sentry si votre tâche dépend de l’état réel de Sentry, si vous avez besoin de requêtes reproductibles ou si vous comptez itérer sur des filtres comme l’environnement, le projet, la plage temporelle ou la priorité. C’est aussi un bon choix quand l’utilisateur veut un workflow sentry pour l’Observability réutilisable dans de l’automatisation ou une analyse assistée par agent.

Ce qu’il faut savoir avant l’installation

Ce skill est en lecture seule. Il ne crée pas d’issues, ne modifie pas le routage des alertes et ne change pas les paramètres des projets. Les blocages les plus fréquents viennent d’une authentification absente, d’une cible org/project mal définie, ou d’une tentative d’utilisation sur des données qui ne sont pas dans Sentry. Si vous avez besoin d’actions en écriture ou de dashboards, ce n’est pas le bon skill.

Comment utiliser le skill sentry

Installer et authentifier

Installez le skill sentry avec npx skills add openai/skills --skill sentry. Si la CLI n’est pas déjà disponible, installez d’abord Sentry CLI, puis authentifiez-vous localement avec sentry auth login ou SENTRY_AUTH_TOKEN. Vérifiez l’accès avec sentry auth status avant de demander un travail d’investigation. Ne collez jamais de tokens dans la conversation.

Donner au skill la bonne entrée

Pour tirer le meilleur parti de sentry, demandez un objectif d’investigation concret avec un périmètre. Les bonnes consignes nomment le symptôme, l’environnement et la fenêtre temporelle, par exemple : « Investigate the latest production 5xx spike in the last 24h and summarize the top unresolved issues. » Si vous connaissez le projet, indiquez-le ; sinon, laissez l’auto-détection essayer d’abord. La CLI peut généralement déduire l’org/le projet à partir des DSN, du code source, des valeurs de configuration par défaut et des noms de répertoires.

Commencer avec les bons fichiers et les bonnes commandes

Lisez d’abord SKILL.md, puis consultez agents/openai.yaml pour comprendre le comportement par défaut et le cadrage du prompt. Utilisez sentry schema <resource> quand vous devez découvrir les endpoints ou les champs disponibles. Pour obtenir des résultats lisibles par machine, demandez toujours --json, et combinez-le avec --fields pour réduire le bruit et rendre les résumés plus précis.

Workflow pratique pour de meilleurs résultats

Un bon workflow de guide sentry consiste à : confirmer l’authentification, vérifier l’org/le projet cible, lancer une requête de liste étroite, puis inspecter une ou deux issues en détail avant de résumer. Par exemple, commencez par les issues de production non résolues des dernières 24 h, puis affinez par release, environnement ou priorité si le premier passage est trop large. Cela permet de garder l’analyse ancrée dans les données actuelles, au lieu de surajuster une seule event bruyante.

FAQ du skill sentry

Le skill sentry a-t-il besoin de Sentry CLI ?

Oui. Le skill sentry est conçu autour de la CLI sentry, pas autour d’un workflow dans le navigateur. Si la CLI manque, installez-la puis authentifiez-vous localement d’abord. C’est cette configuration qui rend l’installation de sentry utile pour une investigation reproductible en lecture seule.

En quoi est-ce différent d’un prompt normal ?

Un prompt normal peut décrire une requête Sentry, mais le skill sentry ajoute un chemin d’exécution concret : attentes sur l’authentification, conventions de requêtes par défaut, sortie JSON et sélection des champs. Cela réduit les tâtonnements et rend le résultat plus facile à vérifier ou à automatiser.

Le skill sentry est-il adapté aux débutants ?

Oui, si l’utilisateur sait formuler clairement son problème. Les débutants s’en sortent généralement bien lorsqu’ils donnent « ce qui a cassé, quand et où », plutôt que d’essayer d’écrire une requête CLI parfaite. Le skill gère la mécanique de requêtage ; l’utilisateur doit seulement définir la cible de l’investigation.

Quand ne faut-il pas l’utiliser ?

N’utilisez pas le skill sentry pour modifier la configuration de Sentry, changer les politiques d’alertes ou tout workflow nécessitant des droits d’écriture. Il est aussi peu adapté si vous n’avez pas accès à l’org/au projet concerné, ou si votre question porte sur des logs applicatifs en dehors de Sentry.

Comment améliorer le skill sentry

Fournir un contexte d’investigation plus précis

Le skill sentry fonctionne mieux si vous précisez l’environnement, la plage temporelle et le symptôme qui vous intéresse. « Résume les erreurs récentes » est moins efficace que « Trouve les principales erreurs de production non résolues dans les 6 dernières heures après la release 2.4.1 ». Un contexte plus riche améliore le classement des issues, réduit les faux positifs et aide l’agent à choisir les bons filtres.

Demander une sortie structurée

Si vous voulez un résultat sentry utile pour l’Observability, demandez un tableau ou un résumé en puces avec short ID, titre, sévérité et impact probable. Cela oriente le workflow vers une sortie exploitable plutôt que vers un récit flou. Si vous avez besoin d’une utilisation machine, demandez des champs compatibles --json pour garder une réponse compacte et exploitable par parsing.

Itérer en resserrant, pas en élargissant

Si le premier passage est trop bruyant, resserrez par release, environnement ou short ID précis plutôt que de demander « tout ». Si le premier passage est trop pauvre, élargissez la fenêtre temporelle avant de supprimer des filtres. Le meilleur usage de sentry vient souvent d’une requête ciblée suivie d’un seul ajustement, pas d’une recherche géante d’un coup.