A explosão do ecossistema de plugins do Claude Code
Em 2026, a especificação oficial de plugins do Claude Code — suportada pela Anthropic — evoluiu para a versão 1.2. O Plugin Marketplace já conta com mais de 420 plugins públicos em abril, e há mantenedores que geram renda mensal de alguns milhares de dólares como projeto paralelo. A cultura de "empacotar seu próprio workflow e compartilhar com outras pessoas" se consolidou, e o ecossistema alcançou uma maturidade semelhante ao do GitHub Actions.
Os plugins se dividem em quatro categorias: slash commands (interações como `/loop` e `/review`), servidores MCP (integração com ferramentas externas), hooks (gatilhos de automação) e arquivos de definição de subagentes. Combinados, permitem empacotar todo o workflow de desenvolvimento de forma declarativa.
Três plugins em destaque
get-shit-done é o plugin de workflow mais comentado. Ele faz o Claude gerenciar uma lista de tarefas e usa um Stop hook para detectar automaticamente o que ficou pendente. O Stop hook registrado no `.claude/settings.json` verifica as tarefas incompletas antes do fim da sessão e, se houver continuação necessária, injeta um novo prompt.
simplify é um plugin de revisão que inspeciona a complexidade do código modificado: detecta automaticamente complexidade ciclomática alta, lógica duplicada e imports não utilizados. Ele roda via PostToolUse hook logo após execuções de Edit/Write e, quando os limiares são ultrapassados, propõe refatorações automaticamente. O ganho de eficiência em projetos de refatoração em larga escala é expressivo.
ultrareview é um plugin baseado em subagente que automatiza o code review por PR. Ele recebe o output de `gh pr diff` e gera um relatório de revisão em três eixos: segurança, desempenho e manutenibilidade. Internamente, inicializa múltiplos subagentes em paralelo e consolida os reviews de cada perspectiva.
Como criar seu próprio plugin
Um plugin é basicamente um diretório `.claude/plugins/<nome>/` contendo `manifest.json`, `commands/*.md`, `hooks.json` e `mcp.json`. O `manifest.json` declara nome, versão e entrypoint; basta colocar arquivos Markdown no diretório `commands` para registrar slash commands.
Para incluir um servidor MCP, especifique o comando de inicialização via stdio no `mcp.json`. Para Node.js, o caminho recomendado é via `npx`; para Python, via `uvx`. O ponto crucial é evitar dependências de caminhos absolutos: ao publicar no Plugin Marketplace, o plugin precisa funcionar em ambientes variados, portanto apenas nomes de comandos resolvíveis pelo PATH são aceitos.
Os hooks são registrados no `hooks.json` com gatilhos como PreToolUse, PostToolUse, UserPromptSubmit, Stop e SessionStart. O formato especifica um `matcher` (expressão regular para o nome da ferramenta) e um `command` (shell a ser executado) via schema JSON — quem já conhece a sintaxe de workflow do GitHub Actions vai achar intuitivo.
Segurança em plugins que executam shell
A capacidade de um plugin executar comandos de shell arbitrários é o maior fator de risco do ecossistema. Em fevereiro de 2026, um servidor MCP malicioso fez um POST do `.ssh/id_rsa` para um servidor externo — um incidente real. Em resposta, a Anthropic adicionou um modo de sandbox obrigatório na versão 1.2.
Três defesas importantes: primeiro, restrição de execução via lista de permissões `allowed_commands` — declarar o conjunto de comandos permitidos no `prePlugin` e bloquear qualquer chamada de shell fora desse conjunto. Segundo, limitar comunicação externa com o flag `network_access` — habilitá-lo apenas via opt-in quando necessário. Terceiro, exigir assinatura no manifesto do plugin (compatível com Sigstore) para verificar a identidade do autor e a integridade do arquivo.
Na KGA, antes de publicar qualquer plugin interno, rodamos análise estática para detectar exec, spawn, curl e wget — e qualquer padrão perigoso derruba o CI. Também usamos um linter que emite alertas quando variáveis de ambiente são acessadas, para cobrir o vazamento de informações sensíveis via variáveis de ambiente — um ponto que desenvolvedores independentes costumam ignorar.
Boas práticas no design de plugins
A regra mais importante é não tentar empacotar funcionalidades demais em um único plugin. Plugins pequenos com responsabilidade clara — como o get-shit-done — são mais fáceis de entender e manter para quem os usa. No `manifest.json`, o campo `description` deve descrever o caso de uso de forma concreta; a primeira linha precisa deixar claro o que é automatizado em nível suficiente de granularidade.
Além disso, toda lógica de hook deve ser projetada para ser idempotente. Mesmo que o PostToolUse hook seja executado em duplicata, o comportamento precisa ser seguro. Processos que mantêm estado devem usar lock files em `.claude/state/` para controle de exclusão mútua. Em especial em operações com múltiplas instâncias, hooks executados simultaneamente podem gerar comportamentos destrutivos.
Por fim, não se esqueça de testar o plugin isoladamente. O comando `claude --plugin-test <path>` permite um dry-run — integre isso ao CI e valide antes de fazer merge na branch main. A maturidade da cultura de plugins depende de a comunidade garantir a qualidade de forma autônoma.