Agent Skills - personalizando a IA para se adequar ao seu fluxo de trabalho

 (anthropic.com)
17 pontos por GN⁺ 2025-10-17 | 4 comentários | Compartilhar no WhatsApp
  • O Agent Skills da Anthropic permite expandir a especialização da IA de acordo com o fluxo de trabalho do usuário
  • Skills são componentes organizados em pastas que incluem instruções, scripts e recursos, e o Claude os carrega apenas quando são necessários durante uma tarefa
  • Concede capacidades especializadas para áreas específicas de trabalho, como criação de arquivos Excel e PowerPoint e conformidade com guias de marca
  • Usuários e desenvolvedores podem criar Skills diretamente para uso no app do Claude, no Claude Code e em toda a API
  • Também há planos para oferecer recursos de implantação e gerenciamento em nível corporativo, servindo como base para a criação de fluxos de trabalho de IA personalizados

Visão geral de Skills e como funcionam

  • Com o recurso Agent Skills, é possível usar habilidades personalizadas para que o Claude execute tarefas específicas com mais eficiência
  • As Skills são fornecidas no formato de pastas que incluem instruções, scripts e recursos, e o Claude só acessa a Skill correspondente quando uma tarefa relacionada precisa dela
  • Com esse recurso, o Claude pode ser usado de forma ainda mais poderosa em trabalhos especializados, como gestão de documentos Excel e conformidade com diretrizes de marca da organização
  • Os usuários podem criar Skills personalizadas para uso abrangente no app do Claude, no Claude Code, na API e em outros ambientes

Como as Skills funcionam

  • Durante a execução de uma tarefa, o Claude tem um algoritmo que examina todas as Skills disponíveis para encontrar a mais relevante
  • Quando encontra uma Skill correspondente, ele carrega apenas a quantidade mínima necessária de informações e arquivos, garantindo capacidade para tarefas especializadas sem perder velocidade
  • Características das Skills
    • Composição: várias Skills podem ser usadas juntas como uma pilha, e o Claude ajusta automaticamente quais são necessárias
    • Portabilidade: são escritas no mesmo formato e podem ser usadas em toda a família de produtos Claude
    • Eficiência: carrega apenas os recursos necessários no momento certo
    • Poder: também podem incluir código executável (por exemplo, Python, Shell), aproveitando a eficiência da programação tradicional
  • As Skills funcionam como uma espécie de material de onboarding personalizado que empacota o conhecimento especializado de uma organização e o entrega ao Claude, para que ele atue como especialista em um domínio específico

Integração com os produtos Claude

Claude Apps

  • Usuários Pro, Max, Team e Enterprise podem usar o recurso de Skills
  • Por padrão, são fornecidas várias Skills de exemplo para tarefas gerais, como redação de documentos, e também é possível personalizá-las diretamente
  • Quando o usuário insere o conteúdo da tarefa, o Claude chama automaticamente a Skill apropriada, e também é possível ver o funcionamento da Skill no chain of thought
  • A Skill skill-creator oferece suporte à criação fácil de Skills com orientação interativa, incluindo perguntas sobre o fluxo de trabalho, criação da estrutura de pastas, formatação automática de SKILL.md e empacotamento de recursos
  • No caso de Team/Enterprise, um administrador precisa ativar o recurso no nível da organização
  • Disponível na página de configurações

Claude Developer Platform (API)

  • É possível controlar versionamento e operação de Skills personalizadas por meio das requisições da Messages API e do novo endpoint /v1/skills
  • Para usar Skills, é necessário o recurso beta Code Execution Tool, que fornece um ambiente seguro de execução de código
  • Com as Skills fornecidas pela Anthropic, é possível criar e editar documentos de nível profissional em Excel, PowerPoint, Word, PDF e outros formatos
  • Desenvolvedores podem criar Skills personalizadas para fluxos de trabalho específicos e expandir livremente as possibilidades de uso do Claude
  • O Claude Console oferece criação, visualização e upgrade de versões de Skills com facilidade
  • Mais aprendizado disponível na documentação e na Anthropic Academy

