Skills pour Claude Code et Codex CLI : le guide complet pour créer des workflows réutilisables

Lorsque l’on utilise Claude Code ou Codex CLI au quotidien, un problème revient très vite : on finit par répéter les mêmes instructions encore et encore. On demande à l’agent d’analyser une API selon une méthode précise, de vérifier toujours les mêmes points avant de modifier le backend, de suivre une procédure particulière pour les audits de sécurité, ou encore d’exécuter une checklist avant une mise en production. Bien sûr, il est possible de conserver ces instructions dans un fichier texte et de les copier dans le prompt à chaque fois, mais ce n’est ni très pratique, ni très élégant.

Les Agent Skills répondent précisément à ce problème. Ils permettent de transformer une méthode de travail en un workflow réutilisable que l’agent peut découvrir, charger et appliquer lorsqu’il en a besoin. L’idée est simple : au lieu de réexpliquer constamment à l’agent comment travailler, on lui fournit une procédure structurée, stockée dans un fichier SKILL.md.

Ce qui rend le système particulièrement intéressant aujourd’hui, c’est qu’il n’est pas réservé à un seul environnement. Claude Code et Codex CLI utilisent tous les deux le concept de Skills, avec un format basé sur SKILL.md et le standard ouvert Agent Skills. Cela signifie qu’une grande partie d’un Skill peut être écrite une seule fois, puis utilisée aussi bien avec Claude Code qu’avec Codex CLI.

L’objectif de ce guide est donc de comprendre comment fonctionne ce système, comment créer un Skill réellement portable, comment l’installer dans les deux environnements, et surtout comment éviter les erreurs classiques lorsque l’on commence à construire une bibliothèque de workflows.

Qu’est-ce qu’un Agent Skill ?

Un Agent Skill est simplement un dossier contenant des instructions spécialisées destinées à un agent IA. Dans sa forme la plus simple, il contient uniquement un fichier SKILL.md, mais il peut également embarquer des scripts, des références ou d’autres ressources lorsque le workflow devient plus complexe.

Une structure classique ressemble à ceci :

my-skill/
├── SKILL.md
├── scripts/
├── references/
└── assets/

Le fichier SKILL.md reste toujours l’élément central. C’est lui qui décrit ce que fait le Skill, dans quelles situations il doit être utilisé et quelles instructions l’agent doit suivre. Les autres dossiers sont facultatifs et servent surtout lorsque le Skill doit exécuter des scripts, consulter une documentation détaillée ou utiliser certaines ressources spécifiques.

Dans la pratique, on peut créer des Skills pour énormément de tâches différentes. Une équipe peut avoir un security-review pour les audits de sécurité, un api-review pour examiner les endpoints, un release-check pour contrôler une application avant sa mise en production, ou encore un database-migration pour formaliser la procédure interne utilisée lors des migrations.

L’intérêt n’est donc pas simplement de “sauvegarder un prompt”. Un Skill permet surtout de capitaliser une méthode de travail et de la rendre réutilisable.

Pourquoi utiliser un Skill plutôt qu’un long prompt ?

La première raison est évidemment de gagner du temps. Si vous répétez régulièrement les mêmes instructions, il devient inutile de les réécrire dans chaque conversation. Mais l’autre avantage, souvent plus important, est la cohérence.

Imaginons qu’un développeur demande un jour “Analyse cette API”, puis le lendemain “Fais une revue complète de cette route” et, une semaine plus tard, “Vérifie si cet endpoint est correctement implémenté”. Les trois demandes sont très proches, mais elles ne décrivent pas forcément les mêmes attentes. Selon la formulation, l’agent peut vérifier certains aspects et en oublier d’autres.

Avec un Skill, la procédure devient constante. On peut par exemple demander systématiquement à l’agent d’identifier la route, les paramètres d’entrée, l’authentification, la gestion des erreurs, les accès à la base de données, les risques de sécurité et la structure de réponse. Le développeur peut ensuite formuler une demande beaucoup plus simple, puisque l’agent connaît déjà la procédure qu’il doit appliquer.

