AI Skills
skill-creator

skill-creator

熱門

建立有效技能的指南。當使用者想要建立新技能（或更新現有技能）以擴展 Claude 的專業知識、工作流程或工具整合能力時，應使用此技能。

132星標
13分支
更新於 2026/3/19
獲取技能源代碼

相關技能

recsys-pipeline-architect24萬academy-guide17萬para-memory-files8萬
SKILL.md
唯讀
名稱
skill-creator
描述

建立有效技能的指南。當使用者想要建立新技能（或更新現有技能）以擴展 Claude 的專業知識、工作流程或工具整合能力時，應使用此技能。

Skill Creator

此技能提供建立有效技能的指引。

關於技能

技能是模組化、自包含的套件，透過提供專業知識、工作流程和工具來擴展 Claude 的能力。將它們視為特定領域或任務的「入門指南」——它們將 Claude 從通用型代理轉變為配備程序性知識的專業代理，這些知識是任何模型都無法完全擁有的。

技能提供的內容

  1. 專業工作流程 - 特定領域的多步驟程序
  2. 工具整合 - 處理特定檔案格式或 API 的指示
  3. 領域專業知識 - 公司特定知識、結構描述、業務邏輯
  4. 捆綁資源 - 用於複雜和重複性任務的腳本、參考文件和資產

核心原則

簡潔是關鍵

上下文視窗是公共資源。技能與 Claude 所需的所有其他內容共享上下文視窗：系統提示詞、對話歷史、其他技能的中繼資料以及實際的使用者請求。

預設假設：Claude 已經非常聰明。 只添加 Claude 尚未具備的上下文。質疑每一項資訊：「Claude 真的需要這個解釋嗎？」以及「這段文字值得它的 token 成本嗎？」

偏好簡潔的範例而非冗長的解釋。

設定適當的自由度

將具體程度與任務的脆弱性和變異性相匹配：

高自由度（文字型指示）：當多種方法都有效、決策取決於上下文、或啟發式方法引導時使用。

中自由度（虛擬碼或帶參數的腳本）：當存在偏好的模式、可接受一些變化、或配置影響行為時使用。

低自由度（特定腳本、少量參數）：當操作脆弱且容易出錯、一致性至關重要、或必須遵循特定順序時使用。

將 Claude 想像為探索路徑：有懸崖的窄橋需要特定的護欄（低自由度），而開闊的田野則允許多種路線（高自由度）。

技能的結構

每個技能包含一個必要的 SKILL.md 檔案和可選的捆綁資源：

skill-name/
├── SKILL.md（必要）
│   ├── YAML 前置中繼資料（必要）
│   │   ├── name:（必要）
│   │   ├── description:（必要）
│   │   └── compatibility:（可選，很少需要）
│   └── Markdown 指示（必要）
└── 捆綁資源（可選）
    ├── scripts/          - 可執行程式碼（Python/Bash 等）
    ├── references/       - 文件，按需載入上下文
    └── assets/           - 輸出中使用的檔案（範本、圖示、字型等）
SKILL.md（必要）

每個 SKILL.md 包含：

  • 前置資料（YAML）：包含 name 和 description 欄位（必要），以及可選欄位如 license、metadata 和 compatibility。只有 name 和 description 會被 Claude 讀取以決定何時觸發技能，因此要清楚且全面地說明技能是什麼以及何時使用。compatibility 欄位用於標註環境需求（目標產品、系統套件等），但大多數技能不需要。
  • 主體（Markdown）：使用技能的指示和指引。只有在技能觸發後（如果有的話）才會載入。
捆綁資源（可選）
腳本（scripts/）

用於需要確定性可靠性或反覆重寫的任務的可執行程式碼（Python/Bash 等）。

  • 何時包含：當相同程式碼被反覆重寫或需要確定性可靠性時
  • 範例：scripts/rotate_pdf.py 用於 PDF 旋轉任務
  • 優點：節省 token、確定性、無需載入上下文即可執行
  • 注意：腳本可能仍需要 Claude 讀取以進行修補或環境特定調整
參考文件（references/）

