Dans Codex, une compétence n'est pas une /commande (et dans Claude Code presque oui)

** TL;DR ** : Si vous utilisez Codex, utilisez une commande pour contrôler la session ou l’application, et utilisez une compétence pour enseigner à l’agent une manière de travailler. Dans Claude Code, la documentation actuelle traite déjà les compétences comme quelque chose qui peut être invoqué avec /nom-compétence, rendant les deux idées beaucoup plus entrelacées. Ce n’est pas le cas dans Codex : types peut exister sous forme de compétence et /types peut ne pas exister.

Il y a une confusion très courante lorsque vous passez de Claude Code à Codex. Et c’est tout à fait normal.

Vous créez une compétence appelée types, retournez au terminal, entrez /types avec toute votre bonne foi… et Codex vous regarde comme si vous veniez de demander une bière dans un magasin de bricolage.

Le problème n’est pas que la compétence est cassée. Le problème est qu’en Codex une compétence et une commande ne sont pas la même chose.

Et attention, cette distinction n’est pas simplement une question de terminologie. Elle impacte la façon dont vous concevez votre flux de travail.

Une analogie pour tout clarifier

Imaginez Codex comme un avion doté de deux couches.

La première couche est le cockpit : boutons, leviers, indicateurs. C’est là que résident les commandes. Elles sont utilisées pour modifier l’état de la session, du client, ou de l’outil. Elles relèvent du contrôle opérationnel.

La deuxième couche est le manuel du copilote : procédures, critères, checklists, pièges à éviter. C’est là que résident les compétences. Elles servent à modifier comment l’agent raisonne lorsqu’il exécute une tâche.

Traduit pour les humains :

• Une commande agit sur le cockpit.
• Une compétence agit sur la tête du copilote.

Si vous essayez d’utiliser le manuel comme s’il s’agissait d’un bouton, ça ne marche pas.

Qu’est-ce qu’une commande dans Codex

Dans Codex, il existe deux types de commandes qu’il vaut mieux ne pas confondre.

Le premier type correspond aux commandes CLI :

codex login
codex exec "run tests and fix failures"
codex resume --last
codex apply

Ici, rien de mystérieux : ce sont des actions de l’application. Authentification, lancement d’une tâche, reprise d’une session, application d’un diff. Si le modèle disparaît demain, ces commandes continueront d’avoir du sens.

Le deuxième type correspond aux slash commandes dans la session interactive :

/model
/permissions
/personality
/agent
/status

Ce ne sont pas non plus de « jolis prompts ». Ce sont des outils qui permettent de contrôler la session active. Ils modifient le modèle, les permissions, la personnalité, le fil actif ou l’état visible : ce sont des boutons du tableau de bord.

OpenAI, en fait, le décrit très clairement : d’un côté, ils ont une page dédiée aux slash commandes pour “gérer Codex pendant les sessions interactives”, et de l’autre, une page distincte pour les compétences, qui définit les skills comme le format d’autorisation pour les workflows réutilisables.

Ainsi, elles existent comme commandes et non comme compétences parce qu’elles nécessitent un comportement prévisible, immédiat et une sémantique stable. Vous ne voulez pas que le modèle « interprète créativement » la signification de /permissions. Vous voulez qu’il modifie les permissions. Point final.

Qu’est-ce qu’une compétence dans Codex

Une compétence dans Codex est tout autre chose. C’est un flux réutilisable qui apprend à l’agent quand appliquer une approche, comment penser une tâche et quelles étapes suivre.

Et voici une autre nuance, subtile mais essentielle : OpenAI affirme que la compétence est le format d’autorisation, tandis que le plugin constitue l’unité installable ou distribuable. En d’autres termes, vous concevez d’abord le flux de travail en tant qu’compétence ; si ensuite, vous souhaitez le partager ou le packager mieux, vous l’enveloppez.

Exemples clairs :

$types
$improve
$owasp
$blog

Ou, si vous préférez en langage naturel :

utilise types pour auditer ce dépôt
utilise improve pour examiner ce diff

Là, vous ne dites pas à Codex “modifie un réglage”. Vous dites “quand vous effectuez cette tâche, suivez ce guide”.

Mon types, par exemple, ne devrait pas être un bouton. Il doit lire le projet, détecter le langage, inspecter les modèles, rechercher un code mal typé, déterminer si un Optional est bien utilisé ou s’il représente un état de domaine. Cela exige du contexte et du discernement. C’est exactement le type de travail qu’une compétence accomplit bien.

De même, improve a du sens en tant que compétence : ce n’est pas une action déterministe. C’est une méthode spécifique pour effectuer une code review.

Pourquoi, dans Claude Code, cela semble « identique »