C’est précisément ce qui rend les Skills intéressants dans un contexte professionnel. Ils permettent de transformer les habitudes, les règles internes et les méthodes d’une équipe en workflows que les agents peuvent appliquer de manière beaucoup plus régulière.

Claude Code et Codex CLI utilisent le même principe de base

Claude Code et Codex CLI ne sont évidemment pas identiques, mais le cœur de leur système de Skills repose sur le même principe. Dans les deux cas, un Skill peut être décrit avec un fichier SKILL.md utilisant un frontmatter YAML contenant notamment un nom et une description, suivi des instructions en Markdown.

Voici un exemple minimal :

---
name: api-review
description: Review an API endpoint for correctness, validation, authentication, error handling and security. Use when the user asks to review, audit or explain an API endpoint.
---

# API Review

Inspect the endpoint implementation.

Check:

1. Route and HTTP method
2. Input parameters
3. Request validation
4. Authentication and authorization
5. Database operations
6. Error handling
7. Response format
8. Security risks

Report problems before suggesting changes.

Do not modify the code unless the user explicitly asks for it.

Ce fichier reste volontairement simple. Il n’utilise aucune fonctionnalité propre à Claude Code ou à Codex, ce qui le rend portable entre les deux environnements.

Le standard Agent Skills impose au minimum name et description. Le nom doit être cohérent avec le dossier du Skill, par exemple :

api-review/
└── SKILL.md

avec :

name: api-review

Le nom doit rester simple, généralement en minuscules avec des chiffres ou des tirets. La description, en revanche, demande beaucoup plus d’attention.

La description est probablement la partie la plus importante

Il est facile de considérer la propriété description comme une simple phrase informative, mais elle joue en réalité un rôle essentiel. C’est elle qui permet à l’agent de comprendre quand un Skill doit être utilisé.

Une description comme celle-ci est beaucoup trop vague :

description: Helps with APIs.

Elle n’explique ni ce que le Skill fait réellement, ni dans quelles situations il doit être déclenché. Une version beaucoup plus utile serait :

description: Review REST API endpoints for request validation, authentication, authorization, error handling and security issues. Use when the user asks to audit, review or inspect an API endpoint.

Cette description donne à l’agent deux informations essentielles : ce que le Skill fait et quand il doit l’utiliser. C’est une bonne règle à retenir lorsque vous créez vos propres Skills : la description doit toujours répondre à ces deux questions.

Il peut aussi être utile d’indiquer ce qui ne doit pas déclencher le Skill. Un Skill de sécurité pourrait par exemple préciser qu’il doit être utilisé uniquement lors d’un audit ou d’une revue de sécurité explicite, et non pour une simple demande d’explication de code. Plus les frontières entre les Skills sont claires, plus leur sélection devient fiable.

Construisons un Skill portable pour les deux environnements

Prenons maintenant un exemple plus réaliste avec un Skill api-review. L’objectif est de créer un seul fichier que l’on pourra utiliser aussi bien avec Claude Code qu’avec Codex CLI.

---
name: api-review
description: Review and explain API endpoints. Use when the user asks to audit, review, inspect, document or understand an API route or endpoint. Check validation, authentication, authorization, database operations, error handling, response structure and security.
---

# API Review

Review the API endpoint requested by the user.

## Locate the endpoint

Find the file containing the relevant route or handler.

Identify the HTTP method, route path, handler function and framework.

Do not assume the implementation before reading the relevant code.

## Explain the endpoint

Describe the route, its purpose, inputs, authentication requirements and outputs.

For inputs, include path parameters, query parameters, request body fields and relevant headers.

For outputs, describe the success status code, response structure and important returned fields.

## Review the implementation

Check input validation, authentication, authorization, database access, external API calls, error handling, status codes, response validation, logging and hardcoded configuration.

## Security review

Look for missing authorization checks, injection vulnerabilities, unsafe user input, exposed secrets, sensitive data leakage, insecure direct object references and excessive error information.