文件與參考資料，按需載入上下文以指導 Claude 的流程和思考。

  • 何時包含：用於 Claude 在工作時應參考的文件
  • 範例：references/finance.md 用於財務結構描述、references/mnda.md 用於公司 NDA 範本、references/policies.md 用於公司政策、references/api_docs.md 用於 API 規格
  • 使用案例：資料庫結構描述、API 文件、領域知識、公司政策、詳細工作流程指南
  • 優點：保持 SKILL.md 精簡，僅在 Claude 判斷需要時載入
  • 最佳實踐：如果檔案很大（>10k 字），請在 SKILL.md 中包含 grep 搜尋模式
  • 避免重複：資訊應只存在於 SKILL.md 或參考檔案中，而非兩者。偏好將詳細資訊放在參考檔案中，除非該資訊確實是技能的核心——這能保持 SKILL.md 精簡，同時讓資訊可被發現而不佔用上下文視窗。僅將必要的程序性指示和工作流程指引保留在 SKILL.md 中；將詳細的參考資料、結構描述和範例移至參考檔案。
資產（assets/）

不打算載入上下文，而是在 Claude 產生的輸出中使用的檔案。

  • 何時包含：當技能需要將在最終輸出中使用的檔案時
  • 範例：assets/logo.png 用於品牌資產、assets/slides.pptx 用於 PowerPoint 範本、assets/frontend-template/ 用於 HTML/React 樣板、assets/font.ttf 用於字型
  • 使用案例：範本、圖片、圖示、樣板程式碼、字型、會被複製或修改的範例文件
  • 優點：將輸出資源與文件分離，使 Claude 能夠使用檔案而無需載入上下文
技能中不應包含的內容

技能應僅包含直接支援其功能的必要檔案。請勿建立額外的文件或輔助檔案，包括：

技能應僅包含 AI 代理完成當前工作所需的資訊。不應包含關於建立過程、設定和測試程序、使用者面向文件等的輔助上下文。建立額外的文件只會增加混亂。

漸進式揭露設計原則

技能使用三層載入系統來有效管理上下文：

  1. 中繼資料（名稱 + 描述） - 始終在上下文中（約 100 字）
  2. SKILL.md 主體 - 技能觸發時載入（<5k 字）
  3. 捆綁資源 - 按 Claude 需要載入（無限制，因為腳本可在不讀入上下文視窗的情況下執行）
漸進式揭露模式

保持 SKILL.md 主體僅包含必要內容，並控制在 500 行以內，以減少上下文膨脹。接近此限制時，將內容拆分到單獨的檔案中。拆分內容時，務必在 SKILL.md 中引用這些檔案，並清楚說明何時讀取它們，以確保技能的讀者知道它們的存在及使用時機。

關鍵原則： 當技能支援多種變體、框架或選項時，僅將核心工作流程和選擇指引保留在 SKILL.md 中。將變體特定的細節（模式、範例、配置）移至單獨的參考檔案。

模式 1：高層級指南搭配參考檔案

# PDF 處理

## 快速開始

使用 pdfplumber 提取文字：
[程式碼範例]

## 進階功能

- **填寫表單**：請參閱 [FORMS.md](FORMS.md) 取得完整指南
- **API 參考**：請參閱 [REFERENCE.md](REFERENCE.md) 取得所有方法
- **範例**：請參閱 [EXAMPLES.md](EXAMPLES.md) 取得常見模式

Claude 僅在需要時載入 FORMS.md、REFERENCE.md 或 EXAMPLES.md。

模式 2：領域特定組織

對於包含多個領域的技能，按領域組織內容以避免載入不相關的上下文：

bigquery-skill/
├── SKILL.md（概覽和導航）
└── reference/
    ├── finance.md（收入、帳務指標）
    ├── sales.md（機會、管道）
    ├── product.md（API 使用、功能）
    └── marketing.md（活動、歸因）

當使用者詢問銷售指標時，Claude 僅讀取 sales.md。

類似地，對於支援多種框架或變體的技能，按變體組織：

cloud-deploy/
├── SKILL.md（工作流程 + 供應商選擇）
└── references/
    ├── aws.md（AWS 部署模式）
    ├── gcp.md（GCP 部署模式）
    └── azure.md（Azure 部署模式）

