Itens e tipos

Skills, agentes, comandos, regras e servidores MCP que você já escreveu para o Claude Code podem ser trazidos para cá como rascunhos com rmk export. Os outros tipos (hooks, políticas de permissões, linhas de status, servidores LSP, estilos de saída e pacotes) são criados aqui, com New item.

Alguns tipos se apoiam em outros e os listam em dependencies no manifesto, cada um com uma faixa de versões como ^1.0.0. Instalar um deles instala aquilo de que ele depende.

• bundle

  Traz qualquer coisa

  Um pacote pode depender de itens de qualquer tipo, outros pacotes incluídos, desde que nada leve de volta a ele mesmo. É assim que um time compartilha um conjunto inicial.

  bundle → qualquer tipo

• agent

  Traz as próprias partes

  Pode depender dos itens que usa: skill, mcp-server, hook, rule, command.

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

• skillcommand

  Trazem o que usam

  Podem depender de mcp-server, instalado com eles.

  skill, command → mcp-server

• rulehookmcp-serverpermission-policyoutput-stylestatuslinelsp-server

  Independente

  Estes tipos não podem ter dependências: cada um é instalado sozinho.

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

No envio, cada dependência precisa ser permitida para o tipo e estar publicada com uma versão dentro da faixa, ou em revisão, sem ciclos.

Adicionar uma

• No formulário: digite parte do nome, como @team/gi ou github, em Add a dependency e escolha na lista. A lista tem itens publicados, os seus (rascunhos, em revisão, aprovados) e os de outras pessoas em revisão, apenas dos tipos de que este item pode depender.
• A versão começa em latest, escrita como ^ mais a versão para a qual a tag aponta agora, já que uma faixa não pode nomear uma tag; escolha outra na lista se precisar. Um item que ainda não foi lançado recebe ^1.0.0, o primeiro release dele.
• Em um arquivo markdown, como o SKILL.md ou o prompt de um agente: digite @ e parte de um nome, e escolha um. O nome vai para o texto e o item é adicionado às dependências. Apagar o texto depois não o remove: faça isso no formulário ou no canvas.
• Como em toda edição, nada é salvo até você clicar em Save. Uma faixa digitada à mão é gravada quando você sai do campo.

Como uma instalação escolhe as versões

Uma instalação recebe uma versão de cada item: a mais alta que atende a todas as faixas que pedem por ela, seja porque você pediu o item, seja porque algo que você pediu depende dele. Versões retiradas (yanked) são ignoradas, e uma faixa só escolhe um pré-release quando nomeia um (^1.1.0-beta.1, não ^1.0.0).

Se nenhuma versão atende a todas as faixas, a instalação para e diz quais faixas divergem e quem pediu cada uma, como ^1.0.0 (the request) e ^2.0.0 (@platform/[email protected]). A solução é ampliar uma faixa ou lançar uma versão que atenda às duas.

Um item exportado com rmk export recebe as dependências preenchidas a partir do que usa, como as skills que um agente carrega: Exportar os seus próprios itens.

Um agente ou um pacote é, em boa parte, os itens que usa, então o rascunho dele mostra o ronne.yaml de uma terceira forma, ao lado de Form e YAML: Canvas. O rascunho é o nó no centro, e cada dependência é um nó ligado a ele, com o tipo, a versão que o catálogo lista, as ferramentas de IA em que funciona e a faixa.

• Adicionar: busque no catálogo abaixo do canvas. Ele oferece itens publicados dos tipos de que o rascunho pode depender. Add coloca um no canvas com a faixa ^ mais a versão listada, como ^1.4.0 (um pré-release começa exatamente nessa versão); arrastá-lo para o canvas o coloca onde você o soltar.
• Mudar uma faixa: digite-a no nó ou na lista abaixo do canvas. É uma faixa de versões como ^1.0.0; uma tag como latest não é.
• Remover: o botão × do nó, ou selecione o nó e pressione Delete.
• Problemas aparecem no nó: o que o envio diria sobre essa dependência, como que ela não está publicada ou que nenhuma versão atende à faixa.
• Sem mouse: Tab chega a cada nó e aos campos dele, Enter seleciona um nó e as setas o movem; a lista abaixo do canvas tem todas as dependências, com os mesmos campos.