Do not invent vulnerabilities. Only report issues supported by the code.

## Report findings

Order findings by severity: Critical, High, Medium, Low and Improvements.

For every issue, provide its location, the problem, its impact and a recommended correction.

If no significant issue is found, say so explicitly.

## Modification policy

Do not modify files automatically.

Explain the findings first and only make changes if the user explicitly asks for them.

Le contenu reste volontairement indépendant du produit utilisé. C’est ce point qui est essentiel si vous souhaitez maintenir une bibliothèque commune de workflows.

Installer le Skill dans Claude Code

Dans Claude Code, un Skill spécifique à un projet est généralement placé sous .claude/skills/.

Notre exemple devient donc :

my-project/
└── .claude/
    └── skills/
        └── api-review/
            └── SKILL.md

Le chemin complet est :

.claude/skills/api-review/SKILL.md

Si vous souhaitez rendre le Skill disponible dans tous vos projets, vous pouvez le placer dans votre répertoire utilisateur :

~/.claude/skills/api-review/SKILL.md

Pour une équipe, il est souvent plus intéressant de conserver les Skills directement dans le repository. Cela permet de les versionner avec Git et de s’assurer que tous les développeurs travaillent avec les mêmes procédures.

L’invocation explicite d’un Skill dans Claude Code peut se faire avec son nom sous forme de commande, par exemple :

/api-review

Il peut également être déclenché automatiquement si la demande de l’utilisateur correspond suffisamment bien à sa description.

Installer le même Skill dans Codex CLI

Avec Codex CLI, la logique est pratiquement identique, mais l’emplacement change. Les Skills d’un projet sont placés sous .agents/skills/.

my-project/
└── .agents/
    └── skills/
        └── api-review/
            └── SKILL.md

Pour un Skill personnel disponible dans tous les projets, on peut utiliser :

$HOME/.agents/skills/api-review/SKILL.md

Codex peut également rechercher les dossiers .agents/skills dans différentes parties d’un repository, ce qui est très pratique dans les monorepos. Vous pouvez ainsi avoir un Skill général à la racine du projet, un Skill spécialisé pour le frontend et un autre uniquement pour le backend.

Par exemple :

project/
├── .agents/
│   └── skills/
│       └── project-review/
│
├── frontend/
│   └── .agents/
│       └── skills/
│           └── frontend-review/
│
└── backend/
    └── .agents/
        └── skills/
            └── api-review/

Dans Codex, l’invocation explicite utilise notamment le préfixe $ :

$api-review review the login endpoint

Il est également possible d’utiliser /skills pour voir ou sélectionner les Skills disponibles. Comme Claude Code, Codex peut aussi choisir automatiquement un Skill lorsqu’une demande correspond à sa description.

Ce qui change réellement entre Claude Code et Codex CLI

Dans la pratique, les différences principales concernent surtout l’emplacement des fichiers et certaines fonctions avancées.

Le cœur du système reste donc très proche. C’est ce qui rend le format particulièrement intéressant pour les équipes qui utilisent plusieurs agents.

Comment les Skills utilisent le contexte

Un point important à comprendre est qu’un Skill n’est pas nécessairement chargé intégralement dans le contexte de l’agent à chaque message. Le système fonctionne selon un principe de chargement progressif.

Au départ, l’agent a surtout besoin de connaître le nom et la description des Skills disponibles. Cela lui permet de comprendre lesquels existent et de choisir celui qui correspond à la demande. Ce n’est qu’une fois le Skill sélectionné que le contenu complet de SKILL.md est réellement chargé. Les fichiers complémentaires présents dans references/, scripts/ ou assets/ peuvent ensuite être consultés lorsque cela devient nécessaire.

Ce fonctionnement est très important, car il évite qu’une bibliothèque de Skills injecte systématiquement toute sa documentation dans chaque requête. Un Skill peut donc être assez riche sans nécessairement consommer tout son contenu à chaque échange.

