agent-config : unifier les skills et les règles de gouvernance entre plusieurs outils d'IA, avec un endpoint MCP en lecture seule auto-hébergé

agent-config distribue un ensemble de skills, rules, commands, guidelines et personas via npm et les projette dans la configuration native de chaque outil d'IA pris en charge, conformément au standard ouvert Agent Skills ; le même contenu de gouvernance peut aussi être exposé depuis votre propre Cloudflare Worker sous forme d'endpoint MCP. Ce n'est pas un agent runtime : la boucle d'agent, la répartition des LLM et l'orchestration des outils restent côté outil hôte. Il résout un problème très concret — un seul jeu de skills et de règles de gouvernance, sans devoir le reconfigurer dans chaque outil.

À qui il s'adresse

• Aux développeurs et équipes qui passent d'un outil d'IA à l'autre et veulent garder des skills et des règles de gouvernance cohérents : la couche de contenu se projette dans la configuration native d'outils hôtes comme Claude Code, Augment, Cursor, Cline, Windsurf, Gemini CLI ou Copilot — maintenue une seule fois, utilisée partout.
• Aux particuliers et équipes qui ont besoin d'un endpoint MCP auto-hébergé : le contenu de gouvernance est servi depuis votre propre Cloudflare Worker, et n'importe quel client MCP — Claude Desktop, Claude Code, Cursor, Zed, Continue, agents hébergés, etc. — y accède via HTTP, sans devoir maintenir une copie dans chaque client.
• Pas fait pour servir d'agent runtime : il n'exécute aucune boucle d'agent et ne prend en charge ni la répartition des LLM ni l'orchestration des outils ; si vous cherchez un service qui exécute des tâches et répartit les modèles à votre place, ces capacités vivent dans l'outil hôte.
• Pas fait pour qui attend un service local prêt à l'emploi : le serveur local stdio intégré exige un checkout local et ne s'utilise pas dès l'installation.
• Prérequis : Node ≥ 18 ; les autres exigences système ne figurent pas dans les preuves et restent non confirmées.

Votre premier essai en 3 minutes

Un seul chemin principal : la commande d'installation canonique officielle, plus une vérification des répertoires globaux.

1. Prérequis : Node ≥ 18 est installé sur la machine.
2. Exécutez la commande canonique officielle dans un terminal : npx @event4u/agent-config init.
3. Avant l'exécution, ayez clairement en tête les effets de bord : init n'écrit que dans des répertoires globaux — ~/.event4u/agent-config/, ~/.claude/, ~/.cursor/, etc. ; il n'écrit aucun fichier de projet, et le project scope est réservé aux mainteneurs. C'est une écriture d'état locale, pas une soumission distante ; les preuves ne décrivent aucun moyen d'annulation ni de retour arrière — en cas de doute sur l'impact, sauvegardez ces répertoires avant d'exécuter.
4. Signaux de succès : une fois la commande terminée, les répertoires globaux ci-dessus contiennent des données écrites, et la configuration native des outils pris en charge laisse voir les skills, rules, commands, guidelines et personas projetés. Pour vérifier d'abord le périmètre, consultez directement les fichiers de ces répertoires globaux.

La voie serveur n'est qu'une mention secondaire : après avoir déployé votre propre Cloudflare Worker, le contenu de gouvernance devient accessible aux clients sous forme d'endpoint MCP. Les preuves confirment la capacité, mais ne donnent ni commandes de déploiement ni extraits de configuration ; les étapes concrètes restent non confirmées. C'est une action de configuration distante — ne la comptez pas parmi les étapes obligatoires d'une prise en main rapide. Au premier contact, privilégiez les petits outils en lecture seule (comme memory_lookup et list_*) : « lecture seule » signifie seulement qu'aucune opération d'écriture n'est exécutée ; cela ne veut pas dire qu'il n'existe pas d'autres risques, et on ne peut pas en déduire l'absence d'accès réseau ou de lecture de données locales.

