GitHub发布代理技能实践指南：用SKILL.md封装可复用任务，权限仍由运行环境提供
GitHub官方博客发布Andrea Griffiths与Procore数据工程高级经理Shishir Tewari在GitHub Universe 2026的分享整理，说明代理技能是可版本化的目录，以SKILL.md为核心；技能可跨代理共享，但工具、凭据和权限需由宿主环境提供。
AI解读：文章给出代理技能的定义：以SKILL.md为核心的版本化目录，描述何时以及如何完成可重复任务；技能可跨代理共享，但环境仍需提供工具、凭据和权限。文中举例说，技能可以描述如何查询数据库，但不会授予数据库访问权。
作者建议技能应有明确的任务、输入和输出。以Proof Agent为例，技能描述对AI生成工作进行对抗性验证，由独立的验证器检查虚假声明、坏代码和安全问题，核心规则是“自验证不算验证”。
多技能协作示例Data Forge面向支持台指标流水线：forge-init先发现源表、命名约定等信息并写入manifest，forge-builder协调从issue到pull request的工作，forge-dbx负责查询，forge-lint应用团队规范，过程中有人工审核，最终PR含流水线代码、schema变更和测试。
文章区分适用边界：技能适合有边界的重复性工作，如清单、发布、迁移或指标流水线；若工作流需要稳定接口、共享状态、审计记录、长时间运行控制或模型之外的权限约束，应用更合适。
配置与权限方面，文章主张项目名称、数据库和约定放在manifest，不硬编码进技能；manifest可以选择DuckDB或Databricks适配器，但不能安装DuckDB CLI或授予数据库访问，这些仍由环境和用户负责。
工作流检查方面，Data Forge示例有七个阶段，每阶段设人工检查点，执行schema变更前需批准；Proof Agent的GitHub Actions工作流对diff做静态审查，不执行代码或运行测试，验证器返回PASS、FAIL或PARTIAL并须引用改动文件中的证据；演示中设block-on-fail: false，发现仅作提示，默认FAIL会使检查失败。
GitHub官方博客发布了一篇代理技能实践指南，内容整理自GitHub的Andrea Griffiths与Procore数据工程高级经理Shishir Tewari在GitHub Universe 2026上的分享，主题为“Build once, run on any agent: a practical guide to agent skills”。
文章把代理技能定义为以SKILL.md文件为核心的版本化目录，用来描述何时以及如何完成可重复任务。文章称，这些指令可以跨代理共享，但运行环境仍需提供执行任务所需的工具、凭据和权限；技能能描述如何查询数据库，却不能授予数据库访问权。
一个技能只定义一项任务
文章建议技能应有明确的任务、输入和输出。示例Proof Agent用于检查AI生成的改动是否符合原始请求。文章提出，如果同一个代理评估自己的工作，其解释可能影响审查，因此Proof Agent使用独立验证器检查改动并为结论提供证据。
其SKILL.md的frontmatter写明技能名称和用途：对AI生成的工作做对抗性验证，启动独立验证器检查虚假声明、坏代码和安全问题。文章称核心规则是“自验证不算验证”，SKILL.md中的“When to Verify”部分说明何时调用该技能，其余指令说明验证器审查什么、结论中应包含哪些证据。
Data Forge示例：多技能共享manifest
文章用Data Forge展示多个技能如何协作完成支持台指标流水线。流程从统计新建和解决事件数的需求开始。forge-init技能先发现源表、命名约定等信息并写入resolved manifest，其他技能从manifest读取项目上下文。
forge-builder协调从issue到pull request的工作，并调用forge-dbx查询数据平台、forge-lint在设计和构建时应用团队标准。文章称，过程中有人审核提出的决策，最终pull request包含流水线代码、schema变更和测试。每个技能有明确职责，共享项目上下文而非各自重新发现；某一步变化时，只需改一个技能。
适用边界与配置分离
文章称技能适合有边界、可重复且受益于复用判断的工作，例如清单、发布、迁移或指标流水线。若工作流需要稳定接口、共享状态、审计记录、长时间运行控制，或需要在模型之外强制权限，应用是更合适的选择。
配置方面，文章主张不把每个项目的名称、数据库和约定硬编码进技能。在示例中，manifest描述项目、指标存储和平台，包括项目名、存储名、引擎、流水线框架和本地目录。文章还提醒，把发现的项目细节与团队标准分开：仓库中发现的模式不自动成为应保留的规则，发现结果应可审查，让人在需要业务判断处确认或修改。
文章以forge-dbx为例说明统一访问路径：它读取manifest，选择Databricks或DuckDB适配器，其他技能不必各自实现连接和查询逻辑。但manifest不能安装DuckDB CLI或授予数据库访问权，这些仍由环境和用户负责。文章概括为：manifest选择引擎，宿主提供访问。
检查点、验证与客户端打包
文章称Data Forge的支持台工作流有七个阶段，每个阶段都设人工检查点；进入下一阶段前检查上一阶段是否完成，执行schema变更前请求批准。
Proof Agent示例则把类似原则用于代码审查：GitHub Actions工作流向验证器提供原始请求和代码改动，但不提供编码代理自己的评估；验证器返回PASS、FAIL或PARTIAL，并必须引用改动文件中的证据。文章说明，该Action对diff做静态审查，不执行代码或运行测试。演示工作流设block-on-fail: false，使发现仅作提示；默认情况下FAIL会使检查失败，若该检查为必需项则阻止合并。
打包方面，Data Forge以skills/*/SKILL.md为源，用脚本生成面向不同客户端的文件，包括Claude Code、Cursor和GitHub Copilot的配置，脚本还提供CI用的检查模式。文章提醒，客户端在模型、工具、凭据和权限上可能不同；安装技能后应确认客户端能为目标任务识别技能、加载引用、使用所需工具并返回技能要求的证据。
文章给出的三条做法
文章最后列出三条实践建议：把业务上下文放在一个文件里，项目名称、schema和约定放在manifest，由各技能读取而非复制；让相关技能通过一致路径执行查询、作业和schema变更；用指令指导工作、用检查验证工作，在需要判断的决策处设人工审核，并用测试和CI检查在变更推进前发现问题。文章还称，若某项检查必须阻止合并或部署，应在仓库规则中配置该要求。
文章建议从自己厌倦反复解释的任务开始，写下任务需要什么、在哪里停止、审核者应看到什么，然后换另一个代理试用，并根据结果改进。