Les agent skills les plus installés et leur utilité

Quels agents de codage lisent les skills, et comment en installer un ?

Dans notre article sur les skills, nous avons expliqué ce qu’est un skill, dans quel dossier le placer pour Claude Code, Codex, Cursor, Gemini CLI et Copilot, et comment écrire un SKILL.md. Cet article répond à la question suivante : où et comment installer des skills écrits par d’autres, lesquels sont les plus installés, et que mesurent ces nombres ?

Ces cinq-là ne sont plus les seuls agents à lire des skills. Le 21 octobre 2026, nous avons regardé 10 agents de codage dont la documentation dit qu’ils lisent SKILL.md. Tous lisent le même format ; la façon d’installer un skill, l’endroit où le trouver et la date d’arrivée du support changent d’un outil à l’autre :

Source : documentation des skills et des plugins de chaque agent et notes de version, 21 octobre 2026. Versions : Claude Code 2.0.20, Gemini CLI 0.23.0 et 0.26.0, Antigravity 1.14.2, OpenCode 1.0.190 (sa note de version sur GitHub), Cursor 2.4 ; gh skill demande GitHub CLI 2.90.0 ou plus récent. Les plugins de Claude Code sont entrés en bêta publique le 9 octobre 2025, et Codex a reçu les plugins le 25 mars 2026. Le 18 juin 2026, Google a fermé Gemini CLI aux utilisateurs gratuits et aux abonnés Google AI Pro et Ultra, et l’a remplacé par Antigravity CLI ; Gemini CLI continue pour ceux qui l’utilisent avec une licence d’entreprise ou une clé API payante. « Non précisé dans la documentation » : dans les pages que nous avons lues ce jour-là, nous n’avons trouvé aucune phrase qui le dise.

Nous avons décrit les dossiers de ces cinq outils dans notre article sur les skills ; les agents qu’il ne couvrait pas cherchent les skills ici :

• OpenCode lit .opencode/skills dans le projet, ainsi que .claude/skills et .agents/skills par compatibilité, depuis le dossier où vous êtes jusqu’à la racine du worktree git. Pour les skills personnels, il regarde dans ~/.config/opencode/skills, ~/.claude/skills et ~/.agents/skills.
• Antigravity lit .agents/skills dans le projet ; l’ancien .agent/skills fonctionne encore. La CLI lit les skills personnels dans ~/.gemini/antigravity-cli/skills et ceux des plugins dans ~/.gemini/antigravity-cli/plugins/<plugin>/skills.
• Amp lit .agents/skills et .claude/skills dans le projet. Pour les skills personnels, il regarde dans ~/.config/agents/skills, ~/.agents/skills, ~/.config/amp/skills et ~/.claude/skills, et aussi dans le cache de plugins de Claude Code (~/.claude/plugins/cache). Si deux skills portent le même nom, il prend le premier qu’il trouve.
• Goose lit .agents/skills dans le projet et ~/.agents/skills pour les skills personnels ; il trouve aussi les anciens .goose/skills et .claude/skills.
• Pi lit .agents/skills dans le projet, depuis le dossier où vous êtes jusqu’à la racine du dépôt, et ~/.agents/skills pour les skills personnels.

Deux outils d’installation ne dépendent d’aucun agent en particulier. La commande gh skill install de GitHub CLI, avec --agent, installe aussi un skill dans Claude Code, Cursor, Codex, Gemini CLI ou Antigravity. La commande npx skills add de Vercel, d’après son README, installe dans OpenCode, Claude Code, Codex, Cursor et 75 autres agents. Ne supposez pas pour autant qu’un skill fera le même travail dans un autre agent. D’après l’étude Skill Constellations, les skills copiés dans les dossiers d’autres agents portent souvent le nom d’outils qui n’existent que dans Claude Code. Regardez quels outils un skill appelle.

