For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Navigation principale
Codex

Codex use case

Automatiser le triage des bugs

Transformez les signalements de bugs quotidiens en liste priorisée, puis automatisez ce passage en revue.

Difficulty Intermédiaire
Time horizon 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.

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.

Contents

    ← Tous les cas d’utilisation

    Automatiser le triage des bugs

    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.

    Intermédiaire
    1 h

    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.

    Skills et plugins

    • 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 canaux ou les fils dans lesquels vos collègues signalent des bugs et préparez un projet de synthèse destiné à un canal d’équipe.
    • 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.
    Skill Why use it
    GitHub 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.
    Sentry 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.
    Slack Consultez les canaux ou les fils dans lesquels vos collègues signalent des bugs et préparez un projet de synthèse destiné à un canal d’équipe.
    Linear 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 :

    1. Effectuez un passage en revue à la demande et obtenez une liste provisoire.
    2. Examinez la liste et faites vos retours dans cette même discussion.
    3. Depuis cette discussion, planifiez une tâche de triage.
    4. 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

    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.

    Cas d’utilisation associés