Exportar os seus próprios itens

Você escreveu uma skill, um agente, um comando, uma regra ou um servidor MCP para o Claude Code, o Codex ou o Cursor, e quer que o seu time tenha acesso a ele. O rmk export lê o item, escreve o ronne.yaml que falta, mostra tudo o que enviaria e cria aqui um rascunho privado: um item novo, ou uma proposta de mudança quando ele altera um item publicado. Você confere o rascunho no app web e o envia para revisão como qualquer outro.

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."

O rmk export só lê: ele nunca altera os seus arquivos e nunca envia nada para revisão.

Ele procura onde cada ferramenta guarda cada tipo, no projeto ou, com --scope user, na sua pasta pessoal (incluindo as subpastas):

• skills: pastas com um SKILL.md em .claude/skills/ e em .agents/skills/, que o Codex e o Cursor compartilham;
• Claude Code: agentes, comandos e regras em Markdown em .claude/agents/, .claude/commands/ e .claude/rules/; servidores MCP no .mcp.json, ou no nível principal do ~/.claude.json;
• Codex: agentes em .codex/agents/*.toml, e servidores MCP em mcp_servers no .codex/config.toml;
• Cursor: agentes em .cursor/agents/, regras em .cursor/rules/*.mdc (só em projetos), comandos em .cursor/commands/, e servidores MCP no .cursor/mcp.json.

O servidor ronne-registry que o rmk mcp-setup adiciona nunca aparece na lista. Regras escritas dentro do AGENTS.md, hooks e configurações de permissão não são lidos, nem o antigo .cursorrules do Cursor ou os prompts personalizados do Codex. Quando o mesmo nome é um item em duas ferramentas, diga qual com --from.

Você indica o nome do que quer exportar, ou o caminho (a pasta de uma skill, ou o arquivo de um agente, comando ou regra). Uma skill é a pasta dela: todos os arquivos dentro dela são enviados, e os scripts continuam executáveis, exceto:

• Nunca fazem parte de um item: .git/, .hg/, .svn/, node_modules/, __pycache__/, .DS_Store, Thumbs.db, .ronne/.
• Prováveis segredos: .env, .env.*, *.pem, *.key, id_rsa*, .npmrc, .netrc.
• Links simbólicos dentro da pasta, que nunca são seguidos.

Um arquivo que contém algo que com certeza é um segredo, como a chave de API de um provedor, barra aquele item: o arquivo é indicado, mas o valor não aparece. Remova o segredo (use uma variável de ambiente no lugar), ou adicione --force. Uma pasta acima dos limites de envio (500 arquivos, 1 MB por arquivo, 20 MB no total) também é barrada.

O ronne.yaml é gerado a partir do frontmatter do SKILL.md: a description (em uma linha, e cortada em 300 caracteres, com um aviso) e a license. Um ronne.yaml que você escreveu na pasta é usado no lugar, só com o name definido. Quando o name do SKILL.md não é o nome do item, a cópia enviada recebe esse nome; o seu arquivo fica como está.

Todo item é @scope/name, e só o root cria escopos, então você escolhe um que já exista: --to @team, ou o escopo do próprio ronne.yaml da pasta, ou, em um terminal, a partir da lista que o rmk mostra. Ele nunca escolhe um por você.

O nome é o que a sua ferramenta de IA usa: o name de uma skill ou de um agente, o nome do arquivo de um comando ou de uma regra (com a subpasta: review/diff.md vira review-diff), ou a chave de um servidor MCP. Quando ele não é um nome de item válido, é convertido em um, em minúsculas e com hifens (My Skill! vira my-skill). O --name define outro, para um item. Se dois itens têm o mesmo nome, como uma skill e um comando chamados review, diga qual com --type; se duas ferramentas têm o item, com --from; ou indique o caminho.

Antes que qualquer coisa saia da sua máquina, a pergunta mostra, para cada item:

• o registro e a conta com que você está logado, e o nome e o tipo do item;
• cada arquivo com o tamanho, e cada arquivo deixado de fora, com o motivo;
• o ronne.yaml que ele gerou, e os avisos: cada coisa que o item perde do formato da sua ferramenta, pelo nome;
• do que ele depende, e se cada dependência é exportada junto ou já foi publicada;
• o que as verificações encontram, para corrigir no app web antes de enviar para revisão;
• para uma proposta de mudança, a versão de partida, o que ela muda, e se já saiu uma versão mais nova;
• a descrição de cada item e de onde ela veio: dos arquivos dele, de você, da sua ferramenta de IA, da versão em que ele se baseia, ou do seu rascunho (veja Descrições);
• quando você já tem um rascunho do item, Updates your draft, com o endereço dele: veja Exportar de novo.

Então ele pergunta Upload n item(s) as drafts?, e nada é enviado a menos que você responda sim.

Todo item precisa de uma descrição: uma linha, de no máximo 300 caracteres, dizendo o que ele faz. É o que as pessoas leem no catálogo e o que as ferramentas de IA usam para decidir quando usar o item. O rmk export a tira dos próprios arquivos do item quando eles têm uma, como a description no frontmatter de uma skill, de um agente ou de um comando. Quando não têm, ele pergunta:

• Em um terminal, para cada item: digite uma frase, ou pressione Enter para usar a primeira linha do item, quando houver uma.
• Pela sua ferramenta de IA, o assistente lê o item e escreve uma, e o plano a mostra como written by your AI tool antes que qualquer coisa seja enviada.
• Sem um terminal, informe as descrições com --describe style="Tabs, not spaces." (uma vez por item) ou --descriptions descriptions.json, um objeto de item para texto.

Uma regra do Claude Code, e uma regra do Cursor sem description, só têm a primeira linha, e um servidor MCP não tem nada no disco, então a pergunta sempre aparece para eles. Uma primeira linha só é oferecida, nunca usada sozinha: muitas vezes ela é um título. Um item sem descrição não é enviado. Uma proposta de mudança mantém a descrição da versão em que se baseia, e exportar de novo mantém a do seu rascunho quando o item ainda não tem nenhuma.

A descrição vai para o ronne.yaml e, no caso de uma skill, também para o frontmatter do SKILL.md enviado, onde as ferramentas de IA a leem. Os seus arquivos não são alterados. Para mudá-la depois, edite-a no editor web, ou adicione uma ao seu arquivo e exporte de novo.

Os arquivos próprios de uma ferramenta podem dizer coisas que um item portátil não pode. Cada coisa deixada de fora vira um aviso na prévia, pelo nome, para você decidir antes de enviar. Para o Claude Code:

Para o Codex e o Cursor:

Um modelo que um agente do Codex ou do Cursor indica é mantido só para aquela ferramenta, então ela continua a usá-lo; as outras ferramentas usam o padrão delas.

Uma descrição é uma linha de no máximo 300 caracteres. A de um agente ou de um comando, se for mais longa, é cortada, e o texto cortado é o que o Claude Code lê depois que o item é instalado. Regras e servidores MCP nunca trazem uma descrição própria, então sempre precisam de uma: veja Descrições.

Servidores MCP: nomes, nunca valores. Os valores do env de um servidor nunca são enviados; cada um vira uma variável que o item declara, marcada como secreta quando parece uma credencial, e quem instala o item a define. Um token escrito em um header, em um argumento ou no endereço é retirado e substituído por uma variável como ${GITHUB_TOKEN}; a prévia diz onde. Se não for possível separar uma credencial do texto em volta dela, o servidor não é exportado: primeiro mova a credencial para uma variável de ambiente. Um servidor não tem descrição no disco, então o rmk export pede uma: veja Descrições.

Um item muitas vezes usa outros: um agente carrega skills, e agentes, skills e comandos chamam servidores MCP pelas ferramentas deles. O rmk export encontra esses itens, segue a cadeia até o fim (um agente que carrega uma skill que usa um servidor precisa dos dois) e diz o que cada um é:

• seu: um item que você escreveu aqui, que ainda não está no registro;
• instalado: o rmk o instalou, então o item depende daquele item do registro na versão que você tem. Nada é enviado para ele;
• já publicado: é seu, mas o escopo já tem um item publicado com esse nome e esse tipo, então o item depende dele em vez de uma cópia;
• não pode ser declarado: embutido na ferramenta, vindo de um plugin, de um lugar que o export não lê, ou um par que os tipos não permitem. Um aviso indica qual é.

Quando alguns são seus, ele pergunta o que fazer com eles:

1. Export them too (recomendado): exportar também. Cada um vira o próprio rascunho, enviado primeiro, e o item os declara em ^1.0.0, o primeiro release. Sem eles, o item não vai funcionar para quem o instalar.
2. Export without them: só o item, que pode não funcionar onde eles faltarem. Os instalados continuam declarados.
3. Cancel.

Sem um terminal, escolha com --with-deps ou --no-deps; pela sua ferramenta de IA, o assistente pergunta a você. Se um envio falhar, os itens que dependem dele não são enviados.

A ordem de envio para revisão. Uma dependência precisa estar em revisão antes do que a usa, então o rmk indica a ordem: @team/github must be in review first: once it is ready, rmk submit @team/reviewer submits it first. Enviar o item para revisão leva junto os seus rascunhos de dependências, e eles são lançados antes dele (Dependências em revisão). Para instalar todos eles como um só item, monte um pacote no canvas.

Cada item chega como rascunho em Submissions, que só você vê, e o rmk mostra o endereço dele e o que falta corrigir. Abra o rascunho, corrija o que as verificações apontam e envie para revisão: daí em diante ele segue a revisão de sempre.

Para enviar muitos para revisão de uma vez, o rmk submit --all --dry-run mostra quais estão prontos, e o rmk submit --all os envia para revisão (veja Enviar em lote); um item e as dependências dele vão juntos, então não há rodadas a esperar. Uma proposta de mudança é revisada como qualquer proposta e lançada como a próxima versão do item. Um rascunho criado assim conta para os limites dos tokens, e fica registrado no log de auditoria.

Continuou trabalhando no item na sua ferramenta de IA? Exporte de novo: o rmk procura um rascunho seu do mesmo item e o atualiza em vez de criar outro.

• Um rascunho, ou um devolvido para mudanças: os arquivos dele são substituídos pelo que você exporta, incluindo as edições que você fez no app web desde então. Se você tiver vários, vale o alterado mais recentemente. Atualizar não conta para o limite de 50 rascunhos. Uma submissão devolvida para mudanças continua assim: envie-a de novo para revisão no app web.
• Um em revisão: fica intocado, e nada é enviado para ele. Para alterá-lo, primeiro retire-o e arquive-o no app web.
• O mesmo item quer dizer o mesmo nome e o mesmo tipo e, para uma proposta de mudança, a mesma versão base. Uma proposta a partir de uma versão mais nova, ou um rascunho de outro tipo, vira um rascunho novo; o antigo continua lá.

A prévia diz Updates your draft com o endereço do rascunho antes que qualquer coisa seja enviada. Para manter o rascunho como está e criar um separado, adicione --new-draft, ou peça ao assistente na sua ferramenta de IA um rascunho separado.

Um item que o rmk instalou e que você editou desde então, e uma cópia vinda de um registro (um ronne.yaml com version), são exportados como uma proposta de mudança para aquele item. Ele se recusa, e diz por quê, para:

• um item que ele instalou e que você não alterou: não há nada para exportar;
• um arquivo que o rmk escreveu sem um registro da instalação, como uma regra ou um comando que ele escreveu como skill: altere esses itens na página do item, com Propose a change;
• uma cópia de registro com --force, que é exportada como um item novo, sem a versão.

Quando o que você exporta é uma mudança em um item publicado, ele chega como uma proposta de mudança para aquele item, e não como um item novo:

• um item que o rmk instalou e você editou: com base na versão que você instalou;
• uma cópia vinda de um registro: com base na versão que o ronne.yaml dela indica;
• um item seu cujo nome já está publicado no escopo, com o mesmo tipo: com base na versão latest dele. Esse é o ciclo habitual: exportar, lançar, editar, exportar de novo.

O rmk baixa a versão base e compara os seus arquivos com a forma que a base tem na sua ferramenta de IA. Só o que você mudou é aproveitado; todo o resto fica como está na base, incluindo o que os arquivos da sua ferramenta não conseguem expressar, como palavras-chave, a licença ou as dependências. Uma edição que o item não consegue carregar (uma configuração que só a sua ferramenta tem) não deixa nada para propor, e o rmk avisa.

A prévia mostra Proposal to @team/reviewer, from 1.2.0 e o que muda: arquivos adicionados, removidos e alterados, e cada campo do ronne.yaml, antigo e novo. Se o item tiver uma versão mais nova, a proposta chega desatualizada: faça o rebase dela no app web. Ela é revisada como qualquer proposta e lançada como a próxima versão do item. Para exportá-la como um item novo, adicione --new (e --name para outro nome).

Com o servidor MCP do registro configurado, você pode pedir à sua ferramenta de IA: “exporte o meu agente deploy-check para o marketplace”. O assistente:

1. lista o que encontra e de quem é cada item (list_local_items);
2. pergunta a você qual escopo usar, a partir da lista deste marketplace: ele não pode escolher um por você;
3. se o item usa itens seus, mostra esses itens e pergunta se deve exportá-los também, recomendando que sim;
4. mostra o plano: o nome, cada arquivo com o tamanho, o que fica de fora e por quê, e o ronne.yaml (plan_export, que não envia nada);
5. depois que você o vê, faz o envio (export_items, que a sua ferramenta pede para você aprovar) e passa o endereço de cada rascunho. Um rascunho seu do mesmo item é atualizado, a menos que você peça um separado.
6. quando você pede, envia para revisão os que estão prontos (check_drafts, depois submit_drafts): veja Enviar em lote.

Ele só exporta itens encontrados nas pastas das suas ferramentas de IA: os seus, e os instalados que você editou, como propostas de mudança. Para um item que não se descreve, o assistente escreve a descrição a partir do conteúdo e a mostra no plano. Um arquivo ou uma pasta em outro lugar, e o --force, são para o rmk export em um terminal.