Cela ne signifie toutefois pas que les Skills sont totalement gratuits.

Pour pouvoir les sélectionner, l’agent doit connaître au minimum leur existence et leur description. Avec cinq ou dix Skills bien définis, ce coût reste généralement négligeable. Avec plusieurs dizaines ou centaines de Skills possédant chacun des descriptions longues, la situation devient différente. L’agent doit traiter davantage de métadonnées, ce qui peut consommer une partie du contexte et rendre la sélection moins précise.

La bonne stratégie consiste donc à garder des descriptions courtes, précises et suffisamment distinctes les unes des autres.

Claude Code et la gestion du coût des Skills

Claude Code charge les informations nécessaires à la découverte des Skills, puis leur contenu complet uniquement lorsqu’ils sont réellement utilisés. Il applique également un budget à la quantité d’informations consacrée aux descriptions afin d’éviter qu’une immense bibliothèque ne monopolise le contexte.

Claude Code propose aussi un outil particulièrement intéressant pour surveiller cet aspect : /skill-doctor.

Cet outil permet d’identifier les Skills présents dans la session, leur utilisation et leur poids dans le contexte. L’idée est simple : si un Skill reste installé pendant des semaines sans jamais être utilisé, il est peut-être préférable de le désactiver, de le rendre uniquement manuel ou tout simplement de le supprimer.

Dans les versions récentes de Claude Code, ces informations sont intégrées aux statistiques du gestionnaire de plugins. C’est une fonction très utile lorsque l’on commence à accumuler de nombreux Skills, car elle permet enfin de distinguer les workflows réellement utilisés de ceux qui restent présents inutilement.

Codex protège lui aussi son contexte

Codex applique sa propre limite aux informations utilisées pour découvrir les Skills. La liste initiale est limitée à environ 2 % de la fenêtre de contexte du modèle, ou 8 000 caractères lorsque cette fenêtre n’est pas connue.

Si la bibliothèque devient trop importante, Codex commence par raccourcir les descriptions. Si cela ne suffit plus, certains Skills peuvent finir par ne plus apparaître dans la liste initiale.

Cette protection est intéressante, mais elle ne remplace pas une bonne organisation. Même si le système limite automatiquement l’impact sur le contexte, une bibliothèque trop importante ou mal structurée reste plus difficile à maintenir et augmente les risques de mauvais déclenchements.

Un gros SKILL.md n’est pas forcément un mauvais Skill

Le fait qu’un SKILL.md soit long n’est pas nécessairement problématique puisque son contenu complet n’est généralement chargé que lorsque le Skill est utilisé. En revanche, cela ne signifie pas qu’il faut tout entasser dans un seul fichier.

Une bonne pratique consiste à garder SKILL.md centré sur le workflow principal et à déplacer les longues documentations dans un dossier references/.

Prenons un Skill PostgreSQL :

postgres-review/
├── SKILL.md
└── references/
    ├── indexing.md
    ├── migrations.md
    └── security.md

Le fichier principal peut simplement indiquer à l’agent de consulter references/indexing.md lorsqu’il analyse les index, references/migrations.md lorsqu’il travaille sur une migration et references/security.md pour les contrôles liés à la sécurité.

L’agent ne charge alors que la documentation dont il a réellement besoin. Cette organisation rend également les Skills beaucoup plus faciles à maintenir.

Utiliser des scripts dans un Skill

Les Skills peuvent également contenir des scripts. Cela devient intéressant lorsqu’une opération doit être déterministe ou reproductible.

Par exemple :

dependency-audit/
├── SKILL.md
└── scripts/
    └── scan.py

Le Skill peut demander à l’agent d’exécuter le script puis d’analyser son résultat. C’est particulièrement utile pour parser des logs, valider des données JSON, extraire un schéma de base de données, vérifier des versions de dépendances ou générer un rapport.

La règle la plus simple est de laisser l’agent effectuer lui-même les opérations qu’il peut raisonnablement gérer avec ses outils, et d’utiliser des scripts lorsqu’une procédure précise ou répétitive gagne à être automatisée.

