Dependabot Now Updates Agent Package Manager: Version-Update PRs for Agent Skills, Prompts and Instructions

Agent skills, prompts and instruction packages have quietly become dependencies: versioned, shared across machines, pinned in some repositories and floating free in others. On Nov. 3, 2026, GitHub made them first-class citizens of its dependency tooling — Dependabot version updates now support Agent Package Manager (APM), the ecosystem that resolves those agent artifacts from git repositories.

Per the changelog, Dependabot opens pull requests to update supported git dependencies declared in apm.yml and regenerates apm.lock.yaml when it is present. The support is generally available on github.com for all GitHub plans and will arrive in GitHub Enterprise Server 3.24.

What changes in practice

Add an apm entry to .github/dependabot.yml, point it at the directory holding apm.yml, and pick a schedule:

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

From there, two things happen on that schedule. First, Dependabot checks the git dependencies your apm.yml declares and opens a version-update pull request when a newer release exists. Second — and this is the part that matters operationally — it regenerates apm.lock.yaml in the same pull request if your repository keeps one.

A manifest bump without a lockfile refresh is how agent setups drift. Your laptop resolves the newest skill revision while CI, a teammate’s container, or an overnight agent lane keeps the old pin. Regenerating the lockfile inside the pull request keeps every lane identical after merge, which is the whole point of a lockfile.

Capability	APM support today
Version-update pull requests	Yes, for supported git dependencies in apm.yml
apm.lock.yaml regeneration	Yes, when the lockfile is present
Security-update pull requests	No — explicitly out of scope
Availability	GA on github.com for all plans; GitHub Enterprise Server 3.24

Standard Dependabot levers apply as documented in the options reference: allow, ignore, groups, labels, open-pull-requests-limit and cooldown. The reference lists apm as a supported package-ecosystem value and spells out ecosystem-specific versioning behavior worth reading before your first pull request lands.

How APM versions resolve

APM packages are git repositories, so Dependabot resolves versions from git tags rather than a registry index. The documented rules explain most surprising pull requests:

• Plain release tags such as v1.4.0 are recognized directly.
• Package-scoped tags resolve when the tag prefix matches the package name — the repository name or the last component of a virtual package path. For a package named review, review-v1.4.0, review--v1.4.0 and review_v1.4.0 all work.
• Prereleases are understood: any SemVer prerelease identifier, commonly alpha, beta and rc, is treated as a prerelease, so review-v2.0.0-beta.1 will not quietly replace a stable pin with a beta.
• Commit SHA pins move only to annotated, non-prerelease release tags.
• Build metadata after + is ignored for version precedence.

General version-update behavior carries over as well: Dependabot applies a default three-day cooldown before a fresh release is considered, and update status shows under Insights, Dependency Graph and Dependabot in your repository.

The gap: no security updates

The changelog is explicit that this covers version updates, not security updates. A compromised or vulnerable agent skill will not trigger an automated security pull request on this path. Your review policy is the only control between an upstream repository and the instructions your agents execute.

Treat agent-package pull requests the way you should treat third-party plugin installs: check what actually changed in the upstream repository between the two tags, not just that the diff looks small. A skill is executable instructions for your agents, so a fast-forward merge is a trust decision, not housekeeping.

What to do this week

1. Inventory where apm.yml lives. Monorepos may need several directory entries.
2. Add the apm entry and watch the first pull request: confirm the lockfile regenerates alongside the manifest bump.
3. Set cooldown and allow or ignore rules for noisy skill repositories before they flood your review queue.
4. Keep a human merge gate on agent packages. Version automation removes the staleness excuse; it does not remove the trust question.

Dependency tooling spent a decade teaching teams that unmanaged versions rot. Agent artifacts are younger and rotted faster, because nothing watched them. They are watched now — reviewed, lockfile-pinned and schedulable like everything else in the repository.

Related reading: Plugins, Gists, and Rotting AGENTS.md, MCP Marketplace Security After MCPJacking and Plugin4Shell: Review, Pin, Verify, and Codex Skills Setup.