Resposta rápida
Se o projeto declara skills, prompts ou instruções em apm.yml, adicione uma entrada com package-ecosystem: "apm" ao arquivo .github/dependabot.yml. Informe o diretório que contém o manifesto e uma agenda diária, semanal ou mensal. O Dependabot passará a abrir pull requests para referências Git compatíveis e regenerará apm.lock.yaml quando o lockfile já existir.
O suporte foi anunciado pelo GitHub em 3 de novembro de 2026 e está disponível no github.com para todos os planos. Ele cobre atualizações de versão, não atualizações de segurança. Revise cada pull request, execute os testes do repositório e inspecione a mudança de conteúdo antes do merge; automatizar a versão não torna uma skill confiável.
O que o Dependabot atualiza no APM
O Agent Package Manager usa apm.yml para declarar o contexto que agentes de programação precisam, incluindo skills, prompts, instruções e pacotes. O arquivo apm.lock.yaml fixa a árvore resolvida com referências e hashes de conteúdo. O novo ecossistema apm do Dependabot procura dependências Git declaradas em dependencies.apm e devDependencies.apm.
Quando encontra uma referência compatível mais nova, o Dependabot abre um pull request. Se apm.lock.yaml já estiver no repositório, ele executa apm lock e inclui o lockfile regenerado. Se o lockfile não existir, o Dependabot não cria um; gere e revise o arquivo com o fluxo oficial do APM antes de depender de uma instalação reproduzível.
Como configurar no repositório
O arquivo de configuração precisa estar na branch padrão em .github/dependabot.yml ou .github/dependabot.yaml. Crie uma entrada em updates com package-ecosystem: "apm", directory apontando para o diretório de apm.yml e schedule.interval com a frequência desejada. Para um manifesto na raiz, use directory: "/".
Comece com uma agenda semanal quando a equipe ainda não tem revisão automática para mudanças em contexto de agentes. O Dependabot aceita opções comuns como labels, reviewers, assignees, open-pull-requests-limit, ignore e cooldown, mas cada regra deve ter um objetivo claro para não esconder atualizações importantes nem criar uma fila impossível de revisar.
- Confirme que apm.yml está versionado e que as dependências Git usam referências explícitas.
- Crie ou abra .github/dependabot.yml na branch padrão e mantenha version: 2 no topo.
- Adicione package-ecosystem: "apm", directory: "/" e schedule.interval: "weekly" para um manifesto na raiz.
- Inclua reviewers ou assignees responsáveis por contexto de agentes e segurança da cadeia de suprimentos.
- Faça merge da configuração e acompanhe o primeiro job em Insights, Dependency graph, Dependabot.
Quais referências recebem atualização
A documentação do GitHub diferencia o comportamento pela forma de fixação. Uma tag SemVer é atualizada para a tag SemVer mais recente compatível com o formato. Um SHA completo de 40 caracteres é movido para o commit da versão anotada e não preliminar mais recente, com a tag registrada como comentário. Uma branch permanece com o mesmo nome no manifesto, mas o commit resolvido pode avançar no lockfile.
A atualização de branch exige um apm.lock.yaml existente, porque apm.yml continua apontando para a branch. Esse caso troca conteúdo sem uma alteração visível na referência do manifesto, por isso a revisão do diff do lockfile, do repositório de origem e dos arquivos compilados é especialmente importante.
O que não é atualizado automaticamente
O suporte atual não atualiza entradas mcp, dependências locais, referências sem ref, SHAs abreviados nem entradas em forma de objeto com git, registry, id ou path. Também ficam fora referências hospedadas no Azure DevOps e URLs de clone com http:// ou git://. O GitHub documenta outras restrições de sintaxe que devem ser conferidas antes de diagnosticar um job como quebrado.
Dependabot para APM também não cria alertas de vulnerabilidade para essas skills e instruções. A tabela oficial marca version updates como suportado e security updates como não suportado. Continue acompanhando avisos do repositório de origem, revisando permissões, procedência, mudanças de instrução e qualquer MCP incluído pelo pacote.
Como revisar o pull request com segurança
Trate uma skill como código que influencia decisões do agente. Antes do merge, compare o repositório, a tag ou o commit de origem, leia o diff das instruções e procure mudanças em ferramentas permitidas, comandos, rede, arquivos e credenciais. O lockfile ajuda a reproduzir conteúdo, mas não afirma que esse conteúdo é seguro para o seu ambiente.
Rode apm install ou o comando de validação adotado pela equipe em um ambiente isolado, compile para os mesmos harnesses usados em produção e revise os arquivos gerados. Execute os testes do projeto e um cenário de agente sem acesso a segredos reais. Para dependências privadas, use secrets do Dependabot e o tipo de registro Git documentado; nunca coloque token no apm.yml ou no dependabot.yml.
- Confirme proprietário, repositório, tag ou commit e compare as notas da versão.
- Revise o diff de apm.yml, apm.lock.yaml e dos arquivos de contexto gerados.
- Procure novas ferramentas, MCPs, comandos, permissões, caminhos e destinos de rede.
- Instale e compile em um ambiente descartável com credenciais fictícias ou ausentes.
- Aprove somente depois que testes e revisão humana cobrirem a mudança de comportamento.
Por que o pull request pode não aparecer
Primeiro confirme que o arquivo está na branch padrão, que package-ecosystem usa exatamente apm e que directory aponta para o local de apm.yml. Depois verifique se a dependência está em dependencies.apm ou devDependencies.apm, possui uma referência suportada e tem uma versão mais nova elegível. O cooldown padrão das atualizações de versão pode atrasar a consideração de um lançamento recente.
Se a dependência é privada, confira o registro Git, os secrets do Dependabot e o acesso do repositório. Consulte os logs do job antes de alterar a referência. Uma página GitHub Status operacional não prova que a configuração está correta; ela apenas ajuda a separar uma indisponibilidade ampla de um erro no manifesto, na autenticação ou na sintaxe.
Disponibilidade e limitações
O GitHub informa que o suporte a APM está disponível no github.com para todos os planos e será incluído no GitHub Enterprise Server 3.24. Esta verificação foi feita em 5 de novembro de 2026. Organizações que usam GHES devem confirmar a versão instalada e a documentação correspondente antes de copiar a configuração do GitHub.com.
APM e AgentPM não são o mesmo projeto. O recurso do Dependabot documentado aqui se refere ao Agent Package Manager mantido no repositório microsoft/apm, com apm.yml e apm.lock.yaml. Ferramentas que usam agent.json, agent.lock ou outro manifesto não são cobertas por esse ecossistema apenas porque têm um nome parecido.
Próxima ação útil
Escolha um repositório não crítico que já tenha apm.yml, crie uma entrada semanal para package-ecosystem: "apm" e mantenha apm.lock.yaml versionado. Quando chegar o primeiro pull request, valide a origem, o diff do contexto e o comportamento do agente em ambiente isolado. Só depois replique a política para outros repositórios.
Se nenhum pull request aparecer, use a referência de ecossistemas suportados para comparar a forma de fixação e consulte o job do Dependabot. Se o GitHub estiver com uma falha ampla, acompanhe a página oficial de status; se apenas um repositório falhar, corrija configuração, acesso ou referência sem ampliar permissões por tentativa.
Faça o próximo teste
Fontes consultadas
Os links abaixo servem para conferir conceitos, orientações oficiais e o critério editorial usado neste conteúdo.
- Dependabot version updates support Agent Package ManagerGitHub Changelog
- Dependabot supported ecosystems and repositoriesGitHub Docs
- About the dependabot.yml fileGitHub Docs
- Dependabot options referenceGitHub Docs
- Configuring access to private registries for DependabotGitHub Docs
- Agent Package ManagerMicrosoft on GitHub
- Install packages with APMMicrosoft on GitHub
- GitHub StatusGitHub