Accélérer la maintenance des projets open source avec les skills

Codex change notre façon de maintenir les dépôts du SDK Agents d’OpenAI. Grâce aux skills propres à chaque dépôt, à AGENTS.md et à GitHub Actions, nous avons transformé des tâches récurrentes en workflows reproductibles : vérification des changements, préparation des versions, tests d’intégration des exemples et revue des pull requests (PR). Malgré sa simplicité, cette organisation nous a permis d’augmenter notre débit de développement dans ces dépôts actifs. Du 1er décembre 2025 au 28 février 2026, nous y avons fusionné 457 PR, contre 316 au cours des trois mois précédents, du 1er septembre au 30 novembre 2025. Le dépôt Python est passé de 182 à 226 PR fusionnées et le dépôt TypeScript, de 134 à 231.

Le SDK existe en Python et en TypeScript. Il fournit les composants essentiels pour créer des applications à base d’agents. Il permet aussi de créer des agents vocaux en peu de code avec la Realtime API, en combinant plusieurs agents, des outils et des contrôles faisant intervenir un humain. Le SDK est largement utilisé : au 6 mars 2026, sur des périodes récentes de 30 jours, le paquet Python comptait environ 14,7 millions de téléchargements sur PyPI et le paquet TypeScript, environ 1,5 million sur npm.

Notre configuration tient en quatre éléments :

• les règles du dépôt dans AGENTS.md
• les skills propres au dépôt dans .agents/skills/
• des scripts et des références facultatifs dans ces skills
• la GitHub Action pour Codex lorsque le même workflow doit s’exécuter en intégration continue (CI)

Codex dispose ainsi d’un contexte stable sur le fonctionnement du dépôt et peut accomplir les tâches récurrentes plus vite et avec plus de précision.

Conservez les workflows dans le dépôt

Dans ces dépôts, nous utilisons les skills pour formaliser les workflows propres à chaque projet. Un skill rassemble le savoir-faire nécessaire à une tâche dans un manifeste SKILL.md, éventuellement accompagné des répertoires scripts/, references/ et assets/. La documentation sur la personnalisation de Codex explique pourquoi les skills se prêtent aux workflows reproductibles : ils peuvent contenir des instructions détaillées, des scripts et des références sans alourdir d’emblée le contexte de l’agent.

L’agent découvre ainsi le contenu des skills progressivement :

• il consulte d’abord les métadonnées, notamment name et description
• il charge SKILL.md uniquement lorsqu’il sélectionne le skill
• il consulte les références ou exécute les scripts au besoin

Les deux dépôts du SDK conservent ces workflows à côté du code :

• .agents/skills dans openai-agents-python
• .agents/skills dans openai-agents-js

Le dépôt Python illustre la configuration de base, plus simple :

• code-change-verification exécute les étapes obligatoires de formatage, d’analyse statique, de vérification des types et de test lorsque le code ou le comportement du build change.
• docs-sync compare la documentation au code source pour repérer les informations manquantes, erronées ou obsolètes.
• examples-auto-run exécute les exemples en mode automatique, consigne les résultats dans des journaux et fournit des outils pour relancer les exemples.
• final-release-review compare le tag de la version précédente à la version candidate et vérifie si celle-ci est prête à être publiée.
• implementation-strategy détermine la compatibilité à préserver et l’approche à suivre avant toute modification du code d’exécution ou de l’API.
• openai-knowledge récupère la documentation à jour sur l’API et la plateforme OpenAI via le workflow MCP officiel de la documentation.
• pr-draft-summary propose un nom de branche, un titre de PR et un brouillon de description lorsque les changements sont prêts à être transmis.
• test-coverage-improver mesure la couverture des tests, repère les lacunes les plus importantes et propose les tests qui auraient le plus d’impact.

Le dépôt JavaScript suit le même principe, avec quelques skills supplémentaires adaptés à son monorepo npm et à son processus de publication :

• changeset-validation vérifie que les changesets et les niveaux d’incrément de version correspondent aux modifications apportées aux paquets.
• integration-tests publie les paquets dans un registre Verdaccio local et vérifie leur installation et leur exécution dans les environnements pris en charge.
• pnpm-upgrade met à jour conjointement la chaîne d’outils pnpm et les versions fixées dans la CI.

