Utiliser les skills pour accélérer la maintenance des logiciels open source

Nous utilisons Codex pour faire évoluer notre façon de maintenir les dépôts OpenAI Agents SDK. Les skills propres aux dépôts, AGENTS.md et GitHub Actions nous permettent de transformer les tâches récurrentes de développement, comme les vérifications, la préparation des versions, les tests d’intégration des exemples et la revue des PRs, en workflows reproductibles. Même avec une configuration assez simple, cette approche nous a permis d’accélérer le développement dans ces dépôts actifs. Entre le 1er décembre 2025 et le 28 février 2026, 457 PRs ont été fusionnées dans les deux dépôts, contre 316 au cours des trois mois précédents, du 1er septembre 2025 au 30 novembre 2025 (Python : 182 -> 226, TypeScript : 134 -> 231).

Pour situer rapidement le contexte, le SDK est disponible en Python et en TypeScript. Il fournit les éléments essentiels pour créer des applications agentiques et permet aussi de créer, avec peu de code, des agents vocaux basés sur la Realtime API, avec plusieurs agents, des outils et des mécanismes d’intervention humaine. Il est utilisé à grande échelle : au 6 mars 2026, sur des périodes récentes de 30 jours, le package Python totalisait environ 14,7 millions de téléchargements sur PyPI, et le package TypeScript environ 1,5 million sur npm.

La configuration est simple :

• 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
• Codex GitHub Action lorsque le même workflow doit s’exécuter en CI

Cette configuration fournit à Codex un contexte stable sur le fonctionnement du dépôt, ce qui améliore la rapidité et la précision des tâches récurrentes de développement.

Conservez les workflows dans le dépôt

Dans ces dépôts, nous utilisons des skills pour formaliser les workflows propres à chaque dépôt. Un skill est un petit ensemble de connaissances pratiques : un manifeste SKILL.md, accompagné éventuellement de scripts/, references/ et assets/. La documentation sur la personnalisation de Codex explique pourquoi cette approche fonctionne bien : les skills conviennent aux workflows reproductibles, car 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.

Cela correspond au principe de présentation progressive des informations utilisé par les skills :

• l’agent voit d’abord les métadonnées comme name et description
• il ne charge SKILL.md que lorsque le skill est sélectionné
• il ne lit les références ou n’exécute les scripts qu’en cas de besoin

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

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

Le dépôt Python constitue la base la plus simple :

• code-change-verification exécute les étapes requises de formatage, de lint, de vérification des types et de tests lorsque le code ou le comportement du build change.
• docs-sync compare la documentation au code source et repère les éléments manquants, incorrects ou obsolètes.
• examples-auto-run exécute les exemples en mode automatique, avec des journaux et des outils de relance.
• final-release-review compare le tag de la version précédente à la version candidate actuelle et vérifie si elle est prête à être publiée.
• implementation-strategy définit les limites de compatibilité à respecter et l’approche d’implémentation avant toute modification du code d’exécution ou des API.
• openai-knowledge récupère la documentation à jour de l’API et de la plateforme OpenAI via le workflow officiel Docs MCP.
• pr-draft-summary prépare une suggestion de nom de branche, un titre de PR et un brouillon de description au moment de passer le relais.
• test-coverage-improver mesure la couverture des tests, repère les principales lacunes et propose des tests à fort impact.

Le dépôt JavaScript suit le même principe général et ajoute quelques skills spécifiques pour son monorepo npm et son processus de publication :

• changeset-validation vérifie que les changesets et les niveaux d’incrémentation de version correspondent bien au diff des packages.
• integration-tests publie les packages dans un registre Verdaccio local et vérifie leur installation et leur exécution dans les environnements d’exécution pris en charge.
• pnpm-upgrade met à jour de façon coordonnée la chaîne d’outils pnpm et les versions figées dans la CI.

Le principe compte davantage que la liste exacte. Chaque skill a un contrat ciblé, un déclencheur clair et un résultat concret.

