AI coding agents increasingly rely on shared skills, prompts, instructions, and other reusable components. A development team might keep code-review instructions in one repository, testing skills in another, and project-specific agent guidance in a third. These dependencies can be shared across projects just like libraries.
The problem starts when those components change. A developer may update a skill locally while the repository still points to an older version. Another developer may use a different revision, and the CI environment may continue using an outdated copy. Over time, the agent's behavior becomes inconsistent across machines.
GitHub has extended Dependabot version updates to support Agent Package Manager (APM), making it possible to automate updates for supported Git dependencies declared in an apm.yml manifest.
This is useful because agent configuration is becoming part of the software supply chain. It needs version control, repeatable installation, and a review process just like application dependencies.
Why Agent Dependencies Need Version Management
Traditional dependency management focuses on packages imported by application code. Agent-based development introduces another category of dependency: the material that guides how an AI agent works.
For example, a repository might use shared components for:
- Reviewing pull requests.
- Generating unit tests.
- Following a team's coding standards.
- Investigating CI failures.
- Creating technical documentation.
- Applying project-specific development instructions.
These components can change independently of the application. A team might improve a review skill, fix an instruction that produces incorrect code, or add support for a new development workflow.
If a project references a Git repository using a fixed tag or commit, it will continue using that revision until someone updates it. That is useful for reproducibility, but it also creates maintenance work.
APM provides a manifest and lockfile for managing these dependencies. Dependabot can now inspect supported Git dependencies in that manifest and open pull requests when newer versions are available.
The important detail is that Dependabot support currently covers version updates, not security updates. It should therefore be treated as an update mechanism, not a complete security-monitoring solution for agent dependencies.
How Dependabot Works With APM
APM uses two files in a project:
apm.yml declares the agent-related dependencies.
apm.lock.yaml records the resolved dependency versions so that installations can reproduce the same dependency set.
Dependabot reads the manifest, checks supported Git dependencies, and opens a pull request when an update is available. If the repository already contains an apm.lock.yaml file, Dependabot regenerates it by running apm lock.
It does not create a lockfile when one is missing.
The behavior depends on how a dependency is pinned:
Dependency reference | Dependabot behavior |
|---|
Semantic version tag | Updates to the latest supported semantic version tag |
Full commit SHA | Updates to the commit associated with the latest annotated, non-prerelease release tag |
Branch reference | Updates the lockfile to the latest commit on that branch; the manifest reference remains unchanged |
This distinction is important when reviewing pull requests. A tag-based update changes the declared version reference, while a branch-based update can change only the resolved lockfile entry.
Configure Dependabot for APM
The configuration belongs in .github/dependabot.yml.
Add an apm entry and specify the directory containing the apm.yml file. For a manifest in the repository root, a weekly schedule is a reasonable starting point.
version: 2
updates:
- package-ecosystem: "apm"
directory: "/"
schedule:
interval: "weekly"
This tells Dependabot to check the root-level APM manifest for supported dependency updates once a week.
If the manifest is stored in a subdirectory, change directory to that location. For example, a repository with an agent configuration under /agent-config would use:
version: 2
updates:
- package-ecosystem: "apm"
directory: "/agent-config"
schedule:
interval: "weekly"
The directory must contain the relevant apm.yml file. Adding an APM entry does not make Dependabot scan every directory automatically.
For a monorepo with multiple independent APM manifests, configure separate update entries for their respective directories. Keep the paths accurate so that each update job operates on the intended project.
Once the configuration is committed, Dependabot can begin checking for supported updates according to the selected schedule.
Understand Which Dependencies Are Updated
APM support is not a general-purpose updater for every entry that might appear in an agent manifest.
Dependabot updates supported Git dependencies declared under both dependencies.apm and devDependencies.apm.
It does not currently update several other forms of dependency declaration, including:
- Object-form entries using
git, registry, id, or path maps. mcp entries.- Git dependencies without a reference.
- Local path dependencies.
- Dependencies hosted on Azure DevOps.
- Dependencies using
http:// or git:// clone URLs. - Entries written using certain YAML block scalar or escaped-string formats.
- Abbreviated commit SHAs.
There is another limitation involving shorthand dependency references. If the manifest defines registries.default, shorthand entries may not be updated. Entries that use an explicit clone URL are still supported.
These restrictions matter when a repository already has a large APM manifest. Before enabling automated updates, inspect the dependency declarations and identify which ones Dependabot can actually maintain.
Do not assume that a successful Dependabot run means every dependency in the manifest was checked.
Keep the Lockfile in the Update Process
The lockfile is an important part of reproducible agent environments.
Imagine that a team references a shared code-review skill using a branch such as main. The manifest continues to reference that branch, but the branch moves as developers improve the skill.
Without a committed lockfile, different installations may resolve different revisions at different times. A developer testing a pull request today could use a newer skill than a CI job running from an older checkout.
When apm.lock.yaml exists, Dependabot regenerates it during the update process. For a branch-based dependency, this is particularly important because the manifest reference itself does not change.
A repository should therefore commit the lockfile if its development workflow depends on repeatable agent configurations.
After an update pull request is opened, review both files:
- Check whether the manifest reference changed.
- Check the resolved revision in the lockfile.
- Confirm that the dependency points to the intended repository and release.
- Run the project's APM installation and validation process.
The lockfile should be treated as part of the dependency update, not as an optional generated file that can be ignored.
Review Agent Updates Like Other Supply-Chain Changes
An updated agent skill may look like a small text change, but it can influence how an agent generates code, handles files, or interacts with development tools.
For that reason, automatically merging every APM update is not a good default for repositories that use agents in important engineering workflows.
A review process should consider what changed in the upstream dependency, who maintains it, and whether the new version changes the agent's behavior.
For example, a pull request that updates a code-review skill should be checked against representative pull requests. A change to a testing instruction should be evaluated against the project's existing test-generation expectations.
The repository can also use ordinary pull request protections:
- Require code-owner or designated maintainer review.
- Run relevant validation jobs.
- Keep the dependency source and revision visible in the pull request.
- Test agent behavior when an update changes instructions or skills.
- Avoid merging updates from untrusted repositories without inspection.
The right level of review depends on how much authority the agent has. A skill that only formats documentation has a different risk profile from one that can modify source code or invoke external tools.
The Security Update Gap
There is an important limitation in the current integration: Dependabot APM support is for version updates only. It does not create security update pull requests for vulnerable APM dependencies.
That means teams should not expect a vulnerability in an agent skill or instruction package to trigger the same automated security update workflow they use for supported application dependencies.
A separate review process is needed. Teams can monitor the upstream repositories they depend on, review security advisories where available, and periodically inspect the dependencies recorded in their APM manifests and lockfiles.
It is also worth maintaining an inventory of agent dependencies. Knowing which repositories supply the skills and instructions used by an engineering team makes it easier to investigate an issue when an upstream component changes or becomes untrusted.
Availability and Practical Considerations
Dependabot version updates for APM became generally available on GitHub.com on November 3, 2026, for all GitHub plans. Support is also planned for GitHub Enterprise Server 3.24.
For organizations using GitHub Enterprise Server, check the installed version before adding the configuration. Availability on GitHub.com does not automatically mean the same capability is present in an earlier self-hosted release.
A sensible rollout is to enable APM updates in one repository first. Confirm that Dependabot recognizes the manifest, opens the expected pull requests, and regenerates the lockfile when one is present. Once the behavior is understood, apply the configuration to other repositories.
Conclusion
Agent skills, prompts, and instructions are becoming dependencies that need the same version-management discipline as application packages. GitHub's APM support gives Dependabot a way to automate updates for supported Git dependencies declared in apm.yml.
The configuration is straightforward, but the dependency format and lockfile behavior deserve attention. Some manifest entries are not supported, branch-based updates may change only the lockfile, and security updates are not included.
Use Dependabot to reduce manual version maintenance, keep the APM lockfile under version control, and review changes before merging them into development environments. That approach helps teams keep agent configurations consistent without treating every automated update as a change that can be accepted blindly.
Join the conversation! Your thoughts help the community grow.