La liste exacte importe moins que le principe : chaque skill a un rôle précis, une condition de déclenchement claire et un résultat concret à produire.

Certains des skills les plus utiles n’imposent aucun contrôle bloquant. docs-sync et test-coverage-improver commencent par dresser un bilan : ils examinent le diff en cours ou les résultats de couverture, établissent les priorités et demandent une approbation avant de modifier les fichiers. Dans le dépôt Python, docs-sync s’appuie aussi sur les docstrings et les commentaires du code source, qui font autorité pour la documentation de référence générée. Cela évite de corriger à la main les fichiers générés. Le skill pnpm-upgrade, propre au dépôt JavaScript, illustre lui aussi l’intérêt d’un workflow de maintenance ciblé : il met à jour ensemble la version locale de pnpm, packageManager et les versions fixées dans les workflows, sans recourir à un rechercher-remplacer généralisé.

Rendez les workflows obligatoires

Les skills gagnent en utilité lorsque le dépôt impose leur utilisation au bon moment. C’est le rôle du fichier AGENTS.md.

Le guide AGENTS.md explique que ces fichiers contiennent des instructions propres au dépôt, qui accompagnent le code source et s’appliquent avant que l’agent commence à travailler. Il recommande aussi de rester concis. Dans les dépôts du SDK Agents, nous y consignons les règles que Codex doit suivre systématiquement et plaçons les plus importantes en tête.

En pratique, les deux dépôts utilisent de courtes règles conditionnelles pour indiquer quels skills sont obligatoires. Avant de modifier le code d’exécution ou l’API, appelez $implementation-strategy pour déterminer la compatibilité à préserver et l’approche à suivre. Si le changement touche le code du SDK, les tests, les exemples ou le comportement du build, appelez $code-change-verification. Si la modification d’un paquet JavaScript touche les métadonnées de publication, appelez $changeset-validation. Si vous intervenez sur une intégration avec l’API ou la plateforme OpenAI, appelez $openai-knowledge. Lorsque le travail est terminé et prêt à être transmis, appelez $pr-draft-summary.

Cette structure suit aussi les recommandations d’agents.md : regroupez la présentation du projet, les commandes de build et de test, les conventions de code, les consignes de test, les considérations de sécurité et les autres règles propres au dépôt. Les dépôts du SDK Agents suivent ce modèle et commencent par les conditions de déclenchement les plus importantes au quotidien. Voici une version abrégée :

# AGENTS.md

## Project overview

- Core SDK code lives under `src/agents/` or `packages/*/src/`.
- Tests live under `tests/` or `packages/*/test/`.
- Sample apps and integration surfaces live under `examples/`.

## Mandatory skill usage

- Use `$implementation-strategy` before editing runtime or API changes that may affect compatibility boundaries.
- Run `$code-change-verification` when runtime code, tests, examples, or build/test behavior changes.
- Use `$openai-knowledge` for OpenAI API or platform work.
- Use `$pr-draft-summary` when substantial code work is ready for review.

## Build and test commands

- Python: `make format`, `make lint`, `make typecheck`, `make tests`
- TypeScript: `pnpm i`, `pnpm build`, `pnpm -r build-check`, `pnpm lint`, `pnpm test`

## Compatibility rules

- Preserve positional compatibility for public constructors and dataclass fields.

Les fichiers utilisés dans les dépôts complètent cette base par des consignes propres à chaque projet. On y trouve par exemple $changeset-validation dans le dépôt JavaScript et, dans les deux fichiers, des instructions plus détaillées sur l’exécution, la documentation et la publication. Pour consulter les exemples complets, ouvrez AGENTS.md dans openai-agents-python et AGENTS.md dans openai-agents-js.

AGENTS.md sert aussi à consigner d’autres règles. Le dépôt Python y précise comment préserver la compatibilité de l’API publique : conservez la signification de chaque position dans les paramètres des constructeurs exportés et les champs des dataclasses, ajoutez si possible les nouveaux paramètres ou champs facultatifs à la fin et ajoutez des tests de compatibilité si vous devez modifier l’ordre. C’est une pratique à reprendre : placez les règles de compatibilité essentielles à la publication au même endroit que les conditions de déclenchement des skills.