Il y a aussi la différence entre skill et plugin. La documentation de Claude Code, de Codex, de Cursor et d’Antigravity décrit la distribution des skills d’autrui par des plugins : Cursor n’importe pas un skill isolé depuis un dépôt, et Codex recommande un plugin pour la distribution. Or un plugin peut apporter plus que des skills. D’après la documentation de Claude Code, un plugin peut exécuter des hooks et des serveurs MCP. Dans Codex, un plugin apporte, à côté des skills, des connexions d’applications et des réglages de serveurs MCP ; dans Cursor, des règles, des agents, des commandes, des serveurs MCP et des hooks. Un skill seul, lui, se compose de texte, de scripts et de fichiers de référence. obra/superpowers, mattpocock/skills et anthropics/skills sont aussi distribués comme plugins.

Comment mesure-t-on « les plus installés » ?

Les listes qui sortent quand vous cherchez « skills les plus installés » comptent des choses différentes. Voici les 4 compteurs que nous avons regardés le 21 octobre 2026 :

• skills.sh est le répertoire de skills de Vercel. D’après sa documentation, le classement repose sur une télémétrie anonyme collectée par la CLI skills et ne suit que les skills installés. Une installation depuis une marketplace de plugins, avec git clone ou avec gh skill n’entre pas dans ce compteur. Les nombres sont tenus skill par skill ; le « total installs » d’un dépôt est la somme de ses skills et ne dit pas combien de personnes l’ont installé. DISABLE_TELEMETRY=1 ou DO_NOT_TRACK=1 désactive la télémétrie.
• Le répertoire de plugins de Claude (claude.com/marketplace) affiche un nombre d’installations à côté de chaque plugin. C’est Anthropic qui fournit le nombre ; la page ne dit pas comment il est compté. Ce sont des installations de plugins : en plus des skills, un plugin peut aussi apporter des hooks, des agents et des serveurs MCP.
• Une étoile GitHub compte l’ajout d’un dépôt aux favoris, pas son usage. D’après Skill Constellations, les étoiles ne disent presque rien de la mesure dans laquelle les skills d’un dépôt sont copiés dans d’autres dépôts (« nearly uninformative ») ; l’étude signale aussi des campagnes de fausses étoiles.
• Les copies sur GitHub sont comptées par des chercheurs. GitSkills a collecté, en juillet 2026, 3 797 117 fichiers SKILL.md dans 282 200 dépôts publics sur GitHub ; une fois les contenus identiques fusionnés, il en restait 1 877 981 différents. D’après Skill Constellations, la moitié des fichiers SKILL.md sur GitHub sont des copies mot pour mot d’un autre fichier ; un seul skill, web-design-guidelines, s’est répandu, au fil de 12 générations de copies, dans 972 dépôts. Les deux études sont des prépublications sur arXiv, non évaluées par des pairs.

Les compteurs peuvent donner, pour un même pack, des nombres qui ne se ressemblent pas du tout, et parfois un seul compteur affiche à lui seul des nombres qu’on ne peut pas expliquer. Voici ce que nous avons vu le 21 octobre 2026 ; nous n’en connaissons pas les raisons :

• skills.sh liste 6 dépôts nommés superpowers qui ne sont pas obra/superpowers. Aucun n’a plus de 8 étoiles sur GitHub ; sur skills.sh, le skill le plus installé de chacun affiche entre 341,9 k et 825,8 k installations. L’un d’eux a 86 skills : 60 affichent 132 installations ou moins, tandis que 4 sont entre 824,3 k et 825,8 k.
• garrytan/gstack a 137,1 k étoiles sur GitHub ; son total sur skills.sh est de 44,2 k. Son README fait installer le pack avec git clone, et skills.sh ne compte que les installations faites avec sa propre CLI.
• Le plugin mattpocock/skills compte 1 745 installations dans le répertoire de Claude ; sur skills.sh, le skill grill-me du pack affiche à lui seul 1,4 M installations. Son README recommande le plugin pour Claude Code et npx skills pour beaucoup d’autres agents ; les deux compteurs comptent deux canaux distincts.

La règle qui en découle est simple : lisez un nombre avec le compteur qui l’a compté. N’additionnez pas les nombres de deux compteurs et ne les comparez pas entre eux. Dans le tableau ci-dessous aussi, chaque compteur a sa propre colonne.

