Guide Agent Skills 2026 : installer, choisir les skills Claude Code et Codex

En septembre 2026, Claude Code, Codex, Cursor et une série d’agents de coding open source partagent un même format ouvert : un répertoire plus un SKILL.md. Un skill n’est pas un énième marketplace de plugins. C’est une procédure qui se charge à la demande. Beaucoup d’équipes collent encore les checklists de release, les étapes de revue et les formules de rollback dans CLAUDE.md ou AGENTS.md, ou installent d’un clic des dizaines de packs communautaires depuis GitHub. La question d’achat n’est pas combien de skills vous possédez. C’est de savoir si cette procédure doit entrer dans le contexte à chaque tour, si la description se déclenchera toute seule sur la mauvaise tâche, et si les scripts/ du dossier tourneront avec les mêmes droits que vous. Cet article ne récite pas le standard ouvert en entier. Il répond à l’install et à la shortlist : quels skills Claude Code et Codex doivent porter, comment les installer, et comment les accepter.

Pourquoi fourrer des procédures dans le prompt global est déjà la mauvaise décision de 2026

L’ancien chemin et le nouveau se heurtent de façon concrète. L’ancien chemin est prompt-first : un manuel de plus en plus long à la racine du dépôt, injecté en entier à chaque session. Le nouveau chemin est skill-first : les faits stables restent dans CLAUDE.md ou AGENTS.md ; le travail répétitif à plusieurs étapes devient un SKILL.md. L’agent commence par le nom et la description, et charge le corps seulement quand il utilise le skill. La même demande — « sors cette release » — vous facture le manuel à chaque tour sur l’ancien chemin, et seulement sur la tâche de release sur le nouveau. Ignorer cette coupure, c’est continuer à payer du texte que personne ne lira dans cette session.

Trois choses en ont fait un problème de planning plutôt qu’un hobby. D’abord, Claude Code a fusionné les commandes slash personnalisées dans les skills. Un fichier en .claude/commands/deploy.md et un skill en .claude/skills/deploy/SKILL.md deviennent tous deux /deploy. Les anciens fichiers de commande continuent de marcher. Les nouvelles capacités — fichiers d’accompagnement, auto-invocation, sous-agents — vivent sur le répertoire du skill. Ensuite, Codex scanne .agents/skills depuis le répertoire de travail jusqu’à la racine du dépôt. Les skills personnels vivent sous ~/.agents/skills. L’ancien chemin ~/.codex/skills est encore scanné, donc un skill « installé » dans le mauvais arbre ressemble à un skill manquant. Enfin, le CLI npx skills de Vercel peut écrire le même pack dans Claude Code, Codex, Cursor et des dizaines d’autres agents. La portabilité tient seulement si vous n’avez pas rédigé le skill contre le frontmatter privé d’un seul fournisseur. Une équipe qui n’écrit pas ces trois points rediscutera la semaine suivante pourquoi « ça marche sur ma machine ».

Une couche est facile à sauter. Les skills ne sont pas MCP, et ce n’est pas du Function Calling. Les protocoles d’outils décident comment un modèle appelle une interface vivante. Un skill décide quand une procédure humaine est chargée. Comment former la boucle d’outils est dans Qu’est-ce que Function Calling. L’état dynamique entre sessions n’appartient pas au corps d’un skill ; c’est un problème de couche mémoire, traité dans Mémoire agent auto-hébergée vs SaaS. Quel harnais vous enroulez autour du modèle est une question d’achat séparée dans Pi vs Claude Code vs Codex. Mélanger ces couches, c’est acheter trois fois la même chose et ne réparer aucun des trois problèmes.

Comment classer les Agent Skills

Aligner les noms de skills comme des pairs garantit une liste de favoris gonflée. Classez-les selon qui les maintient, quand ils se chargent, et s’ils ont des effets de bord. Laissez tomber une classe, il ne reste que la réputation. La classe en dit plus sur la facture, le risque et le retravail qu’aucun screenshot de store.