Certains des skills les plus utiles ne sont pas des contrôles bloquants. docs-sync et test-coverage-improver sont des workflows qui commencent par un rapport : ils examinent le diff actuel ou les artefacts de couverture, établissent les priorités et demandent une approbation avant toute modification. Dans le dépôt Python, docs-sync utilise également les docstrings et les commentaires du code source comme source de vérité pour la documentation de référence générée, plutôt que de corriger manuellement le résultat généré. Le skill pnpm-upgrade, propre au dépôt JavaScript, est un autre bon exemple de workflow de maintenance ciblé : il met à jour ensemble la version locale de pnpm, packageManager et les versions figées dans les workflows, au lieu de recourir à une recherche et un remplacement globaux.

Rendez les workflows obligatoires

Les skills sont plus utiles lorsque les règles du dépôt imposent leur utilisation au bon moment. C’est là qu’intervient AGENTS.md.

Le guide AGENTS.md présente ces fichiers comme 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 les garder courts. Dans les dépôts Agents SDK, nous y plaçons les règles que Codex doit suivre à chaque fois, en mettant les plus importantes près du début.

En pratique, les deux dépôts utilisent de courtes règles « si/alors » pour rendre l’utilisation des skills obligatoire. Avant toute modification du code d’exécution ou des API, appelez $implementation-strategy pour définir d’abord les limites de compatibilité à respecter et l’approche d’implémentation. Si la modification touche le code du SDK, les tests, les exemples ou le comportement du build, appelez $code-change-verification. Si une modification d’un package JavaScript touche les métadonnées de publication, appelez $changeset-validation. Si le travail concerne les intégrations 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 également les recommandations d’agents.md : regroupez la présentation du projet, les commandes de build et de test, le style de code, les consignes de test, les considérations de sécurité et les autres règles propres au dépôt au même endroit. Les dépôts Agents SDK suivent cette structure, en plaçant en premier les conditions de déclenchement les plus importantes au quotidien. En voici une version compacte :

# 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 ensuite cette base avec des détails propres à chacun, comme $changeset-validation dans le dépôt JavaScript, ainsi que des consignes plus détaillées sur l’exécution, la documentation et les publications dans les deux fichiers. Pour consulter des exemples complets, reportez-vous à AGENTS.md dans openai-agents-python et à AGENTS.md dans openai-agents-js.

AGENTS.md ne sert pas uniquement à définir les déclencheurs des skills. Le dépôt Python y consigne également une règle de compatibilité des API publiques : préservez la signification liée à la position des paramètres des constructeurs exportés et des champs des dataclasses, ajoutez si possible les nouveaux éléments facultatifs à la fin, et ajoutez des tests de compatibilité si un changement d’ordre est inévitable. C’est une autre bonne pratique : conservez les règles de compatibilité essentielles à la publication au même endroit que les déclencheurs des skills.

Règles de vérification

$code-change-verification en est un exemple clair.

Dans les deux dépôts, la règle n’est pas « exécutez toujours une longue suite de validations ». Elle est « exécutez-la lorsque le code d’exécution, les tests, les exemples ou le comportement du build ou des tests ont changé, et ne marquez pas le travail comme terminé tant qu’elle n’a pas réussi ».

La condition permet d’alléger les tâches qui ne touchent qu’à la documentation. Le caractère obligatoire garantit que les modifications du code du SDK passent par les étapes de vérification standard du dépôt.

Les suites de vérification sont définies dans les skills eux-mêmes.

Dans le dépôt Python, le skill exige :

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 considère comme « 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 modifications de packages : $changeset-validation, qui s’appuie sur Changesets.

Dès qu’un élément de packages/ change, ou que .changeset/ change, le modèle doit faire plus que simplement exécuter des tests. Il doit créer ou mettre à jour le changeset approprié, valider le niveau d’incrémentation de version et confirmer que le changeset correspond bien au diff.

Ce skill ne se contente pas de vérifier l’existence d’un fichier. Il demande à Codex d’évaluer le diff Git et conserve les règles de validation dans un prompt partagé afin que les exécutions locales et GitHub Actions utilisent la même logique. Il intègre également des règles propres au dépôt, par exemple :