Quels packs de skills sont les plus installés, et à quoi servent-ils ?

Le tableau ci-dessous n’est pas un classement. C’est une sélection de packs généralistes pour écrire du code, que nous avons souvent croisés sur les compteurs ; les lignes suivent l’ordre alphabétique du nom de dépôt. Les skills qu’une entreprise a écrits pour son propre produit (comme ceux de Supabase ou de Prisma) et les packs sans rapport avec le code ne sont pas dans le tableau ; nous citons quelques skills d’entreprises dans une section suivante.

Source : les étoiles GitHub sont le nombre arrondi que GitHub affiche sur la page du dépôt ; la colonne skills.sh donne le skill le plus installé du pack et le nombre arrondi d’installations que skills.sh affiche sur sa page de dépôt ; les deux le 21 octobre 2026. Les deux colonnes sont des compteurs distincts et ne se comparent pas entre elles. La colonne « Où l’installer » vient du README de chaque pack : les outils dont il décrit l’installation. Le README d’anthropics/skills décrit les skills docx, pdf, pptx et xlsx comme « source-available, not open source » ; vercel-labs/agent-skills n’a pas de fichier de licence à la racine, et son README indique la licence MIT.

Le répertoire de plugins de Claude est un compteur à part et ne compte que certains de ces packs. Les nombres d’installations fournis par Anthropic le 21 octobre 2026 : le plugin frontend-design d’Anthropic 1 134 112, superpowers 1 009 371, mattpocock-skills 1 745. Dans le répertoire, les plugins d’Anthropic portent l’étiquette « Anthropic verified » ; c’est aussi Anthropic qui fournit le nombre. La marketplace de Cursor et le répertoire de plugins d’OpenAI n’affichent pas de nombre d’installations.

Que fait Superpowers, et dans quels outils fonctionne-t-il ?

obra/superpowers met en place une façon de travailler plus qu’un ensemble de skills séparés. Son README le décrit comme « a complete software development methodology » pour les agents de codage. Sa dernière version est la 7.0.0 (9 octobre 2026), sa licence est MIT, et il contient 15 skills. Quand l’agent voit que vous voulez construire quelque chose, il ne se jette pas sur le code : il vous demande d’abord ce que vous voulez, attend que vous validiez la conception, puis écrit le plan et mène le travail étape par étape :

Ce qui tient le flux, c’est using-superpowers, sur la première carte. D’après le README, dans Claude Code, Codex, Cursor et Gemini, c’est le hook SessionStart du plugin qui le charge. Dans Claude Code, le hook s’exécute à l’ouverture d’une session, après /clear et quand le contexte est compacté ; nous avons expliqué ce que le compactage fait perdre dans l’article sur l’auto-compact. Le texte du skill est lui aussi catégorique avec l’agent : « If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill. » Selon les mots du README, ce sont des « Mandatory workflows, not suggestions. »

La plupart des étapes sont des habitudes que nous avons trouvées en commun dans les guides des outils, dans l’article sur le vibe coding : d’abord un plan pour un gros travail, des tests que l’agent peut lancer, un worktree séparé pour chaque tâche, relire le changement. Superpowers ne les laisse pas au rang de conseils : il en fait des skills et les fait appliquer par l’agent. Nous utilisons nous aussi obra/superpowers dans nos propres sessions, en développant diffox, notre outil de revue de code par IA. Dans un projet, le skill brainstorming ne laisse pas écrire de code tant qu’un document de conception n’est pas validé ; il écrit le document sous docs/superpowers/specs/, et le skill writing-plans écrit le plan sous docs/superpowers/plans/. Dans notre dépôt aussi, les documents de conception et les plans que superpowers a fait écrire se trouvent dans ces deux dossiers.

Le README décrit l’installation sous 16 titres ; l’application et la CLI de Codex ont chacune le leur. Parmi les agents de cet article, Amp et Goose ne sont pas dans la liste ; Devin CLI, Factory Droid, Grok Build CLI, Kimi Code, Qwen Code, Hermes Agent et Muse y sont. Le README vous demande de l’installer séparément dans chaque outil : « If you use more than one, install Superpowers separately for each one. » Les commandes pour les agents de cet article :

