Transformez les signalements de bugs quotidiens en liste priorisée, puis automatisez ce passage en revue.
DifficultyIntermédiaire
Time horizon1 h
Demandez à Codex de vérifier les alertes récentes, les tickets, les vérifications ayant échoué, les journaux et les signalements dans les discussions, ajustez la liste dans une même discussion, puis planifiez l’exécution de ce passage en revue.
Idéal pour
Les équipes qui suivent les bugs dans les alertes Sentry, les fils Slack, les tickets Linear, les issues GitHub, les vérifications de PR en échec, les tickets d’assistance ou les journaux.
Les flux de travail de triage que vous souhaitez exécuter manuellement dans une même discussion Codex avant de planifier leur exécution.
Transformez les signalements de bugs quotidiens en liste priorisée, puis automatisez ce passage en revue.
Demandez à Codex de vérifier les alertes récentes, les tickets, les vérifications ayant échoué, les journaux et les signalements dans les discussions, ajustez la liste dans une même discussion, puis planifiez l’exécution de ce passage en revue.
Intermédiaire
1 h
Demandez à Codex de vérifier les alertes récentes, les tickets, les vérifications ayant échoué, les journaux et les signalements dans les discussions, ajustez la liste dans une même discussion, puis planifiez l’exécution de ce passage en revue.
Les équipes qui suivent les bugs dans les alertes Sentry, les fils Slack, les tickets Linear, les issues GitHub, les vérifications de PR en échec, les tickets d’assistance ou les journaux.
Les flux de travail de triage que vous souhaitez exécuter manuellement dans une même discussion Codex avant de planifier leur exécution.
Consultez les issues, les pull requests, les commentaires, les fils de revue et les vérifications ayant échoué lorsque GitHub fait partie de vos sources de signalement de bugs.
Examinez les erreurs de production, les traces de pile, les versions concernées et le contexte des événements lorsque des alertes font partie du passage en revue.
Consultez les issues, les pull requests, les commentaires, les fils de revue et les vérifications ayant échoué lorsque GitHub fait partie de vos sources de signalement de bugs.
Examinez les erreurs de production, les traces de pile, les versions concernées et le contexte des événements lorsque des alertes font partie du passage en revue.
Consultez les files de bugs, recherchez les tickets existants, rédigez des mises à jour ou préparez des tickets de suivi liés après le triage.
Prompt de démarrage
Effectuez un triage des bugs pour [repo/service/team] portant sur la période écoulée suivante : [time window].
Utilisez ces plugins : [@Sentry / @Slack / @Linear / @GitHub / none]
Sources d’entrée :
- Sentry : [project / alert link / none]
- Slack : [channel / thread links / none]
- Linear : [team / project / view / issue query / none]
- GitHub : [repo / issue query / PR checks / none]
- Autre : [logs / support tickets / deploy link / dashboard / attached file / none]
Format de sortie :
Commencez par indiquer toute source d’entrée à laquelle vous n’avez pas pu accéder.
Renvoyez ensuite une liste priorisée des bugs, classés de P0 à P3.
Si vous ne trouvez aucun bug, indiquez : Aucun bug répondant aux critères n’a été trouvé.
Pour chaque bug, incluez :
- Priorité : P0, P1, P2 ou P3
- Titre
- Éléments probants (liens ou courtes citations)
- Prochaine action recommandée
Règles :
- Ne publiez rien, ne créez rien, n’attribuez rien, n’ajoutez aucune étiquette, ne fermez rien, ne relancez rien et ne modifiez rien.
- Regroupez les signalements en double sous un même bug.
- Distinguez les faits observés des suppositions.
Effectuez un triage des bugs pour [repo/service/team] portant sur la période écoulée suivante : [time window].
Utilisez ces plugins : [@Sentry / @Slack / @Linear / @GitHub / none]
Sources d’entrée :
- Sentry : [project / alert link / none]
- Slack : [channel / thread links / none]
- Linear : [team / project / view / issue query / none]
- GitHub : [repo / issue query / PR checks / none]
- Autre : [logs / support tickets / deploy link / dashboard / attached file / none]
Format de sortie :
Commencez par indiquer toute source d’entrée à laquelle vous n’avez pas pu accéder.
Renvoyez ensuite une liste priorisée des bugs, classés de P0 à P3.
Si vous ne trouvez aucun bug, indiquez : Aucun bug répondant aux critères n’a été trouvé.
Pour chaque bug, incluez :
- Priorité : P0, P1, P2 ou P3
- Titre
- Éléments probants (liens ou courtes citations)
- Prochaine action recommandée
Règles :
- Ne publiez rien, ne créez rien, n’attribuez rien, n’ajoutez aucune étiquette, ne fermez rien, ne relancez rien et ne modifiez rien.
- Regroupez les signalements en double sous un même bug.
- Distinguez les faits observés des suppositions.
Utilisation
Demandez à Codex de vérifier les sources où les bugs sont déjà signalés : alertes Sentry, tickets Linear, issues GitHub, vérifications de PR, journaux de déploiement, tickets d’assistance et fils Slack. Commencez par un passage en revue manuel, ajustez le rapport dans la discussion, puis planifiez son exécution.
Utilisez une seule discussion Codex pour l’ensemble du cycle de triage :
Effectuez un passage en revue à la demande et obtenez une liste provisoire.
Examinez la liste et faites vos retours dans cette même discussion.
Depuis cette discussion, planifiez une tâche de triage.
Facultatif : demandez à Codex de rédiger des tickets Linear, des mises à jour Slack, des commentaires GitHub ou des notes de relais lorsque le rapport vous paraît fiable.
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 de véritables mentions @ de plugins. Remplacez ensuite chaque source entre crochets par l’emplacement précis à rechercher : un projet ou une URL d’alerte Sentry, un canal ou un fil Slack, une équipe, une vue ou une requête Linear, un dépôt, une requête d’issues ou une vérification de PR GitHub, un lien de déploiement, un fichier journal, une file d’assistance ou un tableau de bord.
Phase 1 : effectuer le passage en revue
Lancez Codex depuis le dépôt concerné par les bugs lorsque le contexte local est utile : tests, outils du dépôt, vérifications de build ou échecs de CI. Vous pouvez également effectuer le passage en revue depuis n’importe quel dépôt si vos sources de bugs sont accessibles via des plugins, des connecteurs, des serveurs MCP, des liens, des exportations, des journaux collés ou des pièces jointes.
Commencez par exécuter le prompt de départ ci-dessus. Ne conservez que les plugins et les sources qui font partie de votre passage en revue.
Par exemple, un prompt complété peut nommer les plugins ainsi que les files d’attente, canaux ou dépôts précis à inclure dans le passage en revue.
Phase 2 : rendre le rapport exploitable
Avant d’automatiser le processus, assurez-vous que le rapport sera utile au quotidien.
Une première exécution exploitable comprend :
Des bugs pertinents classés de P0 à P3.
Les signalements en double sont regroupés sous un même bug.
Chaque bug comporte des liens vers les éléments probants ou de courtes citations.
Les suppositions sont séparées des faits observés.
Chaque bug est assorti d’une brève recommandation sur la prochaine action à mener.
Ajustez le rapport dans la même discussion avant d’en planifier l’exécution. Vous pouvez demander à Codex de :
Consulter une source supplémentaire avant de classer la liste.
Écarter les alertes parasites que l’équipe connaît déjà.
Ne renvoyer que les bugs P0 et P1.
Regrouper les signalements Slack, les alertes Sentry et les échecs GitHub lorsqu’ils correspondent au même bug.
Afficher uniquement le meilleur lien pour chaque bug.
Ajouter suffisamment d’éléments probants pour qu’une autre personne puisse reproduire le problème ou le transmettre à la bonne équipe.
Phase 3 : automatiser le triage
Lorsque le rapport généré à la demande est exploitable, restez dans la même discussion et planifiez depuis celle-ci une tâche de triage. Codex peut s’appuyer sur vos ajustements dans la discussion pour rédiger le prompt récurrent.
Planifier la tâche de triage
Planifiez une tâche pour le flux de travail de triage des bugs que nous avons affiné dans cette discussion.
Planification : [every hour / every weekday morning / daily]
Reprenez les mêmes sources, règles de priorité, regroupement des doublons, présentation des éléments probants et format de rapport P0-P3 que dans cette discussion.
Lorsque vous rédigez le prompt de cette tâche planifiée, incluez les mentions de plugins ou les instructions relatives aux sources connectées nécessaires pour que l’exécution planifiée puisse de nouveau consulter ces sources.
La tâche planifiée doit uniquement produire des brouillons. Ne publiez rien, ne créez rien, n’attribuez rien, n’ajoutez aucune étiquette, ne fermez rien, ne relancez rien, n’entamez aucun correctif et ne modifiez pas le code.
Avant de planifier la tâche, montrez-moi son prompt, sa planification, ses sources et sa politique relative aux actions.
Phase 4 : orienter les actions de suivi
Une fois le rapport planifié exploitable, décidez de la suite à donner. Codex peut rédiger une mise à jour Slack pour un canal d’équipe, préparer des issues Linear pour les bugs que vous souhaitez suivre, rédiger des commentaires GitHub sur une PR dont les vérifications échouent ou préparer une note de passation pour la personne d’astreinte.
Mettez à jour la tâche de triage des bugs planifiée dans cette discussion.
Après chaque exécution planifiée, préparez les éléments de suivi dont j’ai besoin :
- Mise à jour Slack pour [channel]
- Issues Linear pour [which bugs should become issues]
- Commentaire GitHub sur [issue / PR / failing check]
- Note de passation pour [team / on-call / owner]
Règles :
- Préparez d’abord les éléments de suivi sous forme de brouillons dans Codex.
- Ne publiez rien sur Slack, ne créez pas d’issues Linear et ne commentez rien sur GitHub tant que je n’ai pas explicitement approuvé l’action concernée.
- Ajoutez, lorsqu’ils sont disponibles, des liens vers les éléments existants dans Linear, GitHub ou Slack, ou vers les sources d’alertes.
- Pour toute action non explicitement approuvée, préparez uniquement un brouillon.
Tech stack
Need
Default options
Why it's needed
Need
Où trouver le contexte des bugs
Default options
Alertes Sentry, canaux Slack, vues Linear, issues GitHub, vérifications de PR, files d’assistance, notes d’astreinte, journaux, tableaux de bord et notes de déploiement
Why it's needed
Indiquez précisément les files d’attente, canaux, vues, dépôts, liens d’alerte, tableaux de bord et fichiers que Codex doit passer en revue.
Need
Comment Codex y accède
Default options
Plugins pour Slack, Linear, GitHub et Sentry ; connecteurs ; serveurs MCP ; CLI propres aux dépôts ; liens ; exportations ; pièces jointes et journaux collés
Why it's needed
Installez l’intégration existante lorsqu’il y en a une. Créez ou configurez un petit serveur MCP, une CLI, une exportation ou un lien vers un tableau de bord pour les sources internes auxquelles Codex ne peut pas encore accéder.
Need
Default options
Why it's needed
Où trouver le contexte des bugs
Alertes Sentry, canaux Slack, vues Linear, issues GitHub, vérifications de PR, files d’assistance, notes d’astreinte, journaux, tableaux de bord et notes de déploiement
Indiquez précisément les files d’attente, canaux, vues, dépôts, liens d’alerte, tableaux de bord et fichiers que Codex doit passer en revue.
Comment Codex y accède
Plugins pour Slack, Linear, GitHub et Sentry ; connecteurs ; serveurs MCP ; CLI propres aux dépôts ; liens ; exportations ; pièces jointes et journaux collés
Installez l’intégration existante lorsqu’il y en a une. Créez ou configurez un petit serveur MCP, une CLI, une exportation ou un lien vers un tableau de bord pour les sources internes auxquelles Codex ne peut pas encore accéder.