Mode d’emploi
Demandez à Codex de consulter les sources où les bugs se manifestent déjà : alertes Sentry, tickets Linear, issues GitHub, vérifications de PR, journaux de déploiement, tickets d’assistance et fils de discussion Slack. Lancez une première analyse à la demande, ajustez le rapport dans la discussion, puis planifiez les analyses suivantes.
Utilisez une seule discussion Codex pour toutes les étapes du triage :
- Lancez une analyse à la demande pour obtenir une première liste de bugs.
- Examinez la liste et faites part de vos remarques dans la même discussion.
- Depuis cette discussion, planifiez une tâche de triage.
- Si vous le souhaitez, une fois que vous avez confiance dans le rapport, demandez à Codex de rédiger des brouillons de tickets Linear, de messages pour Slack, de commentaires pour GitHub ou de notes de passation.
Avant de commencer, installez les plugins dont Codex a besoin, par exemple Sentry, Slack, Linear ou GitHub. Dans le prompt de départ, remplacez la liste de plugins entre crochets par les mentions de plugins que vous insérez avec @. Remplacez ensuite chaque source entre crochets par l’emplacement précis où chercher : un projet Sentry ou l’URL d’une alerte Sentry, un canal ou un fil de discussion Slack, une équipe, une vue ou une requête Linear, un dépôt GitHub, une requête sur les issues ou une vérification de PR, un lien vers un déploiement, un fichier journal, une file de tickets d’assistance ou un tableau de bord.
Phase 1 : Lancez l’analyse
Lancez Codex depuis le dépôt concerné par les bugs lorsque le contexte local est utile, par exemple pour consulter les tests, les outils du dépôt, les vérifications de build ou les échecs de CI. Vous pouvez aussi lancer l’analyse depuis n’importe quel dépôt si Codex a accès aux sources via des plugins, des connecteurs, des serveurs MCP, des liens, des exports, des journaux collés dans la discussion ou des pièces jointes.
Commencez par exécuter le prompt de départ ci-dessus. Gardez uniquement les plugins et les sources nécessaires à votre analyse.
Par exemple, dans votre prompt, vous pouvez nommer les plugins et préciser les files de tickets, les canaux ou les dépôts à examiner.
Phase 2 : Affinez le rapport
Avant d’automatiser l’analyse, assurez-vous que le rapport mérite d’être lu chaque jour.
Vérifiez que le premier rapport répond aux critères suivants :
- Il fait ressortir les bugs les plus pertinents et les classe par priorité, de P0 à P3.
- Il regroupe les signalements qui concernent le même bug.
- Pour chaque bug, il fournit des liens vers les éléments qui l’étayent ou de courts extraits des sources.
- Il distingue les hypothèses des faits observés.
- Pour chaque bug, il recommande en quelques mots la prochaine action à entreprendre.
Affinez le rapport dans la même discussion avant de planifier la tâche. Vous pouvez demander à Codex de :
- Consulter une source supplémentaire avant de classer les bugs.
- Écarter les alertes que l’équipe connaît déjà et qui encombrent le rapport.
- Afficher uniquement les bugs de priorité P0 et P1.
- Regrouper les signalements Slack, les alertes Sentry et les échecs sur GitHub lorsqu’ils indiquent le même bug.
- Retenir un seul lien par bug, le plus pertinent.
- Fournir suffisamment d’éléments pour qu’une autre personne puisse reproduire le problème ou le transmettre à l’équipe compétente.
Phase 3 : Automatisez le triage
Une fois que le rapport à la demande vous convient, restez dans la même discussion et planifiez-y une tâche de triage. Codex peut s’appuyer sur vos ajustements dans la discussion pour rédiger le prompt de la tâche récurrente.
Planifiez la tâche de triage
Phase 4 : Organisez le suivi
Une fois que le rapport planifié vous convient, choisissez à qui transmettre les éléments à suivre. Codex peut préparer un message pour le canal Slack d’une équipe, rédiger des tickets Linear pour les bugs que vous souhaitez suivre, préparer des commentaires GitHub pour une PR dont les vérifications échouent ou rédiger une note de passation pour la personne d’astreinte.