Source : le README d’obra/superpowers, 21 octobre 2026. Superpowers figure dans la marketplace de Cursor avec l’étiquette « Verified by Cursor », et aussi dans le répertoire de plugins d’OpenAI (openai/plugins).

Le chargement en début de session ne passe pas par le même chemin dans chaque outil. D’après les notes de version de Superpowers, Antigravity n’a pas de hook qui s’exécute au début de la session ; d’après le README, c’est la description de using-superpowers qui amène le modèle à le charger au début de la conversation. Les notes de version disent que cela a été vérifié sur 12 exécutions avec agy 1.3.1 ; c’est une mesure du projet lui-même. Dans Pi, une petite extension ajoute le même texte au début de la session et après le compactage. Hermes Agent n’a pas de hook qui s’exécute après le compactage, si bien qu’une très longue session peut perdre ce chargement. using-superpowers contient des fichiers de référence séparés pour Claude Code, Codex, Pi, Antigravity, Hermes Agent et Muse.

Deux points d’attention. Le premier, c’est le nom : comme nous l’avons vu plus haut, skills.sh liste des dépôts nommés superpowers qui n’ont rien à voir avec obra/superpowers ; écrivez le nom complet du dépôt. Le second, c’est une petite télémétrie : le compagnon visuel facultatif de brainstorming charge le logo de Prime Radiant depuis le site du projet, et cette requête envoie la version de Superpowers. Le README indique que rien n’est envoyé sur votre projet, votre prompt ou votre agent. Pour la couper, il existe la variable d’environnement SUPERPOWERS_DISABLE_TELEMETRY ; Superpowers respecte aussi les réglages DISABLE_TELEMETRY et CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC de Claude Code.

Quels skills aident à écrire du code ?

La plupart des packs se concentrent sur une seule tâche. Nous avons mis côte à côte les skills qui font le même travail ; les nombres entre parenthèses sont les installations que skills.sh affiche par skill (21 octobre 2026). Ce qui décide lequel vous convient, ce n’est pas le nombre mais ce que le skill fait faire à l’agent ; lisez son SKILL.md avant de l’installer.

Tests. Le skill test-driven-development d’obra/superpowers (256,4 k) tient sa règle en une ligne, « NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST », et fait supprimer le code écrit avant le test. Le tdd de mattpocock/skills (1,1 M) applique la même boucle rouge-vert-refactor en découpant le travail en tranches verticales. Pour essayer l’interface, webapp-testing d’anthropics/skills (183,6 k) teste une application web locale avec Playwright, tandis que vercel-labs/agent-browser (1,2 M) est une CLI qui permet à l’agent d’utiliser le navigateur. Nous avons expliqué quand l’agent doit essayer l’interface lui-même et quand il doit écrire un test durable dans l’article sur computer use et Playwright.

Débogage. systematic-debugging de superpowers (302,3 k) interdit de proposer un correctif avant d’avoir trouvé la cause racine et découpe le travail en quatre phases. diagnosing-bugs de mattpocock (819,4 k) fait d’abord construire une boucle de retour qui reproduit le bug et passe au rouge ; viennent ensuite la réduction, l’hypothèse, la mesure, le correctif et le test de régression. verification-before-completion de superpowers (247,9 k) demande à l’agent de lancer la commande de vérification et d’en montrer la sortie avant de dire « corrigé » ou « ça passe ».

Interface. frontend-design d’anthropics/skills (1,0 M) guide la direction visuelle, la typographie et les choix de design pour que l’interface n’ait pas l’air d’un modèle tout fait. vercel-react-best-practices de Vercel (824,7 k) donne des règles de performance pour React et Next.js, classées par impact ; web-design-guidelines (766,1 k) audite le code d’interface selon des règles d’accessibilité, de performance et d’expérience utilisateur. Pour un langage de design, il y a taste-skill (650,4 k), ui-ux-pro-max (407,2 k) et impeccable (349,3 k).