Les skills bundlés de Claude Code sont de l’orchestration de prompts, pas des binaires figés : /code-review, /debug, /run, /verify, /run-skill-generator, /doctor. Depuis la v2.1.145, les trois derniers peuvent inférer un lancement depuis le README ou package.json. Sur un projet qui a besoin d’une base, d’un fichier d’env ou d’un build en plusieurs étapes, lancez /run-skill-generator une fois et commitez les commandes d’install, les variables d’env et le script de lancement comme skill dans le dépôt, pour que les sessions suivantes cessent de redécouvrir la recette. Codex fournit en bundle des guides comme skill-installer, skill-creator, review-agent et openai-docs. Les deux côtés utilisent la divulgation progressive : nom et description d’abord, corps à l’usage. Le champ description n’est pas une décoration. Trop court, le skill ne part jamais. Trop large, il part sur chaque corvée. Écrire la description comme une phrase marketing, c’est acheter des faux déclenchements pour longtemps.

Comparaison centrale : entrée, exécution, contexte, public

La vraie différence est l’entrée, pas quel laboratoire a publié le plus gros catalogue. Utilisez un seul jeu de colonnes, sinon vous ne pouvez pas décider. Les cinq mêmes en-têtes gardent la comparaison honnête et empêchent le tableau de devenir une liste publicitaire.

Un second tableau ne couvre que les pièges « je croyais que c’était installé ». Les en-têtes restent les mêmes pour que la prose ne bascule pas en adjectifs vides. Lisez les lignes comme de la comptabilité, pas comme un jugement de goût.

# Claude Code — project skill (this repo only)
mkdir -p .claude/skills/review-change

# Codex — project skill (open .agents/ convention)
mkdir -p .agents/skills/review-change

# Personal skill, every repo on this machine
mkdir -p ~/.claude/skills/review-change
mkdir -p ~/.agents/skills/review-change

# Cross-agent package manager (Vercel skills CLI)
npx skills add vercel-labs/agent-skills --skill react-best-practices -a claude-code
npx skills add vercel-labs/agent-skills --skill react-best-practices -a codex

# Codex bundled installer (often writes ~/.codex/skills)
# Inside a Codex session:
# $skill-installer linear

Un SKILL.md minimal n’a besoin que des champs ouverts name et description. Le fichier ci-dessous suffit pour tester le déclenchement et le chargement du corps. N’ajoutez scripts/ que lorsque cette boucle est devenue ennuyeuse. Committer des scripts avant le test de déclenchement, c’est mesurer d’abord le dégât, pas le bénéfice.

---
name: review-change
description: Reviews an uncommitted diff and lists risks. Use when the user asks what changed, wants a commit message, or asks to review the working tree. Do not use for greenfield feature design.
---

## Current changes

Run git diff HEAD and summarize in three bullets.
Flag missing tests, hardcoded secrets, and edits outside the named module.
If the diff is empty, say so and stop.

Quels skills Claude Code et Codex doivent vraiment porter

Un stack recommandé n’est pas un top dix de boutique fournisseur. C’est une échelle d’effets de bord. Gardez les skills bundlés. Gardez seulement les flux projet que vous répétez chaque semaine. Gardez les règles transversales seulement après qu’une personne a lu le corps. Le volume sans audit n’est pas une avance, c’est une liste de déclencheurs plus longue.

Un développeur solo devrait poser un skill review-change et un skill release avant de décider qu’il a besoin de règles React. Une petite équipe produit devrait encoder « les checks qui doivent tourner avant une PR » comme skill projet, et laisser le goût personnel dans un CLAUDE.md utilisateur. Les chemins clients n’appartiennent pas à un skill de niveau utilisateur. Une entreprise devrait traiter les skills comme du code : passer SKILL.md et scripts/ en pull request, et refuser les membres qui symlinkent des packs non audités dans ~/.agents/skills. Traiter cela comme de l’overhead, c’est découvrir l’overhead après le premier écriture non auditée.

Comment choisir selon la scène

La scène décide avant la marque. Écrivez d’abord quel flux se répète chaque semaine, quel CLI est déjà payé, et quels droits un skill peut avoir sans demander. Ensuite seulement, choisissez la classe. Le tableau suivant est une règle de routage, pas un classement.

Combinaisons recommandées

