Exporter vos propres éléments

Vous avez écrit un skill, un agent, une commande, une règle ou un serveur MCP pour Claude Code, Codex ou Cursor, et vous voulez que votre équipe l'ait. rmk export le lit, écrit le ronne.yaml qui lui manque, vous montre tout ce qu'il téléverserait et crée ici un brouillon privé : un nouvel élément, ou une proposition de changement quand il modifie un élément publié. Vous le vérifiez dans l'application web et le soumettez à la revue comme n'importe quel autre brouillon.

rmk export                          # lists what it finds here
rmk export secure-coding --to @platform
rmk export github --type mcp-server --to @platform --description "GitHub's issues and pull requests."

rmk export ne fait que lire : il ne modifie jamais vos fichiers, et il ne soumet jamais rien.

Il regarde là où chaque outil garde chaque type, dans le projet ou, avec --scope user, dans votre dossier personnel (sous-dossiers compris) :

• skills : les dossiers contenant un SKILL.md dans .claude/skills/, et dans .agents/skills/, que Codex et Cursor partagent;
• Claude Code : les agents, les commandes et les règles en Markdown dans .claude/agents/, .claude/commands/ et .claude/rules/; les serveurs MCP dans .mcp.json, ou au premier niveau de ~/.claude.json;
• Codex : les agents dans .codex/agents/*.toml, et les serveurs MCP sous mcp_servers dans .codex/config.toml;
• Cursor : les agents dans .cursor/agents/, les règles dans .cursor/rules/*.mdc (projets seulement), les commandes dans .cursor/commands/, et les serveurs MCP dans .cursor/mcp.json.

Le serveur ronne-registry qu'ajoute rmk mcp-setup n'est jamais listé. Les règles écrites dans AGENTS.md, les hooks et les réglages de permissions ne sont pas lus, pas plus que l'ancien .cursorrules de Cursor ou les prompts personnalisés de Codex. Quand le même nom désigne un élément dans deux outils, précisez lequel avec --from.

Vous nommez ce qu'il faut exporter, ou vous donnez son chemin (le dossier d'un skill, ou le fichier d'un agent, d'une commande ou d'une règle). Un skill, c'est son dossier : chaque fichier qu'il contient est téléversé, les scripts restant exécutables, sauf :

• Jamais inclus dans un élément : .git/, .hg/, .svn/, node_modules/, __pycache__/, .DS_Store, Thumbs.db, .ronne/.
• Secrets probables : .env, .env.*, *.pem, *.key, id_rsa*, .npmrc, .netrc.
• Les liens symboliques dans le dossier, qui ne sont jamais suivis.

Un fichier qui contient quelque chose qui est à coup sûr un secret, comme la clé d'API d'un fournisseur, arrête cet élément : le fichier est nommé, la valeur n'est pas affichée. Retirez-le (utilisez plutôt une variable d'environnement), ou ajoutez --force. Un dossier qui dépasse les limites de téléversement (500 fichiers, 1 Mo par fichier, 20 Mo en tout) est arrêté lui aussi.

ronne.yaml est construit à partir du frontmatter de SKILL.md : sa description (sur une ligne, et coupée à 300 caractères, avec un avertissement) et sa license. Un ronne.yaml que vous avez écrit dans le dossier est utilisé à la place, seul son name étant défini. Quand le name de SKILL.md n'est pas le nom de l'élément, la copie téléversée le reçoit; votre fichier reste tel quel.

Chaque élément est @scope/name, et seul root crée les portées, donc vous en choisissez une qui existe : --to @team, ou la portée du ronne.yaml du dossier lui-même, ou, dans un terminal, dans la liste qu'affiche rmk. Il n'en choisit jamais une à votre place.

Le nom est celui qu'utilise votre outil d'IA : le name d'un skill ou d'un agent, le nom de fichier d'une commande ou d'une règle (avec son sous-dossier : review/diff.md devient review-diff), ou la clé d'un serveur MCP. Quand ce n'est pas un nom d'élément valide, il est transformé en un nom valide, en minuscules avec des traits d'union (My Skill! devient my-skill). --name en définit un autre, pour un élément. Si deux éléments portent le même nom, comme un skill et une commande appelés review, précisez lequel avec --type; si deux outils l'ont, avec --from; ou donnez le chemin.

Avant que quoi que ce soit ne quitte votre machine, la question affiche, pour chaque élément :

• le registre et le compte avec lequel vous êtes connecté, ainsi que le nom et le type de l'élément;
• chaque fichier avec sa taille, et chaque fichier laissé de côté, avec la raison;
• le ronne.yaml qu'il a construit, et ses avertissements : chaque chose que l'élément perd du format de votre outil, par son nom;
• ce dont il dépend, et si chaque dépendance est exportée avec lui ou déjà publiée;
• ce que trouvent les vérifications, à corriger dans l'application web avant de soumettre;
• pour une proposition de changement, la version de départ, ce qu'elle change, et si une version plus récente est sortie;
• la description de chaque élément et sa provenance : ses fichiers, vous, votre outil d'IA, la version sur laquelle il est basé, ou votre brouillon (voir Descriptions);
• quand vous avez déjà un brouillon de l'élément, Updates your draft, avec son adresse : voir Exporter de nouveau.

Ensuite, il demande Upload n item(s) as drafts?, et rien n'est envoyé à moins que vous ne répondiez oui.

Chaque élément a besoin d'une description : une ligne, d'au plus 300 caractères, qui dit ce qu'il fait. C'est ce que les gens lisent dans le catalogue et ce que les outils d'IA utilisent pour décider quand se servir de l'élément. rmk export la prend dans les fichiers de l'élément lui-même quand ils en ont une, comme description dans le frontmatter d'un skill, d'un agent ou d'une commande. Sinon, il la demande :

• Dans un terminal, pour chaque élément : tapez une phrase, ou appuyez sur Entrée pour prendre sa première ligne s'il en a une.
• Depuis votre outil d'IA, l'assistant lit l'élément et en écrit une, et le plan l'affiche comme written by your AI tool avant que quoi que ce soit ne soit téléversé.
• Sans terminal, fournissez-les avec --describe style="Tabs, not spaces." (une fois par élément) ou --descriptions descriptions.json, un objet qui associe chaque élément à son texte.

Une règle Claude Code, et une règle Cursor sans description, n'ont que leur première ligne, et un serveur MCP n'a rien sur le disque, donc la question est toujours posée pour eux. Une première ligne est seulement proposée, jamais utilisée d'office : c'est souvent un titre. Un élément sans description n'est pas téléversé. Une proposition de changement garde la description de la version sur laquelle elle est basée, et exporter de nouveau garde celle de votre brouillon quand l'élément n'en a toujours pas.

La description va dans ronne.yaml et, pour un skill, aussi dans le frontmatter du SKILL.md téléversé, où les outils d'IA la lisent. Vos fichiers ne sont pas modifiés. Pour la changer plus tard, modifiez-la dans l'éditeur web, ou ajoutez-en une à votre fichier et exportez de nouveau.

Les fichiers propres à un outil peuvent exprimer des choses qu'un élément portable ne peut pas exprimer. Chaque chose laissée de côté devient un avertissement dans l'aperçu, par son nom, pour que vous décidiez avant de téléverser. Pour Claude Code :

Pour Codex et Cursor :

Un modèle nommé par un agent Codex ou Cursor est gardé pour cet outil seulement, qui continue donc de s'en servir; les autres outils utilisent leur modèle par défaut.

Une description est une ligne d'au plus 300 caractères. Celle d'un agent ou d'une commande, si elle est plus longue, est coupée, et le texte coupé est ce que lit Claude Code une fois l'élément installé. Les règles et les serveurs MCP n'en apportent jamais une à eux, donc ils en ont toujours besoin : voir Descriptions.

Serveurs MCP : les noms, jamais les valeurs. Les valeurs de l'env d'un serveur ne sont jamais téléversées; chacune devient une variable que l'élément déclare, marquée comme secrète quand elle ressemble à un identifiant, et la personne qui l'installe la définit. Un jeton écrit dans un en-tête, un argument ou l'adresse est retiré et remplacé par une variable comme ${GITHUB_TOKEN}; l'aperçu indique où. Si un identifiant ne peut pas être distingué du texte qui l'entoure, le serveur n'est pas exporté : déplacez-le d'abord dans une variable d'environnement. Un serveur n'a pas de description sur le disque, donc rmk export en demande une : voir Descriptions.

Un élément en utilise souvent d'autres : un agent charge des skills, et les agents, les skills et les commandes appellent des serveurs MCP au moyen de leurs outils. rmk export les trouve, les suit de proche en proche (un agent qui charge un skill qui utilise un serveur a besoin des deux), et dit ce qu'est chacun :

• à vous : un élément que vous avez écrit ici, pas encore dans le registre;
• installé : rmk l'a installé, donc l'élément dépend de cet élément du registre à la version que vous avez. Rien n'est téléversé pour lui;
• déjà publié : à vous, mais la portée a déjà un élément publié de ce nom et de ce type, donc l'élément dépend de celui-ci au lieu d'une copie;
• ne peut pas être déclaré : intégré à l'outil, issu d'un plugin, situé quelque part que l'exportation ne lit pas, ou une paire que les types ne permettent pas. Un avertissement le nomme.

Quand certains sont à vous, il demande quoi en faire :

1. Export them too (recommandé) : les exporter aussi. Chacun devient son propre brouillon, téléversé en premier, et l'élément les déclare à ^1.0.0, la première version. Sans eux, l'élément ne fonctionnera pas pour la personne qui l'installe.
2. Export without them : l'élément seulement, qui pourrait ne pas fonctionner là où ils manquent. Ceux qui sont installés restent déclarés.
3. Cancel.

Sans terminal, choisissez avec --with-deps ou --no-deps; depuis votre outil d'IA, l'assistant vous pose la question. Si un téléversement échoue, les éléments qui en dépendent ne sont pas envoyés.

L'ordre de soumission. Une dépendance doit être en revue avant ce qui l'utilise, donc rmk indique l'ordre : @team/github must be in review first: once it is ready, rmk submit @team/reviewer submits it first. Soumettre l'élément entraîne avec lui vos brouillons de dépendances, et ils sont publiés avant lui (Dépendances en revue). Pour les installer tous comme un seul élément, créez un lot sur le canevas.

Chaque élément arrive comme brouillon sous Submissions, que vous seul voyez, et rmk affiche son adresse et ce qu'il reste à corriger. Ouvrez-le, corrigez ce que signalent les vérifications, et soumettez-le : à partir de là, il suit la revue habituelle.

Pour en soumettre plusieurs à la fois, rmk submit --all --dry-run montre ceux qui sont prêts, et rmk submit --all les soumet (voir Soumettre en bloc); un élément et ses dépendances vont ensemble, donc il n'y a pas de tours à attendre. Une proposition de changement est revue comme n'importe quelle proposition et publiée comme version suivante de l'élément. Un brouillon créé ainsi compte dans les limites des jetons, et est inscrit au journal d'audit.

Vous avez continué d'y travailler dans votre outil d'IA? Exportez-le de nouveau : rmk cherche un brouillon à vous du même élément et le met à jour au lieu d'en créer un autre.

• Un brouillon, ou une soumission renvoyée pour changements : ses fichiers sont remplacés par ce que vous exportez, y compris les modifications que vous avez faites depuis dans l'application web. Si vous en avez plusieurs, c'est le plus récemment modifié. La mise à jour ne compte pas dans la limite de 50 brouillons. Une soumission renvoyée pour changements le reste : soumettez-la de nouveau dans l'application web.
• Une soumission en revue : on n'y touche pas, et rien n'est téléversé pour elle. Pour la modifier, retirez-la et archivez-la d'abord dans l'application web.
• Le même élément signifie le même nom et le même type et, pour une proposition de changement, la même version de base. Une proposition à partir d'une version plus récente, ou un brouillon d'un autre type, devient un nouveau brouillon; l'ancien reste.

L'aperçu indique Updates your draft avec son adresse avant que quoi que ce soit ne soit envoyé. Pour garder le brouillon tel quel et en créer un distinct, ajoutez --new-draft, ou demandez un brouillon distinct à l'assistant dans votre outil d'IA.

Un élément installé par rmk que vous avez modifié depuis, et une copie provenant d'un registre (un ronne.yaml avec un version), sont exportés comme une proposition de changement à cet élément. Il refuse, et dit pourquoi, dans ces cas :

• un élément qu'il a installé et que vous n'avez pas changé : il n'y a rien à exporter;
• un fichier écrit par rmk sans trace de l'installation, comme une règle ou une commande qu'il a écrite sous forme de skill : changez-les sur la page de l'élément, avec Propose a change;
• une copie de registre avec --force est plutôt exportée comme un nouvel élément, sans la version.

Quand ce que vous exportez est un changement à un élément publié, il arrive comme une proposition de changement à cet élément, et non comme un nouvel élément :

• un élément installé par rmk que vous avez modifié : basé sur la version que vous avez installée;
• une copie provenant d'un registre : basée sur la version que nomme son ronne.yaml;
• un élément à vous dont le nom est déjà publié dans la portée, avec le même type : basé sur sa version latest. C'est la boucle habituelle : exporter, publier, modifier, exporter de nouveau.

rmk télécharge la version de base et compare vos fichiers à ce que donne la base dans votre outil d'IA. Seul ce que vous avez changé est retenu; tout le reste demeure comme dans la base, y compris ce que les fichiers de votre outil ne peuvent pas exprimer, comme les mots-clés, la licence ou les dépendances. Une modification que l'élément ne peut pas porter (un réglage que seul votre outil possède) ne laisse rien à proposer, et rmk le signale.

L'aperçu affiche Proposal to @team/reviewer, from 1.2.0 et ce qui change : les fichiers ajoutés, retirés et modifiés, et chaque champ de ronne.yaml, ancien et nouveau. Si l'élément a une version plus récente, la proposition arrive périmée : rebasez-la dans l'application web. Elle est revue comme n'importe quelle proposition et publiée comme version suivante de l'élément. Pour l'exporter plutôt comme un nouvel élément, ajoutez --new (et --name pour un autre nom).

Une fois le serveur MCP du registre configuré, vous pouvez plutôt le demander à votre outil d'IA : « exporte mon agent deploy-check vers le marketplace ». L'assistant :

1. liste ce qu'il trouve et à qui appartient chaque élément (list_local_items);
2. vous demande quelle portée utiliser, dans la liste de ce marketplace : il ne peut pas en choisir une à votre place;
3. s'il utilise des éléments à vous, vous les montre et demande s'il faut les exporter aussi, en le recommandant;
4. montre le plan : le nom, chaque fichier avec sa taille, ce qui est laissé de côté et pourquoi, et le ronne.yaml (plan_export, qui n'envoie rien);
5. une fois que vous l'avez vu, le téléverse (export_items, pour lequel votre outil vous demande votre accord) et vous donne l'adresse de chaque brouillon. Un brouillon à vous du même élément est mis à jour, à moins que vous n'en demandiez un distinct.
6. quand vous le demandez, soumet à la revue ceux qui sont prêts (check_drafts, puis submit_drafts) : voir Soumettre en bloc.

Il n'exporte que les éléments trouvés dans les dossiers de vos outils d'IA : les vôtres, et ceux installés que vous avez modifiés, comme propositions de changement. Pour un élément qui ne se décrit pas lui-même, l'assistant écrit la description à partir de son contenu et l'affiche dans le plan. Un fichier ou un dossier situé ailleurs, et --force, sont réservés à rmk export dans un terminal.