Un Skill n’est pas un subagent

Il existe parfois une confusion entre Skills et subagents. Les deux concepts répondent pourtant à des besoins différents.

Un Skill fournit principalement une procédure, des connaissances et éventuellement quelques ressources supplémentaires à l’agent principal. Il lui dit en quelque sorte : “voici comment nous effectuons cette tâche”.

Un subagent, en revanche, correspond davantage à une délégation vers un contexte ou un agent distinct. Il sert à isoler une tâche ou à la confier à une entité spécialisée.

Un Skill ne crée donc pas nécessairement un nouvel agent. Il enrichit surtout le comportement de l’agent existant.

Que faut-il réellement transformer en Skill ?

Les meilleurs candidats sont les procédures que vous répétez régulièrement. Une revue de code, un audit de sécurité, une préparation de release, une migration de base de données, une analyse d’interface ou une investigation de bug sont de très bons exemples.

En revanche, toutes les informations d’un projet ne doivent pas devenir des Skills.

Des règles comme “nous utilisons TypeScript”, “le backend se trouve dans /backend” ou “utilise toujours pnpm” sont plutôt des informations permanentes sur le projet. Dans Claude Code, elles trouvent généralement leur place dans CLAUDE.md. Dans Codex, elles peuvent être stockées dans AGENTS.md.

La distinction est assez simple : si l’information doit toujours être connue, elle appartient plutôt aux instructions permanentes du projet. Si elle correspond à une procédure utilisée uniquement pour certaines tâches, elle constitue probablement un bon candidat pour un Skill.

Évitez les mega-Skills

L’une des erreurs les plus fréquentes consiste à créer un énorme Skill appelé par exemple developer, qui contient à la fois les règles frontend, backend, sécurité, base de données, tests, déploiement, documentation et CI/CD.

Sur le papier, cela peut sembler pratique. En réalité, cela rend le Skill difficile à sélectionner, difficile à maintenir et beaucoup moins réutilisable.

Il vaut mieux séparer les responsabilités avec des Skills tels que :

frontend-review
api-review
security-review
database-review
release-check

Chaque Skill possède alors un rôle clairement identifiable.

Il faut également éviter les Skills qui se chevauchent trop fortement. Si vous avez api-review, backend-review, code-review, security-review et quality-review, et que leurs descriptions indiquent toutes qu’ils doivent être utilisés lorsqu’on “review code”, l’agent doit choisir entre plusieurs candidats presque identiques.

Les descriptions doivent donc être suffisamment précises pour que chaque Skill possède un territoire clair.

Les fonctions spécifiques à Claude Code

Même si le cœur du format reste portable, Claude Code ajoute certaines extensions intéressantes.

Il est notamment possible d’empêcher un Skill d’être déclenché automatiquement avec :

disable-model-invocation: true

Cela peut être très utile pour des workflows sensibles comme un déploiement en production, une migration destructive ou une opération qui ne doit jamais être lancée sans décision explicite de l’utilisateur.

Claude Code propose également plusieurs niveaux de visibilité qui permettent de contrôler si un Skill doit être totalement actif, visible uniquement par son nom, utilisable uniquement manuellement ou complètement désactivé.

Ces options sont utiles, mais elles restent spécifiques à Claude Code. Si votre priorité est la portabilité, il vaut mieux conserver toute la logique principale dans le standard commun et utiliser ces extensions uniquement lorsque cela apporte une vraie valeur.

Les fonctions spécifiques à Codex

Codex dispose lui aussi de ses propres extensions.

Il permet par exemple de contrôler l’invocation automatique d’un Skill via agents/openai.yaml :

policy:
  allow_implicit_invocation: false

Le Skill reste disponible, mais Codex ne le déclenche plus automatiquement à partir d’une simple correspondance avec le prompt. L’utilisateur doit alors l’appeler explicitement avec :

$skill-name

Codex peut également utiliser ce fichier pour certaines métadonnées supplémentaires et dépendances.

