Updating Agent Package Manager (APM) Dependencies with Dependabot: Checking What Gets Rewritten for Each Way of Writing apm.yml

Hello! I'm Yuji Nishimura from the Operations Department!

When you share Agent Skills, prompts, and instruction files as dependencies in apm.yml with APM (Agent Package Manager), keeping up with new versions of those dependencies tends to be a manual task. On November 3, 2026, Dependabot version updates added support for APM.

This article summarizes the results of running the official Dependabot CLI locally, without creating a repository on GitHub. It covers what Dependabot rewrites for each way of writing apm.yml (tag, commit SHA, branch) and how apm.lock.yaml is regenerated, as well as notations that are not updated and operational points to watch out for, such as the 3-day cooldown.

What changed

• Date: November 3, 2026 (GitHub Changelog)
• Summary of the change: Dependabot creates update PRs for git dependencies written in apm.yml. If an apm.lock.yaml exists, it is regenerated. Only version updates are covered; security updates are not included
• Availability: GA on all plans on github.com. GitHub Enterprise Server is planned for 3.24
• Official links: Changelog, Dependabot supported ecosystems and repositories: APM

Behavior by how apm.yml is written

Combining what I verified with the description in the documentation, Dependabot's behavior and the files changed in the PR differ depending on how apm.yml is written, as shown below. The diagram is a conceptual diagram I made myself, not an official one.

Both dependencies.apm and devDependencies.apm are covered. If there is no apm.lock.yaml, Dependabot does not create a new lockfile. The documentation also says that dependencies written as local paths, mcp:, Azure DevOps, or abbreviated SHAs are not updated (I have not tried these).

The dependabot-core README says that the only rewrite targets for SHA pins are annotated tags (tags created with git tag -a); lightweight tags and branches are not used. I have not tried pinning by SHA in a repository that has only lightweight tags.

Adding an apm entry to dependabot.yml

Specify the directory that contains apm.yml and add an entry with package-ecosystem: "apm" (this is written exactly as in the steps in the Changelog and documentation).

version: 2
updates:
  - package-ecosystem: "apm"
    directory: "/"
    schedule:
      interval: "weekly"

Trying it out

Environment and method

• macOS 26.7.2 (arm64), Docker (Colima 0.10.3)
• Dependabot CLI v1.97.0, updater image ghcr.io/dependabot/dependabot-updater-apm:latest (built on November 5, 2026 (UTC); the APM CLI in the image is 0.34.0)
• APM CLI 0.35.0 for creating the initial apm.lock.yaml

The Dependabot CLI does not read .github/dependabot.yml; it runs from a job definition file. I passed the same content as the dependabot.yml above using the following job definition.

job:
  package-manager: apm
  allowed-updates:
    - update-type: all
  experiments:
    enable-beta-ecosystems: true
  source:
    provider: github
    repo: example/apm-demo-a
    directory: /

dependabot update -f input.yml --local ./proj-a -o out.yml

The update job runs using the folder specified with --local as the source. No PR is created on GitHub; instead, the contents of the PR that would have been created (the title and the updated files) appear in the log. All dependencies are in public repositories, and I did not pass a GitHub token. The images are the output of a script I wrote myself (show-prs.py), which writes the updated files from the log into a copy of the folder and displays them with git diff.

1. Without a lockfile

I ran it against the following apm.yml (no apm.lock.yaml).

name: dependabot-apm-demo-a
version: 1.0.0
targets:
  - claude
dependencies:
  apm:
    # Pinned by tag
    - microsoft/azure-skills#v1.2.97
    # Pinned by commit SHA (initial commit)
    - microsoft/apm-sample-package#318a84391e7f7a39e3a3f4b5a1bbb09c45ee8a6e
    # No ref
    - anthropics/skills/skills/frontend-design
    # Object format
    - git: https://github.com/tbhb/vale-ai-tells.git
      ref: v1.35.0
devDependencies:
  apm:
    # Dev dependency (pinned by tag)
    - stbenjam/skillsaw#v0.20.0

One PR was created for each dependency that was a candidate for updating, three PRs in total.

