GitHub padroniza 'agent skills' para levar instruções reutilizáveis a qualquer agente de IA

O GitHub apresentou um formato padronizado para capturar trabalho de engenharia repetível em arquivos que equipes podem revisar e reutilizar entre diferentes agentes de IA. A proposta, detalhada no blog da empresa, gira em torno de um diretório versionado cujo núcleo é o arquivo SKILL.md, que descreve quando e como executar uma tarefa.

A discussão foi conduzida ao vivo durante o GitHub Universe 2026, em sessão com Shishir Tewari, gerente sênior de Engenharia de Dados da Procore, intitulada "Build once, run on any agent: a practical guide to agent skills".

O que separa a instrução da execução

A premissa central é que a skill carrega o conhecimento do procedimento, mas não os meios para executá-lo. Uma skill pode descrever como consultar um banco de dados, por exemplo, mas não concede acesso a esse banco — ferramentas, credenciais e permissões permanecem específicas do ambiente que hospeda o agente.

Esse desenho resolve um problema recorrente: o contexto que hoje se perde em chats ou fica preso na cabeça de um único especialista. Ao transformar esse conhecimento em arquivo versionado, a instrução passa a ser revisável como qualquer outro artefato de código.

Verificação adversarial como princípio

O texto usa o exemplo do Proof Agent, voltado a checar mudanças geradas por IA contra a solicitação original. A regra que orienta a skill é direta: autoverificação não é verificação. Por isso, um verificador independente examina as alterações e apresenta evidências para suas conclusões.

O frontmatter da skill nomeia a tarefa e descreve seu propósito, enquanto a seção "When to Verify" define quando acionar o procedimento e o restante das instruções detalha o que o verificador revisa e quais evidências incluir.

Pipeline de dados como caso de uso

O exemplo Data Forge mostra como várias skills podem trabalhar em conjunto. Em um pipeline de suporte, a skill forge-init descobre detalhes como tabelas de origem e convenções de nomenclatura, gravando-os em um manifesto resolvido que as demais skills leem para obter contexto do projeto.

Na sequência, a forge-builder coordena o trabalho da issue até o pull request, usando forge-dbx para consultar a plataforma de dados e forge-lint para aplicar os padrões da equipe. Uma pessoa revisa as decisões propostas ao longo do caminho, e o pull request resultante reúne código do pipeline, mudanças de esquema e testes.

Cada skill tem responsabilidade definida e compartilha o contexto do projeto em vez de redesenhá-lo de forma independente. Quando uma etapa muda, altera-se uma única skill — e o conhecimento deixa de depender da disponibilidade de quem o detinha.