Automating AI Skill Updates with Dependabot and APM

A developer demonstrated an end-to-end workflow for keeping shared AI agent skills current by combining Microsoft's Agent Package Manager (APM) with Dependabot, publishing a skill in one public repository and consuming it in another. After adding the required enable-beta-ecosystems flag, Dependabot opened a PR bumping the pinned skill from v1.0.0 to v1.1.0, updating both apm.yml and apm.lock.yaml, though the lockfile's apm_version dropped from 0.35.0 to 0.34.0 because Dependabot used an older CLI. The test also required setting the cooldown to zero days to pick up a freshly published tag immediately.

When you use shared skills across multiple projects, keeping up with upstream changes becomes a concern. Copies go stale, and pulling in every update by hand gets tedious. On November 3, 2026, Dependabot added support for APM https://github.blog/changelog/2026-11-03-dependabot-version-updates-support-agent-package-manager/ . I tried updating a skill and following the change through a Dependabot PR, all the way to the files in the consuming repository and the agent's output. APM Agent Package Manager https://microsoft.github.io/apm/ is a dependency management tool for AI agents published by Microsoft. It treats skills, prompts, instruction files, and MCP servers as packages. Like npm, it handles declaring, pinning, and fetching dependencies. | APM file or command | Purpose | |---|---| | apm.yml | Declares the packages to use and their references | | apm.lock.yaml | Records resolved commits and hashes | | apm install | Fetches dependencies and places them where the target agent can read them | APM supports various agents, so you can manage skill configurations centrally even when developers use different agents. I created two public repositories. | Repository | Purpose | |---|---| | trknhr/shared-skills https://github.com/trknhr/shared-skills | Stores the skill and tags its releases | | trknhr/apm-demo https://github.com/trknhr/apm-demo | Installs the skill through APM and receives updates through Dependabot | shared-skills/ ├── apm.yml └── .apm/skills/pr-description/SKILL.md apm-demo/ ├── apm.yml ├── apm.lock.yaml ├── .github/dependabot.yml └── .claude/skills/pr-description/SKILL.md Installed by APM I published the v1.0.0 tag in shared-skills . In the consuming repository, I pinned the upstream package to v1.0.0 : apm-demo/apm.yml name: apm-demo version: 1.0.0 description: End-to-end Dependabot APM update experiment author: trknhr targets: - claude dependencies: apm: - trknhr/shared-skills v1.0.0 Running apm install placed the skill at .claude/skills/pr-description/SKILL.md and generated apm.lock.yaml . The lockfile records information such as the reference tag, resolved commit, and content hashes. Here is the Dependabot configuration: .github/dependabot.yml version: 2 enable-beta-ecosystems: true updates: - package-ecosystem: "apm" directory: "/" schedule: interval: "daily" cooldown: default-days: 0 I initially ran it without the beta flag, and the job failed https://github.com/trknhr/apm-demo/actions/runs/42845367950 . The log contained this message: apm is a beta ecosystem. Set enable-beta-ecosystems: true in your dependabot.yml so Dependabot fetches and updates apm.yml. After I added enable-beta-ecosystems: true , subsequent jobs succeeded. Although the announcement describes the support as generally available, this flag was required in my GitHub runs as of November 11, 2026. The default cooldown for version updates is three days https://docs.github.com/en/code-security/reference/supply-chain-security/dependabot-options-reference cooldown , so I set default-days: 0 to test a newly published tag immediately. I changed the publishing repository's apm.yml to version: 1.1.0 and published a new tag. The PR changed two files: apm.yml and apm.lock.yaml . The dependency reference was updated as follows: dependencies: apm: - - trknhr/shared-skills v1.0.0 + - trknhr/shared-skills v1.1.0 -apm version: 0.35.0 +apm version: 0.34.0 ... - resolved commit: 5e5c776... - resolved ref: v1.0.0 - version: 1.0.0 + resolved commit: 5775479... + resolved ref: v1.1.0 + version: 1.1.0 ... - content hash: sha256:3b8ba878... + content hash: sha256:4f140598... The apm version decreased because Dependabot used CLI version 0.34.0. The diff reflected both the dependency update and the difference in the tool that generated the lockfile. This PR did not include changes to the installed SKILL.md . Before merging, I also opened the upstream diff between tags https://github.com/trknhr/shared-skills/compare/v1.0.0...v1.1.0 and reviewed the added instructions. Accepting the Dependabot PR alone leaves you with an updated dependency declaration but an outdated skill file. To avoid confusion the next time someone updates their checkout, it makes sense to run apm install whenever apm.yml changes, then commit the manifest, lockfile, and installed files together. See the official Quickstart https://microsoft.github.io/apm/quickstart/ what-to-commit . Unlike dependencies managed with tools such as npm, skill files are often committed directly to the repository. Having the actual files included in the PR alongside the dependency update would be useful. The actual Dependabot PR 6 https://github.com/trknhr/apm-demo/pull/6 , which I used to test this again, ended up with two commits: | Author | Commit | Changes | |---|---|---| | dependabot bot | 320a87b | Updated the dependency reference and lockfile | | github-actions bot | 7c28153 | Installed the new skill and updated the installed file hashes | The reinstallation job https://github.com/trknhr/apm-demo/actions/runs/43338551342 committed the changes automatically, and the subsequent audit of the updated commit SHA https://github.com/trknhr/apm-demo/actions/runs/43338592063 also passed. The process became a little more complicated than I expected for this task, but this reinstallation workflow https://github.com/trknhr/apm-demo/blob/eae5e34e4055279c10c1e599610559c6fad5f696/.github/workflows/apm-redeploy.yml let me distribute skill updates automatically through GitHub. I was able to publish a shared skill update as a tag, receive it through a Dependabot PR, and carry the change through to the consuming agent's output. The main lesson was that Dependabot's PR and reinstalling the skill are separate steps. If you track the installed files in your repository, your update process needs to include the changes produced by apm install . This APM support covers version updates rather than security updates, but being able to bring skill updates into the usual PR review process is useful.