Réponse rapide : le contenu peut voyager, pas le chemin d’installation
Codex et Claude Code décrivent tous deux des skills sur le système de fichiers autour de SKILL.md et du format ouvert Agent Skills. Cette base commune rend la réutilisation possible, pas automatique. Les chemins de découverte diffèrent ; Claude Code documente aussi des ajouts propres à sa plateforme, comme le contrôle de l’invocation, l’exécution en sous-agents et l’injection dynamique de contexte.
Un candidat plus facile à porter est un SKILL.md standard avec références relatives et instructions ordinaires. Avant la migration, adaptez commandes, outils, permissions, hooks et champs d’en-tête propres à l’agent ; installez ensuite au chemin documenté de la cible et testez la même petite tâche.
- Codex, projet : .agents/skills/<skill-name>/SKILL.md ; personnelle : ~/.agents/skills/<skill-name>/SKILL.md.
- Claude Code, projet : .claude/skills/<skill-name>/SKILL.md ; personnelle : ~/.claude/skills/<skill-name>/SKILL.md.
- Une copie réussie prouve le transfert de fichiers, pas la découverte, le déclenchement ou l’équivalence des outils et permissions.
Natif et portable répondent à deux questions différentes
La prise en charge native indique si le skill ou la plateforme vise explicitement un agent. La portabilité indique si les instructions peuvent plausiblement être adaptées par une procédure SKILL.md compatible. Les deux sont utiles, mais n’apportent pas la même confiance.
SkillSignal garde ces étiquettes séparées. Un chemin d’installation connu ne transforme jamais une association portable en prise en charge native, et une révision source précise ne prouve pas la compatibilité à l’exécution.
Comparer cinq couches avant de déplacer un skill
Comparez d’abord découverte et chemins d’installation. Examinez les commandes et noms d’outils référencés. Cartographiez ensuite les permissions de fichiers, commandes, navigateur et réseau. Vérifiez si les exemples supposent un contexte, des sous-agents, hooks ou comportements d’interface propres à l’agent. Enfin, exécutez une tâche d’acceptation et conservez la révision exacte et le résultat.
- Installation : les chemins projet et personnels de l’agent cible sont connus.
- Outils : chaque commande ou outil référencé possède un équivalent dans la cible.
- Permissions : les points d’approbation et le périmètre d’écriture restent au moins aussi stricts.
- Ressources : scripts, modèles et références liées restent accessibles après migration.
- Preuves : la même tâche d’acceptation produit un résultat vérifiable.
Pour Codex : privilégier une exécution délimitée et reproductible
Pour Codex, vérifiez l’adéquation au contexte du projet, à l’environnement de commandes, aux autorisations et à une validation répétable. Un skill portable peut convenir s’il utilise des chemins clairs, commandes ordinaires, résultats explicites et aucun hook caché propre à un autre agent.
Ne considérez pas la copie réussie comme une validation complète. Exécutez la plus petite tâche représentative, vérifiez fichiers modifiés et appels externes, puis comparez le résultat aux limites annoncées du skill.
Pour Claude Code : vérifier les hypothèses de l’auteur et l’utilisation des outils
Pour Claude Code, vérifiez si la source utilise explicitement des chemins, outils, modèles de sous-agents ou demandes de permissions propres à Claude. Ce ciblage est une preuve utile, mais scripts référencés et services externes exigent leur propre examen.
Lors du transfert d’un skill ciblant Claude, adaptez chaque appel d’outil et point d’approbation au lieu de préserver uniquement le texte. Si un comportement n’a pas d’équivalent dans la cible, réduisez la procédure ou gardez-la sur l’agent d’origine.
Un test de migration qui dépasse les apparences de compatibilité
Choisissez une petite tâche réversible avec résultat observable. Exécutez-la dans l’environnement d’origine et notez révision source, entrées, commandes, permissions, sorties et conditions d’arrêt. Déplacez le skill, adaptez uniquement les éléments propres à l’agent et répétez la tâche. Comparez les preuves, pas le ton ou le style des réponses.
Indiquez que le résultat est vérifié localement pour cette tâche et cet environnement seulement. Un test réussi ne démontre pas une compatibilité universelle entre dépôts, systèmes d’exploitation, identifiants ou révisions futures.
- Aucun identifiant supplémentaire ni élargissement d’écriture n’a été nécessaire.
- L’agent cible a utilisé des outils équivalents ou des substitutions documentées.
- Le livrable final passe le même contrôle d’acceptation.
- Les échecs et le retour arrière restent compréhensibles.
- La note de compatibilité précise la révision et l’environnement testés.