Automating AI Skill Updates with Dependabot and APM

I want shared skill updates to arrive as PRs, too

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. 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.

What is APM?

APM (Agent Package Manager) 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 supports various agents, so you can manage skill configurations centrally even when developers use different agents.

Set up the publishing and consuming repositories

I created two public repositories.

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.

Configure APM and Dependabot

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. 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, so I set default-days: 0 to test a newly published tag immediately.

Update the skill

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 and reviewed the added instructions.

The problem: the dependency declaration and installed skill drift apart

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.

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.

A possible improvement: automate reinstallation and the follow-up commit

The actual Dependabot PR #6, which I used to test this again, ended up with two commits:

The reinstallation job committed the changes automatically, and the subsequent audit of the updated commit SHA also passed.

The process became a little more complicated than I expected for this task, but this reinstallation workflow let me distribute skill updates automatically through GitHub.

Closing thoughts

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.