Cas d'usage

Cas 1 : faire partager à Claude Code et Cursor le même jeu de compétences et de règles. Garder deux configurations d'outils distinctes finit par créer des écarts. Sur une machine avec Node ≥ 18, exécutez npx @event4u/agent-config init et laissez-le écrire la couche de contenu dans les répertoires globaux. Résultats attendus dans le périmètre des preuves : ~/.event4u/agent-config/, ~/.claude/, ~/.cursor/ et d'autres répertoires reçoivent les écritures, le contenu suit le standard ouvert Agent Skills et les fichiers de vos projets restent intacts ; ensuite, les deux outils lisent le même jeu de skills et de rules dans leur configuration native. Selon la description officielle, la projection vise chaque outil pris en charge, pas seulement les deux cités ici en exemple. Moment opportun : quand les compétences et les règles des deux outils ont évolué séparément et divergent, et que vous voulez qu'un contenu unique fasse foi. Limite : cela ne règle que la distribution du contenu et n'exécutera aucune compétence à votre place dans les outils.

Cas 2 : auto-héberger un endpoint MCP de gouvernance en lecture seule. L'équipe veut que plusieurs clients lisent un contenu de gouvernance unifié via HTTP, sans installation sur chaque machine. Servez-le depuis votre Cloudflare Worker sous forme d'endpoint MCP : le contenu de gouvernance est exposé sous forme de MCP prompts et resources — skills, commands, rules, guidelines, contexts — accompagné des outils en lecture seule memory_lookup, chat_history_read et list_* ; des clients MCP comme Claude Desktop, Claude Code, Cursor, Zed, Continue et les agents hébergés peuvent y accéder via HTTP. Résultat observable : une fois connecté, le client voit ce contenu de gouvernance dans ses listes de prompts et de resources, et peut appeler les outils en lecture seule cités. À anticiper également : le Worker n'exécute pas les ~112 scripts Python (linters, audits, task ci, work-engine hooks) ; ceux-ci exigent une installation locale selon le Quickstart. Les étapes de déploiement du Worker ne figurent pas dans les preuves — on ne peut confirmer que la déclaration officielle de cette capacité.

Limites d'usage

• Nature lecture/écriture : le côté Worker est en lecture seule — le contenu de gouvernance est fourni sous forme de prompts et de resources, et les outils se limitent à de petits outils en lecture seule comme memory_lookup, chat_history_read et list_* ; aucun outil d'écriture n'est mentionné côté officiel. init est une écriture locale, limitée aux répertoires globaux, sans toucher aux dépôts de projet. Les outils en lecture seule prouvent seulement l'absence d'opérations d'écriture ; accès réseau ou lecture de données locales : les preuves n'en disent rien.
• Effets de bord et points de contrôle : init écrit dans ~/.event4u/agent-config/, ~/.claude/, ~/.cursor/, etc. ; le project scope étant réservé aux mainteneurs, une installation normale ne modifie aucun de vos dépôts de projet. Les preuves ne décrivent ni annulation ni rollback automatiques, et ne listent pas les fichiers écrits.
• Limites officielles : le Worker n'exécute pas les ~112 scripts Python (linters, audits, task ci, work-engine hooks), qui exigent une installation locale selon le Quickstart ; le serveur local stdio intégré n'est présent dans la Glama MCP Registry qu'à des fins de découverte et exige un checkout local (voir ADR-067).
• Vérification des voies : pour distribuer le contenu dans les outils, init ; pour lire le contenu de gouvernance via MCP, le Worker ; pour exécuter les scripts Python, une installation locale selon le Quickstart, puis l'exécution sur place.
• Encore non confirmé : commandes de déploiement et extraits de configuration du Worker, configuration de connexion propre à chaque client, exigences système complètes au-delà de Node ≥ 18. Les preuves ne couvrent pas ces points — avant de vous lancer, prenez le dépôt officiel pour référence.