當使用者選擇 AWS 時，Claude 僅讀取 aws.md。

模式 3：條件式細節

顯示基本內容，連結到進階內容：

# DOCX 處理

## 建立文件

使用 docx-js 建立新文件。請參閱 [DOCX-JS.md](DOCX-JS.md)。

## 編輯文件

對於簡單編輯，直接修改 XML。

**如需追蹤修訂**：請參閱 [REDLINING.md](REDLINING.md)
**如需 OOXML 細節**：請參閱 [OOXML.md](OOXML.md)

Claude 僅在使用者需要這些功能時讀取 REDLINING.md 或 OOXML.md。

重要指南：

  • 避免深層嵌套的引用 - 保持引用僅從 SKILL.md 開始一層深度。所有參考檔案應直接從 SKILL.md 連結。
  • 結構化較長的參考檔案 - 對於超過 100 行的檔案，在頂部包含目錄，以便 Claude 在預覽時能看到完整範圍。

技能建立流程

技能建立包含以下步驟：

  1. 透過具體範例理解技能
  2. 規劃可重複使用的技能內容（腳本、參考檔案、資產）
  3. 初始化技能（執行 init_skill.py）
  4. 編輯技能（實作資源並撰寫 SKILL.md）
  5. 打包技能（執行 package_skill.py）
  6. 根據實際使用情況迭代

依序執行這些步驟，僅在明確理由認為不適用時跳過。

步驟 1：透過具體範例理解技能

僅在技能的使用模式已清楚理解時跳過此步驟。即使處理現有技能，此步驟仍然有價值。

為了建立有效的技能，需清楚理解技能將如何使用的具體範例。此理解可來自直接的使用者範例，或透過使用者回饋驗證的生成範例。

例如，在建構圖片編輯技能時，相關問題包括：

  • 「圖片編輯技能應支援哪些功能？編輯、旋轉，還有其他嗎？」
  • 「能否舉例說明此技能將如何使用？」
  • 「我可以想像使用者會要求『移除這張圖片的紅眼』或『旋轉這張圖片』。您還能想像此技能的其他使用方式嗎？」
  • 「使用者說什麼話時應觸發此技能？」

為避免讓使用者感到困擾，避免在單一訊息中問太多問題。從最重要的問題開始，並根據需要跟進以獲得更好的效果。

當對技能應支援的功能有清晰概念時，結束此步驟。

步驟 2：規劃可重複使用的技能內容

為了將具體範例轉化為有效的技能，透過以下方式分析每個範例：

  1. 考慮如何從頭開始執行該範例
  2. 識別哪些腳本、參考檔案和資產在反覆執行這些工作流程時會有幫助

範例：在建構 pdf-editor 技能以處理「幫我旋轉這個 PDF」等查詢時，分析顯示：

  1. 旋轉 PDF 需要每次重新撰寫相同的程式碼
  2. 將 scripts/rotate_pdf.py 腳本儲存在技能中會很有幫助

範例：在設計 frontend-webapp-builder 技能以處理「幫我建立一個待辦事項應用程式」或「幫我建立一個追蹤步數的儀表板」等查詢時，分析顯示：

  1. 撰寫前端網頁應用程式需要每次使用相同的 HTML/React 樣板
  2. 將包含樣板 HTML/React 專案檔案的 assets/hello-world/ 範本儲存在技能中會很有幫助

範例：在建構 big-query 技能以處理「今天有多少使用者登入？」等查詢時，分析顯示：

  1. 查詢 BigQuery 需要每次重新發現表格結構描述和關係
  2. 將記錄表格結構描述的 references/schema.md 檔案儲存在技能中會很有幫助

為了確定技能的內容，分析每個具體範例以建立要包含的可重複使用資源清單：腳本、參考檔案和資產。

步驟 3：初始化技能

此時，是時候實際建立技能了。

僅在正在開發的技能已存在且需要迭代或打包時跳過此步驟。在這種情況下，繼續下一步。

從頭建立新技能時，務必執行 init_skill.py 腳本。該腳本會方便地生成新的技能範本目錄，自動包含技能所需的一切，使技能建立過程更高效且可靠。

