2026 : après avoir changé de Mac avec Cursor Agent Skills, comment continuer à les utiliser avec Claude Code ?

Ancien Mac fonctionnel, nouveau Mac avec deux compétences portant le même nom → choisissez une seule source avant toute copie : les fichiers versionnés du projet ou le plugin Claude Code, jamais les deux.

Cette règle s’applique autant à un Mac local durable qu’à un Mac temporaire ou hébergé. Notez d’abord le mode d’installation utilisé sur l’ancien Mac, puis reconstruisez le nouvel environnement à partir d’une source contrôlée.

À qui s’adresse ce guide ?

Vous migrez un projet Cursor vers un nouveau Mac et devez conserver vos personnalisations, vos réglages de projet et vos compétences existantes.

Vous utilisez un Mac temporaire pour une équipe et souhaitez pouvoir détruire puis recréer l’environnement sans dépendre d’un ancien dossier utilisateur.

Vous voulez enfin utiliser Cursor et Claude Code sur le même Mac, sans exposer à Claude Code deux copies concurrentes d’une même compétence.

Dernière mise à jour : 27 août 2026. Les règles d’installation et l’avertissement concernant la double installation ont été vérifiés dans le README officiel de mattpocock/skills, la documentation du paquet skills et les références officielles des plugins Claude Code.

Le vrai choix : fichiers du projet ou plugin géré par Claude Code

Le nom « Cursor Agent Skills » décrit ici un ensemble de compétences utilisé depuis un projet Cursor, mais cela ne signifie pas que toutes les installations doivent être copiées d’une machine à l’autre. Le dépôt mattpocock/skills distingue deux voies.

Avec la version composée de fichiers dans le projet, les fichiers de compétences deviennent une partie livrée avec le dépôt. Cette solution convient si vous devez modifier le contenu, examiner chaque instruction dans une revue de code ou conserver une variante propre à votre équipe. La mise à jour reste une action explicite : vous récupérez une modification du dépôt, vous l’examinez, puis vous la validez.

Avec le plugin Claude Code, la gestion est confiée à Claude Code. Cette voie convient lorsque vous voulez installer le paquet selon le mécanisme officiel des plugins et recevoir ses mises à jour sans maintenir vous-même chaque fichier dans le dépôt. La documentation de découverte des plugins explique la recherche et l’activation dans l’écosystème Claude Code.

Le README officiel avertit que ces deux voies ne doivent pas être installées ensemble. Le risque n’est pas uniquement esthétique. Deux compétences portant le même nom peuvent rendre leur origine incertaine, produire une liste ambiguë ou faire exécuter une version différente de celle attendue par votre projet. Le premier geste de migration doit donc être un inventaire, pas une commande npx skills add.

Ce qu’il faut relever sur l’ancien Mac

Avant de fermer l’ancien environnement, consignez les éléments suivants dans un fichier de migration ou dans une issue privée de votre équipe :

• la source réellement utilisée : fichiers du projet ou plugin ;
• le chemin du dossier de compétences visible par le projet ;
• les noms des compétences personnalisées ;
• les modifications locales qui ne sont pas encore dans le dépôt ;
• les variables et fichiers de configuration nécessaires à l’initialisation ;
• le résultat d’une tâche simple déjà validée ;
• l’état observé après le redémarrage d’une session.

Ne déduisez pas la source à partir du seul fait que Cursor fonctionne. Une compétence peut être découverte par Cursor alors que Claude Code la récupère ailleurs. Ouvrez les fichiers, recherchez les éventuelles copies homonymes et vérifiez la configuration réellement chargée.

Premier scénario : un nouveau Mac destiné à un projet durable

Si le nouveau Mac devient votre poste principal, la livraison doit partir du dépôt versionné. Il faut éviter la copie d’un dossier utilisateur complet, d’un cache ou d’un répertoire global dont personne ne connaît le contenu exact.

Cette méthode a trois avantages concrets. Elle conserve l’historique des personnalisations. Elle permet à un collègue de reconstruire le même environnement. Elle rend le retour arrière possible sans comparer manuellement deux disques.

Étape 1 : figer l’état connu

Sur l’ancien Mac, validez ou exportez les changements de compétences qui doivent réellement suivre le projet. Ne classez pas automatiquement toute modification locale comme un actif utile. Une instruction expérimentale, un fichier temporaire ou un secret local n’a pas sa place dans le dépôt.