Règles de vérification

Le skill $code-change-verification en est un bon exemple.

Dans les deux dépôts, la règle ne dit pas « exécutez systématiquement une longue série de vérifications ». Elle dit « exécutez les vérifications si le code d’exécution, les tests, les exemples ou le comportement du build ou des tests a changé, et ne considérez le travail comme terminé qu’une fois toutes les vérifications réussies ».

La condition évite d’alourdir les changements limités à la documentation. Le caractère obligatoire des vérifications garantit que toute modification du code du SDK passe par les contrôles habituels du dépôt.

Les skills définissent eux-mêmes les vérifications à exécuter.

Dans le dépôt Python, le skill impose les commandes suivantes :

make format
make lint
make typecheck
make tests

Dans le dépôt JavaScript, le skill impose cet ordre précis :

pnpm i
pnpm build
pnpm -r build-check
pnpm -r -F "@openai/*" dist:check
pnpm lint
pnpm test

Le skill définit ce que le dépôt entend par « vérifié », et AGENTS.md impose le respect de cette définition.

Validation des changesets

Le dépôt JavaScript impose une étape supplémentaire pour les changements apportés aux paquets : $changeset-validation, qui s’appuie sur Changesets.

Dès qu’un élément de packages/ change ou que .changeset/ est modifié, le modèle doit aller au-delà des tests. Il doit créer ou mettre à jour le changeset approprié, valider le niveau d’incrément de version et confirmer que le changeset correspond bien au diff.

Ce skill vérifie davantage que la présence d’un fichier. Il demande à Codex d’évaluer le diff Git et regroupe les règles de validation dans un prompt partagé afin que les exécutions locales et GitHub Actions appliquent la même logique. Il précise aussi des règles propres au dépôt :

• Réutilisez le changeset de la branche s’il existe déjà.
• Rédigez le résumé sur une seule ligne au format Conventional Commit pour qu’il puisse aussi servir de titre de commit.
• Avant la version 1.0, évitez les incréments majeurs pour les évolutions fonctionnelles courantes et traitez comme des correctifs les ajouts explicitement réservés à la préversion s’ils ne modifient pas le comportement existant.
• Vérifiez le niveau d’incrément requis au regard des modifications réellement apportées au paquet.

Codex doit ainsi valider les métadonnées de publication qu’il crée avant de pouvoir annoncer que le travail est terminé.

Utilisez une documentation à jour

Les deux dépôts imposent également $openai-knowledge pour toute intervention sur une intégration avec l’API ou la plateforme OpenAI.

Ce skill fournit un accès direct au MCP officiel de la documentation OpenAI. Plutôt que de laisser le modèle répondre de mémoire, il demande à Codex de consulter le serveur MCP de la documentation développeur OpenAI pour obtenir des informations à jour, notamment sur la Responses API, les outils, le streaming, Realtime et MCP.

Si le serveur MCP n’est pas encore configuré dans l’environnement Codex local, le skill renvoie les responsables du dépôt vers le guide de démarrage du MCP de la documentation et le point de terminaison officiel du serveur MCP.

Préparez la PR pour la revue

À la fin d’une intervention conséquente, les deux dépôts utilisent $pr-draft-summary.

Ce skill se déclenche uniquement lorsque la tâche est pratiquement terminée ou prête pour la revue et que les changements sont significatifs : code, tests, exemples, documentation ayant une incidence sur le comportement ou configuration du build ou des tests. Il relève automatiquement le nom de la branche, l’état de l’arbre de travail, les fichiers modifiés, les statistiques du diff et les commits récents, puis produit :

• une proposition de nom de branche
• un titre de PR
• un brouillon de description de la PR

Le format de sortie est volontairement strict. Voici un résultat typique :

# Pull Request Draft

## Branch name suggestion

git checkout -b fix/tracing-lazy-init-fork-safety

## Title

fix: #2489 lazily initialize tracing globals to avoid import-time fork hazards

## Description

This pull request fixes import-time tracing side effects that could break fork-based process models by moving tracing bootstrap to lazy, first-use initialization.

It updates tracing setup so initialization happens once on first access while preserving the existing public tracing APIs.