A — Développeur solo, un CLI principal : laissez les skills bundlés allumés. Commitez seulement deux skills projet : revoir le diff non commité, et sortir la version avec le script existant. Écrivez quand utiliser et quand ne pas utiliser dans la description. Mettez les écritures de fichiers et bash dans un conteneur ou sur un Mac distant qui isole l’espace par session. Posez la dépense API et la location de nœud sur la même feuille ; le coût mensuel du nœud est sur Mac mini tarifs. Séparer tokens et loyer, c’est presque toujours sous-estimer le mois.

B — Petite équipe produit, Claude Code et Codex ensemble : installez des packs de règles comme react-best-practices ou web-design-guidelines par agent avec npx skills. Ne déversez pas tout le catalogue. Gardez release et rollback dans l’arbre projet et revoyez-les dans la PR. Laissez le phrasé personnel dans un prompt utilisateur, pas dans un skill. Acceptez les deux CLI contre la même tâche de release échantillon. N’assumez pas qu’un skill qui part dans un harnais part dans l’autre. Une équipe qui mesure les deux chemins une fois se dispute moins sur « chez moi ça marche ».

C — Entreprise ou haute sécurité : traitez les skills comme du code. Répertoire, scripts et description passent en pull request. Interdisez les packs non audités dans les dossiers utilisateur. Les scripts qui ouvrent le réseau ou touchent des secrets ne tournent que sur un nœud jetable. Les frontières de compte et de livraison sont dans le centre d’aide. Quand vous avez besoin d’un espace isolé, partez de la location Mac mini plutôt que d’utiliser le portable du bureau comme labo. L’audit veut des nœuds reproductibles, pas un agent qui a les mêmes droits que Slack et le navigateur.

Pièges fréquents

1. Faire ses courses par favoris : « plus de skills, agent plus malin. » Chaque description large est un budget de faux déclenchement. Une liste de favoris n’est pas un critère de shortlist.
2. Laisser les procédures dans le prompt global : une checklist de release qui se charge à chaque session est un manuel que vous payez à chaque tour. Le texte n’est pas gratuit parce qu’il est déjà dans le dépôt.
3. Croire que les chemins sont universels : .claude/skills de Claude Code n’est pas la racine par défaut de Codex. L’installeur Codex peut encore écrire dans ~/.codex/skills. Une invocation manquante est souvent un mauvais arbre, pas une fonction absente.
4. Installer au niveau utilisateur avant d’avoir lu les scripts : scripts/ héritent de l’utilisateur qui lance. Dossier projet d’abord, nœud isolé d’abord. Un pack non lu sous ~/.claude/skills fuit vers chaque dépôt de la machine.
5. Remplacer les tests par un skill communautaire : /verify et votre CI ne sont pas des substituts. Un skill ne remplace pas une suite rouge-vert. Traiter le skill comme un test, c’est mesurer de la prose, pas un comportement.

Plan d’action : 7 étapes

1. Ouvrez CLAUDE.md ou AGENTS.md. Marquez toute procédure plus longue qu’un paragraphe comme candidat : release, revue, rollback, changelog. Gardez les faits. Déplacez les étapes. Ce qui tient en un paragraphe reste souvent un fait, pas un skill.
2. Écrivez un SKILL.md sans scripts/. Mettez quand utiliser et quand ne pas utiliser dans la description. Invoquez-le une fois avec /review-change ou $review-change. Sans cette preuve manuelle, l’auto-déclenchement n’est qu’un espoir.
3. Demandez en langue ordinaire et voyez s’il se déclenche tout seul. S’il part sur la mauvaise tâche, réécrivez la description. N’installez pas un second skill pour recouvrir le premier. Une deuxième description large double le budget de faux déclenchements.
4. Placez les skills Claude Code dans .claude/skills/ et les skills Codex dans .agents/skills/. Si Cursor ou un autre agent doit voir le même pack, utilisez npx skills add … -a au lieu de copier le mauvais dossier à la main. Un arbre inversé ressemble à un skill mort-né.
5. Arrêtez-vous aux skills bundlés plus deux à quatre skills projet. Un pack communautaire entre dans l’arbre projet seulement après qu’une personne a lu le SKILL.md et les scripts. Il n’entre pas d’abord dans ~/.claude/skills ou ~/.agents/skills. Le dossier utilisateur est l’exception, pas le défaut.
6. Exécutez les skills qui livrent des scripts/ dans un conteneur ou sur un Mac distant. Gardez les secrets hors du prompt et hors du corps du skill. L’espace de travail doit pouvoir être essuyé en fin de session. L’isolation fait partie de l’acceptation, pas d’un après-coup après la fuite.
7. Acceptez contre une tâche de release ou de revue : s’est-il déclenché, quels fichiers a-t-il touchés, et les tests CI d’origine sont-ils verts. Un cache local tiède qui « a l’air vert » n’est pas une acceptation. La reproductibilité bat une démo verte une seule fois.

