
Habilidade, MCP, Plugin ou apenas um CLI: como escolho uma extensão de código Claude
Eu estava construindo um lançamento de plugin com Claude Code, e o rascunho do changelog se juntou bem. Puxe git log da última tag até agora, coloque-o sob == Changelog ==. Esse é um procedimento, então funcionou.
O próximo passo é onde eu tropecei. Eu queria adicionar a contagem atual de instalações ativas do WordPress.org ao post de lançamento, então adicionei uma linha ao mesmo arquivo de procedimento: "busque as estatísticas e escreva-as." Não funcionou. Claro que não funcionou. Um arquivo que contém um procedimento ensina a Claude os passos, mas não tem pernas para sair e buscar os números de hoje de um site. Para obtê-los, você precisa de uma boca que fale com o exterior. Esse era o trabalho de uma ferramenta diferente.
Claude Code tem várias maneiras de adicionar capacidade: Skill, MCP, Plugin. Os nomes soam semelhantes e as explicações se confundem, e um CLI também está na mistura. Eu construo plugins do WordPress e uso agentes de codificação na maioria dos dias, e ainda hesitei toda vez sobre qual deles escolher. Este post é como eu traço a linha, estabelecendo uma regra: escolha a coisa mais leve primeiro.
Uma nota rápida sobre configuração
Esses quatro se movem rápido. Trate a lista abaixo como verdadeira quando eu a verifiquei, e verifique em sua própria máquina com /context, /mcp, e /plugins.
- Claude Code: o valor de
claude --version(substitua pelo seu número real) - Os comandos Slash agora estão incorporados nas Skills. Se você ler isso esperando que "comandos" sejam uma coisa separada, não vai se alinhar.
- Meus alvos são plugins e temas do WordPress construídos por mim.
Primeiro: é aninhado, não uma escolha plana de três
Dispostos em uma tabela de comparação, esses três confundem as pessoas, porque você acaba comparando coisas com trabalhos diferentes no mesmo eixo. Eles são na verdade aninhados.
Um Plugin é um contêiner de distribuição. Dentro dele vão Skills, configurações de MCP, comandos slash, subagentes e hooks. Uma Skill é um conjunto de procedimentos ou conhecimentos, e de dentro dela você pode chamar uma ferramenta MCP ou um CLI. Os comandos slash agora vivem dentro das Skills. Pense em um cartão de receita (Skill), a tubulação que conecta sua cozinha ao mercado externo (MCP), e toda a cozinha abastecida que embala tudo isso (Plugin). Ninguém discute se um cartão de receita é melhor que a tubulação. Eles fazem trabalhos diferentes. O mesmo aqui: você não compara, você pergunta em qual camada seu problema reside.
Mantenha esse aninhamento em sua cabeça e meu erro inicial se explica em uma linha: eu tentei fazer o trabalho de um MCP (buscar números externos) com uma Skill (ensinar um procedimento). Eu estava confundindo camadas.
A regra: escolha a coisa mais leve primeiro
Aqui está toda a decisão. Aplique-a de cima para baixo.
- Só ensinando um procedimento ou conhecimento? Skill.
- Precisa de dados ao vivo do exterior? Existe um CLI para isso? Se sim e você o usa raramente, chame o CLI de uma Skill.
- Sem CLI, ou você o usa profundamente todos os dias? MCP.
- Quer agrupar e reutilizar ou compartilhar tudo isso? Plugin.
Eu digo "a coisa mais leve primeiro" porque o custo em contexto e esforço cresce à medida que você desce. A maioria do que você quer é o item 1. Mas a nova ferramenta brilhante chama sua atenção, e você começa a pensar em MCP ou Plugin. Esse era eu. Pergunte-se se uma Skill é suficiente, depois se um CLI a alcança, e só então busque as ferramentas pesadas.
Algumas chamadas recentes, passadas por isso. Padronizar o estilo da mensagem de commit: um procedimento, então Skill. Olhar a contagem de posts em staging: externo, mas wp-cli lida com isso e eu o uso raramente, então chame o CLI de uma Skill. Operar o painel de produção profundamente, todos os dias: um CLI não é suficiente e a frequência é alta, então MCP. Enviar uma configuração de lint compartilhada e passos de lançamento entre plugins: distribuição, então Plugin.
O resto disso é cada camada nessa ordem.
Skill: procedimento e conhecimento
Uma pasta com um SKILL.md: frontmatter YAML no topo, corpo Markdown abaixo. A descrição fica pronta, levemente, e o corpo se abre apenas quando uma tarefa relacionada surge.
---
name: release-build
description: "Preparação de lançamento para um plugin. Aumentos de versão, entrada de changelog, construir o zip de distribuição. "
disable-model-invocation: true
allowed-tools:
- Read
- Edit
- Bash(git log *)
- Bash(unzip -l *)
---
Uma coisa que as pessoas leem mal é allowed-tools. Ele não restringe quais ferramentas podem ser executadas; ele pré-aprova as listadas para serem executadas sem um prompt de confirmação. Ferramentas que não estão na lista ainda podem ser chamadas, sujeitas às suas configurações normais de permissão. Portanto, algo que você realmente deseja bloquear não é impedido por deixá-lo fora desta lista. A outra é disable-model-invocation: true, que eu uso para trabalhos que causam efeitos colaterais, como um lançamento: eu prefiro invocar /release-build eu mesmo do que ter Claude iniciando-o de forma útil.
O ponto chave: uma Skill alcança arquivos locais e comandos que Claude Code pode executar. Buscar os números atuais de um site, qualquer coisa ao vivo, não acontecerá não importa como você formule os passos. É aí que eu tropecei. Uma Skill memorizou os passos; ela não tem pernas para sair.
MCP: dados ao vivo e sistemas reais
MCP (Model Context Protocol) conecta Claude a ferramentas e dados externos. Você declara servidores na configuração, por exemplo .mcp.json:
{
"mcpServers": {
"github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"] }
}
}
Estatísticas do WordPress.org, um banco de dados de staging, problemas do GitHub. Quando você quer o valor do momento do exterior, isso é MCP. As contagens de instalações ativas mudam diariamente, então o número de ontem embutido em uma Skill está errado amanhã. Coisas fixas que você pode anotar vão em uma Skill; coisas que mudam a cada vez precisam de MCP. /mcp lista servidores conectados e permite que você os desconecte.
Mas o MCP é pesado, e não
As empresas brasileiras que desenvolvem plugins e soluções em WordPress podem se beneficiar ao entender as diferenças entre Skills, MCP e Plugins. Essa escolha impacta diretamente na eficiência e na integração com dados externos, essencial para a competitividade no mercado digital.