Comme pour Claude Code, la meilleure stratégie consiste à garder le cœur du workflow portable et à utiliser les extensions du produit uniquement lorsque cela est nécessaire.

Une bibliothèque commune pour plusieurs agents

Pour une entreprise, le scénario le plus intéressant consiste probablement à maintenir une bibliothèque interne de Skills indépendants des agents utilisés.

On peut imaginer une structure comme :

skills/
├── api-review/
├── security-review/
├── frontend-review/
├── database-review/
├── release-check/
└── documentation/

Chaque dossier contient un SKILL.md basé sur le standard commun. Les mêmes Skills peuvent ensuite être exposés dans .claude/skills/ pour Claude Code et .agents/skills/ pour Codex.

Cette approche évite de maintenir deux bibliothèques complètement différentes pour deux agents qui exécutent souvent les mêmes tâches.

À terme, une équipe peut ainsi créer une sorte de “manuel opérationnel exécutable”, dans lequel les procédures de développement, les checklists, les conventions et les méthodes d’audit deviennent directement utilisables par les agents IA.

Tester un Skill avant de lui faire confiance

Créer un Skill est facile. S’assurer qu’il fonctionne correctement demande un peu plus de travail.

Il faut tester deux choses séparément. La première est le déclenchement : le Skill doit être choisi lorsque la demande correspond réellement à son rôle, mais il ne doit pas apparaître pour des tâches sans rapport.

Par exemple :

Audit this endpoint.

devrait logiquement déclencher api-review.

En revanche :

Rename this variable.

ne devrait pas le faire.

La deuxième chose à tester est le résultat lui-même. Un Skill peut parfaitement se déclencher au bon moment tout en fournissant des instructions peu utiles. Il faut donc comparer les réponses obtenues avec et sans Skill, idéalement sur plusieurs demandes réalistes.

Claude Code et Codex proposent aujourd’hui différents outils pour créer et organiser les Skills, mais la qualité finale dépend toujours beaucoup de la qualité des instructions et des tests réalisés.

Attention aux Skills téléchargés sur Internet

Un Skill ne doit pas être considéré comme un simple fichier texte sans danger. Il peut contenir des instructions demandant à l’agent d’exécuter des commandes, de lancer des scripts, d’accéder à certains fichiers ou d’utiliser des ressources externes.

Avant d’installer un Skill trouvé sur GitHub ou dans un repository inconnu, il est donc important de lire son SKILL.md, d’inspecter les scripts associés, de vérifier les commandes qu’il demande d’exécuter et de comprendre les fichiers auxquels il souhaite accéder.

La meilleure attitude consiste à traiter un Skill tiers comme du code que vous ajoutez à votre environnement de développement, pas comme un simple prompt que vous copiez dans une conversation.

À quoi peut ressembler une vraie bibliothèque d’entreprise ?

Une équipe travaillant sur une application SaaS pourrait par exemple organiser ses Skills ainsi :

skills/
├── architecture-review/
│   └── SKILL.md
│
├── api-review/
│   └── SKILL.md
│
├── database-migration/
│   ├── SKILL.md
│   └── references/
│       └── migration-policy.md
│
├── security-review/
│   ├── SKILL.md
│   └── references/
│       ├── auth.md
│       └── secrets.md
│
├── frontend-audit/
│   └── SKILL.md
│
└── release-check/
    ├── SKILL.md
    └── scripts/
        └── validate-release.sh

À ce stade, les Skills ne sont plus de simples raccourcis. Ils deviennent une manière de formaliser le savoir-faire de l’équipe et de le rendre directement exploitable par les agents.

C’est probablement là que leur intérêt devient réellement important.

Skills, prompts et modèles ne sont pas la même chose

Un Skill ne remplace pas le modèle, et il ne remplace pas non plus totalement le prompt de l’utilisateur.

On peut plutôt voir le système comme une chaîne :

Utilisateur
    ↓
Prompt
    ↓
Agent
    ↓
