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.
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 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 | Stores the skill and tags its releases |
| 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:
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:
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.
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.
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.
The actual Dependabot PR #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 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.
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.