Bibliothèques. Certaines entreprises publient des skills pour leurs propres produits. supabase-postgres-best-practices de Supabase (454,1 k) est écrit pour être chargé avant d’écrire ou de modifier quoi que ce soit dans une base Postgres ; prisma-client-api de Prisma (378,2 k) explique l’API de Prisma Client pour écrire des requêtes et des filtres. Si l’éditeur d’une bibliothèque que vous utilisez publie un skill, regardez celui-là en premier.

Documents. Les skills pptx (239,8 k), pdf (214,4 k), docx (204,7 k) et xlsx (185,7 k) d’anthropics/skills sont ceux qui servent à la création de documents dans Claude. Le README les décrit comme « source-available, not open source » : le code source se lit, mais il n’y a pas de licence open source, et le fichier de licence dit « All rights reserved ». Lisez-les comme des exemples ; vérifiez la licence avant d’en copier un dans votre propre pack.

Des skills qui trouvent et écrivent des skills. find-skills de vercel-labs/skills (4,0 M) trouve et installe d’autres skills quand vous demandez « existe-t-il un skill qui fait ça ? ». skill-creator d’anthropics/skills (411,5 k) fait écrire un nouveau skill, améliore un skill existant et mesure la précision de son déclenchement ; writing-skills de superpowers (215,2 k) fait le même travail avec sa propre méthode de test. Codex fournit Skill Creator intégré, et Gemini CLI a ajouté un skill-creator dans la version 0.26.0. Nous avons expliqué comment écrire votre propre skill dans notre article sur les skills.

Est-il sûr d’installer le skill de quelqu’un d’autre ?

Nous avons listé ce qu’il faut vérifier avant d’installer dans notre article sur les skills, expliqué le risque des serveurs MCP dans l’article sur la sécurité MCP, et les fichiers d’un dépôt qui peuvent s’exécuter d’eux-mêmes dans l’article sur le workspace trust. Voici ce que nous avons lu depuis.

Un plugin exécute du code. La page sur la sécurité des plugins de Claude Code le dit clairement : « A Claude Code plugin you install can execute arbitrary code on your machine with your user privileges. » Les hooks et les serveurs MCP d’un plugin s’exécutent avec vos droits. Les règles de permission et la sandbox de Claude Code couvrent les appels d’outils que fait Claude, pas le code que le plugin exécute de lui-même. Superpowers aussi entre dans Claude Code comme plugin et exécute un hook au début de chaque session. La documentation de Codex vous demande d’examiner et d’approuver les hooks d’un plugin avant qu’ils ne s’exécutent.

La version que vous avez lue peut changer. Si la mise à jour automatique est activée pour la marketplace d’où vient un plugin, Claude Code met le plugin à jour en arrière-plan ; la documentation en écrit la conséquence : « the files you reviewed can change on disk. » La mise à jour automatique est activée par défaut dans claude-plugins-official et la plupart des marketplaces officielles, et désactivée dans les marketplaces communautaires et tierces. Le catalogue communautaire, lui, épingle presque chaque plugin sur un commit ; Claude Code n’installe pas d’autre commit que celui-là. Le README de mattpocock/skills résume la différence en une phrase : « A plugin updates itself. » npx skills, à l’inverse, copie les fichiers dans votre projet, et c’est vous qui les mettez à jour.

Une copie ne se corrige pas toute seule. Skill Constellations mesure le risque dans l’autre sens : « Skill copies almost never change with their source, and a fix at the source therefore rarely reaches them. » L’étude recommande donc de distribuer des références versionnées plutôt que des copies. Au moment de choisir l’installation, la vraie question est de savoir comment le skill change ensuite :

L’outil d’installation dont la documentation décrit clairement l’épinglage de version est GitHub CLI : gh skill install … --pin épingle le skill sur un tag ou un commit, et un skill épinglé est ignoré lors des mises à jour. Mais épingler fait aussi de la mise à jour votre travail. Les notes de Superpowers 7.0.0 indiquent la fermeture d’une faille par laquelle, sous Windows, un dépôt pouvait déposer un fichier exécuté au début de la session ; une installation restée sur une version plus ancienne ne reçoit pas ce correctif. Épinglez, lisez les notes de version et faites la mise à jour vous-même.