• utilisez le changeset existant de la branche plutôt que d’en créer un autre lorsqu’il y en a déjà un
• limitez le résumé à une ligne au format Conventional Commit afin qu’il puisse aussi servir de titre de commit
• avant la version 1.0, évitez les incrémentations de version majeure pour les ajouts de fonctionnalités courants, et traitez comme des changements de niveau patch les ajouts explicitement signalés comme réservés à la préversion s’ils ne modifient pas le comportement existant
• validez le niveau d’incrémentation de version requis en fonction des modifications réelles des packages

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 lorsque le travail concerne les intégrations avec l’API ou la plateforme OpenAI.

Ce skill ajoute une fine couche d’instructions au OpenAI Docs MCP officiel. Au lieu de laisser le modèle répondre de mémoire, il demande à Codex d’utiliser le serveur MCP de la documentation développeur OpenAI pour consulter la documentation à jour sur des éléments comme l’API Responses, les outils, le streaming, Realtime et MCP.

Si le serveur MCP n’est pas déjà configuré dans l’environnement local de Codex, le skill oriente les responsables de maintenance vers le guide de démarrage rapide Docs MCP et le point de terminaison officiel du serveur MCP.

Préparez la PR pour la revue

À la fin d’un travail substantiel, les deux dépôts utilisent $pr-draft-summary.

Ce skill ne se déclenche que lorsque la tâche est effectivement terminée ou prête pour la revue et que les modifications concernent du code significatif, des tests, des exemples, de la documentation ayant une incidence sur le comportement ou la configuration de compilation et de test. Il récupère alors 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 suggestion de nom de branche
• un titre de PR
• un brouillon de description de 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.

Une fois que vous faites confiance au modèle pour valider et résumer son propre travail, lui demander de rédiger le brouillon de PR est une dernière étape naturelle. Cela permet de présenter le travail de façon cohérente pour la revue et de réduire la rédaction répétitive une fois le code terminé.

Rédigez de meilleures descriptions

Le champ description dans les métadonnées frontmatter du fichier SKILL.md d’un skill fait partie du contrat de routage.

C’est une question de structure, pas de style. La spécification Agent Skills impose les champs name et description dans les métadonnées frontmatter de SKILL.md. Son modèle de divulgation progressive prévoit que ces champs soient chargés au démarrage pour tous les skills. Le corps complet de SKILL.md et les éventuels contenus de scripts/, references/ ou assets/ ne sont chargés que plus tard, lorsque le skill est effectivement activé.

La documentation des skills Codex et la documentation sur la personnalisation décrivent le même comportement côté Codex : Codex commence par les métadonnées de chaque skill pour découvrir les skills disponibles, ne charge SKILL.md que lorsqu’il sélectionne le skill et ne lit les références ou n’exécute les scripts qu’en cas de besoin. Le Cookbook sur les skills dans l’API OpenAI décrit tout aussi explicitement le fonctionnement côté shell distant : OpenAI lit d’abord les champs name et description ainsi que le chemin de chaque skill, puis le modèle utilise ces informations pour décider quand lire l’intégralité de SKILL.md. La section consacrée aux métadonnées frontmatter de SKILL.md le dit plus directement encore : name et description sont importants pour la découverte et le routage.

Dans les dépôts de l’Agents SDK, cela fait de description l’un des principaux signaux de routage avant que Codex ait lu le reste du skill.

Voici un exemple concret tiré de code-change-verification.

Trop vague :

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

Mieux (la description réellement utilisée) :

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 elle ne précise toujours pas quand il s’applique, quels types de modifications doivent le déclencher ni si les vérifications sont facultatives. La version plus précise fournit ces trois informations au modèle.

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

Trop vague :

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

Mieux (la description réellement utilisée) :

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 réellement utilisée sert de métadonnée de routage. Elle indique à Codex :

• que ce skill s’utilise en fin de tâche
• qu’il concerne les modifications substantielles, pas chaque échange de la discussion
• que le résultat est un bloc prêt à être utilisé dans une PR, pas seulement un résumé rédigé

Ces dépôts nous enseignent une leçon pratique : consacrez du temps à description. Si le routage semble peu fiable, corrigez les métadonnées avant d’ajouter du code.

Confiez les opérations mécaniques aux scripts

La question suivante est de savoir ce qui doit rester à la charge du modèle et ce qui doit être confié à un script.

Voici une répartition fiable :

