Agent Skills 有了共同的维护规则
Agent Skills 捐赠 AAIF 后，11 月通过的治理文件补上了决策与提案规则。理解标准共享到哪一层，再给团队技能留下版本、依赖和验证记录。
团队同时使用几种 Agent 时，最值得共享的往往是同一套工作方法：怎样整理发布说明、怎样查证资料、怎样验收一项修改。Agent Skills 把这些方法放进可携带的目录，如今维护这份格式的人，也有了更明确的共同规则。
Anthropic 在 10 月 22 日宣布把 Agent Skills 捐赠给 Agentic AI Foundation（AAIF）；标准仓库随后通过了 11 月 4 日的治理文件。对已经维护技能的团队，这件事值得关注的地方，是标准如何继续变化、自己的技能如何跟上，以及跨工具共享时还要验证哪些条件。
本文于 2026 年 11 月 11 日重读捐赠公告、当前规范与治理文件。没有在多个宿主中安装或运行本文示例，不报告平台兼容率，也不采用公告里的安装规模来证明某份技能可靠。
这次交接，具体交了什么
公告列出的捐赠内容包括 Agent Skills 名称与标志、GitHub 组织、agentskills.io 域名，以及标准的后续维护安排。使用或参与标准不要求先加入 AAIF。维护者以个人身份参与，不能简单理解成由某几家公司按席位分配所有决定。
11 月 4 日通过的治理文件又把职责分成几层：
| 角色 | 文件规定的主要职责 |
|---|---|
| Contributors | 提交问题、改动与讨论 |
| Maintainers | 维护文档、参考库或其他具体部分 |
| Core Maintainers | 决定规范实质变更、发布和整体方向 |
| Lead Maintainers | 最终决策权限，可处理争议并行使否决权 |
Lead 与 Core Maintainers 共同组成技术指导委员会。决策优先寻求共识，无法达成时按文件规定表决与升级。公开参与不等于每项决定都由所有人平票通过，读到具体争议时仍应看决策过程。
这比只看到“某厂商支持 Skills”多了一层意义：规范变更有了负责的人和公开路径。治理文件也提出带标签的规范发布、变更记录和正式提案流程；其中部分流程采用“建立后”的条件描述，不能把规划写成今天已经存在的完整版本体系。
能一起带走的知识，与宿主能力分开看
当前规范的基础仍然很简单：一个包含 SKILL.md 的目录，文件前面是 YAML 元数据，后面是 Markdown 操作说明。必要字段为 name 和 description；可以附带脚本、参考资料与模板。
这种简单有利于搬运，但真正执行还涉及另外几层：
| 层次 | 可以共享的东西 | 迁到另一个宿主后还要核对 |
|---|---|---|
| 工作方法 | 步骤、判断条件、输出要求 | 是否发现并加载了正确技能 |
| 本地资源 | 相对路径引用的资料、脚本、模板 | 文件是否齐全，运行环境是否具备 |
| 执行能力 | 对工具或服务的要求说明 | 宿主的真实工具、凭据、网络与授权 |
例如，一份发布技能写着“读取仓库记录后创建发布”，并不会自动为另一宿主配置 GitHub 权限。脚本依赖 Python，也不会因目录拷贝完成就自动安装运行时。compatibility 字段可以描述这些前提；实验性的 allowed-tools 支持又因实现而异，不能当作跨客户端统一的权限开关。
项目长期规则与按需流程的区别，可先读AGENTS.md、CLAUDE.md 与 SKILL.md 的分工。需要连接外部工具时，再看 MCP 的作用；技能里写到某个工具，不表示工具服务已连接。
把团队流程写成容易迁移的小技能
下面是一份只整理公开变更的示例。它用于说明格式与边界，不是已安装、已自动触发或已跨宿主验证的技能：
---
name: public-release-brief
description: Turn a supplied public change list into a release brief. Use when drafting release notes from public material.
compatibility: Requires access to the supplied public change list and Markdown output.
metadata:
owner: docs-team
revision: "1"
---
# Public release brief
1. Read the supplied public change list and its source links.
2. Group confirmed changes into Added, Fixed, and Breaking changes.
3. Include only details supported by the supplied material.
4. Return Markdown and list any facts that still need verification.
5. Publication, commits, and messages require a separate authorized task.
目录应叫 public-release-brief，与 name 对应。引用模板或其他文件时，用技能目录下的相对路径，避免写成本机绝对地址。description 要说明何时使用，正文则给出实际步骤和验收条件。
这里的 metadata.revision 是团队自己的记录，不是规范版本，也没有宣称所有宿主都识别它。技能自身的许可证也要独立确认：标准采用开放许可，不会自动给网上每个技能的正文、脚本和附带素材授予相同许可。
共享之前，留四类记录
一个小团队可以先维护这些信息，不必急着建设复杂平台：
- 来源与版本。 从哪个仓库取得、固定到哪个提交、本地改过什么、谁负责维护。
- 运行前提。 用到哪些文件、命令、网络服务和授权，哪些是宿主专用扩展。
- 公开验证样本。 一份固定输入、预期输出与不应执行的动作，方便升级后重复检查。
- 宿主结果。 实际在哪个产品和版本上验证过，验证了发现、加载、资源访问还是完整执行。
格式校验通过，只说明目录和字段满足相应规则；不能证明任务理解正确、脚本安全或所有平台行为相同。迁移时可以先执行只读或返回草稿的公开任务，再根据真实需要配置写入能力。涉及工具输出中的指令与写操作，可以参考读取内容与执行权限的边界。
上游更新后，先看改动了触发说明、脚本还是权限要求，再用同一公开样本检查。不应只因仓库版本更新就整批覆盖团队正在使用的技能，也不应永远停留在无法追溯来源的拷贝。
为不同 Agent 配置模型入口时，可从客户端目录和连接基础核对实际支持。Nbility 提供模型接入这一层；技能发现、执行工具和授权仍需在各宿主中确认。把这些记录留下，才能让“共享一份流程”变成后续有人能维护的工作。