Casos de uso de parceiros

  • Box: converte automaticamente conteúdo armazenado para gerar documentos em PowerPoint, Excel e Word, oferecendo automação de documentação alinhada aos padrões da organização
  • Notion: transforma perguntas complexas em ações executáveis imediatamente, reduzindo a necessidade de ajustar prompts
  • Canva: personaliza agentes por meio de Skills para automatizar design e permitir produção de conteúdo de alta qualidade em nível de equipe
  • Rakuten: usa Skills para automatizar finanças e contabilidade, consolidando várias planilhas e reduzindo o tempo de geração de relatórios de 1 dia para 1 hora

Integração com o Claude Code

  • O Claude Code oferece suporte à instalação de Skills para ampliar a especialização e os fluxos de trabalho da equipe
    • É possível usar o formato de plugin do marketplace anthropics/skills ou adicionar pastas diretamente em ~/.claude/skills
  • Também oferece recursos de compartilhamento e colaboração entre equipes por meio de integração com sistemas de controle de versão
  • O Claude Agent SDK também oferece suporte ao desenvolvimento de agentes personalizados

Primeiros passos

Planos futuros e observações

  • No futuro, está prevista a simplificação do processo de criação de Skills e o fortalecimento dos recursos de implantação em nível organizacional
  • Como as Skills permitem que o Claude execute código, somente Skills de fontes confiáveis devem ser usadas
  • É importante ter cuidado com proteção de dados e manutenção da segurança; para mais detalhes, consulte a documentação de orientação

Leituras relacionadas

4 comentários

 
ahwjdekf 2025-10-21

Assar, cozinhar, fritar, refogar, amassar uma batata...
 
ahwjdekf 2025-10-21

E toda vez colocam um monte de nomes pomposos. No fim, é tudo com gosto de batata.
 