O canvas muda apenas dependencies no ronne.yaml: o formulário e o YAML mostram a mesma coisa, e os revisores leem isso como linhas no diff do arquivo. A posição dos nós fica em .ronne/layout.json, um arquivo do rascunho. Ele fica de fora dos diffs de revisão e não é lançado, então uma proposta de mudança começa com os nós posicionados automaticamente.

A página de um agente ou de um pacote lançado mostra o mesmo canvas, somente leitura, em Overview.

Um item é uma pequena pasta de arquivos. O ronne.yaml, o manifesto, diz o que ele é; os outros arquivos são o conteúdo, como o SKILL.md de uma skill. O editor mostra o ronne.yaml como formulário ou como YAML e, no caso de um agente ou de um pacote, também como canvas.

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

• name e type correspondem aos do rascunho; o editor os mantém em sincronia.
• description é o que o catálogo mostra, e keywords ajudam a busca a encontrá-lo.
• O bloco próprio do tipo, skill: aqui, diz como a ferramenta o usa.
• Não há version: o release a define.

Os arquivos com que New item começa, o ronne.yaml e o arquivo que ele nomeia (como SKILL.md ou prompt.md), são os arquivos iniciais do item: edite-os como quiser, mas eles não podem ser renomeados nem excluídos. Importar um .zip que substitui os arquivos os mantém. Os outros arquivos vêm e vão normalmente.

Toda página de item mostra o que o item é antes de você instalá-lo: os arquivos da versão que você está vendo, exatamente como o rmk install os recebe. Eles vêm do pacote .tgz lançado e são conferidos antes com o checksum dele; lê-los não conta como download.

• Overview, onde a página abre, resume o item em uma tela. No topo: os downloads, quantas versões ele tem, em quantas ferramentas funciona e a revisão (quem aprovou a versão e o que ela pode fazer na sua máquina). Depois, Install, com os dois comandos e um --target rápido para cada ferramenta, e Capabilities and guardrails: o que ele pode fazer, ao lado dos limites que o próprio ronne.yaml define (a lista de ferramentas de um agente, os globs de uma regra, os comandos bloqueados de uma política). Depois, o arquivo principal, para ler: o SKILL.md de uma skill, o prompt de um agente (a instrução de sistema dele), o corpo de uma regra, de um comando ou de um estilo de saída, ou o script de um hook ou de uma linha de status. Ao lado deles: o checksum e o tamanho do .tgz, a configuração, os itens que o usam, o dono e quem o aprovou, e todos os arquivos, cada um com um link para ele em Files.
• Dependências no canvas: um agente ou um pacote mostra os itens que usa no mesmo canvas do editor, somente leitura. Cada nó leva à página daquele item.
• Files: todos os arquivos da versão, incluindo o ronne.yaml, em uma árvore. O Markdown aparece renderizado, com as quebras de linha mantidas e o frontmatter como tabela; a aba Source mostra o texto exatamente como foi escrito. Os outros arquivos aparecem como texto. Arquivos binários e textos acima de 512 KB são listados, mas não exibidos. O arquivo aberto fica no endereço, então você pode mandar a alguém um link para ele.

Quando o uso de um item é reportado, os dois primeiros cards passam a ser Installs e Runs em 30 dias, Works in mostra a participação de cada ferramenta e um card Usage depois de Install traz um gráfico dos últimos 14 dias. Como ler os números explica cada um deles. Requisitos de runtime e releases assinados ainda não aparecem: o registro não os coleta nem armazena.

?version= também funciona aqui, incluindo versões retiradas. Se o pacote .tgz de uma versão estiver faltando ou não bater com o checksum, a página avisa em vez de mostrar qualquer coisa: fale com um administrador.