• l’interprétation, la comparaison et la rédaction des rapports restent à la charge du modèle
• les opérations shell déterministes et répétitives vont dans scripts/

Cela correspond aux recommandations publiques. La documentation sur la personnalisation de Codex présente les skills comme un moyen de fournir à Codex des instructions, des scripts et des références plus riches pour des workflows reproductibles, sans alourdir le contexte dès le départ. Cette approche donne la priorité au modèle : laissez Codex gérer les aspects du travail qui dépendent du contexte et faites intervenir les scripts pour les opérations déterministes uniquement lorsque c’est nécessaire. Le Cookbook sur les skills dans l’API OpenAI recommande également de concevoir les scripts des skills comme de petites CLI : ils s’exécutent en ligne de commande, produisent une sortie stdout déterministe, signalent clairement leurs échecs par des messages d’utilisation ou d’erreur et écrivent leurs résultats dans des fichiers aux chemins connus si nécessaire.

Dans les dépôts de l’Agents SDK, nous essayons d’utiliser le modèle là où son intelligence est réellement utile, par exemple pour :

• lire le code source afin d’en déduire le comportement attendu
• comparer les journaux à ce comportement attendu
• déterminer si le diff d’une version présente un réel risque de compatibilité
• produire une explication qui permette à un mainteneur d’agir

Les scripts prennent alors en charge les opérations mécaniques qui entourent ce travail, par exemple :

• l’exécution des commandes de vérification exigées par le dépôt dans un ordre fixe
• le lancement des exemples, la collecte des journaux de chaque exemple et l’écriture de fichiers permettant de relancer les exemples en échec
• la récupération du tag de la version précédente avant la revue visant à déterminer si la prochaine version est prête à être publiée
• la mise à disposition de commandes utilitaires telles que start, stop, status, logs, tail, collect et rerun pour faciliter l’exécution répétée du même workflow

Si le modèle doit retrouver la même suite de commandes shell à chaque fois, c’est généralement le signe qu’elle devrait être regroupée dans un script. Si la tâche dépend du contexte, de compromis à évaluer ou d’explications à formuler, cette partie doit rester à la charge du modèle.

Automatisez les tests d’intégration

Dans les deux dépôts, les tests d’intégration automatisés comptent parmi les usages les plus utiles de ces workflows. Ils comportent deux niveaux liés : la validation automatique des exemples présents dans chacun des deux dépôts et, dans le dépôt JavaScript, la vérification distincte que les paquets publiés fonctionnent toujours lorsqu’ils sont installés comme le font les utilisateurs.

Avant cette mise en place, la validation des exemples était en partie manuelle. Vous pouviez exécuter les exemples, mais la dernière étape consistait souvent à examiner les journaux ou à vérifier visuellement si la sortie semblait correcte. C’est gérable pour un exemple, mais cette méthode passe mal à l’échelle quand le dépôt du SDK s’agrandit.

Le premier niveau est examples-auto-run, mais le skill est venu après l’outil d’exécution. Pour pouvoir automatiser la validation des exemples, nous avons d’abord dû rendre possible leur exécution non interactive dans les deux dépôts. Il fallait donc permettre l’exécution des scripts d’exemple en mode automatique, y compris ceux qui comportent normalement des invites interactives ou des demandes d’approbation.

Ce travail préparatoire comprenait :

• la réponse automatique aux invites interactives courantes
• l’approbation automatique des actions HITL, MCP, apply_patch et shell lorsque l’outil d’exécution les prend en charge
• le maintien d’une liste d’exemples à ignorer automatiquement parce qu’ils ne se prêtent pas encore à l’automatisation, comme les exemples en temps réel ou d’applications Next.js qui nécessitent une configuration supplémentaire de l’environnement d’exécution
• l’écriture de journaux structurés pour chaque exécution d’exemple
• la génération de fichiers de relance pour réessayer les exemples en échec sans tout réexécuter

Une fois cette base en place, nous l’avons organisée sous forme de skill pour rendre le workflow réutilisable et facile à invoquer. Dans le dépôt Python, examples-auto-run encapsule uv run examples/run_examples.py --auto-mode --write-rerun --main-log ... --logs-dir .... Dans le dépôt JavaScript, il encapsule les vérifications de compilation, puis exécute pnpm examples:start-all en mode automatique, avec des journaux propres à chaque exemple et la prise en charge des relances.

