Copier la commande complète d’installation
Pour un skill publié dans un dépôt GitHub, l’installateur universel accepte l’URL du dépôt, le nom du skill et la cible Codex. Exécutez-le depuis le dépôt où vous souhaitez l’installation limitée au projet. Ajoutez -g uniquement pour une installation personnelle.
Remplacez les paramètres génériques par la source affichée sur la fiche du skill. Si la source ne permet pas de générer une commande fiable, ouvrez le lien fourni et copiez le dossier complet du skill au lieu de deviner un chemin de dépôt.
npx skills add <github-repository-url> --skill <skill-name> --agent codexnpx skills add <github-repository-url> --skill <skill-name> --agent codex -gPortée projet ou portée personnelle ?
L’installation par projet place le skill sous .agents/skills/<skill>/ dans le dépôt courant. C’est le choix recommandé par défaut : la source, les instructions et les modifications peuvent être examinées avec le projet. Les collègues reçoivent le même dossier lorsqu’il est versionné.
L’installation personnelle le place sous ~/.agents/skills/<skill>/ et le rend disponible dans plusieurs dépôts. Cette commodité élargit aussi le périmètre de découverte : ne l’utilisez que si la procédure, les permissions et la responsabilité de maintenance sont réellement identiques entre les projets.
- Choisissez la portée projet pour les conventions d’un dépôt ou le partage en équipe.
- Choisissez la portée personnelle uniquement pour une procédure délibérément commune à plusieurs projets.
- N’installez pas les deux copies sans pouvoir expliquer laquelle Codex doit utiliser.
L’installateur natif $skill-installer et la CLI universelle Skills
Codex possède aussi un $skill-installer natif pour des skills sélectionnés et ceux d’autres dépôts. Utilisez-le si vous souhaitez que Codex gère une installation locale. Les commandes npx skills add ci-dessus appartiennent à une autre CLI, utilisable avec plusieurs agents : elles permettent de préciser explicitement dépôt, skill, agent cible et portée projet ou globale.
Après une installation npx, lancez la commande de liste depuis le dépôt visé ; la seconde commande vérifie les installations globales. Confirmez ensuite que Codex détecte le skill. Pour une installation via $skill-installer, vérifiez directement dans Codex plutôt que de considérer la liste npx comme une validation.
npx skills ls -a codexnpx skills ls -g -a codex- Codex examine .agents/skills dans le dépôt et ~/.agents/skills au niveau utilisateur ; vérifiez que la portée choisie correspond au chemin prévu.
- Si un skill n’apparaît pas, vérifiez les champs name et description de SKILL.md, puis redémarrez Codex.
- Conservez une seule copie de référence, sauf besoin volontaire des deux portées.
PromptScript ne prend pas en charge l’installation globale : qu’est-ce qui a échoué ?
Ce message désigne un agent cible et une portée non prise en charge, pas un paquet Grill Me défectueux ni un besoin de droits administrateur. Dans la révision examinée de l’installateur, PromptScript dispose d’un dossier de skills par projet, mais pas de dossier global. L’installateur refuse une demande globale pour cette cible avant de copier le skill.
Lisez les résultats complets pour chaque agent. Un échec PromptScript ne prouve pas que Codex a aussi échoué ; une bannière de succès ne prouve pas que l’agent voulu détecte sa copie. Notez la version de la CLI, l’agent sélectionné, la portée et le chemin réellement installé avant de recommencer.
Si vous utilisez PromptScript, choisissez la portée projet dans le projet concerné plutôt que d’ajouter -g ou --global. Si vous utilisez Codex, sélectionnez Codex et une portée prise en charge avec les commandes ci-dessus, puis vérifiez la détection. Ne supposez pas que choisir une cible supprime tous les messages supplémentaires dans toutes les versions de la CLI.
Ce dépannage s’appuie sur la source examinée le 20 octobre 2026 à la révision a80e4c9d12d607631249d4d7d059f835d4b2f13a, et non sur une correction d’installation reproduite. Préservez vos modifications ; ne commencez pas par supprimer tous les skills, modifier l’installateur ou relancer une installation générale --all. Pour Grill Me, vérifiez séparément son compagnon grilling : l’erreur de portée et l’absence d’un compagnon sont deux problèmes différents.
- Identifiez l’agent réellement utilisé, pas seulement la dernière ligne d’erreur.
- Distinguez les résultats d’installation par cible et la détection par l’agent.
- Vérifiez séparément grill-me et grilling lorsque cette procédure exige les deux.
Examiner la source avant l’installation
Lisez SKILL.md et chaque script, modèle ou fichier de configuration référencé. Notez le dépôt et la révision examinés. Même un fichier d’instructions court peut déléguer des opérations puissantes à un script inclus ou à un service externe.
Comparez les accès demandés à la première tâche. Un skill de formatage ou de revue ne devrait pas demander des identifiants de publication, des commandes destructrices ou un accès réseau étendu au seul motif que l’environnement de l’agent dispose de ces capacités.
- Le dépôt source et la révision examinée sont notés.
- Les scripts et fichiers référencés existent et sont compréhensibles.
- Les accès réseau, commandes, écritures, identifiants et publications correspondent à la première tâche.
- La source prévoit une façon claire de mettre à jour ou retirer le skill.
Cinq rôles utiles pour débuter, pas cinq installations automatiques
Un ensemble équilibré pour le développement peut couvrir la recherche de skills, la planification, la conception de procédures réutilisables, la revue des changements et les preuves de comportement. La sélection SkillSignal correspondante est find-skills, create-implementation-plan, skill-creator, differential-review et webapp-testing.
Considérez ces noms comme des exemples de rôles, pas comme un classement universel. Installez d’abord celui qui résout le problème actuel. Ajoutez-en un autre seulement s’il produit un livrable distinct que quelqu’un examinera ; remplacez le rôle de validation si le produit n’est pas une application web.
Vérifier la détection avec une tâche contrôlée
Après l’installation, confirmez que Codex détecte le nom et la description attendus. Choisissez ensuite une petite tâche réversible dont les entrées, le résultat, la condition d’arrêt et le retour arrière sont explicites. Notez les fichiers, commandes, appels réseau et résultats réellement utilisés pendant l’exécution.
Une première exécution réussie est une preuve locale pour cette révision, ce dépôt, cet environnement et cette tâche. Ce n’est pas une certification permanente de compatibilité ou de sécurité. Vérifiez à nouveau après une mise à jour de source, un changement d’agent, de nouveaux scripts ou un élargissement des permissions.
- Codex détecte la copie et la portée voulues.
- Le déclencheur correspond à la tâche voulue et reste inactif pour une tâche sans rapport.
- L’exécution reste limitée aux fichiers, commandes et services convenus.
- Le résultat passe un contrôle d’acceptation vérifiable par une personne.
- Le retour arrière rétablit l’état initial du dépôt.
Gardez moins de skills installés que de favoris
Chaque mois, examinez les skills installés selon leur rôle, révision source, dernière utilisation, permissions, responsable du résultat et dernier test contrôlé réussi. Retirez un doublon ou un skill mal défini avant d’en ajouter un autre.
Le but n’est pas d’accumuler tous les paquets utiles, mais de garder le plus petit ensemble dont vous pouvez encore expliquer le comportement, les sources et les résultats. La portée projet facilite cet entretien ; la portée personnelle doit rester une exception justifiable.