Créez ensuite un point de référence identifiable dans votre système de contrôle de version. La documentation du paquet skills doit servir de référence pour la commande effectivement disponible le jour de l’installation. Les commandes et les chemins peuvent évoluer : ne recopiez pas une ligne trouvée dans un ancien article.

Étape 2 : récupérer le projet sur le nouveau Mac

Clonez le dépôt dans le nouvel environnement, puis examinez immédiatement son arborescence. Cherchez le répertoire prévu par la version fichier de vos compétences. Comparez les fichiers suivis par le contrôle de version avec la liste relevée sur l’ancien Mac.

Cette vérification répond à la question « mattpocock/skills peut-il suivre un dépôt Git ? » : oui, lorsque vous utilisez la voie fichier et que les éléments nécessaires sont effectivement présents dans le dépôt. Elle ne signifie pas qu’un dossier global ou un cache personnel sera transféré automatiquement.

Étape 3 : reconstruire sans ajouter une seconde source

Installez les dépendances du projet, appliquez son initialisation et utilisez uniquement la procédure officielle correspondant à la voie déjà choisie. Si le dépôt contient les compétences attendues, n’exécutez pas en plus npx skills add pour installer un paquet équivalent destiné au plugin.

À l’inverse, si vous avez décidé d’abandonner la version fichier au profit du plugin, retirez d’abord les copies homonymes du projet selon une modification contrôlée. Faites cette transition dans une branche ou un commit séparé. Vous pourrez ainsi revenir à la version précédente sans deviner ce qui a changé.

Étape 4 : comparer le contenu, pas seulement les noms

Un nom identique ne prouve pas que le contenu est identique. Comparez les instructions, les fichiers auxiliaires et les réglages de projet. Portez une attention particulière aux compétences orientées audio, vidéo ou design : une instruction qui impose un format de sortie, un outil de traitement ou une convention de répertoire peut modifier silencieusement le résultat.

Étape 5 : exécuter une tâche à faible risque

Demandez à Cursor puis à Claude Code de découvrir la compétence attendue et de réaliser une opération sans effet destructeur : analyser un fichier de test, proposer une modification ou générer un aperçu. Ne commencez pas par une migration de données, une publication ou une modification massive.

Conservez la sortie, la compétence détectée et les fichiers touchés. Cette trace constitue une preuve d’installation plus utile qu’une capture de l’écran des réglages.

Deuxième scénario : Mac temporaire ou environnement hébergé

Un Mac temporaire doit être pensé comme un environnement reconstructible, non comme un ancien Mac que vous auriez cloné en totalité. La différence est importante pour les droits d’accès, les secrets, les caches et les personnalisations invisibles.

La copie complète du dossier utilisateur apporte souvent des dépendances inutiles. Elle peut aussi transporter une ancienne compétence que vous pensiez avoir supprimée. Enfin, elle transforme l’état d’une machine provisoire en pseudo-source de vérité.

Pour un travail court, choisissez généralement la voie fichier lorsque le projet contient déjà les compétences nécessaires et que l’équipe doit pouvoir relancer exactement l’initialisation. Choisissez le plugin lorsque la tâche repose uniquement sur Claude Code et que l’équipe accepte de laisser Claude Code gérer ce paquet. Dans les deux cas, l’environnement temporaire ne doit recevoir qu’une seule source.

Le tableau de décision avant création de l’environnement

Ce tableau ne compare pas une prétendue performance entre les deux méthodes. Il répond à une décision de déploiement : où se trouve l’autorité, qui met à jour la compétence et que restera-t-il après la destruction du Mac ?

Étape 6 : préparer la destruction de l’environnement

Avant de supprimer le Mac temporaire, rapportez dans le dépôt les personnalisations approuvées, les scripts d’initialisation et le relevé de validation. Retirez les secrets et les jetons d’accès des fichiers suivis. Exportez uniquement la configuration nécessaire, jamais une copie brute du dossier utilisateur.

Si une compétence a été améliorée pendant la session, indiquez précisément si cette modification appartient au projet. Une modification non enregistrée disparaîtra avec l’environnement. Une modification enregistrée mais non revue peut, elle, contaminer les prochaines reconstructions.