Les analyses de sécurité ne concordent pas. skills.sh, d’après son annonce du 17 février 2026, analyse les skills avec Gen, Socket et Snyk et retire ceux jugés malveillants de sa liste et de sa recherche ; sa documentation précise aussi qu’il ne peut pas garantir la qualité et la sécurité de chaque skill. Il y a des raisons de ne pas se fier au seul verdict d’un scanner. Dans l’étude After the Party, consacrée à la marketplace de skills d’OpenClaw, trois scanners ont examiné les mêmes 61 990 skills et ont rendu des verdicts différents pour 23 702 d’entre eux. En sens inverse, Context Matters a trouvé que les rapports d’analyse des marketplaces jugeaient malveillants jusqu’à 46,8 % des skills, alors que seuls 0,52 % restaient suspects une fois chaque skill examiné avec son propre dépôt. Ni un badge « validé » ni une alerte « malveillant » ne suffisent donc à eux seuls.

Des skills sains un par un peuvent être risqués ensemble. CompoSkill et Runaway Reaction montrent que des skills qui passent chacun une analyse peuvent produire un comportement nuisible quand on les utilise ensemble. SkillBloat s’intéresse à une autre attaque contre les agents de codage : un skill malveillant peut pousser l’agent à dépenser bien plus de tokens que la tâche ne l’exige ; le dommage apparaît sur la facture. Toutes les études de cette section sont des prépublications sur arXiv, non évaluées par des pairs.

La documentation des agents sur les skills met aussi en garde, à des degrés différents :

• OpenCode vous laisse régler chaque skill, ou un motif, sur allow, ask ou deny avec permission.skill dans opencode.json ; avec ask, il vous demande avant de charger le skill.
• Pi vous demande de lire les skills inconnus et les fichiers qui les accompagnent avant de faire confiance à un projet.
• La documentation VS Code de Copilot vous dit de toujours examiner les skills partagés avant de les utiliser.
• La marketplace de Cursor examine chaque plugin à la main avant de le lister.
• Les pages sur les skills d’Antigravity et Goose ne donnent aucune règle de sécurité : non précisé dans la documentation.

Par quel skill commencer ?

Partez de votre travail, pas d’une liste. Ce que nous conseillons :

• Trouvez d’abord le besoin. Si l’agent fait toujours la même erreur (du code sans tests, un correctif qui ignore la cause racine, une interface qui ressemble à un modèle), cherchez un skill pour cette tâche. Pour changer tout le flux, un pack comme obra/superpowers ; pour corriger une seule tâche, un seul skill suffit.
• Choisissez un pack maintenu, à la licence claire. Le README dit-il quels agents il prend en charge et quelle est sa licence, et quand a-t-il changé pour la dernière fois ? Si l’éditeur d’une bibliothèque que vous utilisez publie un skill, regardez celui-là.
• Lisez avant d’installer. Lisez le SKILL.md et les scripts qui l’accompagnent ; si c’est un plugin, regardez aussi ses hooks et ses serveurs MCP. Dans Claude Code, /plugin install n’installe pas tout de suite le plugin : il ouvre d’abord le panneau de détails, qui montre les commandes, les skills, les hooks et les serveurs MCP que le plugin va ajouter.
• Épinglez la version et faites vous-même la mise à jour. gh skill install … --pin ou un commit ; si c’est un plugin, sachez si la mise à jour automatique est activée ou non.
• N’installez pas le même pack de deux façons. Le README de mattpocock/skills prévient : si vous l’installez à la fois comme plugin et avec npx skills, chaque skill arrive en double.
• Devant un nombre, lisez aussi son compteur. Quel compteur, que compte-t-il, quand a-t-il été lu ? Ne mettez pas côte à côte les nombres de compteurs différents pour les comparer.

Questions fréquentes

Que sont les agent skills ?

Un skill est un dossier qui contient un fichier SKILL.md : en tête figurent le nom et la description du skill, et en dessous les instructions qui expliquent à l’agent comment faire une tâche. Au début d’une session, l’agent ne lit que le nom et la description ; quand une tâche correspond à la description, il charge les instructions complètes. Nous avons expliqué comment l’écrire et dans quel dossier le placer dans notre article sur les skills.

