Some teams pull skills and instructions for AI coding agents from external repositories. Even if you checked the contents when you pulled them in, the source repository keeps changing. If you miss the updates, you stay on old versions; if you pull in the latest without noticing, unchecked content reaches your agents.
APM (Agent Package Manager), published by Microsoft, is a tool for managing these imports with a definition file called apm.yml. On November 2, 2026, documentation stating that Dependabot can update APM dependencies was added to GitHub's documentation repository (github/docs), and it was announced in the GitHub Changelog the next day, November 3. The announcement says it is generally available on all github.com plans. In this article, based on the documentation and the documents in the APM repository, we sort out what is updated automatically and what is not covered (we reviewed the source on November 7, 2026, and checked it against the live pages and the announcement on November 11).
What APM manages
The APM README describes the tool as "a dependency manager for AI agents". You declare instructions, skills, prompts, plugins and MCP servers for agents, such as package.json and requirements.txt, in apm.yml, and apm install deploys them into the configuration of each agent (Copilot, Claude, Cursor and others). The README's example looks like this (we omitted comments and some entries).
name: your-project
version: 1.0.0
targets:
- copilot
dependencies:
apm:
- anthropics/skills/skills/frontend-design
- microsoft/apm-sample-package#v1.0.0
mcp:
- name: io.github.github/github-mcp-server
transport: httpAs in #v1.0.0, you pin a version by writing a tag, commit or branch after #. The resolved result is recorded in apm.lock.yaml together with the commit SHA and a hash of the contents. According to the repository's CHANGELOG and releases, the latest version is 0.35.0, released on October 22, 2026 (as of November 11).
How Dependabot updates
To use Dependabot with APM, specify apm for package-ecosystem in dependabot.yml. In the documentation's support table, APM is listed as follows.
- Version updates: supported
- Security updates: not supported
- Private repositories: supported
- Private registries: supported (git only)
The targets are git dependencies listed in dependencies.apm and devDependencies.apm of apm.yml. How they are updated depends on how the version is pinned. The table in the source can be summarized as follows.
| Pinning method | Examples | Dependabot behavior |
|---|---|---|
| SemVer tag | octo-org/octo-skills#v1.0.0 | Bumps to the latest SemVer tag |
| Commit SHA | octo-org/octo-skills#<40文字のSHA> | Bumps to the commit of the latest annotated, non-prerelease release tag and adds the tag name as a comment (e.g. # v1.4.0) |
| Branch | octo-org/octo-skills#main | Bumps to the latest commit on the branch. The definition file keeps the branch name, so only apm.lock.yaml changes. Requires an existing lockfile |
In addition to regular tags such as v1.4.0, Dependabot also recognizes tags prefixed with the package name, such as review-v1.4.0. The prefix must match the package name (the repository name, or the last segment of a virtual package's path).
As for the lockfile, the documentation says that if apm.lock.yaml exists, Dependabot runs apm lock to regenerate it, and if it does not exist, Dependabot does not create one.
Forms that are not updated
The source also lists the entries Dependabot does not update.
- Object-form entries (in the form of
git:,registry:,id:andpath:) andmcp:entries - Entries without a version (e.g.
octo-org/octo-skills) - Local paths (e.g.
./my-package) - Entries hosted on Azure DevOps
- Entries fetched with
http://orgit:// - Entries written in YAML block style (
>or|) or as quoted strings containing escapes - Shortened commit SHAs
- In definition files that set
registries.default, entries written in shorthand such asocto-org/octo-skills#v1.2.0(entries with an explicit clone URL are updated)
Entries without a version, such as anthropics/skills/skills/frontend-design in the README example, fall under the second item above. Even with Dependabot in place, you will not receive update proposals for such entries. MCP server entries are also not covered.
Security updates are not covered
In the support table, security updates for APM are listed as "not supported". The Changelog announcement also says it "covers version updates, not security updates". For npm or pip dependencies, Dependabot can open pull requests to fixed versions based on vulnerability advisories, but that mechanism is not available for APM. All you receive are version update proposals triggered by new tags or commits.
The Changelog announcement says it is generally available on all github.com plans and is scheduled to ship in GitHub Enterprise Server 3.24. The documentation's feature definition file (data/features/dependabot-apm-support.yml) also targets GitHub.com and GitHub Enterprise Cloud, as well as GitHub Enterprise Server 3.24 and later. As of November 11, GitHub Enterprise Server 3.24 has not yet been released.
APM has also been added to the support table for the waiting period before update proposals (cooldown), and it supports both the default number of days and per-SemVer-level days.
What to decide before adopting it (editorial team's proposal)
The following are our editorial suggestions based on the source documentation and the APM documents. We have not actually run Dependabot's APM updates on a real repository.
Use consistent pinning. Pin entries you want update proposals for with a SemVer tag or a 40-character SHA. Entries without a version and shortened SHAs fall outside Dependabot's scope. Making it an internal rule that imported skills must always specify a version reduces the number of entries that never get proposals.
Read the contents in the proposed pull request. Skills and instructions directly change how agents behave. The APM README also says "prompts are programs for LLMs" and provides a check for hidden Unicode characters at apm install time. A Dependabot pull request is a notice that "a new version is available", so a person should read the actual diff. Setting cooldown to wait a few days before receiving proposals is another option if you are not in a hurry to pull in updates.
Create the lockfile first. Updating branch-pinned entries and regenerating the lockfile both assume that apm.lock.yaml exists. According to the APM documents, apm lock only resolves dependencies and writes the lockfile, without deploying anything into agent configurations.
We covered the idea of pinning GitHub Actions action references in our article on actions.lock. For evaluating whether imported skills are actually useful, see our article on evaluating AI skills.
Scope of verification
On November 7, 2026, we reviewed the diff of commit e755a93 (November 2, 2026, "Update docs with apm package manager support") in GitHub's documentation repository (github/docs), along with the source on main for Dependabot's support table, the option descriptions and the description of version tags. We also read the microsoft/apm README, the CHANGELOG (0.35.0) and the description of
apm lock(document research). On November 11, 2026, we confirmed that the live pages on docs.github.com (support table and option descriptions) match the source, and reviewed the GitHub Changelog announcement (November 3, 2026). We did not test Dependabot updates or run APM.
GleamHub helps with how to manage AI agent configuration within your development process as part of our development, AI and automation consulting. What needs deciding depends on your team structure and the agents you use, so please reach out via our contact form.
References
- GitHub Changelog — Dependabot version updates support Agent Package Manager (November 3, 2026)
- GitHub Docs — Dependabot supported ecosystems and repositories
- GitHub Docs — Dependabot options reference
- github/docs — commit e755a93（Update docs with apm package manager support）
- microsoft/apm — README
- microsoft/apm — apm lock