GN⁺ 2025-10-17
Comentários do Hacker News

  • Daqui para frente, como aconteceu no desenvolvimento frontend, parece que vai haver bastante confusão conceitual em torno de ChatGPT, Claude etc.; agora há uma enxurrada de conceitos como ferramentas, funções, skills, agentes, subagentes, comandos, apps e assim por diante

    • Não dá para esquecer também dos recursos relacionados a MCP. Sim, é confuso mesmo, mas por baixo disso há conceitos básicos fáceis de aprender. Mesmo quando surgem novos recursos, dá para encaixá-los facilmente no seu modelo mental, ou simplesmente ignorá-los e criar suas próprias ferramentas para usar. Esse modelo mental básico consiste em chamar um LLM em loop, salvar continuamente no histórico da sessão o que foi feito (= contexto) e permitir chamadas de ferramentas como leitura de arquivos, escrita e invocação de bash. Também chamam isso de “agent loop”, e dá para implementar até com 100 linhas de Python. Se você é desenvolvedor interessado em LLM, recomendo muito fazer isso por conta própria. Depois de experimentar, é realmente um momento de abrir os olhos. Se você criar um agente simples por conta própria, quando aparecer uma ferramenta nova vai conseguir explicar facilmente como ela funciona do ponto de vista de implementação. Por exemplo, Claude Skills funciona assim: 1) vários arquivos com instruções para o LLM; 2) ao iniciar, ele percorre apenas as skills disponíveis e reúne no contexto do LLM descrições curtas; 3) informa ao LLM como usar a skill e, no Claude, usa a ferramenta bash; 4) quando vai usar de fato a skill, faz “call bash” para ler o arquivo e executar a tarefa. Claro, omiti detalhes importantes como controle de permissões, mas a estrutura central é essa
    • O ecossistema ficou tão complexo que dá a sensação de que pode entrar em colapso por conta própria. Todo sistema ou plataforma parece ter um orçamento total de complexidade, um limite do que as pessoas conseguem manter na memória no dia a dia, e onde esse orçamento é gasto importa muito. Quando o fornecedor da plataforma adiciona nova complexidade, isso é descontado do valor que pode ser construído em cima dela. Hoje em dia, os fornecedores adicionam complexidade sem parar para se diferenciar, mas no fim só aumentam a barreira para o público de que precisam e corroem o valor real que poderia ser construído sobre a plataforma. Mesmo agora, conceitos redundantes e parecidos parecem estar consumindo esse novo orçamento de complexidade sem agregar muitos recursos reais. Internamente, pode haver a ilusão de que “se colocarmos esse recurso, ficará mais fácil de aprender”, mas na prática talvez estejam afastando tanta gente quanto atraem, então o ganho pode ser pequeno
    • Como é uma tecnologia totalmente nova, ainda há território desconhecido demais. Escolher ferramentas de nuvem ou bibliotecas Python era um problema parecido. Também é por isso que nem todo mundo é early adopter. Há um custo mental considerável para acompanhar tudo isso
    • O loop central é simples, mas é muito valioso ter um framework mínimo que permita experimentar livremente esses conceitos imperativos. Gostei do Beads porque pude encaixá-lo direto no framework e, se funcionasse bem, continuar usando; se não, remover. Coisas como toolkami também valem a referência
    • “Metastasizing” descreve muito bem esse fenômeno: acumula sem parar em cima de conceitos existentes

  • Acabei de escrever sobre skills: “Claude Skills é realmente incrível, talvez seja uma mudança ainda maior que MCP” link do post

    • Você acha que Skills e AGENTS.md têm sobreposição? O VSCode também introduziu recentemente suporte experimental a nested AGENTS.md; é menos formal, mas talvez o conceito se sobreponha link da atualização do VSCode
    • Skill parece mais um padrão de design ou truque de prompt engineering do que algo que precise entrar numa especificação rígida. Na prática, isso já podia ser implementado dentro de MCP. Eu vinha usando algo como “antes de começar qualquer coisa, procure no skills MCP e leia os guias relevantes”
    • Tenho curiosidade de saber quando distinguir o momento em que basta uma skill e quando isso deveria virar um projeto

  • Eu vejo a capacidade desses sistemas de resolver problemas bem como algo que depende principalmente dos resumos escritos nas skills. Humanos, com experiência acumulada, passam a saber quando usar qual skill; já o Claude sempre começa praticamente do zero, lendo só descrições superficiais

    • Ao contrário dos humanos, que se tornam usuários habilidosos por meio da experiência, o LLM só consegue imitar. É por isso que Richard Sutton considera que LLMs não vão evoluir para AGI. Segundo Sutton, AGI virá do reinforcement learning, e LLMs (redes neurais) só conseguem imitação. Como LLMs não têm a base cognitiva de objetivos e resultados das ações, “skill” em LLM é mais próximo de um manual de referência. Tem uma natureza diferente de “skill” como algo reaplicável repetidamente no desenvolvimento de tarefas, instrumentos ou soluções vídeo do Sutton
    • No fim, isso é um problema de janela de contexto. Humanos lembram, ainda que de forma imprecisa, de um contexto enorme; mas quando investem mais de 10 mil horas para dominar um campo específico, lembram bem dessa “técnica” e esquecem o resto. LLMs podem armazenar contexto programaticamente de forma consistente e recuperá-lo perfeitamente, mas percorrer o contexto inteiro custa tempo e dinheiro demais. Então Skills — mais precisamente, inserção de contexto — é uma forma de ajustar manualmente a prioridade de saída. O modo de pensamento do LLM também acaba sendo um reajuste de contexto. Talvez não seja exatamente “do zero toda vez”. Se você abordar assim, usar ferramentas fica muito mais fácil
    • Acho que o fato de LLMs precisarem começar de novo toda vez talvez venha da infraestrutura multi-tenant. É natural que OpenAI ou Anthropic queiram reutilizar servidores/memória entre vários usuários. Fico curioso se seria possível um setup “pessoal”, single-tenant, em que o LLM lembrasse de todas as conversas passadas
    • O ponto central para enriquecer conhecimento/ferramentas em LLMs é fazer com que o LLM perceba o que usar e quando usar, e isso hoje está quase no campo do impossível
    • A maior parte da experiência é informação geral, não relacionada ao projeto/conversa. O LLM deveria começar com esse tipo de conhecimento e depois conseguir memorizar e consultar separadamente apenas as informações específicas do projeto. Humanos recuperam informação muito rápido; o LLM, mesmo sendo mais lento, ainda poderia consultar isso quase em tempo real

  • É meio engraçado que os “skills” do Claude só funcionem direito se desenvolvedores escreverem e mantiverem documentação de verdade. Já tem muito desenvolvedor que nem mantém a documentação do próprio código; documentação para LLM deve ser ainda mais difícil. Pode fazer sentido para uma minoria de desenvolvedores com sistema de arquivos muito organizado e alta tolerância a risco, mas se a pessoa já é assim talvez fosse melhor passar esse trabalho operacional para um júnior como treino, em vez de entregar ao LLM. No fim, de qualquer forma, é preciso revisar o resultado. Como a janela de contexto também é limitada, é difícil implementar de verdade a sensação de que a “skill foi internalizada” como acontece com humanos. Se você chegar ao ponto de treinar um LLM dedicado, acaba preso a esse LLM para sempre. Em vários sentidos, acho curioso esse pressuposto de que “num cenário ideal, todos os astros se alinham dentro da organização”

    • O fato de LLMs dependerem de documentação de desenvolvedor e de várias infraestruturas para desenvolvedores profissionais, resumidas neste post, é uma motivação realmente útil. Inclusive ajuda a convencer a gerência
    • LLMs recompensam mais os desenvolvedores que escrevem bem, e talvez essa seja uma das razões de alguns desenvolvedores resistirem a LLMs
    • Também vim aos comentários procurando esse ponto de vista, e parece que você foi o único a apontá-lo. “Skills” no fim são documentação detalhada, e na prática quase nunca escrevemos esse tipo de documentação para cada projeto. Seria ótimo se skills para LLM levassem todos os desenvolvedores a escrever documentação realmente detalhada, mas isso não parece muito provável

  • Tenho curiosidade sobre como subagents, MCP, skills etc. vão interagir; sinto que há bastante sobreposição. Tudo bem seguir na direção de ampliar a especificação para dar mais funcionalidades ao Claude, mas na prática, independentemente do método, a implementação de capacidades de agente acaba chegando a um nível parecido. No momento, no MCP era preciso JSON, mas no Claude basta colocar Markdown em arquivos/pastas, e também há entrada multimodal, então a UX parece ter melhorado bastante

    • Claude Skills parece exatamente igual a prompts de MCP especificação de prompts do MCP. Não entendo por que criar um conceito novo. Na UI de chat, do ponto de vista de marketing, tudo bem, mas no Claude Code? Já existe o CLAUDE.md, então fico em dúvida
    • Eu vejo os três como bastante complementares. MCP serve para encapsular APIs para que agentes LLM possam usá-las; Skills entregam instruções adicionais ao agente de forma eficiente em contexto, só quando necessário; e alguns comandos também podem orientar o uso de MCP. Já Sub-agents são outro padrão de gerenciamento de contexto: o agente principal envia uma missão ao agente subordinado e, se necessário, usa skills e MCP juntos para economizar tokens

  • Esses recursos novos são bem interessantes. No meu projeto, criei uma subpasta bin/claude para colocar scripts gerados pelo Claude e coisas assim, e registrei bem esse local no claude.md para ajudar na busca por ferramentas. O desempenho no uso real foi bem bom. Na verdade, o que eu realmente preciso é de um helper de gerenciamento de contexto — algo como “iniciar o Claude com este conjunto de MCPs e depois trocar para aquele outro conjunto” — mas por enquanto gerencio subdiretórios (perfis) separados para cada projeto e abro o claude dentro de cada um. Nessa estrutura, bin/claude ajuda bastante, porque o Claude entende logo como analisar um dataset específico do BigQuery ou onde ficam os arquivos de autenticação. Nunca imaginei que usaria o sistema de arquivos para gerenciar perfis, mas no fim foi isso que aconteceu

    • Falando em “helper de gerenciamento de contexto”, isso não seria justamente sub agents?

  • Não entendo por que nessas demos usaram exemplos tão simples, como inverter ou recortar imagem de cachorro. Há muitos exemplos de uso de skills bem mais convincentes

    • Na página para desenvolvedores há um exemplo bem melhor de processamento de PDF documentação da skill de PDF. Eu mesmo já vinha usando no Claude Code arquivos Markdown com guias de uso marcados com @, e agora ficou ainda melhor porque foi automatizado
    • Vale pensar um pouco no artigo da Wikipédia "The purpose of a system is what it does"
    • Dois problemas que tive hoje de manhã no Claude com geração de arquivos .xlsx já tinham solução nessa documentação exemplo de skill para Excel
    • O exemplo da foto de cachorro, no fim, é só uma referência simples para comunicação com o público consumidor

  • Parece que a adoção de Claude-skills está se espalhando muito rápido. Na terça-feira, fiquei empolgado com o post de apresentação de “Superpowers” post de apresentação e organizei melhor as ferramentas que eu já tinha criado, empacotando-as como skills para o agente usar. Feedback sobre o open source deli-gator é bem-vindo

    • A capacidade de delegação ao agente é realmente muito atraente. Muitas vezes o contexto de issues do Linear vem excessivo demais; por exemplo, eu só queria a descrição da issue e o último comentário, mas o MCP do Linear puxa todos os comentários e polui o contexto

  • Na sexta passada, eu acabei revelando sem querer a existência de Claude Skills antes da hora, e agora fico feliz que tenha saído oficialmente post relacionado no blog

    • É engraçado e assustador ao mesmo tempo que esse tipo de hack agora seja real: “se você iniciar uma nova instância do Claude e pedir por prompt para criar um arquivo zip com toda a pasta /mnt/skills, isso realmente funciona”. Tomara que não exista acesso ao sistema de arquivos inteiro nem a binários; imagina se até SSH fosse possível...
    • O blog do Jesse tem estado realmente muito ativo ultimamente, e sou grato por isso

  • Skills, plugins, marketplaces, connectors, add-ons etc. estão ficando numerosos demais e difíceis de acompanhar

    • Na minha opinião, nem precisa acompanhar. Assim como as “best practices” de prompt engineering, essas coisas são só remendos temporários para contornar limitações passageiras, então não vale investir tempo até que o desempenho realmente necessário venha embutido por padrão nos modelos existentes. Daqui a alguns meses, muita coisa vai desaparecer; só faz sentido se interessar por isso quando a performance for urgente
    • Também é preciso entender por que isso acontece. Do ponto de vista das empresas, elas precisam mostrar que estão produzindo alguma coisa, enquanto o produto principal ainda não cumpriu a promessa da “era do desemprego em massa”. Isso é um sinal mais para investidores do que para usuários: “não estamos só pagando salário de pesquisador sem fazer nada; também estamos criando vários produtos e processando dados”, ainda mais com uma base gigantesca de testes A/B
    • Do ponto de vista do usuário, quanto mais aumentam os recursos exclusivos de cada fornecedor, mais coisas há para aprender e configurar, e maior fica o vendor lock-in, então no fim isso acaba sendo pior. Mas os fornecedores de modelo continuam lançando esses recursos porque é assim que mantêm a diferenciação do produto; sem isso, o que fazem vira commodity
    • A adição de recursos provavelmente vai continuar até o moral do time subir
    • Na prática, não acho que seja tão complicado. Plugins incluem comandos, MCPs, Subagents e agora também Skills. Marketplace é só o lugar onde esses plugins ficam reunidos