Pour les équipes qui alternent entre environnements, la console MacHTML peut servir de point de gestion pour le cycle de vie du Mac temporaire. Elle ne remplace toutefois pas la version contrôlée du projet ni la preuve d’installation de la compétence.

Troisième scénario : restaurer uniquement le plugin Claude Code

Si l’ancien Mac utilisait exclusivement le plugin, ne copiez pas manuellement ses fichiers internes vers le nouveau système. Réinstallez le plugin avec la méthode officielle de Claude Code. Les références officielles de gestion des plugins indiquent les opérations de recherche, d’installation, d’activation et de contrôle à utiliser selon la version disponible.

La restauration doit être vérifiée à trois niveaux.

D’abord, le plugin doit apparaître comme installé et activé dans Claude Code. Ensuite, la compétence attendue doit être découvrable dans le contexte du projet. Enfin, l’initialisation du dépôt doit réussir sans dépendre d’un fichier oublié sur l’ancien Mac.

Claude Code plugin sur un nouveau Mac : ordre de contrôle

1. Ouvrez le projet depuis le nouveau Mac.
2. Vérifiez que le plugin apparaît dans la gestion officielle des plugins.
3. Contrôlez qu’il est activé pour le contexte où vous travaillez.
4. Demandez la liste des compétences visibles.
5. Comparez cette liste avec l’inventaire de l’ancien Mac.
6. Lancez une tâche d’analyse sans écriture destructive.
7. Fermez puis rouvrez la session et répétez la découverte.

Ces étapes ne constituent pas une garantie abstraite de compatibilité. Elles vérifient le chemin réel emprunté par votre session. Si la compétence disparaît après redémarrage, notez la configuration qui n’a pas été persistée au lieu de copier immédiatement un répertoire supplémentaire.

Quatrième scénario : Cursor et Claude Code sur le même Mac

Le fonctionnement conjoint est possible si vous séparez clairement les rôles. Cursor peut utiliser les fichiers de compétences présents dans le projet. Claude Code peut utiliser ces mêmes fichiers, si votre procédure les rend visibles, ou utiliser son plugin. Ce qui est à éviter est la présence simultanée d’une version fichier et d’un plugin fournissant la même compétence à Claude Code.

Dans le premier modèle, les deux outils lisent une source éditable et versionnée. Vous devez alors vérifier qu’ils interprètent bien le même projet, le même contexte et les mêmes conventions. Dans le second, Claude Code reste sur le plugin et le projet ne doit pas contenir de copie homonyme destinée à lui fournir la même compétence.

Une validation séparée pour chaque outil

Commencez par Cursor. Ouvrez le projet, vérifiez la compétence attendue et effectuez une tâche de lecture ou de proposition. Notez le fichier de contexte utilisé et la sortie obtenue.

Passez ensuite à Claude Code sans modifier l’installation entre les deux tests. Vérifiez sa propre liste de compétences, puis répétez une tâche équivalente sur un fichier de test. Une différence de résultat n’est pas automatiquement un défaut : les deux outils peuvent avoir des mécanismes de découverte distincts. Elle devient un problème lorsque vous ne pouvez plus identifier la source des instructions.

Pour un projet créatif, utilisez par exemple un court fichier audio de test, une séquence vidéo non publiée ou une maquette de design sans données sensibles. Vous pourrez contrôler le format produit, les conventions de nommage et les transformations appliquées, sans risquer une livraison réelle.

Quand npx skills add est-il approprié ?

La commande npx skills add ne doit pas devenir un réflexe de migration. Elle n’est pertinente que si la procédure officielle du jour et la voie choisie par votre projet la demandent. Le paquet publié sur npm est une source documentaire utile pour vérifier la syntaxe actuelle, mais il ne décide pas à votre place si le projet doit utiliser des fichiers ou un plugin.

Avant de l’exécuter, posez trois questions :

• le projet utilise-t-il déjà des fichiers de compétences suivis par le contrôle de version ?
• Claude Code gère-t-il déjà un plugin fournissant la même compétence ?
• la commande va-t-elle créer une seconde copie dans un autre emplacement ?

Si la réponse à la deuxième ou à la troisième question est oui, arrêtez-vous. Supprimez ou désactivez l’ancienne source selon une modification réversible, puis reprenez l’installation avec une seule méthode.

