Exporting your own items

You wrote a skill, an agent, a command, a rule or an MCP server for Claude Code, Codex or Cursor, and want your team to have it. rmk export reads it, writes the ronne.yaml it lacks, shows you everything it would upload, and creates a private draft here: a new item, or a change proposal when it changes a published one. You check it in the web app and submit it for review like any other draft.

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 only reads: it never changes your files, and it never submits anything.

It looks where each tool keeps each type, in the project or, with --scope user, in your home folder (subfolders included):

• skills: folders with a SKILL.md in .claude/skills/, and in .agents/skills/, which Codex and Cursor share;
• Claude Code: agents, commands and rules as Markdown in .claude/agents/, .claude/commands/ and .claude/rules/; MCP servers in .mcp.json, or at the top of ~/.claude.json;
• Codex: agents in .codex/agents/*.toml, and MCP servers under mcp_servers in .codex/config.toml;
• Cursor: agents in .cursor/agents/, rules in .cursor/rules/*.mdc (projects only), commands in .cursor/commands/, and MCP servers in .cursor/mcp.json.

The ronne-registry server rmk mcp-setup adds is never listed. Rules written inside AGENTS.md, hooks and permission settings aren't read, nor Cursor's old .cursorrules or Codex's custom prompts. When the same name is an item in two tools, say which with --from.

You name what to export, or give its path (a skill's folder, or an agent, command or rule file). A skill is its folder: every file in it is uploaded, keeping scripts executable, except:

• Never part of an item: .git/, .hg/, .svn/, node_modules/, __pycache__/, .DS_Store, Thumbs.db, .ronne/.
• Likely secrets: .env, .env.*, *.pem, *.key, id_rsa*, .npmrc, .netrc.
• Symbolic links inside the folder, which are never followed.

A file that contains something that is certainly a secret, such as a provider's API key, stops that item: the file is named, the value isn't shown. Remove it (use an environment variable instead), or add --force. A folder over the upload limits (500 files, 1 MB a file, 20 MB in all) is stopped too.

ronne.yaml is made from SKILL.md's frontmatter: its description (on one line, and cut at 300 characters, with a warning) and license. A ronne.yaml you wrote in the folder is used instead, with only its name set. When SKILL.md's name isn't the item's name, the uploaded copy gets it set; your file stays as it is.

Every item is @scope/name, and only root creates scopes, so you choose one that exists: --to @team, or the scope in the folder's own ronne.yaml, or, in a terminal, from the list rmk shows. It never picks one for you.

The name is the one your AI tool uses: a skill's or an agent's name, a command's or rule's file name (with its subfolder: review/diff.md is review-diff), or an MCP server's key. When it isn't a valid item name, it's made into one, in lowercase with hyphens (My Skill! becomes my-skill). --name sets another, for one item. If two items share a name, such as a skill and a command called review, say which with --type; if two tools have it, with --from; or give the path.

Before anything leaves your machine, the question shows, for each item:

• the registry and the account you're logged in as, and the item's name and type;
• every file with its size, and every file left out, with why;
• the ronne.yaml it made, and its warnings: each thing the item loses from your tool's format, by name;
• what it depends on, and whether each is exported with it or already published;
• what the checks find, to fix in the web app before submitting;
• for a change proposal, the version it starts from, what it changes, and whether a newer version is out;
• each item's description and where it came from: its files, you, your AI tool, the version it's based on, or your draft (see Descriptions);
• when you already have a draft of the item, Updates your draft, with its address: see Exporting again.

Then it asks Upload n item(s) as drafts?, and nothing is sent unless you answer yes.

Every item needs a description: one line, at most 300 characters, saying what it does. It's what people read in the catalogue and what AI tools use to decide when to use the item. rmk export takes it from the item's own files when they have one, such as description in a skill's, agent's or command's frontmatter. When they don't, it asks:

• In a terminal, for each item: type one sentence, or press Enter to take its first line when it has one.
• From your AI tool, the assistant reads the item and writes one, and the plan shows it as written by your AI tool before anything is uploaded.
• Without a terminal, give them with --describe style="Tabs, not spaces." (once per item) or --descriptions descriptions.json, an object from item to text.

A Claude Code rule, and a Cursor rule without description, only have their first line, and an MCP server has nothing on disk, so they're always asked about. A first line is only offered, never used on its own: it's often a heading. An item without one isn't uploaded. A change proposal keeps the description of the version it's based on, and exporting again keeps your draft's when the item still has none.

The description goes into ronne.yaml, and for a skill also into the uploaded SKILL.md's frontmatter, where AI tools read it. Your files aren't changed. To change it later, edit it in the web editor, or add one to your file and export again.

A tool's own files can say things a portable item can't. Each one left out is a warning in the preview, by name, so you decide before uploading. For Claude Code:

For Codex and Cursor:

A model a Codex or Cursor agent names is kept for that tool only, so it still uses it there; other tools use their default.

A description is one line of at most 300 characters. An agent's or command's longer one is cut, and the cut text is what Claude Code reads once the item is installed. Rules and MCP servers never carry one of their own, so they always need one: see Descriptions.

MCP servers: names, never values. The values of a server's env are never uploaded; each becomes a variable the item declares, marked secret when it looks like a credential, and whoever installs it sets it. A token written into a header, an argument or the address is taken out and replaced by a variable such as ${GITHUB_TOKEN}; the preview says where. If a credential can't be told apart from the text around it, the server isn't exported: move it into an environment variable first. A server has no description on disk, so rmk export asks for one: see Descriptions.

An item often uses others: an agent loads skills, and agents, skills and commands call MCP servers through their tools. rmk export finds them, follows them through (an agent that loads a skill that uses a server needs both), and says what each is:

• yours: an item you wrote here, not in the registry yet;
• installed: rmk installed it, so the item depends on that registry item at the version you have. Nothing is uploaded for it;
• already published: yours, but the scope already has a published item of that name and type, so the item depends on that one instead of a copy;
• can't be declared: built into the tool, from a plugin, somewhere export doesn't read, or a pair the types don't allow. A warning names it.

When some are yours, it asks what to do with them:

1. Export them too (recommended): each becomes its own draft, uploaded first, and the item declares them at ^1.0.0, the first release. Without them, the item won't work for whoever installs it.
2. Export without them: only the item, which may not work where they're missing. Installed ones are still declared.
3. Cancel.

Without a terminal, choose with --with-deps or --no-deps; from your AI tool, the assistant asks you. If an upload fails, the items that depend on it aren't sent.

The order to submit in. A dependency has to be in review before what uses it, so rmk says the order: @team/github must be in review first: once it is ready, rmk submit @team/reviewer submits it first. Submitting the item takes your dependency drafts with it, and they're released before it (Dependencies in review). To install all of them as one item, make a bundle on the canvas.

Each item arrives as a draft under Submissions, which only you see, and rmk prints its address and what is left to fix. Open it, fix what the checks say, and submit it: from there it follows the usual review.

To submit many at once, rmk submit --all --dry-run shows which are ready, and rmk submit --all submits them (see Submitting many at once); an item and its dependencies go together, so there are no rounds to wait for. A change proposal is reviewed like any proposal and released as the item's next version. A draft made this way counts towards the limits for tokens, and is written to the audit log.

Kept working on it in your AI tool? Export it again: rmk looks for a draft of yours of the same item and updates it instead of making another.

• A draft, or one sent back for changes: its files are replaced with what you export, including edits you made in the web app since. If you have several, the one changed most recently. Updating doesn't count towards the 50-draft limit. A submission sent back for changes stays that way: resubmit it in the web app.
• One in review: left alone, and nothing is uploaded for it. Withdraw and archive it in the web app first to change it.
• The same item means the same name and type, and for a change proposal the same base version. A proposal from a newer version, or a draft of another type, becomes a new draft; the old one stays.

The preview says Updates your draft with its address before anything is sent. To keep the draft as it is and make a separate one, add --new-draft, or ask the assistant in your AI tool for a separate draft.

An item rmk installed that you edited since, and a copy from a registry (a ronne.yaml with a version), are exported as a change proposal to that item. It refuses, and says why:

• an item it installed that you haven't changed: there's nothing to export;
• a file rmk wrote without a record of the install, such as a rule or command it wrote as a skill: change those on the item's page, with Propose a change;
• a registry copy with --force is exported as a new item instead, without the version.

When what you export is a change to a published item, it arrives as a change proposal to that item, not a new one:

• an item rmk installed and you edited: based on the version you installed;
• a copy from a registry: based on the version its ronne.yaml names;
• an item of yours whose name is already published in the scope, with the same type: based on its latest version. That's the usual loop: export, release, edit, export again.

rmk downloads the base version and compares your files with what the base looks like in your AI tool. Only what you changed is taken; everything else stays as the base has it, including what your tool's files can't say, such as keywords, the license, or dependencies. An edit the item can't carry (a setting only your tool has) leaves nothing to propose, and rmk says so.

The preview shows Proposal to @team/reviewer, from 1.2.0 and what changes: files added, removed and changed, and each field of ronne.yaml, old and new. If the item has a newer version, the proposal arrives stale: rebase it in the web app. It's reviewed like any proposal and released as the item's next version. To export it as a new item instead, add --new (and --name for another name).

With the registry MCP server set up, you can ask your AI tool instead: “export my deploy-check agent to the marketplace”. The assistant:

1. lists what it finds and whose each is (list_local_items);
2. asks you which scope, from this marketplace's list: it can't choose one for you;
3. if it uses items of yours, shows them and asks whether to export them too, recommending it;
4. shows the plan: the name, every file with its size, what's left out and why, and the ronne.yaml (plan_export, which sends nothing);
5. once you've seen it, uploads it (export_items, which your tool asks you about) and gives you each draft's address. A draft of yours of the same item is updated, unless you ask for a separate one.
6. when you ask, submits the ready ones for review (check_drafts, then submit_drafts): see Submitting many at once.

It exports only items found in your AI tools' folders: your own, and installed ones you edited, as change proposals. For an item that doesn't describe itself, the assistant writes the description from its content and shows it in the plan. A file or folder elsewhere, and --force, are for rmk export in a terminal.