Pour améliorer la qualité de la validation, l’outil d’exécution se charge d’exécuter les exemples et de conserver leurs sorties stdout et stderr dans des journaux propres à chacun. Le skill demande ensuite à Codex de parcourir ces journaux un par un et de les comparer au code source :

• Lisez le code source et les commentaires de l’exemple
• Déduisez-en le déroulement attendu
• Ouvrez le journal correspondant
• Comparez le comportement attendu aux sorties stdout et stderr réelles
• Faites-le pour chaque exemple exécuté avec succès, pas seulement pour un seul exemple

Cette approche est plus précise et plus souple que de tenter de définir ce qui est correct au moyen d’une assertion fixe dans un script. Un code de sortie indiquant une réussite est utile, mais il ne suffit pas pour les exemples qui communiquent avec de vraies API, utilisent des outils ou produisent une sortie structurée. En enregistrant d’abord la sortie réelle, puis en la comparant soigneusement au code source, nous pouvons valider chaque exemple selon son objectif réel.

Dans le dépôt JavaScript, un deuxième niveau vient s’ajouter : le skill distinct integration-tests. Ce workflow va au-delà de l’exécution des exemples directement depuis leur code source dans le dépôt. Il publie les paquets dans un registre Verdaccio local et teste leur installation et leur exécution dans plusieurs environnements, notamment Node.js, Bun, Deno, Cloudflare Workers et une application Vite React. Cela permet de détecter une autre catégorie de problèmes : la question n’est plus « l’exemple s’exécute-t-il dans le dépôt ? », mais « le paquet se comporte-t-il toujours correctement après publication, installation et intégration dans l’environnement d’exécution ? »

Ensemble, ces workflows montrent l’intérêt de combiner les skills, les scripts et le jugement du modèle. Les scripts rendent les exécutions reproductibles, recueillent les éléments de vérification et couvrent des parcours d’installation fastidieux à vérifier manuellement. Codex s’appuie ensuite sur ces éléments pour effectuer une comparaison plus approfondie qu’un simple contrôle scripté de réussite ou d’échec.

Ajoutez des vérifications avant publication

La préparation des versions est un autre domaine où cette approche est utile.

Dans les deux dépôts, le workflow de révision avant publication commence par rechercher le tag de la version précédente et le comparer au dernier état de main, puis demande à Codex d’examiner ce diff pour repérer :

• les problèmes de rétrocompatibilité dans les API publiques et le comportement du SDK côté utilisateur
• les régressions, y compris les changements mineurs du 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 globalement si la version est prête à être publiée.

La PR openai/openai-agents-python#2480 en est un exemple concret : la révision donne un feu vert global à la publication, tout en signalant l’abandon de la prise en charge de Python 3.9 et la mise à jour des notes de version qu’il nécessite :

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 définit aussi les critères qui autorisent ou bloquent la publication. La révision part du principe que la version peut être publiée sans risque et ne bloque la publication que si le diff apporte des preuves concrètes d’un problème réel. Toute décision de blocage doit s’accompagner d’une liste précise des actions nécessaires pour le lever. Le résultat est ainsi beaucoup plus facile à exploiter : un feu vert signifie qu’aucun problème bloquant pour la publication n’a été détecté dans le diff ; un blocage signifie qu’un problème réel existe et que la prochaine étape est clairement définie.

C’est plus utile qu’une demande générique comme « Veuillez examiner la version avant publication ». Le modèle doit ainsi raisonner à partir d’un diff concret et expliquer le résultat en termes opérationnels. Si la version peut être publiée sans risque, dites-le. Sinon, indiquez précisément les éléments qui le prouvent et les actions nécessaires.

Exécutez les workflows en CI

Lorsqu’un skill est utile en local, Codex GitHub Action permet d’automatiser facilement le même workflow en CI. Cette approche fonctionne mieux lorsque le workflow local est déjà stable, car c’est en l’utilisant manuellement que vous corrigez les instructions, affinez les scripts et découvrez les véritables cas limites.