It also adds regression tests for import-time behavior, one-time bootstrap, and custom provider handling.

This pull request resolves #2489.

Lorsque vous pouvez compter sur le modèle pour valider et résumer son travail, il est naturel de lui confier aussi le brouillon de la PR. Les changements sont ainsi présentés de manière cohérente et vous évitez une tâche de rédaction répétitive une fois le code terminé.

Rédigez des descriptions plus précises

Le champ description dans les métadonnées d’en-tête du fichier SKILL.md contribue à déterminer quand le skill sera sélectionné.

Il s’agit d’une exigence structurelle. La spécification Agent Skills impose les champs name et description dans l’en-tête de SKILL.md. Selon son principe de découverte progressive, ces champs sont chargés au démarrage pour tous les skills. Le corps de SKILL.md et les éventuels répertoires scripts/, references/ ou assets/ ne sont chargés que plus tard, lorsque le skill est activé.

La documentation sur les skills Codex et la documentation sur la personnalisation décrivent ce fonctionnement du côté de Codex : Codex commence par les métadonnées de chaque skill pour découvrir les skills disponibles. Il charge SKILL.md uniquement s’il sélectionne le skill, puis consulte les références ou exécute les scripts au besoin. Le guide du Cookbook sur les skills dans l’API OpenAI décrit tout aussi précisément le fonctionnement du shell distant : OpenAI lit d’abord les champs name et description ainsi que le chemin de chaque skill. Le modèle utilise ces informations pour décider quand lire le fichier SKILL.md en entier. La section sur l’en-tête de SKILL.md le précise : name et description jouent un rôle important dans la découverte et la sélection des skills.

Dans les dépôts du SDK Agents, description est donc l’un des principaux critères dont dispose Codex pour choisir un skill avant d’en lire le contenu.

Prenons l’exemple de code-change-verification.

Description trop vague :

description: Run the mandatory verification stack in the OpenAI Agents JS monorepo.

Description plus précise, telle qu’elle figure dans le dépôt :

description: Run the mandatory verification stack when changes affect runtime code, tests, or build/test behavior in the OpenAI Agents JS monorepo.

La version courte indique déjà à Codex ce que fait le skill, mais laisse trois questions ouvertes : quand s’applique-t-il, quels changements doivent le déclencher et les vérifications sont-elles facultatives ? La version plus précise répond aux trois.

On retrouve le même principe dans pr-draft-summary.

Description trop vague :

description: Create a PR title and draft description for a pull request.

Description plus précise, telle qu’elle figure dans le dépôt :

description: Create a PR title and draft description after substantive code changes are finished. Trigger when wrapping up a moderate-or-larger change (runtime code, tests, build config, docs with behavior impact) and you need the PR-ready summary block with change summary plus PR draft text.

Là encore, la description sert à orienter le modèle. Elle indique à Codex que :

• le skill intervient en fin de tâche
• il s’applique aux changements conséquents, sans se déclencher à chaque échange
• il produit un bloc de texte prêt à intégrer à la PR, qui va au-delà d’un simple résumé

Ces dépôts nous ont appris à soigner le champ description. Si Codex ne sélectionne pas les skills de manière fiable, corrigez les métadonnées avant d’ajouter du code.

Confiez les opérations répétitives aux scripts

Il reste ensuite à déterminer ce que le modèle doit prendre en charge et ce qu’il vaut mieux confier à un script.

La répartition suivante fonctionne bien :

• le modèle interprète, compare et rend compte des résultats
• les opérations shell déterministes et répétitives vont dans scripts/

Cette répartition suit les recommandations publiques. La documentation sur la personnalisation de Codex présente les skills comme un moyen de fournir à Codex des instructions détaillées, des scripts et des références pour les workflows reproductibles sans alourdir son contexte initial. Le modèle peut ainsi piloter le workflow : laissez Codex traiter ce qui dépend du contexte et faites appel aux scripts pour les opérations déterministes, uniquement au besoin. Le guide du Cookbook sur les skills dans l’API OpenAI recommande aussi de concevoir les scripts des skills comme de petites CLI : ils s’exécutent en ligne de commande, produisent une sortie standard déterministe, signalent clairement les échecs par un message d’aide ou d’erreur et, au besoin, écrivent leurs résultats à des emplacements connus.

