- Claude Skills, anunciado pela Anthropic, é um novo padrão em que o modelo recebe, em forma de pasta, as instruções, scripts e recursos necessários para executar tarefas específicas, carregando especialização por tarefa de forma dinâmica
- Skills é composto por arquivos Markdown e scripts opcionais; no início da sessão, apenas os metadados de cada skill são carregados em algumas dezenas de tokens, e o conteúdo completo só é buscado quando realmente necessário, o que garante altíssima eficiência de tokens
- Com o Claude Code, Skills vai além de uma simples ferramenta de programação e se expande para um agente de automação de propósito geral; com acesso ao sistema de arquivos e a um ambiente de execução de comandos, torna-se possível automatizar diversos tipos de trabalho
- Diferentemente do MCP, Skills não é um protocolo, mas sim uma estrutura simples baseada em Markdown e YAML, que pode ser usada imediatamente também por outros modelos e ferramentas, facilitando compartilhamento e adoção
- Graças a essa simplicidade e eficiência, espera-se que o ecossistema de Skills cresça muito mais rápido que o do MCP, permitindo a criação de agentes especializados em áreas que vão de jornalismo de dados a diretrizes de marca, evitando os problemas de consumo de tokens e de especificações complexas do MCP
Conceito e estrutura de Skills
- Em 16 de outubro de 2025, a Anthropic anunciou oficialmente o Claude Skills
- Um sistema de expansão de capacidades em nível de pasta que reúne instruções, scripts e recursos necessários para que o modelo execute tarefas específicas, como trabalhar com Excel ou seguir as diretrizes de marca de uma organização
- O Claude acessa a skill apenas quando ela é relevante para a tarefa, melhorando sua capacidade de executar trabalhos especializados
- O repositório GitHub anthropic/skills oferece exemplos oficiais de skills
- Conceitualmente, Skills é extremamente simples
- O núcleo é um arquivo Markdown que ensina ao modelo como executar a tarefa
- Opcionalmente, pode incluir documentação adicional e scripts prontos para ajudar na conclusão do trabalho
- O recurso de geração de documentos anunciado em setembro para o Claude, na prática, foi inteiramente implementado com Skills
- As skills para processar arquivos
.pdf, .docx, .xlsx e .pptx podem ser vistas no repositório público
Eficiência de tokens: a principal vantagem de Skills
- No início da sessão, o Claude varre todos os arquivos de skill disponíveis e lê apenas uma descrição curta no frontmatter YAML de cada skill
- O custo inicial de tokens por skill é de apenas algumas dezenas, o que é extremamente eficiente
- Os detalhes completos só são carregados quando o usuário pede uma tarefa em que a skill pode ajudar
- Esse é o diferencial essencial que transforma algo além de simplesmente salvar arquivos em disco em uma funcionalidade de verdade
Exemplo prático: skill para criar GIFs para Slack
- Descrição dos metadados da skill slack-gif-creator
- Um toolkit para gerar GIFs animados otimizados para o Slack
- Inclui um validador de restrições de tamanho e elementos básicos de animação que podem ser combinados
- Aplica-se a pedidos como: "Faça um GIF para o Slack em que X faça Y"
- Processo do teste real
- Skill
slack-gif-creator ativada no aplicativo web móvel do Claude usando o modelo Sonnet 4.5
- Inserido o prompt: "Make me a gif for slack about how Skills are way cooler than MCPs"
- O Claude gerou automaticamente o GIF (a qualidade ainda precisa melhorar, mas a skill pode ser refinada iterativamente com facilidade)
- Pontos notáveis do script Python gerado
- Adiciona o diretório da skill ao caminho do Python:
sys.path.insert(0, '/mnt/skills/examples/slack-gif-creator')
- Usa a classe
GIFBuilder do diretório core/ da skill
- Salva o arquivo em
/mnt/user-data/outputs/
- Verifica conformidade com as restrições de tamanho do Slack (2MB) usando a função
check_slack_size()
- Se o tamanho exceder o limite, o modelo pode tentar automaticamente recriar um arquivo menor
Dependências de ambiente de Skills
- O mecanismo de Skills só funciona por completo se o modelo puder acessar:
- o sistema de arquivos
- ferramentas para explorar o sistema de arquivos
- a capacidade de executar comandos no ambiente
- Esse é um padrão comum no tooling de LLMs
- O ChatGPT Code Interpreter foi o primeiro caso em grande escala no início de 2023
- Depois disso, a ideia se expandiu até a máquina local por meio de ferramentas de agentes de código como Cursor, Claude Code, Codex CLI e Gemini CLI
- Esse requisito é a maior diferença em relação a tentativas anteriores de expandir capacidades de LLM, como MCP e ChatGPT Plugins
- Embora seja uma dependência importante, a escala das novas capacidades desbloqueadas é surpreendentemente grande
- Questões de segurança continuam sendo importantes
- É necessário oferecer um ambiente de programação seguro
- Também é preciso descobrir como construir ambientes sandbox que limitem danos de ataques como prompt injection a um nível aceitável
Claude Code: evolução para um agente de propósito geral
- Em janeiro de 2025, o autor previu que “agentes” fracassariam, mas errou completamente
- Na prática, 2025 se tornou o ano dos “agentes” (embora existam várias definições, aqui vale a de tools in a loop)
- Claude Code tem um nome ruim
- Não é apenas uma ferramenta de programação, mas uma ferramenta de automação computacional de propósito geral
- Pode automatizar qualquer tarefa que possa ser alcançada por meio de comandos no computador
- A descrição mais apropriada é a de um agente de propósito geral
- Skills torna essa possibilidade muito mais clara e explícita
- O potencial de aplicação é vertiginosamente amplo
- Exemplo em jornalismo de dados: seria possível montar uma pasta de skills para lidar com tarefas como
- entender as fontes e a estrutura dos dados do censo dos EUA
- carregar dados em vários formatos em SQLite/DuckDB com bibliotecas Python
- publicar dados online como arquivos Parquet no S3 ou tabelas no Datasette Cloud
- encontrar histórias interessantes em novos datasets com orientação de um repórter de dados experiente
- construir visualizações de dados limpas e legíveis com D3
- Resultado: apenas com arquivos Markdown e alguns scripts Python de exemplo, seria possível criar um “agente de jornalismo de dados” capaz de descobrir e publicar histórias a partir dos dados do censo dos EUA
Comparação entre Skills e MCP
- O Model Context Protocol (MCP) recebeu enorme atenção desde seu lançamento em novembro de 2024
- Toda empresa precisava de uma “estratégia de IA”, e anunciar uma implementação de MCP era uma forma fácil de atender a essa demanda
- Aos poucos, os limites do MCP ficaram mais claros
- O problema mais importante é o uso de tokens
- O MCP oficial do GitHub, sozinho, consome dezenas de milhares de tokens de contexto
- Se adicionar mais alguns, quase não sobra espaço para o LLM fazer trabalho realmente útil
- Depois de começar a levar a sério agentes de código, o interesse do autor pelo MCP diminuiu
- Quase tudo o que se pode alcançar com MCP pode ser substituído por ferramentas de CLI
- O LLM já sabe como chamar
cli-tool --help, então não é preciso gastar muitos tokens explicando como usar
- O próprio modelo pode descobrir isso quando precisar
- Skills oferece exatamente as mesmas vantagens, e ainda mais, sem exigir sequer a implementação de uma nova ferramenta de CLI
- Basta adicionar um arquivo Markdown explicando como realizar a tarefa
- Scripts extras entram apenas quando ajudam a melhorar robustez ou eficiência
Perspectiva de crescimento explosivo do ecossistema de Skills
- Um dos aspectos mais interessantes de Skills é a facilidade de compartilhamento
- Muitas skills provavelmente serão implementadas em um único arquivo
- Skills mais sofisticadas podem vir em forma de pasta com alguns arquivos
- Materiais fornecidos pela Anthropic
- O autor também está pensando em ideias de skills, como uma sobre como criar plugins para o Datasette
- Também pode ser usado com outros modelos: essa é outra vantagem do design de Skills
- Se você conectar a pasta de skills ao Codex CLI ou Gemini CLI e pedir: "leia
pdf/SKILL.md e crie um PDF que explique este projeto", isso funciona
- Isso é possível mesmo que a ferramenta e o modelo não tenham conhecimento embutido sobre o sistema de skills
- Previsão: pode ocorrer uma explosão cambriana de Skills capaz de fazer a corrida pelo MCP deste ano parecer modesta
A simplicidade é a força principal
- Algumas pessoas reagem dizendo que Skills é simples demais para ser considerado uma funcionalidade
- Muita gente já vinha experimentando o truque de colocar instruções adicionais em arquivos Markdown e fazer agentes de código os lerem
- AGENTS.md já é um padrão bem estabelecido, e pode incluir instruções como “leia
PDF.md antes de gerar o PDF”
- A simplicidade central do design de Skills é justamente o que empolga o autor
- MCP é toda uma especificação de protocolo
- host, client, server, resources, prompts, tools, sampling, roots, elicitation
- inclui três meios de transporte (
stdio, streamable HTTP e, originalmente, SSE)
- Skills é Markdown + um pouco de metadados YAML + scripts opcionais executáveis
- É muito mais próximo do espírito dos LLMs: entregar texto ao modelo e deixá-lo resolver o resto
- Skills terceiriza as partes difíceis para o harness de LLM e o ambiente computacional associado
- Considerando tudo o que foi aprendido nos últimos anos sobre a capacidade dos LLMs de usar ferramentas, essa parece uma estratégia extremamente inteligente
12 comentários
Fico pensando se isso também pode ser aplicado ao usar o Claude Code para programação.
Mesmo agora, estou colocando orientações no
Claude.mde separando os guias detalhados para seguir com cada parte.Se a ideia é realizar muito trabalho com poucos tokens, parece que isso poderia ser resolvido de forma mais simples usando multiagentes e resumos, em vez de otimização de prompt. Concordo com o problema apontado, mas a forma de resolvê-lo me parece ter limitações.
Skills também não usam tokens? Se for o caso, parece que o problema do consumo de tokens vai surgir de novo, mas não sei bem como eles pretendem lidar com isso nessa hora.
Parece que, no contexto, não entra sempre o
SKILLS.mdinteiro; por enquanto, o que entra sempre no topo é só a parte de nome e descrição, como abaixo.name: skill-creator
description: Guia para criar skills eficazes. Esta skill deve ser usada quando os usuários quiserem criar uma nova skill (ou atualizar uma skill existente) que expande os recursos do Claude com conhecimento especializado, fluxos de trabalho ou integrações de ferramentas.
license: Termos completos em LICENSE.txt
Ao trabalhar com o Claude Code, você acaba alimentando continuamente instruções e regras no contexto, e no fim fica quebrando a cabeça entre uso de tokens e tamanho do contexto. Aí pensei em criar uma pasta, escrever nela os detalhes de cada função em arquivos
.mdseparados, e deixar noclaude.mdsó um monte de ponteiros dizendo o que consultar para cada tarefa; funcionou surpreendentemente bem e de forma bem barata. Como os Skills no fim devem ser uma coleção desse tipo de coisa, parece que vão ser bem úteis.E, como anunciaram, se também sair um marketplace de skills, acho que pode ser bem legal poder baixar só as skills necessárias e ativá-las quando precisar.
Oh, obrigado pela explicação essencial.
Qual seria a relação entre o gerenciamento de contexto e as Claude Skills? Eu já tinha pensado: no que isso é diferente dos custom commands do Claude Code que já existiam antes? Mas, lendo a documentação, a maior diferença me parece ser que, dentro de uma única skill, dá para incluir e executar código de script como Python ou JavaScript.
Opiniões do Hacker News
Para mim, Claude Skills parece ser uma prova de que o RAG ficou desnecessariamente difícil do ponto de vista da experiência do usuário. Não é uma complexidade técnica, o problema é UX. Se essa parte for bem resolvida, acho que o próprio Claude Skills pode se tornar desnecessário. O ponto em que Claude Skills é melhor que MCP é que é fácil de criar. Dá para fazer só escrevendo, então qualquer pessoa pode usar. Mas ele depende muito do ambiente. Por exemplo, quando são necessárias ferramentas específicas para funcionar, como configurar o sandbox para automatizar isso? E ainda é difícil ter certeza de que a versão correta está sendo usada
Estamos tentando algo parecido internamente na empresa. Os arquivos de contexto do nosso monorepo ficaram grandes demais, então construímos uma árvore de fragmentos que é carregada gradualmente por tarefa. Esses documentos de contexto parecem muito com documentação tradicional de desenvolvedor, mas na prática são bem mais úteis e orientados à tarefa. Isso faz a gente se perguntar por que não criamos esse tipo de documento antes.
Isso é basicamente um problema principal-agente com um pouco de marshmallow test misturado. Quando um desenvolvedor escreve documentação para outras pessoas, e não para a IA, ele não sabe quem vai usar, o que essa pessoa precisa, nem mesmo se ela vai ler aquilo. Claro, pode acabar ajudando ele próprio no futuro, mas é difícil ter essa visão ou manter o tempo e a disciplina. Já quando a IA usa a documentação para me ajudar diretamente, existe um incentivo imediato enorme para registrar a informação necessária. Além disso, o ciclo de feedback fica curto. Aliás, como comentários no código tendem a ser apagados por causa das características dos LLMs, hoje em dia tenho deixado mais documentação e reduzido bastante os comentários
Desenvolvedores novos raramente reclamam da documentação ruim porque têm medo de parecer idiotas. Quem escreveu já tem o modelo mental na cabeça, então muitas vezes nem percebe o problema, e escrever boa documentação era quase uma forma de colocar o próprio emprego em risco. Mas, quando você entrega documentação bagunçada para um robô burro, se aquilo não funciona bem, a culpa é sua. No fim, acho que é #2 + #3. A grande mudança é que a “substituibilidade” passou de algo negativo para algo positivo (substituir a si mesmo por um agente antes que um agente barato tome o seu lugar)
É parecido com o motivo pelo qual dívida técnica existe: pressão de negócio, design ruim, falta de recursos. Antigamente, manter boa documentação continuamente a cada mudança no código realmente custava muito caro
Quando pediram para imaginar várias skills dentro de uma pasta, pensei em tarefas como localizar dados do censo dos EUA ou entender a estrutura deles. Assim que ouvi isso, lembrei de quando usei o Wolfram Alpha pela primeira vez. Diferente de um mecanismo de busca comum, eu fiquei impressionado com uma ferramenta realmente estruturada resolvendo problemas. Usei de novo agora e continua incrível: Consultar a população dos EUA no Wolfram Alpha. O meu modelo mental de Skills é algo parecido com adicionar extensões customizadas ao Wolfram Alpha
Cliquei no link que você postou e a consulta no Wolfram Alpha abre como
what%27s the total population of the United States%3F. O resultado é curioso: aparece6.1% mod 3 °F (2015-2019 American Community Survey 5-year estimates). Fiquei curioso sobre como isso foi calculadoSinceramente, o Wolfram Alpha antigo foi uma conquista absurda. Até hoje acho impressionante como conseguiram implementar naquela época um sistema que lidava até com problemas matemáticos complexos sem IA
Ainda fico meio confuso com a diferença entre Skills e ferramentas tradicionais. Muitas skills poderiam ser vistas simplesmente como ferramentas, ou talvez como um conjunto de ferramentas com explicações a mais. Mas a definição da ferramenta e a definição da skill não ficam em lugares diferentes? Tenho curiosidade sobre como expressar a dependência entre as duas. Se uma skill declara “usa linha de comando, python, tool A e tool B”, isso significa que, ao carregar a skill, essas ferramentas também são ativadas?
O que realmente chama atenção é que todo mundo ficou obcecado com MCP e passou a agir de forma dependente desse caminho. O que é realmente interessante, na verdade, é simplesmente o próprio “tool call”. Tool call é realmente útil e impressionante. MCP é só um dos vários meios para isso. E nem é um meio tão bom assim
Acho que o MCP se espalhou tanto porque timing é tudo. Já existia chamada de ferramentas antes do MCP, mas os modelos não eram bons nisso. O surgimento do MCP coincidiu exatamente com o momento em que os modelos começaram a ficar bons em chamar ferramentas. Então, no fim, a essência da febre do MCP é que as pessoas perceberam que os LLMs podem chamar ferramentas para interagir com outros sistemas
Um servidor MCP é, na prática, um registro que cadastra tool calls. Então o que ele tem de pior em comparação com um tool call comum?
O que dá significado ao MCP é ensinar ao LLM o conceito de oauth. Foi isso que permitiu chamadas de ferramentas baseadas em servidor. Antes, era preciso instalar separadamente cada cli usado e cuidar da autenticação dentro de cada um. Concordo que tool calling é a maior força dos LLMs, mas acho que o fato de ter ficado explícita a mensagem “é preciso se preocupar com autenticação de ferramentas” também tem bastante valor
Aliás, vale lembrar que o MCP também foi uma funcionalidade inovadora criada pela Anthropic
Mesmo deixando Skills de lado, fico curioso sobre que tipo de abordagem seria melhor que MCP
A influência do MCP vai muito além do terminal. Dá para usar no ChatGPT, Claude Web, n8n e LibreChat, e ele já considera autenticação, recursos e até UI (
apps-sdketc.). Se o foco for workflow de programação ou agentes baseados em CLI (como Claude Code), ferramentas CLI têm um valor enorme, mas em áreas como CRM, vendas, suporte, operações e finanças, ferramentas baseadas em MCP são um formato mais adequado. Skills e MCP não competem; têm objetivos complementares. O verdadeiro salto acontece especialmente quando o código Python de uma Skill pode chamar MCP diretamente pelo interpreter (nós também já fizemos isso e funciona muito bem)Uma das grandes vantagens do MCP em relação a ferramentas baseadas em terminal é que ele pode funcionar sem precisar de um sandbox como um ambiente Linux totalmente isolado. E também dá para usar com modelos muito mais simples. Até modelos rodando em notebook ou mesmo no celular conseguem lidar com dois ou três MCPs sem problema. Sinceramente, pedir para esses modelos lerem arquivos e ainda usar
curlcom confiabilidade já é exigir demaisIntegrar LLMs com software externo ou com o mundo físico está realmente muito legal hoje em dia. Tudo isso pode ser feito em linguagem natural. E o LLM pode até gerar o código de um servidor MCP, então fica fácil criar capacidades totalmente novas
Sinceramente, acho que o MCP foi supervalorizado e que suas limitações são claras. Hoje, 95% dos servidores MCP não servem para nada e poderiam ser substituídos tranquilamente por um simples tool call
É óbvio, mas um servidor MCP bem feito é realmente muito bom. Já um servidor MCP mal feito cria problemas ainda piores. Em geral, todas as equipes de produto estão sob pressão para criar um servidor MCP só porque “MCP está em alta”. E os clientes também sempre têm metas relacionadas ao uso de IA, então pedem esse tipo de coisa. Só que muitas vezes nem sabem o que realmente querem, basta poder dizer “tem IA”. Então as equipes de produto também entram nisso: mesmo sem um efeito claro da adoção de IA, o MCP permite divulgar rapidamente “somos um produto de IA”. É um fenômeno que não tem muito a ver com a essência da IA
O MCP só pode ser usado se você confiar no provedor do servidor. Na prática, ele depende da honestidade do servidor. Na vida real, empresas como a Uber certamente vão usar todo tipo de prompt engineering para induzir o LLM a achar que o serviço delas é a melhor opção. No fim, os incentivos entre o publisher e o consumer de MCP ficam completamente desalinhados
Concordo que, no fim, o essencial é o tool call. Mas o MCP tem pelo menos duas vantagens em relação ao CLI. Uma é que, quando um LLM de tool call exige saídas estruturadas e precisa implementar interações complexas, o MCP é mais fácil do que CLI. A outra é que o estado entre tool calls pode ser mantido naturalmente em um servidor MCP. No começo eu também achei que talvez estivesse caindo facilmente no hype, mas um pequeno demo recente que fiz para aprender MCP (https://github.com/cournape/text2synth) foi mais fácil de construir do que seria com CLI, e acho que esse tipo de exemplo mostra bem as possibilidades interessantes do MCP
Tenho a sensação de que servidores MCP são extremamente populares entre hackers. Há muitas instâncias mal configuradas e implantadas de qualquer jeito. As empresas apagaram todas as linhas de defesa tradicionais de implantação
Nossa equipe de frontend extraiu um valor enorme do MCP do Figma. Conseguimos terminar em um dia um trabalho que levaria três semanas
Eu também fiz algo comparável a skills usando só alguns arquivos markdown. Basta lembrar o agente da skill uma vez por sessão e isso já resolve. Não vejo muito o que haveria de especial só porque o Claude faz isso
Uma parte importante é justamente dar nome a um padrão. Já era um padrão útil que muita gente vinha descobrindo e usando naturalmente, mas, quando ele ganha um nome, fica possível ter discussões de nível mais alto. A Anthropic também percebeu que esse padrão ajuda a resolver a crônica “poluição de contexto” dos agentes de programação. O antigo
AGENTS.mdou o MCP colocavam informação demais no contexto e ficavam pouco práticos; o padrão de skills é bem mais eficienteParece uma versão mais oficial e estruturada de um problema já resolvido, com um pouco mais de automação. Entre os MCPs que eu usava antes, muitos eram só uma busca de documentação mais sofisticada, e espero que skills desse tipo acabem substituindo isso
Tenho a mesma dúvida. Já uso isso há mais de um ano com Aider ou CC
Isso pode soar um pouco negativo, mas queria ver se mais alguém sente o mesmo. Se pedirem para um usuário médio configurar esse tipo de serviço por conta própria, a reação correta seria “vocês estão malucos?”. A maioria só quer fazer login, pedir alguma coisa, e o sistema cuidar do resto sozinho. MCP, Apps, Skills, Gems e afins estão todos atacando o problema errado. Isso parece aqueles canais no YouTube que a cada seis meses dizem “a nova linguagem de programação ou framework é a melhor”, fazem um app de tarefas e repetem praticamente o mesmo vídeo até seis vezes. Existe uma melhora superficial e repetitiva, mas os problemas fundamentais não são resolvidos. Tem algo errado em algum ponto do gênero tecnológico, e quando o dinheiro começa a fluir só aparecem anúncios assim, depois vem mais um release, promoções, troca de emprego, e no fim parece que não sobra valor essencial
Sobre a afirmação de que os problemas fundamentais não estão sendo resolvidos, hoje em dia as soluções já vêm embaladas junto com problemas totalmente novos. Você abre a caixa e problema e solução pulam ao mesmo tempo, perseguindo um ao outro e fugindo. E isso ainda dá a sensação de que você virou um ser humano tecnologicamente mais avançado
Sobre a ideia de que MCP, Apps, Skills, Gems etc. estão todos atacando o problema errado, na minha visão negativa estamos criando mais documentação e APIs para IA, quando, na prática, se tivéssemos criado isso para pessoas, o resultado talvez fosse parecido. Metade do meu tempo foi consumida depurando sistemas complexos sem documentação
Fico curioso sobre o que exatamente seria esse “problema fundamental” e qual era o ritmo de resolução desse tipo de “problema fundamental” antes da popularização do ChatGPT em 2023
Usando como exemplo a frase “faz o mesmo app de tarefas seis vezes e depois esquece”, não vejo muito qual é o problema nisso. A tecnologia avança de forma incremental e repetitiva por natureza. Amanhã alguém vai postar outro vídeo dizendo qual é o melhor framework de frontend, e antes era Nextjs, depois React, Angular, JQuery, PHP, HTML, sempre a mesma coisa. Se as balas não tivessem sido gastas em IA, ainda estaríamos parados no GPT-3 e no Claude 2. Do ponto de vista de ferramentas, às vezes sai coisa ruim (eu acho Skills bem bom), mas não acho que isso permita dizer que a indústria inteira apodreceu
Bem, tudo ainda está num estágio inicial e ninguém sabe de verdade o que funciona. Pode parecer tentativa superficial, mas na prática é estado da arte
Isso é um conceito completamente diferente. MCP inclui conexão com serviços externos e até tratamento de autenticação como oauth. Skills são basicamente uma combinação de ferramenta cli + prompt. Como as áreas de uso são diferentes, comparar diretamente não é simples. Aliás, antes do MCP aparecer, nós também criamos e usamos um sistema chamado Skillset, e olhando agora eu diria que era o melhor híbrido possível, misturando as vantagens de MCP e Skills
É puro exagero, de verdade