一次编写、多端运行：GitHub 官方的 Agent Skill 实战指南

GitHub Universe 2026 演讲整理，讲如何把重复交代给 AI Agent 的任务沉淀成可复用的 skill。文章用 Proof Agent 和 Data Forge 两个案例，给出 skill 拆分、manifest 配置分离、多客户端打包和人工审批点的具体做法，读完可以直接照着搭自己的 skill 体系。

什么是 Agent Skill，边界在哪

• skill 是一个以 SKILL.md 为核心的版本化目录，描述某项可重复任务在何时、如何执行
• skill 可以跨 Agent 共享，但不提供工具、凭证和权限——比如描述怎么查数据库，但不会授予数据库访问权
• 核心原则：自我验证不算验证，Proof Agent 用独立的 verifier 检查 AI 生成的代码，避免自己评自己的工作

多个 skill 协作：Data Forge 案例

• 把散落在四个人脑子里的数据管道经验沉淀成一组协作 skill，降低对特定人的依赖
• forge-init 先探查源表、命名规范等细节，写入 resolved manifest，其他 skill 共享这份上下文而不是各自重新发现
• forge-builder 负责从 issue 到 PR 的全流程，调用 forge-dbx 查数据平台、forge-lint 应用团队规范
• 每个 skill 职责单一，某一步变了只改一个 skill，其余不动

项目配置不要写死在 skill 里

• 项目名、数据库、引擎等配置放在 manifest 中（示例用 DuckDB + Spark Python），skill 只读取不硬编码
• 探查到的仓库现状和团队规范要分开：仓库里的模式不自动等于要遵守的规则，需人工确认
• 检验可移植性的标准：另一个团队换一份 manifest，能否不改 skill 直接用

统一执行路径与人工检查点

• forge-dbx 是所有 skill 访问数据平台的唯一入口，根据 manifest 自动选 Databricks 或 DuckDB 适配器
• manifest 只负责选引擎，安装 CLI、授权等仍由宿主环境完成
• Data Forge 工作流分七个阶段，每阶段设人工检查点，schema 变更前必须审批
• Proof Agent 的 verifier 只拿到原始需求和代码改动，看不到编码 Agent 自己的评估，返回 PASS/FAIL/PARTIAL 并必须引用文件中的证据

多客户端打包与三条实践建议

• 以 skills/*/SKILL.md 为唯一源，用打包脚本生成 Claude Code、Cursor、GitHub Copilot 各自的插件文件，脚本带 --check 模式可进 CI
• 安装后要验证客户端能识别 skill、加载引用、调用所需工具并返回要求的证据
• 三条实践：业务上下文集中在一个 manifest；相关 skill 共用同一套平台访问路径；指令引导工作、检查验证工作，阻塞合并的需求配置在仓库规则里