FAQ

Quelle différence entre Skills et CLAUDE.md / AGENTS.md ?

Les faits stables vont dans CLAUDE.md ou AGENTS.md et se chargent à chaque session. Les procédures répétables à plusieurs étapes vont dans Skills et se chargent seulement à l’usage. Mettre une checklist de release dans le prompt global, c’est payer le manuel à chaque tour. La différence est le moment de chargement, pas l’extension de fichier.

Claude Code et Codex peuvent-ils partager le même skill ?

Ils partagent le format ouvert SKILL.md. Ils ne partagent pas les chemins ni l’invocation. Claude Code lit .claude/skills/ et ~/.claude/skills/. Codex lit .agents/skills/ et ~/.agents/skills/, et scanne encore l’ancien chemin ~/.codex/skills. Ciblez un agent avec npx skills -a. Qui ne vérifie qu’un côté déclare souvent mort un skill déjà installé.

Faut-il installer d’un clic tous les skills GitHub populaires ?

Non. Une description trop large se déclenche sur les mauvaises tâches. scripts/ tourne avec les mêmes droits que vous. Lisez le SKILL.md et les scripts, puis installez dans le dossier projet — pas dans le dossier utilisateur qui fuit vers tous les dépôts. Un pack d’un clic avec des dizaines de skills est une liste de favoris, pas une shortlist.

Différence entre $skill-installer Codex et npx skills ?

$skill-installer est l’installeur bundlé Codex et écrit souvent dans ~/.codex/skills. npx skills est un gestionnaire de paquets multi-agents et peut viser claude-code ou codex. Les skills écrits à la main vont dans .agents/skills ou .claude/skills. Vérifiez les deux arbres avant de conclure « pas installé ». L’erreur typique est de ne lire que l’arbre dans lequel vous avez écrit vous-même.

Puis-je lancer des skills avec scripts sur mon portable quotidien ?

Ils tourneront. Ne le faites pas sur un dépôt inconnu ni avec des secrets de production. Mettez-les d’abord dans un conteneur ou sur un nœud Mac distant, confirmez le périmètre de déclenchement et d’écriture, puis décidez si le skill peut entrer dans le dépôt d’équipe. Un portable où le mail, Slack et l’agent partagent les mêmes droits n’est pas un labo, c’est une surface d’attaque commune.

Conclusion

En 2026, ne traitez pas un classement communautaire comme un panier pour Agent Skills. Choisissez d’abord par classe d’entrée : skills bundlés pour le repli fournisseur, skills projet pour la release et la revue que vous répétez chaque semaine, et règles transversales seulement après qu’une personne les a lues. Claude Code et Codex partagent un format. Ils ne partagent pas un répertoire par défaut. Gardez les descriptions étroites, installez les scripts tard, et traitez le dossier utilisateur comme une exception plutôt que comme le défaut. Écrivez la coupure, le déclencheur, le chemin et le nœud nettoyable dans l’acceptation en sept étapes. Les nœuds distants commencent sur la page de location et la page des tarifs. Les questions de compte vont au centre d’aide. Tenir cet ordre, c’est acheter moins de faux déclenchements et plus de releases répétables.

Pour aller plus loin

• Pi vs Claude Code vs Codex : choisir le harnais 2026 →
• Qu’est-ce que Function Calling : OpenAI, Gemini, Claude →
• Mémoire agent auto-hébergée vs SaaS →