• Tag: microsoft/azure-skills#v1.2.97 became #v1.2.110. Only that one line changed; the comment lines and ordering were left as they were
• Commit SHA: The SHA of the initial commit was rewritten to the commit of the annotated tag v1.0.0 (fb28516...), and # v1.0.0 was added at the end of the line
• devDependencies: stbenjam/skillsaw became #v0.22.0. In the log, this PR's dependency is treated as a non-production dependency (development). This is separate from the feature that groups PRs with the groups setting in dependabot.yml
• No ref / object format: Neither was a candidate for an update check (they do not appear in the log's Checking if ... lines), and no PR was created
• Lockfile: In all three, only apm.yml changed, and apm.lock.yaml was still not created

For azure-skills, the remote has tags up to v1.2.114, but v1.2.110 was chosen. The log shows the following.

INFO Filtered git tag v1.2.111 for microsoft/azure-skills: released 2026-11-03 (2/3 cooldown days)
INFO Filtered git tag v1.2.113 for microsoft/azure-skills: released 2026-11-04 (1/3 cooldown days)
INFO Filtered git tag v1.2.114 for microsoft/azure-skills: released 2026-11-05 (0/3 cooldown days)

The job does not set cooldown, but as the documentation states, a 3-day cooldown applies to version updates even when nothing is configured, and versions less than 3 days old are not chosen. For a package that is tagged every day, the version proposed in the PR will always be one published several days earlier. The documentation says the number of days can be changed with default-days and similar options under cooldown, but I have not tried this.

2. With a lockfile

I ran it on two folders where I had created apm.lock.yaml with apm lock. As in step 1, the apm.yml in both has name, version, and targets: [claude] (below is an excerpt of only the dependencies part).

dependencies:
  apm:
    - stbenjam/skillsaw#v0.20.0

dependencies:
  apm:
    - microsoft/azure-skills#v1.2.97
    - microsoft/apm-sample-package#main

In the folder where I tried branches, I first pointed apm.yml at the commit just before main and locked it, then changed it back to #main and also rewrote the lockfile's resolved_ref to main. This reproduces a state where the branch has advanced after locking.

• Tag: Two files, apm.yml and apm.lock.yaml, changed. In the lockfile, resolved_commit and resolved_ref (v0.20.0 → v0.22.0) were updated. For the 6 individual skills (skills/skillsaw-*) installed from the same repository, these two fields were updated in the same way. content_hash got a new value in 3 of the 7 entries including the main package, and the other 4 kept the same value. In this folder I wrote skillsaw under dependencies, so the PR's dependency is treated as dependencies
• Branch: Only apm.lock.yaml changed; resolved_commit became main's head commit, and content_hash became the value corresponding to that commit's contents. apm.yml stayed at #main
• Branch without a lockfile: In a separate folder, when I wrote only microsoft/apm-sample-package#main without placing a lockfile and ran it, it was not loaded as a dependency, and neither a PR nor an error appeared
• apm_version: In both cases, apm_version in apm.lock.yaml changed from 0.35.0 to 0.34.0. What gets written is the version of the APM CLI that Dependabot uses, not that of the local APM CLI that created the lockfile

If the local APM CLI is newer, every time Dependabot creates an update PR, a line lowering apm_version is included in the diff. This line has nothing to do with the dependency update. Also, as of November 6, 2026, a dependabot-core PR (not yet merged) has been opened that upgrades Dependabot's APM CLI to 0.35.0 and, when the deployment target can be determined from targets: in apm.yml or deployments in the lockfile, regenerates using apm install instead of apm lock. Once it is merged, this diff and the regeneration method may change.

3. When the new version cannot be resolved by apm lock

microsoft/azure-skills#v1.2.97, which was written in the folder where I tried branches, did not become a PR. Dependabot determined the update target to be 1.2.110, and then failed at apm lock, which regenerates the lockfile.

microsoft/azure-skills -- Failed to download dependency microsoft/azure-skills: Agent Plugin portable identity is owned by plugin.json; conflicting apm.yml fields: name, version

With the local APM CLI 0.35.0 as well, azure-skills#v1.2.110 could not be locked with the same message, while v1.2.97 could be locked. The failure was not because the APM CLI that Dependabot uses is old, but because the current APM CLI (0.35.0) cannot resolve this version of the package (as of November 6, 2026).

On the other hand, in the step 1 folder without a lockfile, the update to the same v1.2.110 was created as a PR. Without a lockfile, apm lock does not run, so even updates to versions that apm lock cannot resolve become PRs. If you keep a lockfile in place, updates that cannot be resolved do not become PRs and are recorded as Dependabot errors.

In the local CLI, the above message appeared together with the error type dependency_file_not_resolvable. I have not verified how it is displayed on GitHub.

Discussion of the results

• What I confirmed: For the combinations of tag (without and with a lockfile), commit SHA (without a lockfile), and branch (without and with a lockfile), the rewrite targets and the changed files split as the documentation describes. Entries with no ref and in object format were not updated, and branch pins were not targeted without a lockfile
• What is only in the official information and was not tried: The combination of commit SHAs with a lockfile, SHA pins in repositories with only lightweight tags, and the handling of shorthand forms when registries.default is set are based on the documentation and README descriptions, and I did not try them this time
• Operational points to note: Dependencies you want updated automatically need to be written as strings with a ref attached, such as owner/repo#v1.2.0 (the documentation says that if you set registries.default in apm.yml, shorthand forms are not updated). New versions are not chosen until 3 days after publication unless cooldown is set. When a lockfile exists, the PR diff also includes the line where apm_version changes to the version of Dependabot's APM CLI

Because I verified this with the local Dependabot CLI, I have not checked how PRs look on GitHub (body, labels) or execution on a schedule. In particular, I don't know whether enable-beta-ecosystems is needed on GitHub, so if PRs are not created, it seems necessary to check for the message above. I also have not tried dependencies in private repositories, cooldown or groups settings, or package-scoped tags (tags with the package name prefixed, such as review-v1.4.0). I can't say whether these results apply as-is if you keep skills in an internal private repository.

Summary

According to the Changelog, adding package-ecosystem: "apm" to .github/dependabot.yml makes Dependabot create PRs that update the dependencies in apm.yml. In the range I verified with the local Dependabot CLI, apm.yml was rewritten for tag and commit SHA pins, only apm.lock.yaml was updated for branch pins, and dependencies with no ref or in object format were not updated.

If you leave Agent Skills updates to Dependabot, it seems best to write dependencies as strings pinned by tag or SHA and to commit apm.lock.yaml as well. With a lockfile, branch pins also become update targets, and updates to versions that cannot be resolved with apm lock do not become PRs and are recorded as errors.

I hope this is helpful to someone.

Reference links:

• Dependabot version updates support Agent Package Manager (GitHub Changelog)
• Dependabot supported ecosystems and repositories: APM (GitHub Docs)
• Dependabot options reference: cooldown (GitHub Docs)
• dependabot-core: apm (GitHub)
• dependabot-core PR #16792: Regenerate apm.lock.yaml with apm install when it records deployments (GitHub)
• Dependabot CLI (GitHub)
• microsoft/apm (GitHub)