Items and types

Skills, agents, commands, rules and MCP servers you already wrote for Claude Code can be sent here as drafts with rmk export. The other types (hooks, permission policies, status lines, LSP servers, output styles and bundles) are made here, with New item.

Some types build on others, and list them under dependencies in their manifest, each with a version range such as ^1.0.0. Installing one installs what it depends on.

• bundle

  Brings anything

  A bundle may depend on items of any type, other bundles included, as long as nothing leads back to itself. It's how a team shares a starter set.

  bundle → any type

• agent

  Brings its parts

  May depend on the items it uses: skill, mcp-server, hook, rule, command.

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

• skillcommand

  Bring what they use

  May depend on mcp-server, installed with them.

  skill, command → mcp-server

• rulehookmcp-serverpermission-policyoutput-stylestatuslinelsp-server

  Stands alone

  These types can't have dependencies: each is installed on its own.

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

At submit, each dependency must be allowed for the type and published with a version in its range, or in review, with no cycles.

Adding one

• In the form: type part of its name, such as @team/gi or github, in Add a dependency, and pick it from the list. The list has published items, yours (drafts, in review, approved), and others' in review, only of the types this one may depend on.
• The version starts on latest, written as ^ and the version it points to now, since a range can't name a tag; pick another from the list if you need one. An item that isn't released yet gets ^1.0.0, its first release.
• In a markdown file, such as SKILL.md or an agent's prompt: type @ and part of a name, and pick one. Its name goes in the text and it's added to the dependencies. Deleting the text later doesn't remove it: do that in the form or on the canvas.
• Like every edit, nothing is saved until Save. A range typed by hand is written when you leave the field.

How an install picks versions

An install gets one version of each item: the highest one that fits every range asking for it, whether you asked for the item yourself or something you asked for depends on it. Yanked versions are skipped, and a range only picks a pre-release when it names one (^1.1.0-beta.1, not ^1.0.0).

If no version fits every range, the install stops and says which ranges disagree and who asked for each, such as ^1.0.0 (the request) and ^2.0.0 (@platform/[email protected]). The fix is to widen a range, or to release a version that fits both.

An item exported with rmk export gets its dependencies filled in from what it uses, such as the skills an agent loads: Exporting your own items.

An agent or a bundle is mostly the items it uses, so its draft shows ronne.yaml a third way, next to Form and YAML: Canvas. The draft is the node in the centre, and each dependency is a node joined to it, with its type, the version the catalogue lists, the AI tools it works in, and its range.

• Add: search the catalogue under the canvas. It offers published items of the types the draft may depend on. Add puts one on the canvas with the range ^ and its listed version, such as ^1.4.0 (a pre-release starts on that exact version); dragging it onto the canvas puts it where you drop it.
• Change a range: type it in the node, or in the list under the canvas. It's a version range such as ^1.0.0; a tag such as latest isn't one.
• Remove: the node's × button, or select the node and press Delete.
• Problems show in the node: what submitting would say about that dependency, such as that it isn't published or no version fits the range.
• Without a mouse: Tab reaches each node and its fields, Enter selects a node and the arrow keys move it; the list under the canvas has every dependency, with the same fields.

The canvas changes only dependencies in ronne.yaml: the form and the YAML show the same thing, and reviewers read it as lines in the file's diff. Where you put the nodes is kept in .ronne/layout.json, a file of the draft. It's left out of review diffs and isn't released, so a change proposal starts with the nodes placed automatically.

A released agent's or bundle's page shows the same canvas, read-only, on its Overview.

An item is a small folder of files. ronne.yaml, its manifest, says what it is; the other files are its content, such as SKILL.md for a skill. The editor shows ronne.yaml as a form or as YAML, and an agent's or a bundle's also as a canvas.

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

• name and type match the draft's; the editor keeps them in step.
• description is what the catalogue shows, and keywords help search find it.
• The type's own block, skill: here, says how the tool uses it.
• There's no version: the release sets it.

The files New item starts with, ronne.yaml and the file it names (such as SKILL.md or prompt.md), are the item's starting files: edit them as you like, but they can't be renamed or deleted. Importing a .zip that replaces the files keeps them. Other files come and go as usual.

Every item page shows what the item is before you install it: the files of the version you're looking at, exactly as rmk install gets them. They come from the released package and are checked against its checksum first; reading them isn't counted as a download.

• Overview, where the page opens, sums the item up on one screen. At the top: its downloads, how many versions it has, how many tools it works in, and its review (who approved the version, and what it can do on your machine). Then Install, with both commands and a quick --target for each tool, and Capabilities and guardrails: what it can do, beside the limits its own ronne.yaml sets (an agent's tool list, a rule's globs, a policy's blocked commands). Then its main file, to read: a skill's SKILL.md, an agent's prompt (its system instruction), a rule's, command's or output style's body, or a hook's or status line's script. Beside them: the package's checksum and size, its configuration, the items that use it, its owner and approver, and every file, each a link to it in Files.
• Dependencies on the canvas: an agent or a bundle shows the items it uses on the same canvas as the editor, read-only. Each node links to that item's page.
• Files: every file of the version, ronne.yaml included, in a tree. Markdown is shown rendered, line breaks kept, with its frontmatter as a table; the Source tab shows the text exactly as written. Other files are shown as text. Binary files and text over 512 KB are listed but not shown. The file you open is in the address, so you can send someone a link to it.

Once usage of an item is reported, its first two cards become Installs and Runs over 30 days, Works in shows each tool's share, and a Usage card after Install charts the last 14 days. Reading the numbers explains them. Runtime requirements and signed releases aren't shown yet: the registry doesn't collect or store them.

?version= works here too, yanked versions included. If a version's package is missing or doesn't match its checksum, the page says so instead of showing anything: tell an administrator.