最近 GitHub Copilot 正式宣佈支援由 Anthropic 發起的 Agent Skills 開放標準 -- Copilot Skills。它就像是為 AI 安裝一個專屬的「專業技能擴充包」（包含操作手冊與執行工具），讓它能瞬間學會特定的工作流（如自動化測試），從「只懂寫 "Code" 的助手」變身為「能執行任務的專家」。
這裡先特別說明下，Agent Skills 並沒有交付給 AAIF 成為核心標準項目（如 MCP），主要原因應該是它不算是底層核心技術，而是較偏向技能/任務層級的描述格式。不過如同 JSON、Markdown 這類「非組織標準的標準」，因為大家都在用（目前確認 Copilot/Cursor/Codex 已支援，Gemini 尚未原生支援），就有機會成為業界的開放標準了。
初接觸會覺得是一種「強化版的提示詞」，但這樣不太精確，它更接近「具備結構、生命週期與介面契約的 Prompt 容器」。
什麼（What）是 Agent Skills？
Agent Skills 是一種「將提示詞升級為可封裝、可重用、可治理之 Agent 能力模組」的開放規格。
用一句話定義：
Agent Skills = 結構化 Prompt + 行為約束 + 可執行上下文 + 可分享的能力單元
它不是模型、不是 API，也不是單一工具，而是：
- 用標準化結構描述「一個 Agent 能做什麼、怎麼做、在什麼邊界內做」。
- 讓不同 Agent（Copilot、Cursor、Codex、Claude Code…）可以「載入同一個能力描述」並產生一致行為。
Agent Skills 解決的本質問題：
- Prompt 無法被當成「工程資產」管理。
- Agent Skills 讓「能力」成為一等公民（first-class artifact）。
如何（How）使用 Agent Skills
使用 Agent Skills 的方式很單純：建立一個標準化的目錄結構來描述一項技能。
只需在專案的 '.github/skills/` 目錄下建立子資料夾，例如：'.github/skills/unit-testing/ '，並在其中放入一個 「SKILL.md」 檔案。
這個 SKILL.md 用來定義：
- 技能的名稱
- 技能的用途與描述
- Agent 在執行該技能時應遵循的具體操作步驟
此外，也可以在同一個資料夾中放入 Python、Bash 等腳本檔案，讓 Agent 讀取這些檔案內容，並在合適的情境下 建議或協助執行對應的操作。
使用它的好處
當配置了這些技能後，支援該標準的工具（如 GitHub Copilot in VS Code, Claude Code 等）就可以有著如同某一特定專業技能的專家：
- 按需載入（Context 節省）： 這是與 System Prompt 之間一個重要的不同。Agent 通常只有在判斷需要該項技能時（例如問 「如何測試？」），才會載入 SKILL.md 的內容。這避免了塞爆 Context 對話框，讓 AI 保持輕量與專注。
- 可執行的工作流： 不只是生成文字，Skill 可以包含具體的腳本（Scripts）。AI 可以精準地告訴 「執行 test-script.js」，而不是憑空捏造一段無法運行的 code。
- 專業分工： 可以為 「資料庫遷移」、「API/單元 測試」、「安全性掃描」 分別建立不同的 Skills。AI 會根據開發者的問題，自動切換戴上不同的 「專家帽子」。
- 跨平台標準： 雖然這不是 AAIF 託管的標準，但它是由 Anthropic 發起的開放規格（agentskills.io）。這意味著所寫的一套 Skill，未來可以在 GitHub Copilot、Claude Code 或其他支援該標準的 Agent 工具中通用，無需重寫。
一個標準的 Agent Skill 資料夾內容大致涵蓋了 「SKILL.md（核心指令）」、「腳本檔案（Scripts，如 .py, .sh）」、「範例文件（Examples）」 以及 「相關資源（Resources）」，形成一個可移植的 AI 能力包。
Github 提供了一個 Sample 技能包 - Web Application Testing，這項技能能夠使用 Playwright 自動化對本機 Web 應用程式進行全面的測試和除錯。
我個人也整理了一個關於「使用 C#.NET + MSTEST」 單元測試專案的 SKILL.md 範本，作為範例放在 Gist 連結。全文內容也可以參考如下：
# 技能名稱：.NET 8.0 應用層測試專家 (MSTest)
## 簡介
本技能專門用於 .NET 8.0 LTS 專案的全方位測試。涵蓋 Service 、Entity (Domain Object)、Dao (Data Access Object) 以及 Adapter (外部系統連結)。本規範強調真實互動與高品質的程式碼風格，確保測試既能驗證邏輯，又符合架構一致性。
## 啟動時機 (Activation)
當使用者要求針對以下類型的類別撰寫單元測試或整合測試時：
- 「針對 [待測類別] 撰寫單元測試」
- 涉及目標為：`*Service`, `*Entity`, `*Dao`, `*Repository`, `*Adapter`, `*Client`。
## 分層測試準則 (Layer Guidelines)
針對不同層級，請遵循以下原則：
1. **Entity (Domain Object)**：測試狀態變更、驗證邏輯及領域行為。
2. **Service (Application Logic)**：測試業務流程串接與邏輯分支，確保正確調用內部組件。
3. **Dao (Data Access Object)**：**禁止使用 Mock**。必須連結實體資料庫，測試真實的 SQL 執行與資料取得。
4. **Adapter (Integration)**：測試與外部系統 (如第三方 API、外部 SDK) 的介接邏輯。
## 程式碼規範 (Coding Standards)
產出的測試程式碼必須嚴格遵守以下風格：
1. **命名規範**：
- 測試類別：`[待測類別]Test`。
- 測試方法：`Test[動名詞]` (例如：`TestDBConnIsOK`, `TestCalculateOrderTotal`, `TestAdapterCallSuccess`)。
2. **註解風格**：
- 單行註解：使用 `//`。
- 多行註解：必須使用 Java 註解風格 `/** ... */`。
3. **測試結構**：
- 必須遵循 **3A Pattern** (Arrange, Act, Assert)。
4. **技術禁令**：
- **不對 private 方法進行測試**。
- **禁止使用 Reflection (反射)** 進行測試。
- 在 Dao 測試中 **禁止使用 Mock** (其餘層級視需求由使用者指示)。
## 操作指令 (Instructions)
身為資深開發專家，請按以下步驟操作：
1. **環境確認**：確保專案使用 .NET 8.0 LTS 與 MSTest 框架。
2. **結構建立**：
- 建立 `[待測類別]Test.cs` 檔案。
- 在類別上方使用 `/** ... */` 標註測試目的。
3. **撰寫 3A 邏輯**：
- **Arrange**: 準備環境、輸入參數或資料庫實體資料。
- **Act**: 調用待測方法。
- **Assert**: 使用 `Assert` 類別驗證結果。
## 範例 (Examples)
**使用者問：** 「幫我為 MemberService 寫測試，要包含資料庫 Dao 的調用。」
**Agent 應對：** - 建立 `MemberServiceTest` 類別。
- 寫入 Java 風格多行註解描述測試情境。
- 建立方法 `TestRegisterMemberSuccess`。
- 內部不使用 Mock，直接準備 Dao 所需的資料庫環境。
- 使用 `// Arrange`, `// Act`, `// Assert` 分隔代碼。
---
> 備註：此規範已整合使用者之核心提示詞與 ASP.NET Core 架構實務。
> 請將此檔案放置於：.github/skills/dotnet-full-stack-testing/SKILL.md