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

Codex use case

Automatisez le tri des bugs

Classez les bugs signalés chaque jour par ordre de priorité, puis automatisez ce tri.

Difficulty Intermediate
Time horizon 1h

Demandez à Codex d’examiner les données récentes : alertes, tickets, vérifications en échec, journaux et signalements dans les discussions. Affinez la liste dans une seule discussion, puis planifiez ce tri à intervalles réguliers.

Best for

  • Les équipes qui suivent les bugs à partir d’alertes Sentry, de fils Slack, de tickets Linear, d’issues GitHub, de vérifications de PR en échec, de tickets d’assistance ou de journaux.
  • Les workflows de tri que vous souhaitez exécuter manuellement dans une seule discussion avec Codex avant de les planifier.

Contents

    ← All use cases

    Automatisez le tri des bugs

    Classez les bugs signalés chaque jour par ordre de priorité, puis automatisez ce tri.

    Demandez à Codex d’examiner les données récentes : alertes, tickets, vérifications en échec, journaux et signalements dans les discussions. Affinez la liste dans une seule discussion, puis planifiez ce tri à intervalles réguliers.

    Intermediate
    1h

    Demandez à Codex d’examiner les données récentes : alertes, tickets, vérifications en échec, journaux et signalements dans les discussions. Affinez la liste dans une seule discussion, puis planifiez ce tri à intervalles réguliers.

    Intermediate
    1h

    Best for

    • Les équipes qui suivent les bugs à partir d’alertes Sentry, de fils Slack, de tickets Linear, d’issues GitHub, de vérifications de PR en échec, de tickets d’assistance ou de journaux.
    • Les workflows de tri que vous souhaitez exécuter manuellement dans une seule discussion avec Codex avant de les planifier.

    Skills & Plugins

    • Si vous recevez des signalements de bugs sur GitHub, consultez les issues, les pull requests, les commentaires, les fils de revue de code et les vérifications en échec.
    • Si le tri inclut des alertes, examinez les erreurs en production, les traces de pile, les versions touchées et le contexte des événements.
    • Consultez les canaux ou les fils de discussion où vos collègues signalent des bugs et préparez un brouillon de synthèse pour un canal d’équipe.
    • Après le tri, parcourez les files de bugs, recherchez les tickets existants, rédigez des propositions de mise à jour ou préparez des tickets de suivi liés aux bugs examinés.
    Skill Why use it
    GitHub Si vous recevez des signalements de bugs sur GitHub, consultez les issues, les pull requests, les commentaires, les fils de revue de code et les vérifications en échec.
    Sentry Si le tri inclut des alertes, examinez les erreurs en production, les traces de pile, les versions touchées et le contexte des événements.
    Slack Consultez les canaux ou les fils de discussion où vos collègues signalent des bugs et préparez un brouillon de synthèse pour un canal d’équipe.
    Linear Après le tri, parcourez les files de bugs, recherchez les tickets existants, rédigez des propositions de mise à jour ou préparez des tickets de suivi liés aux bugs examinés.

    Starter prompt

    Triez les bugs de [repo/service/team] sur la période écoulée : [time window]. Utilisez les plugins suivants : [@Sentry / @Slack / @Linear / @GitHub / none] Sources à consulter : - Sentry : [project / alert link / none] - Slack : [channel / thread links / none] - Linear : [team / project / view / issue query / none] - GitHub : [repo / issue query / PR checks / none] - Autres : [logs / support tickets / deploy link / dashboard / attached file / none] Format attendu : Indiquez d’abord les sources auxquelles vous n’avez pas pu accéder. Dressez ensuite la liste des bugs par ordre de priorité, de P0 à P3. Si vous ne trouvez aucun bug, indiquez : « Aucun bug ne répond aux critères. » Pour chaque bug, précisez : - La priorité : P0, P1, P2 ou P3 - Le titre - Les éléments à l’appui (liens ou courtes citations) - La prochaine action recommandée Règles : - Ne publiez, ne créez, n’attribuez, n’étiquetez, ne fermez, ne relancez et ne modifiez rien. - Regroupez les signalements qui concernent le même bug. - Distinguez les faits observés des hypothèses.
    Triez les bugs de [repo/service/team] sur la période écoulée : [time window]. Utilisez les plugins suivants : [@Sentry / @Slack / @Linear / @GitHub / none] Sources à consulter : - Sentry : [project / alert link / none] - Slack : [channel / thread links / none] - Linear : [team / project / view / issue query / none] - GitHub : [repo / issue query / PR checks / none] - Autres : [logs / support tickets / deploy link / dashboard / attached file / none] Format attendu : Indiquez d’abord les sources auxquelles vous n’avez pas pu accéder. Dressez ensuite la liste des bugs par ordre de priorité, de P0 à P3. Si vous ne trouvez aucun bug, indiquez : « Aucun bug ne répond aux critères. » Pour chaque bug, précisez : - La priorité : P0, P1, P2 ou P3 - Le titre - Les éléments à l’appui (liens ou courtes citations) - La prochaine action recommandée Règles : - Ne publiez, ne créez, n’attribuez, n’étiquetez, ne fermez, ne relancez et ne modifiez rien. - Regroupez les signalements qui concernent le même bug. - Distinguez les faits observés des hypothèses.

    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 :

    1. Lancez une analyse à la demande pour obtenir une première liste de bugs.
    2. Examinez la liste et faites part de vos remarques dans la même discussion.
    3. Depuis cette discussion, planifiez une tâche de triage.
    4. 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

    Planifiez une tâche pour le workflow de triage des bugs que nous avons affiné dans cette discussion. Fréquence : [every hour / every weekday morning / daily] Reprenez les sources, les règles de priorité, les critères de regroupement des doublons, la présentation des éléments à l’appui et le format du rapport P0 à P3 définis dans cette discussion. Dans le prompt de la tâche planifiée, incluez les mentions de plugins ou les instructions d’accès aux sources connectées nécessaires pour que la tâche puisse consulter à nouveau ces sources à chaque exécution. Limitez la tâche planifiée à la rédaction de brouillons. Ne publiez, ne créez, n’attribuez, n’étiquetez, ne clôturez et ne relancez rien. N’entamez aucun correctif et ne modifiez pas le code. Avant de planifier la tâche, montrez-moi son prompt, sa fréquence, ses sources et les règles qui encadrent ses actions.

    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.

    Mettez à jour la tâche de triage des bugs planifiée depuis cette discussion. Après chaque exécution planifiée, préparez les brouillons dont j’ai besoin pour le suivi : - Message Slack pour [channel] - Tickets Linear pour [which bugs should become issues] - Commentaire GitHub pour [issue / PR / failing check] - Note de passation pour [team / on-call / owner] Règles : - Rédigez d’abord les brouillons dans Codex. - Ne publiez rien sur Slack, ne créez aucun ticket Linear et ne laissez aucun commentaire sur GitHub sans mon approbation explicite pour l’action concernée. - Lorsque les liens sont disponibles, incluez ceux qui renvoient aux sources existantes dans Linear, GitHub ou Slack, ou à l’origine des alertes. - Pour toute action que je n’ai pas explicitement approuvée, limitez-vous à la rédaction d’un brouillon.

    Tech stack

    Need

    Sources d’information sur les bugs

    Default options

    Alertes Sentry, canaux Slack, vues Linear, issues GitHub, vérifications de PR, files de tickets d’assistance, notes d’astreinte, journaux, tableaux de bord et notes de déploiement

    Why it's needed

    Précisez les files, les canaux, les vues, les dépôts, les liens vers les alertes, les tableaux de bord et les fichiers que Codex doit examiner.

    Need

    Comment Codex accède aux sources

    Default options

    Plugins pour Slack, Linear, GitHub et Sentry, connecteurs, serveurs MCP , CLI des dépôts, liens, exports, pièces jointes et journaux collés dans la discussion

    Why it's needed

    Si une intégration existe, installez-la. Pour les sources internes auxquelles Codex n’a pas encore accès, créez ou configurez un petit serveur MCP, une CLI, un export ou un lien vers un tableau de bord.

    Need Default options Why it's needed
    Sources d’information sur les bugs Alertes Sentry, canaux Slack, vues Linear, issues GitHub, vérifications de PR, files de tickets d’assistance, notes d’astreinte, journaux, tableaux de bord et notes de déploiement Précisez les files, les canaux, les vues, les dépôts, les liens vers les alertes, les tableaux de bord et les fichiers que Codex doit examiner.
    Comment Codex accède aux sources Plugins pour Slack, Linear, GitHub et Sentry, connecteurs, serveurs MCP , CLI des dépôts, liens, exports, pièces jointes et journaux collés dans la discussion Si une intégration existe, installez-la. Pour les sources internes auxquelles Codex n’a pas encore accès, créez ou configurez un petit serveur MCP, une CLI, un export ou un lien vers un tableau de bord.

    Related use cases