Dans les dépôts du SDK Agents, nous sollicitons le modèle pour les tâches qui demandent du discernement, par exemple :

• lire le code source pour en déduire le comportement attendu
• comparer les journaux à ce comportement
• déterminer si le diff d’une version présente un risque réel de compatibilité
• fournir des explications qui permettent au responsable du dépôt de décider de la suite

Les scripts se chargent des opérations nécessaires à ce travail, par exemple :

• exécuter dans un ordre fixe les commandes de vérification exigées par le dépôt
• lancer les exemples, recueillir les journaux de chacun et écrire les fichiers permettant de relancer ceux qui ont échoué
• récupérer le tag de la version précédente avant de vérifier si la nouvelle version est prête à être publiée
• fournir des commandes auxiliaires comme start, stop, status, logs, tail, collect et rerun pour faciliter les exécutions successives du même workflow

Si le modèle doit retrouver la même séquence de commandes shell à chaque exécution, il vaut généralement mieux en faire un script. Si une partie de la tâche dépend du contexte, demande un arbitrage ou nécessite une explication, confiez-la au modèle.

Automatisez les tests d’intégration

Les tests d’intégration automatisés comptent parmi les workflows les plus utiles dans les deux dépôts. Ils interviennent à deux niveaux : dans les deux dépôts, nous validons automatiquement les exemples fournis avec le code. Dans le dépôt JavaScript, nous vérifions aussi, séparément, que les paquets publiés fonctionnent toujours lorsqu’on les installe comme le font les utilisateurs.

Auparavant, la validation des exemples était en partie manuelle. On pouvait les exécuter, mais il fallait souvent finir par parcourir les journaux à l’œil ou examiner la sortie pour juger si elle semblait correcte. C’est faisable pour un exemple, beaucoup moins à l’échelle d’un dépôt de SDK qui continue de s’étoffer.

Le premier niveau repose sur examples-auto-run, mais nous avons créé l’outil d’exécution avant le skill. Pour automatiser la validation, il fallait d’abord que les deux dépôts puissent exécuter les exemples sans interaction. Nous avons donc doté les scripts d’exemple d’un mode automatique, y compris ceux qui demandent normalement une saisie ou une approbation.

Ce travail préparatoire a consisté à :

• répondre automatiquement aux invites interactives courantes
• approuver automatiquement les actions HITL, MCP, apply_patch et shell lorsque l’outil d’exécution le permet
• tenir une liste des exemples à ignorer automatiquement tant qu’ils ne se prêtent pas à l’automatisation, notamment les exemples en temps réel ou les applications Next.js qui nécessitent une configuration d’exécution supplémentaire
• consigner chaque exécution d’exemple dans un journal structuré
• générer des fichiers de relance pour pouvoir réessayer les exemples en échec sans tout réexécuter

Une fois ces mécanismes en place, nous les avons regroupés dans un skill pour rendre le workflow réutilisable et facile à lancer. Dans le dépôt Python, examples-auto-run s’appuie sur uv run examples/run_examples.py --auto-mode --write-rerun --main-log ... --logs-dir .... Dans le dépôt JavaScript, il effectue les vérifications du build, puis lance pnpm examples:start-all en mode automatique, avec un journal par exemple et la possibilité de relancer les exemples en échec.

Pour améliorer la qualité de la validation, l’outil exécute les exemples et conserve leur sortie standard (stdout) et leur sortie d’erreur (stderr) dans un journal par exemple. Le skill demande ensuite à Codex de parcourir ces journaux un à un et de les comparer au code source :

• Lisez le code source de l’exemple et ses commentaires.
• Déduisez-en le déroulement attendu.
• Ouvrez le journal correspondant.
• Comparez le comportement attendu aux sorties stdout et stderr obtenues.
• Répétez ces étapes pour chaque exemple dont l’exécution a réussi, sans vous limiter à un échantillon.

Cette méthode est plus précise et plus souple qu’une assertion figée dans un script pour vérifier le comportement. Un code de sortie indiquant un succès est utile, mais insuffisant pour les exemples qui appellent de vraies API, utilisent des outils ou produisent des sorties structurées. En enregistrant d’abord la sortie réelle, puis en la comparant attentivement au code source, nous pouvons valider chaque exemple en fonction de ce qu’il est censé faire.