Skill pertinent
    ↓
Modèle IA
    ↓
Outils, terminal et fichiers

Le prompt décrit la demande actuelle. Le Skill apporte une procédure ou une méthode de travail. Le modèle fournit les capacités de raisonnement et de génération, tandis que l’agent orchestre l’accès au terminal, aux fichiers et aux autres outils.

Cette distinction devient particulièrement intéressante lorsqu’un même agent peut utiliser plusieurs modèles différents derrière une même interface.

Quelques règles simples pour garder une bibliothèque saine

Il n’est pas nécessaire d’avoir cinquante Skills pour profiter du système. Cinq bons Skills, bien définis et réellement utilisés, valent généralement mieux qu’une bibliothèque immense remplie de workflows redondants.

Pour commencer, des Skills comme api-review, security-review, frontend-review, bug-investigation et release-check couvrent déjà une grande partie des besoins courants.

Ensuite, observez simplement votre utilisation quotidienne. Chaque fois que vous vous surprenez à écrire quelque chose comme “fais toujours A, puis B, puis C, et vérifie D avant de terminer”, vous avez probablement identifié un excellent candidat pour un nouveau Skill.

À l’inverse, si un Skill reste installé pendant des mois sans jamais être utilisé, il ne sert probablement plus à grand-chose. C’est précisément le type de situation que des outils comme /skill-doctor dans Claude Code permettent aujourd’hui de détecter.

Le véritable intérêt des Skills

Les Skills sont parfois présentés comme une nouvelle manière d’écrire des prompts, mais cette définition est trop limitée.

Leur intérêt réel est de permettre à une équipe de capitaliser ses méthodes de travail. Les procédures de développement, les checklists, les conventions, les processus de validation, les méthodes d’audit et certaines connaissances internes peuvent être transformés en workflows directement utilisables par les agents.

On passe alors progressivement d’un modèle où chaque développeur doit expliquer à l’IA comment il souhaite travailler à un modèle où l’organisation possède déjà une bibliothèque de méthodes que ses agents peuvent appliquer.

Pour les entreprises qui utilisent de plus en plus Claude Code, Codex CLI ou d’autres coding agents, cette évolution est probablement beaucoup plus importante qu’elle n’en a l’air aujourd’hui.

Conclusion

Claude Code et Codex CLI utilisent aujourd’hui le même concept fondamental : des Agent Skills basés sur SKILL.md.

Leurs chemins diffèrent :

Claude Code
.claude/skills/

et :

Codex CLI
.agents/skills/

leurs méthodes d’invocation explicite diffèrent également :

Claude Code
/api-review

contre :

Codex CLI
$api-review

et chaque environnement ajoute quelques fonctionnalités spécifiques.

Mais le point essentiel reste le même : un Skill construit proprement autour du standard commun peut conserver le même SKILL.md, la même logique et une grande partie du même workflow dans les deux environnements.

Pour une équipe qui utilise plusieurs coding agents, c’est probablement la meilleure approche : construire une bibliothèque de workflows indépendante du fournisseur, puis exploiter les fonctions spécifiques de Claude Code ou de Codex uniquement lorsqu’elles apportent une vraie valeur.

Le but n’est pas d’avoir le plus grand nombre de Skills possible. Le but est d’avoir quelques workflows précis, utiles, testés et suffisamment bien conçus pour éviter de devoir réexpliquer sans cesse aux agents comment travailler.

Sources

Agent Skills — spécification du format SKILL.md : https://agentskills.io/specification

Anthropic — documentation Claude Code Skills : https://code.claude.com/docs/en/skills

Anthropic — contexte, Skills, Hooks et Subagents : https://claude.com/blog/steering-claude-code-skills-hooks-rules-subagents-and-more

OpenAI — documentation des Skills dans Codex : https://developers.openai.com/codex/skills

Informations vérifiées en septembre 2026. Claude Code et Codex évoluent rapidement, certaines commandes ou fonctionnalités avancées peuvent donc changer dans de futures versions.