Centraliser ses skills et ses serveurs MCP quand on utilise plusieurs agents IA

Utiliser plusieurs agents IA pour coder est devenu assez courant. Claude Code, Codex, Cursor, Gemini CLI ou encore GitHub Copilot ont chacun leurs qualités, leurs modèles et leurs limites d’utilisation.

Passer d’un agent à l’autre permet de choisir le bon outil selon la tâche, mais cela crée aussi un problème assez concret : chaque agent possède ses propres conventions et ses propres répertoires de configuration.

Un skill installé pour Claude Code ne sera pas forcément visible dans Codex. Un serveur MCP déclaré dans la configuration de Cursor devra être ajouté une seconde fois ailleurs. Même les instructions du projet peuvent changer de fichier selon l’agent utilisé.

C’est précisément le problème que j’ai voulu résoudre avec MyOwnSkillsHub.

Le code ne dépend pas uniquement du prompt

Quand on parle d’agent IA, on se concentre souvent sur le modèle ou sur la manière de rédiger le prompt. Pourtant, la qualité du résultat dépend aussi beaucoup de l’environnement mis à sa disposition.

Cet environnement contient généralement :

• les fichiers d’instructions du projet, comme AGENTS.md ou CLAUDE.md ;
• les skills qui décrivent des méthodes de travail spécialisées ;
• les serveurs MCP qui donnent accès à des outils et à des sources externes ;
• le contexte du projet, sa structure et ses conventions.

Autrement dit, changer d’agent ne consiste pas seulement à ouvrir une autre interface. Il faut aussi retrouver un environnement de travail cohérent.

C’est là que les choses se compliquent.

Chaque provider utilise ses propres dossiers

Les agents utilisent des structures proches, mais rarement identiques.

Codex recherche par exemple ses skills globaux dans :

~/.codex/skills
~/.agents/skills

Dans un projet, il utilise notamment :

.agents/skills

Claude Code utilise plutôt :

~/.claude/skills
.claude/skills

Cursor, Gemini CLI, Cline, Kiro ou Zed ont encore d’autres emplacements.

Le même problème existe pour les configurations MCP. Codex utilise un fichier TOML, tandis que plusieurs autres outils reposent sur du JSON. Le nom de la propriété racine, la structure du serveur et l’emplacement du fichier changent également selon le provider.

Maintenir ces configurations à la main devient vite pénible. Il faut se souvenir des chemins, éviter d’écraser un dossier existant et vérifier régulièrement quels projets disposent de quels outils.

MyOwnSkillsHub, un inventaire local de votre environnement IA

MyOwnSkillsHub est une application locale distribuée sous la forme d’un package npm.

Elle scanne les répertoires documentés des différents providers installés sur la machine, puis construit un inventaire des skills, des projets et des serveurs MCP détectés.

L’application reconnaît actuellement 16 providers intégrés, parmi lesquels :

• Codex ;
• Claude Code ;
• Gemini CLI ;
• GitHub Copilot ;
• OpenCode ;
• Cline ;
• Roo Code ;
• Kiro ;
• Kimi Code ;
• Cursor ;
• Pi ;
• Windsurf ;
• Amp ;
• Zed ;
• Qwen Code ;
• Warp.

IMG_REF // Différents providers proposés

Il est également possible d’ajouter un provider personnalisé en indiquant son dossier global et son dossier de projet.

Dans le code, chaque provider est représenté par un adaptateur. Cet adaptateur décrit les emplacements à scanner et, lorsque c’est possible, le format de sa configuration MCP.

Cette séparation permet de conserver les conventions de chaque outil. MyOwnSkillsHub ne cherche pas à imposer un nouveau dossier commun à tous les agents.

Comment fonctionne le scan des skills

Le système de fichiers reste la source de vérité. L’application ne crée pas de base de données pour recopier l’état de vos installations.

Pendant un scan, elle parcourt les dossiers globaux et les dossiers associés aux projets. Un skill est reconnu lorsqu’un fichier SKILL.md est présent dans son répertoire.

Les métadonnées disponibles dans ce fichier sont ensuite utilisées pour afficher son nom, sa description et ses différentes installations.

Le dossier partagé .agents/skills demande une attention particulière. Plusieurs providers peuvent l’utiliser, mais il ne doit être scanné qu’une seule fois. Sans cette déduplication, le même skill apparaîtrait plusieurs fois dans l’interface alors qu’il correspond au même dossier physique.

MyOwnSkillsHub sait aussi analyser un répertoire contenant plusieurs dépôts Git. Chaque sous-répertoire possédant un dossier .git peut alors être présenté comme un projet distinct.

Des racines supplémentaires peuvent être ajoutées depuis l’interface. Une racine peut représenter une bibliothèque de skills ou un ensemble de projets. Cette distinction évite de mélanger les skills disponibles comme sources avec ceux qui sont déjà installés dans un projet.

Copier un skill sans écraser l’existant

