GitHub Dependabot 开始为 Agent Skills 提交版本更新

假设团队共享一个代码审查 Skill，里面规定了审查顺序、检查项和测试命令。维护者新增数据库迁移检查后，使用方也需要更新。GitHub 新增的 APM 集成让这次更新可以像常见的代码依赖更新一样，以 Pull Request 的形式进入仓库。

GitHub 在 2026 年 11 月 3 日宣布，Dependabot 可以定期检查 APM 声明的受支持 Git 依赖，并提交版本更新 PR。该功能已在 GitHub.com 的所有套餐开放，GitHub Enterprise Server 计划从 3.24 起提供。此次集成覆盖版本更新，APM 依赖的安全更新仍需单独处理。 GitHub 更新公告

同一个 Skill，三种更新方式

APM 是面向 AI Agent 的依赖管理工具。项目用 apm.yml 声明所需的 Skill、提示词和指令等内容，安装时由 APM 解析依赖，并写入目标 Agent 能读取的位置。apm.lock.yaml 记录解析出的提交与内容哈希，让团队可以从同一份锁文件还原已选定的依赖内容。 APM 安装文档

以下示例假设应用仓库引用团队维护的代码审查包，并在 apm.yml 中指定版本标签。

name: storefront
version: 0.1.0
dependencies:
  apm:
    - example-org/review-skills#v1.2.0

上游发布 v1.3.0 后，Dependabot 可以发起 PR，将清单里的标签更新到新版本。如果仓库已有 apm.lock.yaml，Dependabot 会通过 apm lock 重新生成锁文件。清单差异显示新版本号，锁文件差异记录实际解析到的提交。 APM 更新规则

如果依赖写的是 example-org/review-skills#main，PR 只会更新锁文件中的提交，因为清单仍然指向同一条分支。这种写法要求仓库已有锁文件。如果依赖固定到完整的提交 SHA，Dependabot 会查找最新的带注释正式发布标签，并将 SHA 更新到该标签对应的提交。 APM 更新规则

每周检查一次的配置

如果 apm.yml 位于仓库根目录，可以在 .github/dependabot.yml 中这样配置。仓库已经为其他依赖启用 Dependabot 时，把 apm 条目加到现有的 updates 列表即可。

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

directory 指向清单所在的目录。dependencies.apm 与 devDependencies.apm 下符合条件的条目都会纳入检查。当前更新范围以带引用的 Git 依赖为主，本地路径、MCP 条目、对象形式声明和省略引用的仓库简写均在范围之外。新项目可先运行 APM 安装生成锁文件，再将其提交到仓库。 GitHub 更新公告 依赖支持范围

更新 PR 里要审什么

回到数据库迁移检查的例子。审查者可以先用锁文件里的新旧提交定位上游差异，确认新增规则会读取哪些文件、触发哪些命令，再拿一条包含迁移文件的测试任务验证行为。例如，同一个 Skill 是否会在新增非空字段时提醒检查历史数据，并在普通文案变更中跳过这项检查。

如果仓库同时提交了 Agent 实际读取的已部署文件，审查范围还包括这些文件与新锁文件是否一致。可以在 CI 中执行 apm install --frozen，按锁定结果还原依赖，再检查部署文件是否产生差异。对于团队共享 Skill，锁文件提供了定位变更的入口，代表性任务则能验证升级后实际读到的规则是否按预期生效。 APM 安装文档