# Skills, subagentes, MCP e plugins no Claude Code: qual escolher

> Skills, subagentes, MCP e plugins são quatro camadas de extensões do Claude Code. Explico quando usar cada uma, com uma matriz de decisão pronta a usar e exemplos de projetos.

Source: https://ailoot.ai/blog/pt-pt/skills-subagents-mcp-plugins-claude-code/
Canonical: https://ailoot.ai/blog/pt-pt/skills-subagents-mcp-plugins-claude-code/
Language: pt-PT
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-214
Revision: sha256-0728760670f83c9c1f6894ed74c9768bf2e395a89739150b095c669e2b2ea8bc


Atualmente, no Claude Code, existem cinco formas de fazer a mesma revisão de código: um comando com barra, uma skill, um subagente, um plugin ou simplesmente um pedido no chat. E nenhuma destas formas é melhor do que as outras por defeito — a escolha depende da tarefa, do orçamento de tokens e de quem, além de si, a vai utilizar.



Este é o guia que eu gostaria de me ter dado há um ano. Uma árvore com 4 perguntas, uma matriz pronta a usar de «tarefa → camada» e 5 erros comuns que desperdiçam tokens para metade dos vibe coders com quem trabalho.

Sobre como trabalhar com o serviço — na [documentação da Ailoot](https://ailoot.ai/docs/).

## O que são skills, subagentes, MCP e plugins numa frase?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Pontos principais">

Ponto principal

Uma skill é uma metodologia empacotada que o Claude carrega quando é acionada. Um subagente é um «colega» isolado, com o seu próprio contexto, para uma tarefa longa. O MCP é uma ponte para um sistema externo (uma base de dados, o GitHub, o Notion). Um plugin é um conjunto pronto a usar de tudo o que foi referido, criado por terceiros e instalado com uma única linha.

</div>

Antes de escolher, vamos distinguir os termos. As quatro camadas têm o mesmo objetivo: ampliar aquilo que o Claude consegue fazer de origem. Mas cada camada tem a sua própria natureza.

**Skill** é um diretório com um ficheiro `SKILL.md` que descreve quando e como aplicar uma metodologia específica. A Anthropic compara uma skill às instruções dadas a um novo funcionário: não lhe dita cada passo todos os dias; entrega-lhe um procedimento.

**Subagente** é uma sessão separada do Claude, com o seu próprio contexto, iniciada a partir da conversa principal. Tem uma característica fundamental: o isolamento. Um subagente pode ler 30 ficheiros, produzir um resumo e devolver apenas esse resumo ao chat principal. O contexto da conversa principal mantém-se limpo.

**MCP (Model Context Protocol)** é uma norma aberta da Anthropic para ligar o Claude a sistemas externos. Numa publicação de blogue de 13 de novembro de 2025, a Anthropic explicou a distinção da forma mais clara possível:

<figure>
<blockquote>
<p>O MCP liga o Claude aos dados; as Skills ensinam o Claude a fazer algo com esses dados. Se estiver a explicar como utilizar uma ferramenta ou seguir procedimentos — por exemplo, «ao consultar a nossa base de dados, filtre sempre primeiro por intervalo de datas» — isso é uma Skill. Se precisar que o Claude tenha acesso à base de dados ou aos ficheiros do Excel, antes de mais — isso é MCP.</p>
</blockquote>
<figcaption>— Anthropic Engineering, https://claude.com/blog/skills-explained</figcaption>
</figure>

**Plugin** é um conjunto pronto a usar de skills, subagentes, hooks e comandos criado por terceiros e disponibilizado num marketplace. Instale-o com uma única linha usando `/plugin install` e obtém tudo de uma vez. Se uma skill é um procedimento seu, um plugin é um procedimento adquirido a outra empresa.

Em suma, as skills são receitas, os subagentes são colegas especializados e o MCP disponibiliza ferramentas externas através das quais o Claude pode aceder a serviços e dados. O custo em tokens varia: uma skill é a opção mais barata (é carregada quando é acionada), enquanto o MCP é consideravelmente mais dispendioso (cada servidor ligado ocupa continuamente espaço na janela de contexto).

## Porque existem 4 camadas se pode usar um único CLAUDE.md?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Pontos principais">

Ponto principal

O CLAUDE.md é um pedido: o Claude lê-o no início de uma sessão e pode ignorá-lo após 20 mensagens. As skills, os subagentes, o MCP e os plugins resolvem o que o CLAUDE.md não consegue: escala, isolamento de contexto, acesso ao mundo exterior e partilha de metodologias com uma equipa.

</div>

No projeto descrito, o CLAUDE.md é um grande mapa de regras: onde colocar cada coisa, como publicar e que acordos estão em vigor. Sem este ficheiro, o Claude começaria cada nova sessão do zero.

Mas o CLAUDE.md tem um limite. Vou explicar através de três situações em que deixa de funcionar.

**Situação 1: uma regra só funciona às vezes.** O CLAUDE.md diz: «execute sempre `npm run build` antes de `git push`». O Claude lê-o no início da sessão, concorda, começa a escrever código após 25 mensagens e esquece-se. Já me apanhei a enviar alterações sem fazer a compilação três vezes; essas alterações falharam em produção. Um hook corretamente configurado e testado pode executar uma verificação determinística da compilação e rejeitar a operação abrangida. A cobertura depende do evento e da ferramenta: um hook do Claude Code não interceta, por si só, todos os envios de outro terminal ou aplicação. Verifique que uma compilação deliberadamente falhada bloqueia o percurso real que utiliza.

**Situação 2: um processo repetido de 15 passos.** No exemplo descrito, cada guia passa por 14 etapas: pesquisa → estrutura → MDX → 7 verificações de QA em paralelo → publicação em produção → IndexNow. Se escrevesse sempre um pedido a dizer «execute a Etapa 1, depois a 2 e depois a 3», desperdiçaria tokens antes sequer de começar. Por isso, todo este fluxo de trabalho está empacotado na skill `build-masterskaya-guide` — um conjunto de instruções de 34 KB, iniciado com a frase «vamos criar um novo guia para o projeto».

**Situação 3: uma tarefa que devora o contexto.** Para verificar se um guia já publicado continua atualizado, o Claude tem de ler a transcrição de uma transmissão em direto de 30 KB, 20 retrospetivas de 5 KB cada e compará-las com o site atual. Se fizer isto no chat principal, no fim da revisão terei 200K tokens de ruído no contexto. Um subagente faz o mesmo trabalho, devolve apenas um resumo de 300 palavras à conversa principal e termina.

**Situação 4: quero que a equipa tenha os mesmos modelos que eu.** Um conjunto pronto de regras para design frontend, hooks para publicar através do Coolify e MCP para verificações com o Playwright. Isso é um plugin: empacoto a minha configuração, publico-a no marketplace e um colega instala-a com uma única linha.

O CLAUDE.md cobre o essencial: «como fazemos as coisas aqui». As 4 camadas adicionais cobrem o que o CLAUDE.md não consegue fazer fisicamente: repetição através de acionadores, isolamento de contexto, acesso ao mundo exterior e partilha.

## Quando precisa de uma skill em vez de CLAUDE.md?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Pontos principais">

Ponto principal

Uma skill é a escolha certa quando existe um processo repetível, com um acionador claro, que executa mais de uma vez por dia. Ao contrário do CLAUDE.md, uma skill só é carregada quando é necessária e não consome o contexto de base em todas as sessões.

</div>





O teste para perceber se precisa de uma skill é simples: apanha-se a copiar o mesmo pedido longo das suas notas para o chat. À terceira vez, já é um sinal.

Atualmente, tenho 7 diretórios em `~/.claude/skills/`: `build-masterskaya-guide`, `build-vc-spoke`, `build-reel-script`, `build-practicum-instruction`, `update-config`, `simplify` e `keybindings-help`. O que mais utilizo é `build-masterskaya-guide` (este guia foi escrito com ele). Contém 34 KB de metodologia: que etapas seguir, que verificações de QA multiagente executar, que condições de controlo devem interromper o processo e que artefactos guardar em `/tmp/`.

**Quando não criar uma skill.**

- Uma regra como «responda no idioma preferido do utilizador» pertence ao CLAUDE.md, não a uma skill. Uma skill só é carregada quando é acionada, mas esta regra deve aplicar-se sempre.
- Uma instrução única como «execute já a refatorização» pertence ao chat, não a uma skill.
- Uma tarefa que precise de contexto separado pode usar um subagente; se também seguir um procedimento recorrente, mantenha essa metodologia numa skill.

**O principal anti-padrão.** O erro mais comum dos vibe coders é colocar um procedimento num subagente quando devia ser uma skill. Um subagente custa mais tokens (tem o seu próprio contexto), demora mais a iniciar e, muitas vezes, é excessivo. Se a tarefa couber numa metodologia de 1 500–2 000 palavras sem ler ficheiros externos, é uma skill.

Como estruturar uma skill, o que colocar no frontmatter e que frases de acionamento funcionam — no guia [Skills do Claude Code em 2026: como criar uma biblioteca pessoal de skills](https://ailoot.ai/blog/pt-pt/claude-code-skills-library/).

## Quando precisa de um subagente em vez de uma skill?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Pontos principais">

Ponto principal

Um subagente transfere o trabalho pesado para o seu próprio contexto e devolve apenas um resumo ao chat principal. Use-o quando a tarefa exigir a leitura de muitos ficheiros, uma análise longa ou 5 verificações idênticas em paralelo — e não precisar de ver toda a confusão intermédia na conversa principal.

</div>

Uma skill guarda a metodologia; um subagente executa o trabalho. São camadas diferentes, muitas vezes confundidas porque ambas são iniciadas «a partir do chat».

Um subagente só faz sentido para isolar o contexto. A sessão principal do Claude tem um orçamento de 200 000 tokens (ou 1 milhão na versão beta). Se lhe pedir no chat principal que leia 30 ficheiros e analise cada um, gastará metade da janela com a leitura intermédia. Um subagente faz o mesmo trabalho numa sessão separada e devolve apenas o resultado ao chat principal.

**Um exemplo concreto de projeto.** Cada guia passa por várias verificações de QA em paralelo: estilo, citações e factos comparados com fontes primárias, estrutura para motores de pesquisa e integridade das ligações internas e externas. Cada verificação usa o seu próprio contexto: um glossário de regras, WebFetch para dezenas de URLs e pesquisas no texto.

Se executasse todas estas verificações num único chat, o contexto sufocar-me-ia antes de a primeira terminar. Executar subagentes em paralelo com `run_in_background: true` resolve isto: trabalham em segundo plano, o chat principal avança e, ao fim de 4–6 minutos, recebo relatórios concisos e aplico as alterações.

**Um segundo exemplo — investigação aprofundada.** Quando escolho um tema para um novo guia, 4 subagentes recolhem sinais em paralelo:

- V1 - fóruns e comunidades nos últimos 14 dias
- V2 - redes sociais
- V3 - plataformas de vídeo + blogue da Anthropic
- V4 - lacunas de SEO

Cada um devolve 30–40 itens com pontuações de viralidade. Reúno-os num conjunto, pondero-os em 9 dimensões e escolho o vencedor. Sem subagentes, esta etapa prolonga-se por 2–3 horas de consumo do contexto principal.

**Quando não criar um subagente.**

- Uma tarefa que não exija leitura de ficheiros nem utilização de WebFetch pertence ao chat principal.
- Um procedimento repetível pertence a uma skill, mas pode correr dentro de um subagente quando o isolamento for útil.
- O acesso externo exige uma ferramenta autorizada, como MCP ou uma CLI; um subagente pode usá-la quando receber a tarefa.

**O principal anti-padrão.** Criar um subagente chamado `backend-engineer` ou `qa` na esperança de que o Claude perceba quando o deve utilizar. Os subagentes específicos (como `migration-test-writer` ou `api-route-reviewer`) oferecem uma qualidade muito superior à dos genéricos. Quanto mais preciso for o nome e as instruções do subagente, mais corretamente o Claude escolherá o indicado.

Como criar subagentes para tarefas específicas, a sintaxe de frontmatter e 5 exemplos prontos a usar — no guia [Subagentes do Claude Code em 2026: um guia passo a passo](https://ailoot.ai/blog/pt-pt/claude-code-subagents/).

## Quando precisa de MCP em vez de uma skill ou de um subagente?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Pontos principais">

Ponto principal

O MCP fornece ferramentas e acesso a dados para sistemas como bases de dados, GitHub, Sentry ou um navegador. Use-o quando o fluxo precisar desse acesso. Uma skill pode fornecer a metodologia para usar as mesmas ferramentas; as duas camadas complementam-se.

</div>

A Anthropic apresentou a fórmula mais sucinta para esta diferença numa publicação de blogue: o MCP liga o Claude aos dados; as skills ensinam o Claude a fazer algo com esses dados.

Por exemplo, uma skill de revisão de issues GitHub precisa do conteúdo da issue. Forneça-o por uma ferramenta MCP autorizada, uma CLI ou texto disponibilizado. A skill define depois como rever e estruturar as conclusões; só o acesso MCP não prescreve esse procedimento.

**A minha stack específica de MCP.**

- **Playwright MCP** - QA visual para cada guia. Abra a página no computador e no telemóvel, verifique a largura do contentor e se os blocos foram apresentados.
- **Stitch MCP** - acesso ao sistema de design, criação de componentes ao estilo da marca.
- **vidIQ MCP** - análise de tendências e verificação da viralidade de ideias.
- **Railway MCP** - gestão da infraestrutura de implementação.

Cada um destes 4 é uma ponte para um sistema externo. Sem MCP, teria de escrever o meu próprio código wrapper ou mudar para um browser. Com MCP, tudo acontece na sessão do Claude.

**Custo em tokens.** O MCP é a camada mais dispendiosa. Cada servidor ligado ocupa continuamente espaço na janela de contexto: declarações de ferramentas, esquemas de argumentos e descrições. Tenho 4 servidores MCP — cerca de 8–12K tokens em cada nova sessão, antes de fazer qualquer pergunta.

Isto significa que só ligamos o MCP se for realmente necessário na maioria das sessões. Se utiliza o MCP do Sentry uma vez por semana, é melhor ativá-lo quando necessário com a flag `--mcp sentry` do que mantê-lo na lista permanente.

**Quando não utilizar MCP.**

- A metodologia para «como trabalhar com dados» pertence a uma skill, não ao MCP.
- Uma tarefa longa de leitura pode beneficiar de um subagente; se alguns ficheiros ou registos forem externos, esse subagente pode também precisar de acesso MCP.
- Publicar com um comando requer um hook ou plugin, não MCP.

**O principal anti-padrão.** Criar um servidor MCP para algo que uma skill resolveria melhor. Vi um exemplo numa discussão do HN (o próprio tópico com 422 pontos de 27 de maio): o autor escreveu um servidor MCP que fornece «instruções para revisão de código». Mas isso não dá acesso ao mundo exterior; é um procedimento. Uma skill faz o mesmo por 10 vezes menos tokens.

**Um incidente de disputa por recursos.** Uma vez, o Playwright MCP bloqueou com o erro «Browser is already in use» — tinha uma janela do Chrome aberta ao mesmo tempo e o MCP não conseguia assumir o controlo do browser. É uma lição importante: um servidor MCP utiliza recursos de sistema partilhados. Se houver disputa por um recurso (um browser, uma porta ou um ficheiro), pense no isolamento desde o início.

Um guia pronto a usar para ligar 7 MCP funcionais encontra-se em [Servidores MCP do Claude Code em 2026: 7 configurações prontas a usar](https://ailoot.ai/blog/pt-pt/mcp-servers-claude-code/).

## Quando precisa de um plugin em vez de uma skill ou de um subagente?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Pontos principais">

Ponto principal

Um plugin é um conjunto empacotado de skills, subagentes, hooks e comandos criado por terceiros, instalado com uma única linha através do marketplace. Use um se não quiser construir tudo de raiz e confiar no autor do pacote — por exemplo, para design frontend, testes com Playwright ou integração com o Telegram.

</div>

As skills, os subagentes e o MCP dizem respeito à sua metodologia. Um plugin é a metodologia pronta a usar de outra pessoa, que importa para a sua configuração.

Em outubro de 2025, a Anthropic lançou os Claude Code Plugins, um mecanismo oficial de distribuição. Um plugin é um diretório que pode conter:

- os seus próprios comandos com barra
- as suas próprias skills
- os seus próprios subagentes
- os seus próprios hooks
- as suas próprias configurações MCP
- os seus próprios estilos de saída

Tudo isto é empacotado num único pacote com `plugin.json`. A instalação faz-se com uma linha em `~/.claude/settings.json` ou com o comando `/plugin install <name>`.

**A minha stack específica de plugins.**

- **`frontend-design`** do `claude-plugins-official` oficial — 67 estilos, 96 paletas, 57 pares de tipos de letra, 13 frameworks. Quando crio um novo bloco para o site ou um modelo de e-mail, carrego este plugin e obtenho toda a biblioteca de uma vez.
- **`playwright`** do mesmo marketplace oficial — um conjunto de skills e configurações MCP para testes no browser.
- **`telegram`** — um conjunto pronto a usar para gerir uma conta Telegram a partir do Claude Code (política, lista de permissões, emparelhamento).
- **`trailofbits/skills`** — um conjunto de skills de segurança da Trail of Bits, uma empresa em que confio para questões de segurança.

Os 4 ocupam três linhas em `settings.json`. Sem plugins, passaria horas a construir a mesma biblioteca à mão.

**Quando não utilizar um plugin.**

- Se a metodologia for inteiramente sua e não se destinar a outras pessoas, mantenha-a como uma skill.
- Se ainda não souber quem a vai utilizar, experimente-a primeiro consigo, como skill.
- Se precisar de copiar rapidamente três ficheiros para uma máquina nova, basta usar `cp ~/.claude/skills/X /new/machine/.claude/skills/`.

**O principal anti-padrão.** Utilizar um plugin para substituir o CLAUDE.md — por exemplo, um plugin com regras sobre «como trabalhamos neste projeto». Um plugin destina-se à distribuição e reutilização. Se as regras forem específicas de um único repositório, pertencem ao CLAUDE.md, não a um plugin.

Perspetivas para 2026: a Anthropic está claramente a avançar para um marketplace de plugins para equipas. Isso permitirá às empresas publicar as suas metodologias internas como plugins, atribuir-lhes versões e atualizá-las para todos os funcionários com um único comando. Para um empreendedor a solo, isso significa: instale o que já está pronto e não reinvente a roda.

## Árvore de decisão: 4 perguntas a fazer antes de cada tarefa

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Pontos principais">

Ponto principal

Responda às quatro perguntas de forma independente. Cada «sim» identifica uma necessidade; continue a verificar as restantes, porque um fluxo pode combinar várias camadas. Se todas forem «não», um prompt normal e as instruções do projeto podem bastar.

</div>

**Pergunta 1: existe um procedimento repetível que vale a pena guardar?**

Se sim, reúna a metodologia numa **skill**, num ficheiro `SKILL.md` com descrição clara de quando a usar. Fornece o procedimento; não dá, por si só, acesso externo nem contexto separado.

**Pergunta 2: o trabalho precisa de contexto separado ou de uma função delegada focada?**

Se sim, use um **subagente** com tarefa e ferramentas precisas. A mesma tarefa pode seguir a metodologia de uma skill dentro desse contexto isolado.

**Pergunta 3: a tarefa precisa de ferramenta ou acesso a dados externos?**

Se sim, forneça acesso autorizado por **MCP ou outra ferramenta adequada**, como uma CLI já configurada. Uma skill descreve como usar esse acesso; um subagente pode ser quem o utiliza.

**Pergunta 4: esta configuração deve ser distribuída e mantida como pacote?**

Se sim, use um **plugin** para distribuir as skills, definições de agentes, hooks ou configuração MCP pertinentes. O pacote pode ser seu ou de outro autor.

**Exemplo combinado: revisão recorrente de issues GitHub.** Uma skill define o procedimento e formato do resultado. Um MCP GitHub ou CLI configurado fornece acesso autorizado às issues. Um subagente pode ler uma discussão longa no seu contexto e devolver conclusões. Um plugin pode distribuir a combinação à equipa. As quatro respostas podem ser «sim»; nenhuma anula outra.

## 5 erros de escolha de camada cometidos por vibe coders

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Pontos principais">

Ponto principal

Os erros mais dispendiosos são usar um subagente em vez de uma skill, MCP em vez de uma skill, um plugin em vez do CLAUDE.md e uma skill através de um hook. Cada um desperdiça tokens ou prejudica o comportamento. Vou mostrar o que aconteceu e o que devia ter acontecido, com exemplos concretos.

</div>

Vejo estes 5 padrões uma vez por semana entre os vibe coders com quem trabalho. Um em cada dois comete pelo menos um deles na primeira semana.

**Erro 1: subagente em vez de skill.**

Sintoma: um autor criou um subagente para «escrever uma nova publicação para o blogue». Sempre que o executa, o subagente é carregado, lê 2 KB de metodologia, gera uma publicação e termina. Ao fim de uma semana, o autor percebe que cada execução consome mais 5K tokens a carregar o subagente.

O que devia acontecer: «como escrever uma publicação» é uma metodologia — portanto, uma skill. A frase de acionamento é «nova publicação para o blogue». A skill é carregada no chat principal e não abre uma sessão separada. É 3–5 vezes mais barata.

**Erro 2: servidor MCP em vez de skill.**

Sintoma: um autor escreveu um servidor MCP que fornece instruções sobre «como fazer uma revisão de código». As declarações das ferramentas, as descrições do esquema de argumentos e a documentação continuam a ocupar contexto. Cada pedido desperdiça 2–3K tokens sem necessidade.

O que devia acontecer: «como fazer uma revisão de código» é um procedimento, não o acesso a um sistema externo. Use uma skill. O MCP só se justifica quando precisa de acesso ativo — por exemplo, ao Sentry para obter os erros mais recentes.

**Erro 3: plugin em vez de CLAUDE.md.**

Sintoma: um autor empacotou regras do projeto («utilize sempre o modo estrito do TypeScript», «não utilize travessões», «utilize apenas pnpm, não npm») num plugin e instalou-o. Agora, cada nova sessão carrega um plugin que duplica o que devia estar no CLAUDE.md.

O que devia acontecer: as regras de um projeto pertencem ao CLAUDE.md desse projeto. Um plugin destina-se a uma metodologia que possa ser utilizada por várias pessoas ou em vários repositórios.

**Erro 4: tentar criar uma skill através de um hook.**

Sintoma: um autor reparou que um hook é executado automaticamente quando ocorre um evento (por exemplo, antes de guardar um ficheiro). Decidiu criar uma «skill através de um hook» para o Claude aplicar automaticamente a metodologia a cada edição. Acabou com um ciclo infinito de acionamentos, contexto desperdiçado e comportamento imprevisível.

O que devia acontecer: um hook é código determinístico que executa um comando, formata o resultado ou bloqueia uma operação. Um hook não carrega uma skill nem invoca o Claude. Se precisar de «aplicar sempre a metodologia X», utilize uma skill com um acionador ou uma entrada no CLAUDE.md.

**Erro 5: uma camada extra quando não é preciso nada.**

Sintoma: um autor ouve falar de skills, lê guias, decide «preciso de empacotar esta metodologia» e passa uma noite a criar uma skill para uma tarefa que surge uma vez por mês.

O que devia acontecer: uma tarefa única pertence ao chat, de forma pontual. Uma skill só se justifica se fizer isto mais de uma vez por dia. Caso contrário, é engenharia excessiva que depois terá de manter.

Nestes exemplos, verifique as necessidades independentemente: procedimento, isolamento de contexto ou função, acesso a ferramentas e distribuição. Acrescente cada camada com finalidade concreta e combine-as quando a tarefa precisar de várias.

## O que diz a Anthropic sobre a fragmentação: para onde se dirige o Claude Code em 2026

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Pontos principais">

Ponto principal

As cinco formas de fazer uma revisão de código (um comando, uma skill, um subagente, um plugin ou o chat) estão a convergir numa única skill integrada `/code-review`. Isto significa que não precisa de entrar em pânico por haver «camadas a mais» — em 2026, as fronteiras estão a esbater-se e a simplificar-se.

</div>









O que isto significa para os próximos seis meses a um ano.

**Primeiro: as skills estão a tornar-se a camada principal para tarefas procedimentais.** A Anthropic está claramente a apostar nesta camada por ser a mais barata e previsível. Se não perceber porque precisaria de uma skill em 2026, comece por estudá-la. Todas as outras camadas irão girar à sua volta.

**Segundo: os subagentes estão a especializar-se.** O papel principal dos subagentes é isolar o contexto em tarefas exigentes. Os subagentes genéricos, como `qa-engineer`, vão desaparecer; os específicos, como `migration-test-writer` e `api-route-reviewer`, vão manter-se.

**Terceiro: os novos anúncios da Anthropic nos últimos 14 dias — o comando `/workflows` (28 de maio de 2026) para orquestrar dezenas de subagentes e a separação da faturação do Agent SDK a partir de 15 de junho — significam que a utilização programática está a passar para um grupo separado.** É um sinal de que a Anthropic está a construir infraestrutura para sistemas automatizados com 10+ agentes, em vez de sessões individuais.

Para um vibe coder em 2026, isto significa uma coisa simples: as quatro camadas vão durar pelo menos mais seis meses e, depois, algumas irão fundir-se. Mas a árvore de decisão com quatro perguntas continuará a funcionar após essa fusão — diz respeito à natureza da tarefa, não ao nome específico da camada.

## Matriz pronta a usar: 10 tarefas típicas → a camada certa

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Pontos principais">

Ponto principal

A tabela identifica a necessidade principal de cada situação. As linhas complementam-se: uma tarefa pode corresponder a várias e combinar as camadas indicadas.

</div>

| \# | Situação de acionamento | Camada certa | Porquê esta |
|----|----|----|----|
| 1 | O Claude ignora a mesma regra 2–3 vezes numa sessão | **CLAUDE.md** | Reativa, está sempre no contexto, não requer acionador |
| 2 | Escrevo o mesmo pedido longo mais de uma vez por dia | **Skill** | Carregada quando necessário, não consome o contexto de base |
| 3 | É a terceira vez que colo no chat um manual de 1 500 palavras | **Skill** | Metodologia procedimental, carregada por uma frase de acionamento |
| 4 | Uma tarefa enche o chat principal com mais de 20 ficheiros para ler | **Subagente** | Isolamento do contexto; só um resumo regressa ao chat principal |
| 5 | Preciso de 5 verificações idênticas em paralelo (QA, revisão, lint) | **Subagentes** | Iniciados com `run_in_background`; a duração total diminui cinco vezes |
| 6 | Quero ler issues do GitHub ou os erros mais recentes do Sentry | **MCP** | Acesso direto a um sistema externo através de um protocolo normalizado |
| 7 | Quero verificar automaticamente uma operação de envio abrangida | **Hook testado** | Verificação determinística; confirmar o acionador real e o comportamento de bloqueio |
| 8 | Quero transferir a minha configuração para um segundo repositório ou uma nova máquina | **Plugin** | Distribuição através de um marketplace e de um namespace |
| 9 | Uma equipa de 10 pessoas precisa de seguir as mesmas regras | **Plugin num marketplace para equipas** | Com versões, instalação única e atualizações centralizadas |
| 10 | Preciso de responder a um webhook de um serviço externo (Telegram, GitHub Actions) | **Canal MCP ou Agent SDK** | Introduz mensagens do mundo exterior na sessão |

A regra principal para utilizar esta tabela é não tentar «fazer tudo de uma vez». A maioria dos vibe coders a solo consegue orientar-se com CLAUDE.md + 5–7 skills + 2–4 servidores MCP. Os subagentes e os plugins são acrescentados à medida que o projeto cresce.

## O que se segue: como criar o seu espaço de trabalho no Claude Code

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Pontos principais">

Ponto principal

O CLAUDE.md contém as regras básicas do projeto, as skills empacotam a metodologia, os subagentes distribuem o contexto pesado, o MCP liga ao mundo exterior e os plugins distribuem o conjunto pronto a usar de outra pessoa. Estes são os cinco elementos fundamentais da sua configuração do Claude Code em 2026.

</div>

Estas cinco camadas não se sucedem umas às outras; encaixam-se umas nas outras. O CLAUDE.md é a base do projeto e as outras quatro são ligadas à medida que as tarefas crescem.



<div class="section" role="doc-bibliography" aria-label="Fontes">

### Fontes

- [Anthropic Engineering: Skills explained (13 de novembro de 2025)](https://claude.com/blog/skills-explained)
- [Documentação do Claude Code: visão geral das Skills](https://code.claude.com/docs/en/skills)
- [Documentação do Claude Code: Subagents](https://code.claude.com/docs/en/subagents)
- [Documentação do Claude Code: visão geral do MCP](https://code.claude.com/docs/en/mcp)
- [Documentação do Claude Code: Plugins](https://code.claude.com/docs/en/plugins)
- [Lançamentos do Claude Code no GitHub](https://github.com/anthropics/claude-code/releases)
- [Notícias da Anthropic: atualizações do blogue de 2026](https://www.anthropic.com/news)
- [Receitas do Sentry MCP](https://sentry.io/blog/sentry-mcp-server-for-claude-code/)
- [Repositório de skills da Trail of Bits](https://github.com/trailofbits/skills)
- [Marketplace oficial do Claude Plugins](https://github.com/anthropics/claude-plugins-official)

</div>



Conheça a [Ailoot](https://ailoot.ai/).

## Perguntas frequentes

### Uma revisão GitHub pode precisar de skill, subagente e MCP em conjunto?

Sim. A skill define o procedimento, MCP ou uma CLI autorizada fornece os dados da issue e um subagente pode fazer uma revisão longa no seu próprio contexto. Um plugin pode distribuir essa combinação.

### Como uso a lista de quatro perguntas?

Responda a cada uma de forma independente: preciso de procedimento, isolamento de contexto, acesso a ferramentas ou distribuição? Cada sim acrescenta um requisito concreto; o primeiro sim não encerra a decisão.


## Ailoot · A empresa e a sua carteira de projetos

A Ailoot assenta numa experiência operacional consolidada, numa ampla base de clientes, num serviço estável e no acompanhamento contínuo dos KPI.

A empresa e a sua carteira de projetos: milhões de clientes; vendas mensais na ordem dos milhares de milhões.

A Ailoot aplica essa experiência operacional ao acesso por API a funcionalidades de IA nos produtos dos clientes, agentes, aplicações e automatizações.
