Agent Skills

• Agent Skills é um formato aberto para adicionar novas funcionalidades e conhecimento especializado a agentes de inteligência artificial
• Desenvolvido pela Anthropic e depois lançado como um padrão aberto, vem sendo adotado por diversos produtos de agentes
• As skills têm a forma de uma pasta composta por instruções, scripts e recursos, que o agente pode explorar para executar tarefas com mais precisão e eficiência
• Dá suporte a especialização por domínio, expansão de novas funcionalidades, workflows repetíveis e interoperabilidade
• Empresas e desenvolvedores podem usar isso para viabilizar a reutilização do conhecimento organizacional e a automação de implantações

---

Visão geral

• Agent Skills é um formato simples e aberto para dar aos agentes novas capacidades e especialização
• Cada skill é composta por uma pasta com comandos, scripts e recursos, que o agente pode carregar para aumentar a precisão e a eficiência nas tarefas

Por que Agent Skills?

• Os agentes estão cada vez mais poderosos, mas ainda existe o problema da falta de informação contextual para executar trabalho real com estabilidade
• As skills permitem carregar, quando necessário, conhecimento procedural e contexto específico de organização, equipe ou usuário
• Agentes que possuem skills podem expandir suas capacidades conforme a tarefa
• Autores de skills podem distribuir uma funcionalidade criada uma vez para vários produtos de agentes
• Agentes compatíveis permitem que os usuários adicionem novas funcionalidades imediatamente
• Equipes e empresas podem preservar o conhecimento da organização como pacotes portáteis com versionamento

O que é possível fazer com Agent Skills

• Especialização por domínio: empacotar conhecimento especializado, como revisão jurídica e análise de dados, em instruções reutilizáveis
• Novas funcionalidades: adicionar vários recursos, como criação de apresentações, construção de servidores MCP e análise de datasets
• Workflows repetíveis: transformar tarefas de múltiplas etapas em processos consistentes e auditáveis
• Interoperabilidade: reutilizar a mesma skill em vários produtos de agentes compatíveis

Estado de adoção

• Agent Skills é compatível com várias ferramentas de desenvolvimento de IA
• Alguns exemplos incluem Factory.ai, Gemini CLI, Mux, Ampcode, Letta, Autohand.ai, Spring AI, Goose, Piebald.ai, OpenAI Codex, Cursor, Databricks, Mistral Vibe, Roocode, VS Code, Agentman.ai, Trae.ai, Commandcode.ai, Firebender, Opencode.ai e Claude.ai

Desenvolvimento aberto

• O formato Agent Skills foi inicialmente desenvolvido pela Anthropic e publicado como padrão aberto
• Desde então, diversos produtos de agentes vêm adotando o formato, permitindo contribuições de todo o ecossistema
• É possível consultar o formato e skills de exemplo no repositório do GitHub

Como começar

• Na página “What are skills?”, é possível aprender a estrutura e o funcionamento das skills
• Em “Specification”, é possível conferir a especificação de formato do arquivo SKILL.md
• Em “Integrate skills”, é possível adicionar suporte a skills a um agente ou ferramenta
• No GitHub, é possível explorar as skills de exemplo e a biblioteca de referência

[cgl00]

Existe um repositório oficial da Anthropic, então por que estão fazendo esse tipo de projeto por terceiros?

[skageektp]

> Agent Skills é um formato aberto mantido pela Anthropic e aberto a contribuições da comunidade.

Então foi a Anthropic que criou o padrão, né

[cgl00]

Aqui também é oficial, né.. Parece que é diferente disso aqui, certo? https://github.com/anthropics/skills

[skageektp]

Sim, o que você enviou é a implementação
o que foi compartilhado no texto principal é a spec

Como, por exemplo,
o padrão de algo como o Docker = OCI
Docker, podman = runtimes de contêiner que implementam a OCI

(posso estar errado rs)

[cgl00]

Ah, então é a especificação e a implementação, né.. obrigado

[GN⁺]

Opiniões no Hacker News

• Esta discussão parte de uma dúvida sobre a necessidade de padronização
  Eu ainda acho que a essência de uma boa documentação é ser “escrita para humanos lerem com facilidade”. Fico me perguntando se realmente há motivo para forçar um novo formato. Se o ganho de produtividade for real, isso deveria poder ser comprovado com estudos comparativos

  • Além do que outras pessoas já disseram, acho que a padronização também abre oportunidades para uso em treinamento e RL
  • Houve de fato um experimento comparativo. Um funcionário da Hugging Face disse que, ao fazer fine-tuning do modelo Qwen3-0.6B com codex + skills, a pontuação no HumanEval melhorou em +6. O link relacionado está aqui, e o projeto está em huggingface/upskill
  • O sistema não é apenas documentação simples: ele cria um índice de todas as skills e o envia ao LLM em cada conversa. Assim, o LLM lê a skill só quando precisa. É um conceito parecido com a descobribilidade de recursos em GUI. Pessoalmente, acho uma estrutura centrada em README mais intuitiva
  • Eu automatizo tarefas de trabalho com Claude Code e conecto cada tarefa por comandos slash. No fim, skills também parecem ser apenas outra forma de documentação. No longo prazo, acho que o paradigma de skills vai desaparecer com a expansão da context window e a melhora da inteligência dos modelos
  • Mas, olhando para os modelos atuais, o Claude lê só até a descrição da skill e para, então o efeito de economia de tokens é grande. Em repositórios grandes, essa diferença é perceptível. Vale a pena divulgar esse padrão mais amplamente