Comment ajouter un skill à Claude Code ?

Vous placez votre propre skill dans .claude/skills/<nom>/SKILL.md dans le projet, ou dans ~/.claude/skills pour vous. Les skills des autres arrivent le plus souvent par des plugins : /plugin install <plugin>@<marketplace> affiche d’abord les détails du plugin et l’installe quand vous choisissez une portée. La marketplace officielle d’Anthropic (claude-plugins-official) est ajoutée automatiquement à la première session interactive ; pour une autre marketplace, il faut d’abord /plugin marketplace add. N’oubliez pas qu’un plugin peut aussi exécuter des hooks et des serveurs MCP.

Comment installer un skill dans Codex ?

Pour installer un skill depuis le catalogue de Codex, tapez $skill-installer <nom> ; Codex repère le nouveau skill tout seul, et s’il n’apparaît pas, redémarrez Codex. Les plugins s’installent avec /plugins dans la CLI et depuis l’onglet Plugins dans l’application ; la documentation de Codex recommande les plugins pour distribuer des skills. Les skills que vous ajoutez à la main se trouvent dans .agents/skills dans le projet et dans $HOME/.agents/skills pour vous. L’ancien catalogue openai/skills est obsolète ; les exemples à jour sont dans openai/plugins.

Dans quels dossiers OpenCode lit-il les skills ?

Dans le projet, il lit .opencode/skills, .claude/skills et .agents/skills à chaque niveau, depuis le dossier où vous êtes jusqu’à la racine du worktree git. Pour les skills personnels, il regarde dans ~/.config/opencode/skills, ~/.claude/skills et ~/.agents/skills. L’agent charge un skill avec l’outil intégré skill ; avec permission.skill dans opencode.json, vous pouvez autoriser chaque skill, lui faire demander une confirmation ou le désactiver. Sa documentation ne mentionne ni commande d’installation ni marketplace.

Les skills de Gemini CLI fonctionnent-ils encore ?

Oui, mais pas pour tout le monde. Le 18 juin 2026, Google a fermé Gemini CLI aux utilisateurs gratuits et aux abonnés Google AI Pro et Ultra, et l’a remplacé par Antigravity CLI. Gemini CLI continue pour ceux qui l’utilisent avec une licence d’entreprise ou une clé API payante ; la dernière version dans les notes de version est la 0.64.0 (13 octobre 2026). D’après Google, Antigravity CLI conserve les skills. Si vous placez vos skills dans .agents/skills, les deux les lisent ; dans Gemini CLI, ce dossier passe avant .gemini/skills.

Qu’est-ce que skills.sh, et que comptent ses nombres d’installations ?

skills.sh est le répertoire de skills de Vercel et le site de la CLI npx skills. Son classement repose sur une télémétrie anonyme collectée par la CLI : il compte les installations faites avec npx skills add, skill par skill. Les installations depuis une marketplace de plugins, avec git clone ou avec gh skill n’entrent pas dans ce nombre. Le total d’un dépôt est la somme de ses skills ; il ne dit pas combien de personnes l’ont installé. DISABLE_TELEMETRY=1 ou DO_NOT_TRACK=1 désactive la télémétrie.

Superpowers fonctionne-t-il dans Codex, OpenCode ou Cursor ?

Le README d’obra/superpowers décrit une installation pour les trois. Dans Codex, il est dans le répertoire de plugins d’OpenAI : vous le cherchez avec /plugins dans la CLI et vous l’installez. Dans Cursor, il s’installe avec /add-plugin superpowers ou depuis la marketplace, où il figure avec l’étiquette « Verified by Cursor ». Dans OpenCode, vous demandez à l’agent de lire et d’appliquer .opencode/INSTALL.md du dépôt ; le README demande d’installer Superpowers séparément dans OpenCode, même si vous l’utilisez déjà dans un autre outil. Comme d’autres dépôts portent le même nom, écrivez le nom complet du dépôt : obra/superpowers.