Lorsqu’un skill est disponible pour un provider mais absent chez un autre, l’application peut le copier vers le bon répertoire.

L’utilisateur sélectionne explicitement :

• le skill source ;
• le projet concerné, si la copie est locale ;
• les providers de destination.

Avant la copie, MyOwnSkillsHub calcule le chemin attendu à partir de l’adaptateur du provider cible.

Si le dossier existe déjà, il est ignoré. L’application ne fusionne pas son contenu et ne remplace aucun fichier automatiquement. Cette règle évite qu’une synchronisation supprime une version modifiée localement.

Il est possible de synchroniser un seul skill ou tous les skills déjà présents dans un projet. Le même principe s’applique dans les deux cas : seuls les dossiers manquants sont créés.

IMG_REF // Sync les skills

Une commande est également disponible pour effectuer une copie depuis le terminal :

myownskillshub copy <skill> --to <provider-id>

L’option --global permet de viser le dossier global du provider au lieu du projet courant.

Normaliser les configurations MCP

La gestion des serveurs MCP est plus complexe qu’une simple copie de dossiers.

Chaque provider peut utiliser un format différent. Codex stocke ses serveurs dans des sections TOML de type :

[mcp_servers.mon-serveur]
command = "..."
args = ["..."]

D’autres outils utilisent une propriété JSON comme mcpServers, mcp, context_servers ou une structure propre à leur fichier de paramètres.

MyOwnSkillsHub commence donc par convertir chaque définition vers une représentation interne commune. Celle-ci contient notamment le nom du serveur, son transport, sa commande, ses arguments et son URL lorsqu’il utilise HTTP.

Lors d’une copie, cette représentation est reconvertie vers le format natif du provider cible. L’application ne copie pas aveuglément un bloc JSON dans un fichier TOML.

Les configurations globales et les configurations de projet restent séparées. Un serveur installé globalement n’est pas considéré comme installé localement dans tous les projets, et inversement.

L’interface peut également détecter plusieurs configurations différentes pour un même serveur. Elle affiche alors les variantes trouvées et permet de choisir celle qui doit être conservée pour aligner les providers concernés.

IMG_REF // page d'un skill

Cette opération modifie uniquement la définition du serveur sélectionné. Les autres serveurs et les autres paramètres du fichier sont préservés.

Éviter la duplication entre AGENTS.md et CLAUDE.md

Les fichiers d’instructions posent un autre problème.

Codex et plusieurs agents compatibles utilisent AGENTS.md. Claude Code utilise nativement CLAUDE.md. Copier le même contenu dans les deux fichiers fonctionne, mais les instructions finissent facilement par diverger.

MyOwnSkillsHub utilise plutôt un fichier source et un pont de compatibilité.

Si le projet possède déjà un fichier AGENTS.md, l’application peut créer un CLAUDE.md qui importe ces instructions. Dans le sens inverse, elle peut créer un AGENTS.md demandant aux agents compatibles de lire CLAUDE.md.

Le fichier existant devient ainsi la source de vérité.

Cette opération reste volontairement prudente. Le pont n’est créé que si un seul des deux fichiers existe. Si le fichier cible est déjà présent, l’application refuse de le remplacer.

Il ne s’agit donc pas d’une synchronisation bidirectionnelle du contenu, mais d’un moyen d’éviter d’avoir deux copies à maintenir.

Une application locale et sans dépendance externe

Le package repose sur les modules natifs de Node.js et ne nécessite pas de framework côté serveur ou côté interface.

Lorsque la commande suivante est exécutée :

myownskillshub

un serveur HTTP local démarre par défaut sur :

http://127.0.0.1:4173

Le navigateur s’ouvre ensuite automatiquement.

L’interface est écrite en JavaScript natif et communique avec une API locale. Les scans restent en lecture seule. Les copies ou les modifications de configuration correspondent toujours à une action explicite de l’utilisateur.

Les quelques informations propres à l’application sont enregistrées dans des fichiers JSON locaux. Ils contiennent notamment :

• les répertoires ajoutés par l’utilisateur ;
• les providers activés ;
• les providers personnalisés ;
• les préférences d’apparence ;
• les tags associés aux skills.

Les tags sont liés au nom du dossier du skill. Deux copies du même skill peuvent donc partager les mêmes tags, même si elles se trouvent chez des providers différents.

Utiliser MyOwnSkillsHub

L’installation globale tient en une commande :

npm install -g myownskillshub

L’application peut ensuite être lancée avec :

myownskillshub

Quelques commandes permettent aussi de consulter l’inventaire sans ouvrir l’interface :

myownskillshub list
myownskillshub providers
myownskillshub roots

Pour mettre le package à jour :

npm install -g myownskillshub@latest

MyOwnSkillsHub ne remplace ni les skills ni les mécanismes propres à chaque agent. Il fournit une vue commune sur ce qui existe déjà sur la machine et facilite les opérations qui deviennent répétitives dès que l’on utilise plusieurs outils.

Le package est disponible sur npm.