• Nossa equipe teve sucesso ao tratar skills como funções reutilizáveis semideterminísticas
  Por exemplo, a skill /create-new-endpoint inclui todo o boilerplate, como atualização de OpenAPI e adição de testes de integração. Ao informar o número do ticket JIRA no CLI, o LLM conclui o trabalho com qualidade consistente

  • Alguém perguntou “como vocês testam a consistência ao longo do tempo?”

• Houve uma proposta para padronizar a estrutura de pastas

  .claude/skills
  .codex/skills
  .opencode/skills
  .github/skills
  

  • Ainda não é um padrão, mas a maioria das ferramentas de CLI faz scan de arquivos .md para executar. Mesmo assim, seria bom ter uma padronização integrada incluindo plugins
  • Disseram que o Codex começou e o OpenCode veio logo atrás. Tweet relacionado
  • Essa discussão também está acontecendo em agentskills/agentskills#15
  • Algumas pessoas disseram que “ainda está muito no começo, então padronizar agora pode limitar a criatividade”
  • Outra pessoa argumentou que seria melhor seguir a XDG base spec e usar caminhos como ~/.config/claude. O formato atual ~/.claude seria inconveniente

• Houve a dica de criar um README.md em cada subpasta para linkar as skills relacionadas. Isso também é útil para humanos. O texto relacionado é Claude Skills Considered Harmful

  • Surgiu a opinião de que “skills no fim são apenas READMEs de um tema específico”. Dá para organizar como skill aquilo que precisa ser explicado repetidamente. Nem é necessário seguir uma pasta padrão; basta adicionar ao contexto quando precisar
  • Outra pessoa disse que usar um executor de comandos como just ajuda tanto humanos quanto agentes

• Para mim, tratar skills como workflows explícitos foi eficaz
  Quando se define um procedimento completo como “faça X, depois Y, valide Z”, o agente entende isso como um modo único. Já diretrizes vagas em formato de guideline tendem a ser ignoradas

  • Alguém disse que aplicou ao Claude um sistema de hooks que ativa automaticamente uma skill em certas situações. Por exemplo, ao lidar com arquivos Python, ele carrega a skill relevante automaticamente
  • Outra pessoa apontou que a diferença entre skill e command é ambígua. Se no fim ambos são usados como comandos, fica a dúvida se essa distinção é realmente necessária
  • Houve quem dissesse que essa estrutura lembra notas do Obsidian ou coleções de comandos de CLI
  • Outra pessoa enfatizou que é preciso descrever com muita clareza as condições de ativação da skill. No Claude Code, é possível chamar explicitamente com algo como /foo, então ela prefere esse método

• Algumas pessoas acham que, com skills, dá para documentar conhecimento de domínio implícito. Regras que estavam só na cabeça do desenvolvedor podem ser registradas e reutilizadas no treinamento de LLMs

• Surgiu a pergunta: “o agente não usa skills se eu não pedir?”

  • Várias pessoas relataram o mesmo problema. Os modelos atuais não foram treinados com RLVR em torno de skills, então ficam confusos. A expectativa é que a próxima geração de modelos, como o Opus, use skills com muito mais estabilidade
  • Nas avaliações da Vercel, disseram que em 56% dos casos a skill não foi chamada. Em vez disso, relataram que a abordagem AGENTS.md foi mais eficaz em uma gama mais ampla de cenários. Blog relacionado
  • Quem usa Codex disse que, se você especificar o diretório de skills no AGENTS.md, funciona razoavelmente bem. Ainda assim, quanto mais skills existem, maior a chance de conflito, então é melhor manter tudo simples
  • Outra pessoa disse que quase não conseguiu usar skills e que, em vez disso, colocar o conteúdo da skill diretamente em AGENTS.md foi mais preciso

• Disseram que a terceira skill mais popular em skills.sh era simplesmente um link para download de comando. Esses arquivos SKILLS.md/AGENTS.md/COMMANDS.md no fim são apenas coleções de prompts, e podem ser perigosos se forem mal utilizados

  • Mas alguém respondeu que, no fim, com ferramentas o importante é o uso responsável

• Uma pessoa que está desenvolvendo uma nova linguagem de programação disse que usa AGENTS.md e SKILLS para fazer o LLM entender uma linguagem na qual ele não foi treinado. Graças à padronização, a integração com ferramentas ficou mais fácil

• O valor real não está no formato, mas na divulgação progressiva (progressive disclosure)
  Se você colocar todas as instruções em um único documento, desperdiça tokens desnecessariamente. O padrão de skills permite carregar os detalhes só no momento em que forem necessários. A padronização serve principalmente para distribuição e reutilização

  • Em resposta a isso, o desenvolvedor do projeto MOOLLM explicou que expandiu essa ideia com o conceito de Semantic Image Pyramid.
    GLANCE.yml → CARD.yml → SKILL.md → README.md aplica um refinamento progressivo nessa ordem.
    GLANCE, com 5 a 70 linhas, serve apenas para julgar “isso é relevante?”. CARD define a interface, SKILL traz o procedimento real e README é a explicação para humanos.
    Disseram que INDEX.md tem uma taxa de compressão mais de 80% maior que INDEX.yml e oferece uma estrutura narrativa.
    Links relacionados: INDEX.yml, INDEX.md
    Além disso, com a estrutura sniffable-python, dá para entender a API lendo apenas as 50 primeiras linhas do código.
    Materiais relacionados: explicação de Semantic Image Pyramid, sister-script, README do sniffable-python, SKILL do sniffable-python