Voici où se trouve le piège mental.

La documentation actuelle de Claude Code n’est plus aussi réservée à ce sujet. Elle parle de compétences et vous explique que vous pouvez les invoquer directement avec :

/nom-compétence

Autrement dit, dans Claude Code, une partie importante de ce que vous percevez comme un « workflow réutilisable » est accessible via une syntaxe de slash commande. L’expérience utilisateur lie deux concepts qui, dans Codex, sont séparés :

• réutiliser un flux
• l’invoquer via /quelque-chose

De plus, Claude Code conserve ses commandes intégrées séparées :

/help
/compact

Et, en plus, maintient une autre pièce distincte : les agents secondaires, qui sont des assistants spécialisés avec leur propre contexte, leurs permissions et leur system prompt.

En somme :

• Dans Claude Code, les compétences, les agents secondaires et les commandes cohabitent, mais les compétences peuvent être invoquées avec /.
• Dans Codex, les flux réutilisables existent sous forme de compétences, et les /commandes restent un moyen explicite de contrôle de session.

Ainsi, si vous venez de Claude, votre cerveau apprend très rapidement une équivalence pratique : « Si quelque chose est réutilisable, je vais probablement le lancer avec /quelque-chose ». Dans Codex, ce raccourci mental ne fonctionne plus.

Exemples concrets : qu’est-ce qui devrait être une compétence ou une commande

Choses qui, dans Codex, devraient être des compétences

types

Parce que vous ne voulez pas « exécuter une action ». Vous souhaitez appliquer un principe de design adapté au code.

improve

Parce qu’examiner un diff n’est pas une opération mécanique. Cela implique des jugements, du contexte et des priorités.

blog

Parce qu’écrire un article avec un ton, une structure et des vérifications logiques requiert un flux de raisonnement, pas un bouton.

owasp

Parce qu’un audit de sécurité nécessite d’adapter les heuristiques au framework, au dépôt et aux risques spécifiques.

Choses qui, dans Codex, devraient être des commandes

codex login

Là, rien à réfléchir. Vous vous authentifiez ou non.

/model

Changer de modèle est une opération au niveau client. Ce n’est pas un critère de travail.

/permissions

Modifier les permissions en cours de session relève du contrôle opératif pur.

codex resume --last

Reprendre une session n’est pas un flux cognitif. C’est une action d’application.

Cas les plus déroutants : les hybrides

Il existe une catégorie intermédiaire qui peut troubler vos réflexes au début : les flux que vous aimeriez invoquer avec une syntaxe confortable, mais dont la logique reste celle d’une compétence.

Par exemple :

• vous aimeriez écrire /types
• cependant types reste conceptuellement une compétence

La solution élégante ici n’est pas de « transformer la compétence en autre chose ». La solution consiste à l’envelopper.

C’est-à-dire :

1. Vous conservez l’intelligence dans la compétence.
2. Vous créez un plugin ou une commande qui l’invoque avec l’ergonomie d’une /slash-commande.

Ainsi, vous obtenez le meilleur des deux mondes : l’expérience utilisateur d’une commande et l’intelligence d’une compétence.

La règle d’or pour Codex

Si vous hésitez entre une compétence et une commande, appliquez ce test :

Souhaitez-vous modifier l’état de la session ou de l’application ?

Dans ce cas, vous avez besoin d’une commande.

Souhaitez-vous modifier la manière dont l’agent aborde une tâche ?

Dans ce cas, vous avez besoin d’une compétence.

Voici un tableau utile pour récapituler :

Alors, que devriez-vous utiliser ?

La réponse courte : dans Codex, vous devriez utiliser des compétences pour la connaissance réutilisable et des commandes pour le contrôle opérationnel.

Si vous venez de Claude Code, votre premier réflexe sera de convertir n’importe quel workflow réutilisable en /quelque-chose. C’est tout à fait compréhensible, car Claude vous encourage à penser ainsi. Mais dans Codex, ce réflexe mène rapidement dans une impasse.

Concevez d’abord la compétence. Si vous avez besoin ensuite d’une syntaxe plus ergonomique, enveloppez-la dans un plugin ou une commande. Pas l’inverse.

Parce que si vous commencez par le bouton avant d’avoir défini le processus, vous finirez avec une interface jolie, mais peu utile. Et de ça, le secteur regorge déjà.

Gardez cette phrase en mémoire, et je vous laisse : dans Claude Code, une compétence peut passer par la porte des /slash-commandes. Dans Codex, non. Et c’est presque mieux ainsi.

Une fois que vous comprenez la différence, vous arrêtez de vous battre avec /types et commencez à construire des flux vraiment adaptés à l’outil. Ce n’est pas rien.