Livraison du nouveau Mac : la preuve avant le confort

Une migration est terminée lorsque quelqu’un d’autre peut comprendre et vérifier l’état du système. L’apparence familière de Cursor ou de Claude Code ne suffit pas.

Utilisez cette liste avant de remettre le Mac à son utilisateur :

• [ ] La source unique est écrite : fichiers du projet ou plugin.
• [ ] L’emplacement ou le mécanisme d’installation est documenté.
• [ ] Aucune compétence homonyme concurrente n’a été détectée.
• [ ] Les personnalisations attendues correspondent au dépôt ou au plugin validé.
• [ ] Cursor découvre la compétence attendue, si Cursor fait partie du scénario.
• [ ] Claude Code découvre la compétence attendue, si Claude Code fait partie du scénario.
• [ ] Une tâche réelle, mais réversible, a été exécutée.
• [ ] Le résultat et les fichiers touchés ont été conservés.
• [ ] Une nouvelle session confirme que l’état persiste.
• [ ] Les fichiers utilisateur, caches, secrets et réglages non documentés ne sont pas utilisés comme preuve de livraison.

Cette procédure couvre aussi la migration d’un Mac temporaire. Après destruction, recréez l’environnement depuis le dépôt ou réinstallez le plugin. Si la reconstruction échoue, vous avez alors un défaut explicite à corriger, plutôt qu’un état caché à préserver.

Retour arrière : revenir à une seule version validée

Si la nouvelle installation produit une liste incohérente ou deux compétences homonymes, n’ajoutez pas une troisième commande pour « réparer » la situation. Revenez à la dernière version du dépôt qui fonctionnait ou restaurez le plugin seul, selon l’ancien état validé.

Pour une version fichier, restaurez le commit de référence, supprimez les fichiers ajoutés hors contrôle et relancez l’initialisation. Pour un plugin, retirez la copie fichier concurrente, vérifiez l’état du plugin et répétez le test après redémarrage. Le retour arrière doit modifier une seule variable à la fois.

Vous trouverez les procédures générales de compte et d’assistance dans le centre d’aide MacHTML, mais la décision de source reste une décision de projet. Une page d’aide ne peut pas déterminer si votre équipe doit conserver une compétence modifiée dans son dépôt.

Pourquoi un Mac temporaire peut être préférable à votre ancien poste cloné

Un ancien Mac cloné conserve souvent des caches, des droits personnels, des chemins absolus et des installations dont le projet ne dépendait pas officiellement. Cette méthode semble rapide, mais elle rend la prochaine migration plus difficile et masque les fichiers réellement nécessaires.

Un Mac temporaire correctement initialisé impose au contraire une preuve : le dépôt doit contenir ce qui est requis, le plugin doit être identifiable et la compétence doit réussir un test après reconstruction. Vous perdez le confort d’une copie intégrale, mais vous gagnez une procédure reproductible, particulièrement utile pour une équipe qui alterne entre développement, audio, vidéo et design.

Si votre besoin est seulement de tester pendant une courte période Cursor et Claude Code, choisissez l’environnement selon la durée et la stabilité attendues plutôt que selon l’habitude de l’ancien poste. Le guide MacHTML sur le choix entre environnement Mac temporaire et Mac durable vous aidera à cadrer cette décision. La location d’un Mac MacHTML devient pertinente lorsque vous devez obtenir rapidement un environnement isolé, le reconstruire proprement et éviter les dépendances d’une machine personnelle ; elle l’est moins pour une charge lourde permanente ou pour un travail exigeant un accès physique continu à des périphériques.

Une fois la source unique choisie, la migration de Cursor Agent Skills vers Claude Code n’est donc pas une copie de disque. C’est une livraison contrôlée : dépôt versionné si vous devez modifier et auditer les fichiers, plugin seul si Claude Code doit gérer le paquet, puis validation sur une session neuve. C’est cette discipline qui rend un nouveau Mac ou un Mac temporaire réellement exploitable.

Pour aller plus loin: Installer et versionner Cursor Agent Skills dans un projet Comparer Cursor et Claude Code selon la charge de travail sur Mac Choisir entre éditeur, agent terminal et environnement isolé pour coder avec l’IA