Le dépôt JavaScript ajoute un second niveau de vérification avec un skill distinct, integration-tests. Ce workflow va au-delà de l’exécution des exemples directement depuis le code source. Il publie les paquets dans un registre Verdaccio local, puis teste leur installation et leur exécution dans plusieurs environnements, dont Node.js, Bun, Deno, Cloudflare Workers et une application React avec Vite. Il détecte ainsi d’autres problèmes. À la question « l’exemple s’exécute-t-il dans le dépôt ? » s’ajoute « le paquet fonctionne-t-il toujours correctement une fois publié, installé et intégré à son environnement d’exécution ? ».

Ces workflows montrent l’intérêt d’associer les skills, les scripts et le jugement du modèle. Les scripts rendent les exécutions reproductibles, recueillent les éléments à examiner et couvrent des scénarios d’installation fastidieux à vérifier à la main. Codex s’appuie ensuite sur ces éléments pour effectuer une comparaison plus fine qu’un simple contrôle de réussite ou d’échec dans un script.

Ajoutez des contrôles avant publication

Cette répartition des rôles facilite aussi la préparation des versions.

Dans les deux dépôts, le workflow de revue avant publication commence par retrouver le tag de la version précédente et produire un diff avec le dernier état de main. Il demande ensuite à Codex de rechercher dans ce diff :

• les problèmes de rétrocompatibilité dans les API publiques et le comportement du SDK visible par les utilisateurs
• les régressions, y compris les écarts mineurs par rapport au comportement attendu
• les notes de migration manquantes ou les notes de version à mettre à jour pour les changements qui le nécessitent

À partir de ces constats, le skill détermine si, dans l’ensemble, la version est prête à être publiée.

La PR openai/openai-agents-python#2480 en donne un exemple concret. La revue donne son feu vert à la publication, tout en signalant l’abandon de la prise en charge de Python 3.9 et la nécessité de le mentionner dans les notes de version :

Release readiness review (excerpt)

Release call:
🟢 GREEN LIGHT TO SHIP. Minor-version bump includes expected breaking change
(Python 3.9 drop) with no concrete regressions found.

Scope summary:

- 38 files changed (+1450/-789); key areas touched: `src/agents/tool.py`,
  `src/agents/extensions/`, `src/agents/realtime/`, `tests/`,
  `pyproject.toml`, `uv.lock`.

Python 3.9 support removed

- Risk: 🟡 MODERATE. Users pinned to Python 3.9 will be unable to install the
  0.9.0 release.
- Evidence: `pyproject.toml` now sets `requires-python = ">=3.10"` and drops
  the Python 3.9 classifier; CI skip logic for 3.9 was removed.
- Action: Ensure release notes clearly call out the Python 3.9 drop and that
  packaging metadata remains `>=3.10`.

Le skill précise également les critères de décision. La revue part du principe que « la version peut être publiée » et ne bloque la publication que si le diff fournit des éléments concrets attestant un problème réel. Chaque décision de blocage doit s’accompagner d’une liste précise des actions à mener pour le lever. Le résultat est ainsi plus facile à exploiter : un feu vert signifie que la revue n’a relevé aucun problème bloquant dans le diff. En cas de blocage, le problème est identifié et la prochaine étape est claire.

Cette consigne est plus utile qu’un simple « veuillez examiner la version ». Elle oblige le modèle à raisonner à partir d’un diff concret et à expliquer les conséquences de ses constats pour la publication. Si la version peut être publiée sans risque, indiquez-le. Sinon, précisez quels éléments justifient le blocage et quelles actions sont nécessaires.

Exécutez les workflows en CI

Dès qu’un skill fait ses preuves en local, la GitHub Action pour Codex facilite l’automatisation du même workflow en CI. Les résultats sont meilleurs si le workflow est déjà stable en local : c’est en l’exécutant manuellement que vous corrigez les instructions, affinez les scripts et découvrez les cas limites qui se présentent réellement.

