What Dependabot APM support changes for agent skills
GitHub announced Dependabot version updates for Agent Package Manager on 3 November 2026. It can propose changes to supported Git dependencies in apm.yml and regenerate an existing apm.lock.yaml. The announcement explicitly covers version updates, not security updates. Support is generally available on github.com across plans, with GitHub Enterprise Server support announced for 3.24. See the primary announcement.
For a team using shared agent instructions, the useful change is a review opportunity. An upstream release can become a concrete proposal with a before and after revision. Someone can read the change, try the affected workflow and decide whether the team should adopt it. That is a better starting point for maintenance than discovering an instruction change halfway through a delivery task.
This guide proposes a practical review process. The examples below are suggested team practices, not results from a benchmark or a claim that we tested the integration. They focus on the decisions surrounding an update: ownership, evidence, representative tasks and recovery. Start with the agent skills overview if your team has not yet agreed what it considers a skill.
Start with one dependency and one owner
Choose a skill with a clear purpose and a reviewer who understands that purpose. A documentation helper with a narrow output is easier to assess than a collection that touches deployment, accounts and external services. The pilot should answer whether your team can recognise an acceptable update, not whether it can produce the largest number of update pull requests.
Write down what the chosen skill is supposed to do today. For example, your documentation helper might identify missing setup steps and suggest a patch. Record whether it may edit files, run commands or contact another service. This creates a useful baseline without turning the review into a large policy project. If nobody can state the expected behaviour, resolve that ambiguity before adding an automatic update proposal.
Assign a second person who can cover the owner during leave. An unattended queue becomes stale quickly, and a stale queue encourages rushed batch approvals. Keep the pilot small enough that one reviewer can read the meaningful upstream changes. A collection with many unrelated workflows may need separate owners even when it arrives through one dependency declaration.
Compare this maintenance decision with single-skill APM installation. Selecting an appropriately narrow dependency at installation time can make later reviews easier. Do not assume that updating a whole collection is equivalent to updating only the workflow your team happens to use.
Check the manifest before enabling updates
GitHub documents support for entries under dependencies.apm and devDependencies.apm. Pinning affects the proposal: semantic version tags, full commit references and branches have different update behaviour. Branch updates require an existing lockfile. Some forms are excluded, including local paths, unpinned entries, abbreviated commit references and object-form declarations. Check your exact declaration against the APM ecosystem reference rather than assuming every valid APM dependency is updateable.
For a repository with apm.yml at its root, the following illustrates a weekly update entry. If a Dependabot configuration already exists, add the entry to its existing updates list rather than replacing the file. The announcement directs users to select the apm ecosystem, the manifest directory and a schedule.
version: 2
updates:
- package-ecosystem: "apm"
directory: "/"
schedule:
interval: "weekly"
Treat the chosen frequency as a staffing decision. Daily proposals make sense only if someone can assess them promptly. A weekly review window may suit a small team whose skills change infrequently. Neither frequency makes a proposed change safe or useful on its own. Agree who looks at failed update jobs and who decides whether a delayed update needs attention outside the normal window.
Review the instructions as part of the dependency
Read the changed instructions alongside any changed code. A skill update can be significant even when it contains no new executable script. Compare the task it claims to handle, the files it asks the agent to read, the actions it permits and the conditions under which it stops. Those are the parts most likely to change the experience of someone using the workflow.
Use the SKILL.md format guide as a reading aid. For your review, focus on meaning rather than line count. A short new sentence that authorises publication deserves more attention than a large spelling cleanup. Conversely, a long documentation revision may leave the operational behaviour unchanged. Explain that distinction in the review so the next person does not need to repeat the investigation.
Follow newly referenced files. If the instruction body now sends the agent to another document, compare that document too. If a bundled script changed, inspect its inputs, outputs and external calls. Ask whether the script now writes somewhere different, needs additional credentials or handles failure differently. Keep the evidence tied to the proposed revision so a later upstream edit cannot silently change what you reviewed.
Build a small behaviour check before merging
Choose three tasks from your own workflow: an ordinary request, an incomplete request and a request outside the skill's intended scope. Use synthetic project material. The point is to observe the boundaries that matter to your team without placing private production information into an evaluation repository or an update discussion.
For a documentation helper, the ordinary task could ask for missing setup instructions in a small example project. The incomplete task could omit the target environment. The out-of-scope task could ask it to publish the documentation to an external service. Decide the expected response before running the proposed update. Otherwise, it is too easy to reinterpret whatever the agent does as acceptable.
A review note can use a compact structure like this. It is an illustrative checklist, not a tool configuration or a claim about Dependabot's output.
Update review
Old revision: recorded in the review
Proposed revision: recorded in the review
Expected task: suggest missing setup instructions
Expected output: a reviewable documentation patch
Missing information: ask for the target environment
External publication: requires separate authorisation
Evidence: synthetic task results linked from the review
Decision: accept, request changes, or defer with a reason
Run the same examples against the current and proposed revisions when practical. Keep the surrounding instructions and available tools consistent. Record differences that affect the user, such as a changed output format, a new question or an unexpected write. Avoid turning a few examples into a broad accuracy claim. They support a local acceptance decision for those tasks and conditions.
Separate successful execution from useful output
A completed run is only one piece of evidence. Read the produced patch or report and check it against the task. A documentation update can finish successfully while introducing an incorrect command. A review helper can return a polished summary that overlooks the relevant file. Your acceptance criteria should describe the output you need, not merely the absence of an error message.
Pay particular attention to when checks ran. If the agent tested an earlier state and then changed a file, that result does not establish that the final state passed. Ask the reviewer to identify the final artefact and the evidence that applies to it. This is a general review discipline, not a feature this APM integration promises to enforce.
Also record whether the updated workflow used a different service or required a new permission. A result that looks equivalent may have a different operational cost or exposure. Your team's agent skill security review should fit the actions the skill can actually take. A local formatting helper and a release assistant need different acceptance examples.
Diagnose missing update pull requests methodically
When no proposal appears, begin with the configured manifest location. Confirm that the update entry points to the directory containing the intended apm.yml. In a repository with several manifests, write down which one the pilot covers. This avoids debugging the wrong project simply because its filename looks familiar.
Next, compare the exact dependency declaration with the current ecosystem documentation linked above. Do not rewrite several declarations at once to see what works. Change one understood mismatch and retain the original revision in version history. Check the update job's available diagnostic output for the specific failure rather than inferring that no upstream version exists.
If access is the issue, involve the person responsible for repository permissions. Avoid pasting credentials into review comments or using a personal secret as an unexplained workaround. Once access is resolved, rerun the relevant check and record whether the proposed revision can now be resolved. Keep authentication troubleshooting separate from deciding whether the update itself should be accepted.
Handle a lockfile-only proposal as a real change
A pull request with little or no manifest movement can still deserve a full review. Begin by identifying the old and new resolved revisions and the upstream changes between them. Do not use the size of a generated file diff as your estimate of behavioural risk. A compact reference change can point to a substantial instruction or script revision.
Ask the reviewer to summarise the relevant difference in ordinary language. For example, the proposed helper may now read a broader set of project files or produce an additional report. The review should state whether that change is wanted in this repository. If the upstream release mixes unrelated improvements, explain which parts affect your installed workflow and which do not.
Keep generated dependency state and your review evidence aligned. If another update lands before approval, reassess the actual proposed revision instead of reusing a conclusion for a different one. This makes the review useful months later when someone needs to understand why a particular version was adopted.
Make the acceptance decision understandable
Close the review with a specific decision and its scope. An approval might say that the documentation workflow produced the expected patch on the three example tasks and introduced no additional external action in those runs. A deferral might identify an unexplained change to a helper script and name the information needed before reconsideration. Both are more useful than a bare approval or a vague concern.
Keep unresolved questions visible. If a test environment cannot exercise a particular integration, describe that limit instead of silently treating it as covered. Assign someone to resolve it before the workflow relies on that integration. This gives future maintainers a record of what the team actually checked and where judgement, rather than direct observation, informed the decision.
Plan recovery before expanding the rollout
Before merging the pilot, identify the previous known working dependency state and how your team normally restores it. Include the manifest, any tracked lockfile and relevant project configuration in that reasoning. Do not promise that reverting a dependency reference reverses external actions an agent has already performed. Recovery for published content or changed service settings needs its own procedure.
After adoption, watch a small number of real tasks with the same acceptance criteria used during review. Record problems in terms a maintainer can reproduce with synthetic inputs. If the update is unsuitable, restore the known working state through your normal review process and document the reason. Keep the rejected revision visible in that decision so a later update does not accidentally repeat the same problem.
Expand only when the team can keep up with the review work. The useful outcome is a maintained set of skills with understandable changes and clear ownership. A large queue of unattended proposals does not achieve that. Start from the skill directory, inspect the upstream code for each selected workflow, and treat the first successful update as evidence that your process is manageable before adding another dependency.