同一份 SKILL.md 能被兩個 Agent 讀取，還不足以讓團隊把兩個執行環境視為相同。宿主可能提供不同工具、讀取不同目錄，也可能對同一支腳本給出不同權限。標準治理有了共同歸屬之後，這些差異仍要留在團隊的驗收紀錄裡。

Anthropic 在 2026 年 10 月 22 日公告，將 Agent Skills 名稱、標誌、GitHub 組織與 agentskills.io 網域捐贈給 Linux Foundation 旗下的 Agentic AI Foundation（AAIF）。使用或貢獻標準不需要加入 AAIF，來自不同公司的工程師將以個人身分維護。

公告把版本化發布、正式提案流程和技能撰寫／安裝的安全指引列為「提議的起始路線圖」。到這次查核時，不能把這句話改寫成三套機制都已完成發布。這篇依官方公告與現行規格整理，沒有跨宿主執行測試；後面的採用紀錄是我的工程建議。

捐贈的是標準治理，現有技能沒有自動取得執行許可

現行規格以含有 SKILL.md 的目錄為基本單位，要求 name 和 description 等 metadata，並允許搭配 scripts、references 與 assets。這些檔案描述的是工作內容與資源，不代表所有宿主都會提供同一組工具。

規格中的 allowed-tools 仍標示為 experimental，且支援程度可能因 Agent 實作而異。團隊不能只看技能宣告這個欄位，就推定它已在執行環境建立沙盒。腳本能讀哪裡、能否連外、可不可以發送或部署，應由實際宿主與工具的權限控制來確認。

我會保留兩個分開的審查結果。一個是格式與內容相容性：檔名、metadata、相對路徑與指令能否被目標宿主理解。另一個是執行授權：這次任務允許哪些讀寫與外部操作。移交標準維護組織，不會替某個第三方技能完成後一項審查。

站內的技能可攜性分析已說明格式重用的限制。這次新增的問題，是標準往後如何演進，以及團隊怎麼在演進過程中保留可回復的部署版本。

版本化路線圖還在提議，今天可以先固定自己的輸入

若團隊每次任務都讀上游最新分支，同一個技能名稱就可能代表不同內容。出問題時，只記「使用某某 skill」很難重現。即使未來有正式版本發布，腳本依賴與參考文件仍可能另有變動。

我會讓安裝審查留下以下資料：

  • 來源 repository 與固定 commit，或可驗證的發布產物身分。
  • SKILL.md、腳本、參考檔及必要依賴的實際版本。
  • 驗收過的宿主版本、工具名稱與權限範圍。
  • 退回上一版的方法，以及需要重新取得使用者授權的操作。

這是團隊自己的安裝紀錄，不是 AAIF 已公布的新 lockfile 格式。技能有了新版，就對照差異重新驗收；不要只比 Markdown 本文，漏掉腳本新增的網路目的地或讀取路徑。

來源版本或執行權限變動後，舊版的驗收結果不能直接沿用。 這條規則可以放進現有依賴更新流程，不必等標準組織先制定所有機制。

相容性驗收要記錄宿主實際做了什麼

假設團隊有一份「產生發布摘要」技能，在兩個宿主上都能載入。第一個宿主只產生文字，第二個宿主另有發送工具。若只驗收最後摘要，會漏掉第二個環境是否自行送出的差異。

這個假設案例可以拆成幾個可檢查項目：是否載入指定版本、能否找到參考檔、腳本失敗時是否停止，以及未獲授權時是否保留為草稿。若宿主缺少某個工具，預期結果應明寫為停止或採用經允許的替代方式，不能讓 Agent 自行擴大操作範圍。

對只產生文字的技能，品質驗收可以看來源引用與輸出要求。對帶有腳本或外部寫入的技能，再加上操作目標、參數和副作用的證據。兩類技能不適合共用一句「載入成功」作為上線條件。

這延續技能安裝契約的權限審查，也與技能遵循和效果評測分工：前者確認安裝與操作範圍，後者比較技能有沒有改善交付。新治理架構提供共同討論規格的地方，這兩份驗收仍由採用團隊完成。

先選一份會執行腳本的技能，補齊版本與回復紀錄

今天可以從風險最清楚的一份技能開始：固定目前版本，列出它讀寫的目錄、外部連線與工具，再用一個成功案例和一個失敗案例驗證預期行為。最後確認回復到上一版時，宿主真的載入了舊內容。

等 AAIF 下的提案、版本發布與安全指引陸續形成，再逐項對照現有流程。能刪除的是重複工作，需要保留的是對實際執行環境的查證。標準的維護歸屬已經改變，團隊對安裝來源與副作用的責任沒有移交出去。