使用方式：

scripts/init_skill.py <skill-name> --path <output-directory>

該腳本：

  • 在指定路徑建立技能目錄
  • 生成帶有正確前置資料和 TODO 佔位符的 SKILL.md 範本
  • 建立範例資源目錄：scripts/、references/ 和 assets/
  • 在每個目錄中新增可自訂或刪除的範例檔案

初始化後，根據需要自訂或刪除生成的 SKILL.md 和範例檔案。

步驟 4：編輯技能

編輯（新生成或現有）技能時，請記住技能是為另一個 Claude 實例使用而建立的。包含對 Claude 有益且非顯而易見的資訊。考慮哪些程序性知識、領域特定細節或可重複使用的資產能幫助另一個 Claude 實例更有效地執行這些任務。

學習經過驗證的設計模式

根據技能需求查閱以下有用的指南：

  • 多步驟流程：請參閱 references/workflows.md 了解順序工作流程和條件邏輯
  • 特定輸出格式或品質標準：請參閱 references/output-patterns.md 了解範本和範例模式

這些檔案包含有效的技能設計的既定最佳實踐。

從可重複使用的技能內容開始

開始實作時，從上述識別的可重複使用資源開始：scripts/、references/ 和 assets/ 檔案。請注意，此步驟可能需要使用者輸入。例如，在實作 brand-guidelines 技能時，使用者可能需要提供品牌資產或範本以儲存在 assets/ 中，或提供文件以儲存在 references/ 中。

新增的腳本必須透過實際執行來測試，以確保沒有錯誤且輸出符合預期。如果有多個相似的腳本，只需測試代表性樣本，以確保對所有腳本有信心，同時平衡完成時間。

任何技能不需要的範例檔案和目錄應刪除。初始化腳本會在 scripts/、references/ 和 assets/ 中建立範例檔案以展示結構，但大多數技能不需要全部。

更新 SKILL.md

撰寫指南： 始終使用祈使句/不定詞形式。

前置資料

撰寫包含 name 和 description 的 YAML 前置資料：

  • name：技能名稱
  • description：這是技能的主要觸發機制，幫助 Claude 理解何時使用技能。
    • 同時包含技能的功能以及何時使用的具體觸發條件/情境。
    • 將所有「何時使用」的資訊放在此處——不要放在主體中。主體僅在觸發後載入，因此主體中的「何時使用此技能」章節對 Claude 沒有幫助。
    • 例如 docx 技能的描述：「全面的文件建立、編輯和分析，支援追蹤修訂、註解、格式保留和文字提取。當 Claude 需要處理專業文件（.docx 檔案）時使用，用於：(1) 建立新文件，(2) 修改或編輯內容，(3) 處理追蹤修訂，(4) 新增註解，或任何其他文件任務」

請勿在 YAML 前置資料中包含任何其他欄位。

主體

撰寫使用技能及其捆綁資源的指示。

步驟 5：打包技能

技能開發完成後，必須將其打包為可分發的 .skill 檔案，以便與使用者分享。打包過程會先自動驗證技能，確保其符合所有要求：

scripts/package_skill.py <path/to/skill-folder>

可選的輸出目錄指定：

scripts/package_skill.py <path/to/skill-folder> ./dist

打包腳本將：

  1. 驗證 技能自動，檢查：

    • YAML 前置資料格式和必要欄位
    • 技能命名慣例和目錄結構
    • 描述完整性和品質
    • 檔案組織和資源引用

  2. 打包 技能（如果驗證通過），建立以技能命名的 .skill 檔案（例如 my-skill.skill），包含所有檔案並保持正確的目錄結構以供分發。.skill 檔案是副檔名為 .skill 的 zip 檔案。

如果驗證失敗，腳本將報告錯誤並退出，不建立套件。修正任何驗證錯誤後再次執行打包命令。

步驟 6：迭代

測試技能後，使用者可能會要求改進。這通常發生在使用技能之後，對技能表現有最新了解時。

迭代工作流程：

  1. 在實際任務中使用技能
  2. 注意困難或效率低下的地方
  3. 確定應如何更新 SKILL.md 或捆綁資源
  4. 實作變更並再次測試