Éléments et types

Les skills, agents, commandes, règles et serveurs MCP que vous avez déjà écrits pour Claude Code peuvent être envoyés ici comme brouillons avec rmk export. Les autres types (hooks, politiques de permissions, lignes d'état, serveurs LSP, styles de sortie et lots) se créent ici, avec New item.

Certains types s'appuient sur d'autres et les listent sous dependencies dans leur manifeste, chacun avec une plage de versions comme ^1.0.0. Installer l'un d'eux installe ce dont il dépend.

• bundle

  Apporte n'importe quoi

  Un lot peut dépendre d'éléments de tout type, y compris d'autres lots, tant que rien ne ramène à lui-même. C'est ainsi qu'une équipe partage un ensemble de départ.

  bundle → tout type

• agent

  Apporte ses parties

  Peut dépendre des éléments qu'il utilise : skill, mcp-server, hook, rule, command.

  agent → skill, mcp-server, hook, rule, command

• skillcommand

  Apportent ce qu'ils utilisent

  Peuvent dépendre de mcp-server, installé avec eux.

  skill, command → mcp-server

• rulehookmcp-serverpermission-policyoutput-stylestatuslinelsp-server

  Autonome

  Ces types ne peuvent pas avoir de dépendances : chacun s'installe seul.

  rule, hook, mcp-server, permission-policy, output-style, statusline, lsp-server → rien

À la soumission, chaque dépendance doit être permise pour le type et publiée avec une version dans sa plage, ou en revue, sans cycle.

En ajouter une

• Dans le formulaire : tapez une partie de son nom, comme @team/gi ou github, dans Add a dependency, et choisissez-la dans la liste. La liste contient les éléments publiés, les vôtres (brouillons, en revue, approuvés) et ceux des autres en revue, uniquement des types dont celui-ci peut dépendre.
• La version commence à latest, écrite comme ^ suivi de la version vers laquelle l'étiquette pointe maintenant, car une plage ne peut pas nommer une étiquette; choisissez-en une autre dans la liste au besoin. Un élément pas encore publié reçoit ^1.0.0, sa première version.
• Dans un fichier Markdown, comme SKILL.md ou le prompt d'un agent : tapez @ et une partie d'un nom, puis choisissez-en un. Son nom va dans le texte et il est ajouté aux dépendances. Supprimer le texte plus tard ne le retire pas : faites-le dans le formulaire ou sur le canevas.
• Comme pour toute modification, rien n'est enregistré avant Save. Une plage tapée à la main est écrite quand vous quittez le champ.

Comment une installation choisit les versions

Une installation obtient une version de chaque élément : la plus haute qui respecte toutes les plages qui la demandent, que vous ayez demandé l'élément vous-même ou que quelque chose que vous avez demandé en dépende. Les versions retirées (yanked) sont ignorées, et une plage ne choisit une préversion que si elle en nomme une (^1.1.0-beta.1, pas ^1.0.0).

Si aucune version ne respecte toutes les plages, l'installation s'arrête et indique quelles plages sont en désaccord et qui a demandé chacune, comme ^1.0.0 (the request) et ^2.0.0 (@platform/[email protected]). La solution est d'élargir une plage, ou de publier une version qui convient aux deux.

Un élément exporté avec rmk export reçoit ses dépendances remplies d'après ce qu'il utilise, comme les skills qu'un agent charge : Exporter vos propres éléments.

Un agent ou un lot, c'est surtout les éléments qu'il utilise; son brouillon montre donc ronne.yaml d'une troisième façon, à côté de Form et YAML : Canvas. Le brouillon est le nœud au centre, et chaque dépendance est un nœud relié à lui, avec son type, la version que liste le catalogue, les outils d'IA où elle fonctionne et sa plage.

• Ajouter : cherchez dans le catalogue sous le canevas. Il propose les éléments publiés des types dont le brouillon peut dépendre. Add en place un sur le canevas avec la plage ^ suivie de sa version listée, comme ^1.4.0 (une préversion commence à cette version exacte); le glisser sur le canevas le place là où vous le déposez.
• Changer une plage : tapez-la dans le nœud, ou dans la liste sous le canevas. C'est une plage de versions comme ^1.0.0; une étiquette comme latest n'en est pas une.
• Retirer : le bouton × du nœud, ou sélectionnez le nœud et appuyez sur Suppr.
• Les problèmes s'affichent dans le nœud : ce que la soumission dirait de cette dépendance, par exemple qu'elle n'est pas publiée ou qu'aucune version ne respecte la plage.
• Sans souris : Tab atteint chaque nœud et ses champs, Entrée sélectionne un nœud et les flèches le déplacent; la liste sous le canevas contient toutes les dépendances, avec les mêmes champs.

Le canevas ne modifie que dependencies dans ronne.yaml : le formulaire et le YAML montrent la même chose, et les réviseurs le lisent comme des lignes dans le diff du fichier. La position des nœuds est conservée dans .ronne/layout.json, un fichier du brouillon. Il est exclu des diffs de revue et n'est pas publié, donc une proposition de changement commence avec les nœuds placés automatiquement.

La page d'un agent ou d'un lot publié montre le même canevas, en lecture seule, sous Overview.

Un élément est un petit dossier de fichiers. ronne.yaml, son manifeste, dit ce qu'il est; les autres fichiers sont son contenu, comme SKILL.md pour un skill. L'éditeur montre ronne.yaml sous forme de formulaire ou de YAML, et pour un agent ou un lot, aussi sous forme de canevas.

name: "@platform/secure-coding"
type: skill
description: Checks code for common security mistakes.
license: MIT
keywords: [security, review]
skill:
  entry: SKILL.md

• name et type correspondent à ceux du brouillon; l'éditeur les garde synchronisés.
• description est ce que montre le catalogue, et keywords aide la recherche à le trouver.
• Le bloc propre au type, skill: ici, dit comment l'outil l'utilise.
• Il n'y a pas de version : c'est la publication qui la fixe.

Les fichiers avec lesquels New item démarre, ronne.yaml et le fichier qu'il nomme (comme SKILL.md ou prompt.md), sont les fichiers de départ de l'élément : modifiez-les à votre guise, mais ils ne peuvent être ni renommés ni supprimés. Importer un .zip qui remplace les fichiers les conserve. Les autres fichiers vont et viennent comme d'habitude.

Chaque page d'élément montre ce qu'est l'élément avant que vous l'installiez : les fichiers de la version que vous consultez, exactement comme rmk install les obtient. Ils viennent du paquet publié et sont d'abord vérifiés avec sa somme de contrôle; les lire ne compte pas comme un téléchargement.

• Overview, où la page s'ouvre, résume l'élément sur un seul écran. En haut : ses téléchargements, son nombre de versions, le nombre d'outils où il fonctionne, et sa revue (qui a approuvé la version, et ce qu'elle peut faire sur votre machine). Ensuite Install, avec les deux commandes et un --target rapide pour chaque outil, et Capabilities and guardrails : ce qu'il peut faire, à côté des limites que fixe son propre ronne.yaml (la liste d'outils d'un agent, les globs d'une règle, les commandes bloquées d'une politique). Puis son fichier principal, à lire : le SKILL.md d'un skill, le prompt d'un agent (son instruction système), le corps d'une règle, d'une commande ou d'un style de sortie, ou le script d'un hook ou d'une ligne d'état. À côté : la somme de contrôle et la taille du paquet, sa configuration, les éléments qui l'utilisent, son propriétaire et son approbateur, et chaque fichier, chacun avec un lien vers lui dans Files.
• Les dépendances sur le canevas : un agent ou un lot montre les éléments qu'il utilise sur le même canevas que l'éditeur, en lecture seule. Chaque nœud mène à la page de cet élément.
• Files : chaque fichier de la version, ronne.yaml compris, dans une arborescence. Le Markdown est affiché rendu, avec les sauts de ligne conservés et son frontmatter sous forme de tableau; l'onglet Source montre le texte exactement tel qu'il est écrit. Les autres fichiers sont affichés comme du texte. Les fichiers binaires et les textes de plus de 512 Ko sont listés, mais pas affichés. Le fichier ouvert figure dans l'adresse, ce qui permet d'envoyer à quelqu'un un lien vers lui.

Une fois que l'utilisation d'un élément est signalée, ses deux premières cartes deviennent Installs et Runs sur 30 jours, Works in montre la part de chaque outil, et une carte Usage après Install trace les 14 derniers jours. Lire les chiffres les explique. Les exigences d'exécution et les versions signées ne sont pas encore affichées : le registre ne les recueille ni ne les stocke.

?version= fonctionne ici aussi, versions retirées comprises. Si le paquet d'une version manque ou ne correspond pas à sa somme de contrôle, la page l'indique au lieu d'afficher quoi que ce soit : prévenez un administrateur.