Um plugin junta o que você já escreveu — comandos, subagentes, skills, hooks — numa pasta que outra pessoa pode instalar. O manifesto é pequeno e pouco polêmico, e por isso os erros nele são tão irritantes: uma versão que não é versão, um nome com maiúscula, um site sem esquema. Nenhum impede o arquivo de ser JSON válido e todos causam problema depois. Este criador preenche os campos, confere os que têm regra e mostra a estrutura que o manifesto espera em volta, já que o manifesto sozinho não faz nada: são as pastas ao lado que de fato são carregadas.
Recursos
Nome conferido contra as regras de nomenclatura
Versão conferida como versão semântica, pré-lançamentos incluídos
Autor e e-mail aninhados corretamente em vez de achatados
O site é conferido quanto ao esquema
Campos vazios são omitidos em vez de escritos em branco
A estrutura de pastas ao lado do manifesto
Palavras-chave inseridas uma por linha
Baixa como plugin.json
Como usar Manifesto de plugin
Nomeie o plugin e dê a ele uma versão inicial
Descreva o que ele reúne
Acrescente autor, site e licença se for compartilhar
Baixe o plugin.json para a pasta .claude-plugin
Exemplo
Entrada
"version": "1.0"
Saída
Error: not a semantic version — use major.minor.patch
Versões de duas partes são a rejeição mais comum.
Erros comuns e solução de problemas
A versão é rejeitada. — Versões semânticas têm três partes: 1.0.0, não 1.0. Um sufixo de pré-lançamento como 1.0.0-beta.1 pode.
O plugin não é encontrado depois de instalar. — O manifesto fica em .claude-plugin/plugin.json dentro da pasta do plugin, não na raiz dela. A estrutura abaixo da saída mostra onde cada coisa vai.
O nome é rejeitado. — Minúsculas, dígitos e hifens simples. Ele é usado como identificador, então maiúsculas e espaços estão fora.
Nada carrega mesmo com o manifesto válido. — O manifesto só descreve o plugin. Comandos, agentes, skills e hooks são carregados das pastas ao lado: um plugin vazio com manifesto perfeito não faz nada.
Perguntas frequentes
O que um plugin pode conter?
Qualquer combinação de comandos de barra, definições de subagente, skills e hooks, cada um na sua pasta ao lado do manifesto. Todos são opcionais: um plugin que entrega um comando útil é um plugin perfeitamente válido.
Quais campos são realmente obrigatórios?
O nome, na prática. O resto são metadados que tornam o plugin utilizável por outras pessoas: uma descrição para saberem o que é, uma versão para perceberem quando mudou e um site para acharem o código.
Como devo versionar?
Comece em 0.1.0 enquanto ele estiver se movendo, e trate o primeiro número como a promessa de compatibilidade que você faz. Mudar o nome de um comando ou remover uma skill é uma quebra para quem estiver usando.
Preciso do campo de licença?
Só se for compartilhar. E se for, dizer isso explicitamente poupa uma conversa: um repositório sem licença é juridicamente incômodo de reutilizar mesmo quando obviamente foi feito para isso.
Posso montar um plugin com coisas que já tenho?
Costuma começar assim. Comandos e skills que já funcionam mudam de lugar para as pastas certas sem alteração; o manifesto é o único arquivo novo.
Ferramentas relacionadas
Construtor de comandos — Crie um comando próprio, com argumentos e uma lista de ferramentas.
Construtor de subagentes — Monte o arquivo de definição de um subagente com ferramentas e modelo.
Construtor de skills — Escreva um SKILL.md com o frontmatter verificado enquanto você digita.
Construtor de hooks — Monte hooks do settings.json e pegue os matchers que nunca disparam.