Dans un dépôt public, le choix des conditions de déclenchement compte autant que le skill lui-même. La liste de contrôle de sécurité de la GitHub Action recommande de limiter les personnes autorisées à lancer le workflow, de privilégier les événements de confiance ou les approbations explicites, d’assainir les entrées du prompt provenant de PR, de commits, d’issues ou de commentaires, de protéger OPENAI_API_KEY avec drop-sudo ou un compte utilisateur sans privilèges et d’exécuter Codex en dernière étape du job.

Lorsqu’un workflow dispose de droits d’écriture et accepte des entrées publiques non fiables, le risque tient généralement aux conditions de déclenchement, au traitement des entrées et aux privilèges dont dispose le skill à l’exécution.

Utilisez Codex pour la revue des PR

Les skills expliquent en partie les gains de productivité dans ces dépôts. La révision automatique des PR GitHub avec Codex y contribue également.

Depuis que cette fonctionnalité est disponible, Codex nous aide à examiner la plupart des modifications de code dans les deux dépôts. Nous l’utilisons couramment pour la revue de code.

Pour les bugs simples, les régressions et les tests manquants, notre expérience montre que nous pouvons désormais confier la revue obligatoire à Codex avec suffisamment de confiance. Il vérifie systématiquement les mêmes critères de correction, ce qui a éliminé un frein majeur aux petits correctifs et aux améliorations courantes.

La revue par les pairs reste importante pour d’autres types de changements.

Une revue humaine reste indispensable lorsque la question centrale dépasse « ce code est-il correct ? » et devient « laquelle de ces options valables devons-nous choisir et comment devons-nous la déployer ? ». Cela concerne notamment :

• les changements d’API ou d’architecture pour lesquels plusieurs conceptions se défendent et les responsables du dépôt doivent trancher explicitement
• les changements de comportement qui touchent aux attentes vis-à-vis du produit, aux engagements de rétrocompatibilité ou aux règles de déploiement
• les décisions de nommage, de migration ou de communication sur une version, lorsque la difficulté est de choisir ce qui sera le plus clair pour les utilisateurs et les contributeurs
• les changements qui exigent un accord entre responsables ou équipes, par exemple pour délimiter le travail, en ordonner les étapes ou décider de ce qui sera livré maintenant ou plus tard

Codex peut apporter une contribution utile dans chacun de ces cas, mais une discussion directe et une personne pour trancher gardent toute leur valeur.

AGENTS.md peut aussi préciser cette répartition : le dépôt peut indiquer à Codex les points importants à examiner pour vérifier que le code fonctionne correctement, et Codex peut appliquer ces consignes de manière cohérente.

Cette pratique a également contribué à augmenter notre débit de développement. Pour les changements à faible risque, les revues et validations répétitives n’attendent plus systématiquement qu’une personne se libère. Les responsables des dépôts peuvent se concentrer sur les revues qui exigent une connaissance approfondie du contexte et où leur jugement compte le plus. Nous corrigeons ainsi beaucoup plus vite les bugs en attente et livrons plus rapidement les petites améliorations fonctionnelles.

Pour conclure

Dans les dépôts du SDK Agents d’OpenAI, les skills donnent les meilleurs résultats lorsqu’ils font partie des pratiques habituelles du projet.

AGENTS.md indique à Codex quels workflows sont obligatoires. Le champ description précise quand les sélectionner. Les opérations déterministes sont regroupées dans scripts/. Le modèle se charge de celles qui dépendent du contexte. Une fois le workflow éprouvé en local, la GitHub Action pour Codex permet de l’exécuter à l’identique en CI.

Nos pratiques de développement au quotidien sont ainsi plus explicites et plus fiables. Nous livrons aussi plus rapidement les petites améliorations, car la vérification, la revue avant publication et la préparation des PR suivent désormais un processus reproductible.

Ressources

• SDK Agents d’OpenAI pour Python
• SDK Agents d’OpenAI pour JavaScript
• Skills dans Codex
• Instructions personnalisées avec AGENTS.md
• GitHub Action pour Codex
• Utiliser Codex dans GitHub
• Guide du Cookbook sur les skills dans l’API OpenAI
• Spécification Agent Skills
• Bonnes pratiques d’utilisation des skills dans l’API OpenAI