Pour les dépôts publics, la conception des déclencheurs compte autant que le skill. La liste de contrôle de sécurité de GitHub Action recommande de limiter les personnes autorisées à lancer le workflow, de privilégier les événements de confiance ou les approbations explicites, de filtrer les entrées de prompt provenant de PRs, 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 à la dernière étape du job.

Si un workflow dispose de droits d’écriture et accepte des entrées publiques non fiables, le risque se situe généralement dans la conception des déclencheurs, le traitement des entrées et les privilèges de l’environnement d’exécution du skill.

Utilisez Codex pour la revue des PRs

Les skills contribuent aux gains de productivité dans ces dépôts. La révision automatique des PRs GitHub par Codex y contribue également.

Depuis que la révision automatique des PRs GitHub par Codex est disponible, Codex nous aide à examiner la plupart des changements de code dans ces dépôts. Nous l’utilisons régulièrement dans notre processus de revue, et non comme un outil réservé à des cas particuliers.

Pour les bugs simples, les régressions et les tests manquants, confier à Codex la revue obligatoire est désormais suffisamment fiable en pratique. Il applique avec constance les mêmes vérifications de correction du code, même de façon répétée, et a supprimé un important goulot d’étranglement pour les petits correctifs et les améliorations courantes.

La revue par les pairs reste importante, mais pour une autre catégorie de changements.

La revue humaine reste essentielle lorsque la question principale n’est pas « Ce code est-il correct ? », mais « Parmi plusieurs options valables, laquelle choisir et comment la livrer ? ». Cela comprend :

• les changements d’API ou d’architecture pour lesquels plusieurs conceptions sont raisonnables et les responsables du projet doivent faire un choix explicite
• les changements de comportement qui touchent aux attentes concernant le produit, aux engagements de rétrocompatibilité ou à la politique de déploiement
• les décisions de nommage, de migration et de communication sur les versions, où la difficulté consiste à choisir ce qui sera le plus clair pour les utilisateurs et les contributeurs
• les changements qui nécessitent un accord entre les responsables du projet ou les équipes, par exemple pour définir le périmètre du travail, en ordonner les étapes ou décider de ce qui doit être livré maintenant ou plus tard

Codex peut apporter une contribution utile dans tous ces cas, mais l’intervention d’une personne pour décider et une discussion directe restent bénéfiques.

AGENTS.md peut aussi formaliser cette répartition : le dépôt peut indiquer à Codex les points importants pour vérifier la correction du code, et Codex peut appliquer ces consignes de manière cohérente.

Cela a aussi contribué de manière significative à augmenter le débit de livraison. Pour chaque changement à faible risque, les tâches répétitives de revue et de validation n’attendent plus qu’une personne déjà très sollicitée trouve le temps de s’en charger. Les responsables du projet peuvent ainsi se concentrer sur les revues qui exigent davantage de contexte et où leur jugement compte le plus. Cette évolution nous a permis de traiter beaucoup plus vite les bugs en attente et les petites améliorations fonctionnelles.

Pour conclure

Dans les dépôts OpenAI Agents SDK, les skills sont plus efficaces lorsqu’ils font partie des pratiques de travail habituelles du dépôt.

AGENTS.md indique à Codex les workflows obligatoires. description lui indique quand les utiliser. scripts/ prend en charge les parties déterministes. Le modèle s’occupe de celles qui dépendent du contexte. Et une fois qu’un workflow est fiable en local, Codex GitHub Action peut transposer le même processus en CI.

Cette organisation a rendu le travail d’ingénierie quotidien dans ces dépôts plus explicite et plus fiable. Elle permet aussi de livrer plus facilement et plus vite de petites améliorations, car la vérification, la révision avant publication et la préparation des PRs suivent désormais le même processus reproductible.

Ressources

• OpenAI Agents SDK pour Python
• OpenAI Agents SDK pour JS
• Skills dans Codex
• Instructions personnalisées avec AGENTS.md
• Codex GitHub Action
• Utilisez Codex dans GitHub
• Skills dans le Cookbook de l’API OpenAI
• Spécification Agent Skills
• Skills dans l’API OpenAI : bonnes pratiques opérationnelles