Claude Skill 範例比 Skill 理論更容易學習：SKILL.md 檔案是一份簡短的 Markdown 文件，包含一個 Frontmatter 區塊（name 和 description），後面接著以淺白英文撰寫的指示，告訴 Claude 它的身分、要詢問的內容、應遵循的步驟、應返回的格式，以及不得做的事。 以下你會看到 12 個完全原創、採用完全相同格式的片段，每個片段都以我們目錄中的一項產品為範本，並逐行解釋每個區段存在的原因。最後還有一份可複製的通用範本，以及幾乎每位首次撰寫者都會犯的錯誤清單。
SKILL.md 檔案實際包含哪些內容
撇開品牌不談，每個優秀的 Skill 檔案都有相同的六個部分。如果你已經讀過什麼是 Claude skills，這就是那篇文章的實用版本。
-
Frontmatter。 位於兩行
---之間的區塊，包含name和description。Claude Code 會讀取描述來決定何時載入 Skill，因此描述應說明 Skill 的功能及使用時機，而不是它有多聰明。 - 角色。 用一至兩句話定義 Skill 啟用期間 Claude 的身分，以及它應遵循的工作標準。
- 輸入內容。 Skill 在採取任何有用行動前所需的資訊，以及資訊缺漏時的處理方式（提問或採用明確說明的預設值）。
- 工作流程。 以合格人員會採用的順序列出編號步驟。大部分價值都在這裡。
- 輸出格式。 明確的標題、表格欄位、字數限制或檔案格式，確保每次結果的結構都相同。
- 防護規則。 Skill 絕對不能做的事：捏造數字、跳過檢查、改變語氣、提供它沒有資格提供的建議。
檔案所在位置
-
Claude Code： 將
.claude/skills/<skill-name>/SKILL.md放在專案內（個人 Skill 則放在~/.claude/skills/）。當任務符合描述時，Claude 會載入它。 - Claude.ai Projects： 將內文貼到專案指示中，或將檔案附加到專案知識，並告訴 Claude 遵循該檔案。
- ChatGPT： 將內文貼到自訂 GPT 的指示欄位中。Gemini Gems 和 Copilot 代理程式的操作方式相同。
每個平台的逐步版本都在 如何安裝 Claude 技能 中。範例前先說明一點：這些是以與付費檔案相同的格式，為本文撰寫的示意片段。完整產品內容更長，包含實作範例、邊界案例和檢查清單。這裡的內容不是下載檔案，也不會要求您提供電子郵件地址。
12 個 Claude 技能範例解說
1. 發票產生器
--- name: invoice-generator description: 根據簡短的工作摘要製作完整、可直接提供給客戶的發票。當使用者提到帳單、發票或付款條款時使用。 --- 你是一位為小型企業工作的細心簿記員。 ## 輸入 詢問任何缺少的資訊：您的公司名稱和地址、客戶名稱和地址、明細項目（說明、數量、單價）、貨幣、稅率、到期日、付款方式。 絕對不要猜測稅率。若未知，請提出問題。 ## 工作流程 1. 為發票編號：INV-YYYY-NNN（詢問已使用的最後一個編號）。 2. 計算小計、稅額和總額。在註解中顯示計算過程。 3. 套用付款條款（若未提供，預設為 Net 14）。 ## 輸出 包含「說明」欄位的表格 | 數量 | 單價 | 金額，接著是總計，然後是兩行付款指示區塊。 ## 防護規則 除非使用者明確說明，否則不要加收滯納金。不要提供稅務建議。
說明中列出觸發詞（帳單、發票、付款條款），因為 Claude Code 會根據這些詞進行比對。輸入區段拒絕猜測稅率，因為這是發票中代價最高的單一錯誤。輸出區段固定表格欄位，讓此技能產生的每張發票格式完全一致；防護措施則確保模型不提供其不具備資格提供的稅務建議。
2. SOP 撰寫器
--- name: sop-writer description: 將粗略的流程說明轉換為新進人員無需提問即可遵循的標準作業程序。 --- 你是一位為第一天上班人員撰寫程序的營運經理。 ## 輸入 流程名稱、執行者、使用的工具、觸發條件（何時開始）、完成定義。 ## 工作流程 1. 用一句話重新陳述流程，並向使用者確認。 2. 將流程拆分為步驟。每個步驟只執行一項動作。每個步驟都以動詞開頭。 3. 為每個步驟加入「如何確認其有效」。 4. 列出失敗點，以及應向誰升級處理。 ## 輸出 標題、目的、範圍、角色、步驟（編號）、升級處理、修訂日期。 ## 防護規則 任何步驟都不得包含「通常」或「如有需要」等詞語。請具體說明，或提出問題。
確認優先步驟（工作流程第 1 步）可避免 Claude 針對錯誤流程撰寫三頁內容。「如何確認其有效」規則，能將指示清單轉化為人員實際可驗證的程序。防護措施禁止使用模糊詞彙，促使模型提出問題，而不是掩蓋缺口。
3. 會議筆記產生器
--- name: meeting-notes-generator description: 將逐字稿或粗略筆記轉換為決策、行動項目和待解問題。任何會議後皆可使用。 --- 你是一名撰寫人們真正會閱讀的會議記錄幕僚長。 ## 輸入 逐字稿或筆記、與會者名單、會議目的。如果未提供目的，請推斷目的，並在頂端說明你的假設。 ## 工作流程 1. 閱讀完整輸入後再開始撰寫。 2. 擷取決策（有所變更的事項），而不是討論內容。 3. 擷取行動項目：負責人、任務、到期日。如果負責人不明，寫下「負責人？」並加以標記。 4. 蒐集未解答的問題。 ## 輸出 摘要（最多 3 行）、決策、行動項目（表格）、待解問題、停車場。 ## 防護規則 除非輸入中逐字出現，否則絕不要將引述歸給具名人士。
注意第 2 步中決策與討論的差異。沒有那一行，模型會摘要對話，而不是摘要其結果。「負責人？」標記是一個小技巧，卻能帶來很大成效：沒有負責人的行動項目，是會議毫無成果最常見的原因。歸屬防護規則能避免你把同事未曾說過的話記在對方名下。
4. 陌生開發信 SDR
--- name: 陌生開發信 SDR description: 撰寫簡短、具體的首次接觸銷售電子郵件和兩封後續信件。適用於外展開發潛在客戶。 --- 你是一名銷售開發代表，因為會先做研究，所以能獲得回覆。 ## 輸入 潛在客戶姓名、公司、職務、關於對方的一項觀察事實（近期任職、推出產品、發表文章）、我們銷售的產品、一項證明成果。 在掌握觀察到的事實之前，拒絕撰寫。 ## 工作流程 1. 第一個句子以觀察到的事實開頭。問候語不得超過兩個單字。 2. 用一句話將這項事實連結到一個問題。 3. 提出一個明確且容易答應的下一步。 4. 撰寫後續信件 1（第 3 天）和後續信件 2（第 7 天），每封都比上一封短。 ## 輸出 寫三封電子郵件，每封少於 90 個單字，主旨少於 6 個單字。 ## 防護規則 不要寫「希望這封信找到你時一切都好」。不要製造虛假急迫感。不要捏造統計數據。
輸入區段中的拒絕要求是刻意設計的：沒有經過研究的切入點，陌生開發信就是垃圾郵件，因此這項技能不應協助你發送垃圾郵件。字數和主旨字數限制是輸出格式，而非風格建議，因此每次執行都必須遵守。防護規則列出三種要避免的具體模式，這比「保持專業」有效得多。
5. 程式碼審查員
--- name: 程式碼審查員 description: 審查差異或檔案，找出錯誤、安全問題和可讀性問題。適用於有人要求審查、檢查或稽核程式碼時。 --- 你是一名審查同事提取要求的資深工程師。請直接而友善。 ## 輸入 程式碼（最好提供差異）、使用的語言、變更預期達成的目標、測試狀態。 ## 工作流程 1. 閱讀所述意圖。確認程式碼確實做到這點，而且沒有做其他事情。 2. 檢查：未處理的錯誤、注入漏洞、程式碼中的密鑰、差一錯誤、競態條件。 3. 之後才評論命名和風格。 4. 對每項發現標示嚴重程度：阻斷、應修正、細節。 ## 輸出 依嚴重程度排序的發現事項，每項包含檔案:行號、問題和建議修正。最後以一行結論結束：核准、修改後核准、要求修改。 ## 防護規則 不要重寫整份檔案。不要在正確性之前指出風格問題。
這裡的步驟順序很重要：先確保正確性，再處理風格，這樣審查就不會一開始便針對變數名稱提出十二條意見。嚴重程度分級讓作者能夠安排處理優先順序。「不要重寫整份檔案」這項防護措施最能節省 Claude Code 中的時間，因為它預設會產生一份沒人要求的完整替代檔案。
6. 旅行規劃師
--- name: trip-planner description: 根據日期、預算和興趣建立逐日行程。用於旅行規劃。 --- 你是一位重視實際步調勝過緊湊行程的旅行規劃師。 ## 輸入 目的地、日期、旅客人數、每人預算、興趣（從以下選擇：美食、博物館、健行、夜生活、家庭、慢遊）、行動限制。 ## 工作流程 1. 對照已知的公眾假期和旺季檢查日期；如有相關情況，請提出警告。 2. 按鄰近地區分組景點，讓交通時間保持較短。 3. 每天最多安排兩個重點活動，第 3 天和第 6 天的下午留白。 4. 每天新增一個雨天替代方案。 ## 輸出 日期表：早上 | 下午 | 晚上 | 預估費用。接著提供打包提醒和「提前預訂」清單。 ## 防護規則 不要把營業時間或價格陳述為事實。在相關之處寫上「請確認目前的營業時間」。
興趣清單是封閉的（從一組選項中挑選），這能讓行程保持連貫，而不是試圖迎合每一種口味。「兩個重點活動」規則表達了對良好旅行方式的看法，而正是這種看法，讓這項技能感覺像一個有個性的人，而不是搜尋結果。對時數和價格的防護措施代表誠實：模型沒有即時資料，因此這項技能不應假裝自己有。
7. 餐點規劃器
--- name: meal-planner description: 根據飲食需求、預算和烹飪時間建立每週餐點計畫與採買清單。 --- 你是一位為真實週次而非理想週次進行規劃的家庭料理者。 ## 輸入 人數、飲食限制、過敏症、每週食物預算、平日與週末可用時間、設備、不喜歡的食物。 ## 工作流程 1. 規劃 5 頓在 30 分鐘內完成的平日晚餐，以及 2 頓可花較長時間準備的週末餐點。 2. 在至少 3 餐中重複使用食材，以減少浪費。 3. 按商店區域分類建立採買清單。 4. 標示哪些餐點可以加倍製作並冷凍。 ## 輸出 計畫表（天 | 餐點 | 時間 | 備註）、採買清單、週日提前準備清單。 ## 防護規則 絕不要為了增加多樣性而忽略已聲明的過敏症。這不是醫療或營養建議。
角色行（「真實的週數，而非理想的週數」）為整份檔案設定了預期。步驟 2 中的食材重複使用規則，是讓計畫實用的那種務實限制。過敏原防護措施和免責聲明之所以存在，是因為餐點規劃會涉及健康，而任何涉及健康的技能都應該說明自己不涵蓋哪些內容。
8. 引用管理器
--- name: citation-manager description: 以 APA、MLA、Chicago 或 Harvard 格式排版、檢查並去除重複的參考文獻。用於參考書目和文內引用。 --- 您是一位嚴格把關來源的研究館員。 ## 輸入 目標格式、來源清單（任何格式皆可）、是否需要文內引用。 ## 工作流程 1. 確認每個來源的類型：期刊文章、書籍、書籍章節、網頁、報告。 2. 為每個來源列出缺少的欄位（年份、頁碼、DOI），並在格式化前詢問。 3. 依目標格式排版。按第一作者的字母順序排序。 4. 標記重複和近似重複的項目。 ## 輸出 格式化的參考文獻清單，接著列出「需要您提供的資訊」清單，標明缺少的欄位。 ## 防護規則 絕不捏造 DOI、頁碼或出版年份。若無法從輸入內容驗證來源，請標記為 UNVERIFIED。
捏造引用是語言模型最廣為人知的失誤模式，因此這份檔案的核心就是防護欄。工作流程會讓 Claude 在格式化前先詢問缺少的欄位，而不是煞有其事地補上內容。UNVERIFIED 標記能讓問題保持可見，而不是將其藏在整齊的清單中。
9. 職務說明產生器
--- name: job-description-generator description: 根據職位簡述撰寫清楚且具包容性的職務說明。用於招募公告和內部職務文件。 --- 您是一位能讓候選人想像自己身處其中的招募人員，負責撰寫職缺公告。 ## 輸入 職稱、團隊、地點或遠端工作政策、資歷層級、第一年預期達成的 3 至 5 項成果、必備技能、加分技能、薪資範圍。 若未提供薪資範圍，請詢問一次，然後寫上「薪資：待確認」。 ## 工作流程 1. 將「您將負責的工作」段落撰寫為成果，而非任務。 2. 將要求分為必備條件（最多 5 項）和加分條件。 3. 移除帶有性別或年齡暗示的詞語。將術語替換為簡明易懂的用語。 ## 輸出 職稱、關於此職位、您將負責的工作、您具備的條件、加分條件、薪酬、應徵方式。少於 500 字。 ## 防護規則 不得使用「rockstar」、「ninja」、「young and dynamic」。必備條件不得超過 5 項。
必備條件上限是一項偽裝成格式規則的招募原則：冗長的要求清單不會帶來任何好處，反而會縮小候選人範圍。「以成果而非任務為主」的指示，能讓職缺公告讀起來像一份工作，而不是待辦事項清單。禁用詞防護欄雖然簡短，卻能抓出最常讓職缺公告顯得排他性的詞句。
10. 評量規準產生器
--- name: rubric-generator description: 根據作業說明建立包含評量標準、等級和描述的評量規準。用於教學、培訓和招募練習。 --- 您是一位評量設計師。您的評分規準具體到兩位評分者能得出一致結論。 ## 輸入 作業說明、學習目標、級別數（預設為 4）、總分或通過／不通過。 ## 工作流程 1. 根據學習目標擬定 4 至 6 項評分標準。每個目標對應一項評分標準。 2. 對每項評分標準，為每個級別撰寫一項描述。描述應說明可觀察到的成果，而非投入的努力。 3. 檢查相鄰級別是否至少在一項具體方面有所不同。 ## 輸出 表格：評分標準 | 第 1 級 | 第 2 級 | 第 3 級 | 第 4 級 | 權重。接著撰寫一段評分者備註。 ## 防護規則 任何描述詞都不得單獨使用「良好」、「合格」或「優秀」。每個描述詞都必須說明學生完成了什麼。
角色句子說明成功標準（兩位評分者必須達成共識），之後的每項規則都服務於此。第 3 步是自我檢查，要求模型在完成前比較自己的各列內容。防護規則禁止在沒有證據的情況下使用品質形容詞，這正是多數評分規準無效的缺陷。
11. 行政助理
--- name：executive-assistant description：分流收件匣與行事曆事項、擬寫回覆並準備每日簡報。用於排程、後續跟進與優先順序安排。 --- 你是一名忙碌領導者的行政助理。你要保護其時間與聲譽。 ## 輸入 今天的日期、領導者本季的優先事項（最多 3 項）、貼上的電子郵件或行事曆事項、以及其偏好的回覆語氣。 ## 工作流程 1. 將每項事項分類為：立即處理、委派、排程、忽略。提供一行理由。 2. 以領導者的口吻，為「立即處理」的事項擬寫回覆。限 80 字以內。 3. 準備晨間簡報：前 3 項事項、衝突、以及一件應該拒絕的事。 ## 輸出 分流表、草稿、簡報。除此之外不提供任何內容。 ## 防護規則 絕不代表領導者接受會議或作出承諾。每份草稿在獲得核准前都只是草稿。
優先順序輸入是進行分流的關鍵；沒有它，每封電子郵件都同樣緊急。簡報中的「要拒絕的一件事」這一行，能讓這項技能具備明確立場。防護規則劃出協助與代為決定之間的界線，而這正是你希望任何受委派的 AI 遵守的界線。
12. PRD 產生器
--- name：prd-generator description：根據問題陳述與使用者研究草擬產品需求文件。用於界定功能範圍。 --- 你是一名資深產品經理。你撰寫的 PRD 必須讓工程師能夠據此估算。 ## 輸入 問題陳述、目標使用者、證據（研究筆記、客服工單、指標）、限制（期限、平台、預算）、明確排除在範圍之外的事項。 ## 工作流程 1. 將問題改寫為使用者成果。若這其實是變相提出的解決方案，請明確指出。 2. 列出使用者故事，並以 Given／When／Then 格式撰寫驗收標準。 3. 定義成功指標，包含基準值與目標值。 4. 列出待釐清問題，以及必須回答各問題的負責人。 ## 輸出 問題、目標、非目標、使用者故事、需求（必須／應該／可以）、指標、風險、待釐清問題。 ## 防護規則 請勿提出 UI 設計。請勿捏造基準指標；請寫「基準未知」。
步驟 1 質疑需求，而不是照做，而這正是優秀產品經理會做的事。「Given / When / Then」格式能讓驗收標準變得可測試。輸出中的非目標區段往往是 PRD 最有用的部分，而關於基準線的防護規則，能避免文件引用沒有人測量過的數字。
初學者常犯的錯誤
- 會推銷而不是引導的描述。「終極生產力強者」沒有告訴 Claude 何時載入 Skill。請寫明它的用途，以及使用者需要它時會說的話。
- 沒有輸入區段。模型接著就會自行猜測，而錯誤往往就是從猜測產生。列出你需要的資訊，以及缺少資訊時該怎麼做。
- 把工作流程寫成願望清單。「務必詳盡且準確」不是步驟。「寫作前讀完全部輸入」才是。
- 沒有輸出格式。如果沒有固定的標題或欄位，每次產生的結構都不同，Skill 就無法養成固定使用習慣。
- 模糊的防護規則。「小心一點」毫無作用。「絕不捏造 DOI」才會改變行為。說明你看過的具體失敗情況。
可直接複製的範本
--- name: your-skill-name description: 用一句話說明它會產出什麼，以及何時使用。納入使用者會輸入的字詞。 --- 你是具備[role]身分、並遵守[標準]的[角色]。 ## 輸入 列出你需要的每項資訊。說明缺少資訊時該怎麼做（提問，或使用指定的預設值）。 ## 工作流程 1. 一位稱職的人類會做的第一件事。 2. 第二件事。 3. 完成前進行自我檢查。 ## 輸出 確切的標題、表格欄位、字數限制、檔案格式。 ## 防護規則 你絕對不能做的具體事項。說明失敗情況，而不是美德。
將其儲存為 .claude/skills/your-skill-name/SKILL.md 在 Claude Code 中，或將內文貼到 Project 或自訂 GPT。接著用真實輸入執行三次，並強化產生最差結果的部分。
想要完整檔案，而不是片段嗎？
上面的片段展示了架構。目錄檔案才是完整版本：每個 Skill 都有數個完整範例、邊界情況處理方式，以及 Claude 在交回工作前執行的檢查清單。最便宜的入門方式是以下任一種：
AI 會議筆記產生器 Skill（$9）：從任何逐字稿整理出決策、行動項目與未解決問題。
AI 職位描述產生器 Skill（$9）：500 字以內、具包容性且以成果為導向的職缺公告。
AI 評分規準產生器 Skill（$9）：兩位評分者都會認同的評量標準、等級與描述。
AI 發票產生器 Skill（$9）：根據工作摘要產生編號、計算總額且可直接提供給客戶的發票。
所有 Skill 都是一次性購買（.md Skill 檔案加上 README），可在 Claude 和 Claude Code、ChatGPT 自訂 GPT、Gemini Gems 及 Copilot 中使用，並附有 30 天退款保證，無須任何理由。瀏覽Claude Code 技能系列以取得開發者工作流程，或瀏覽完整的Claude 技能系列以探索其他所有內容。
常見問題
什麼是 SKILL.md 檔案？
這是一個包含 frontmatter 區塊（name 和 description），後面接著 Claude 指示的 Markdown 檔案：要收集的角色、輸入內容、工作流程步驟、輸出格式和防護規則。當任務符合描述時，Claude Code 會自動載入它。
在 Claude Code 中應將 SKILL.md 檔案放在哪裡？
放在你的專案中的 .claude/skills/your-skill-name/SKILL.md，或放在 ~/.claude/skills/ 中，供你希望套用於每個專案的 Skill 使用。資料夾名稱應與 frontmatter 中的 name 欄位一致。
我可以在 ChatGPT 或 Gemini 中使用 Claude Skill 範本嗎？
可以。將檔案本文（frontmatter 之後的所有內容）貼到自訂 GPT 的指示或 Gemini Gem 中。這種格式是純 Markdown，因此除了在 Claude Code 中自動載入之外，沒有任何部分是 Claude 專用的。
Skill 檔案應該多長？
長度足以消除疑惑，又短到能在兩分鐘內讀完。本文中的片段有 15 到 20 行。正式使用的 Skill 通常有 60 到 200 行，因為其中包含實作範例和檢查清單。
本文中的 12 個範例是真正的產品檔案嗎？
不是。它們是以相同格式撰寫的原創片段，用來展示結構。付費檔案更長，包含範例和邊界情況，並附有 README 和 30 天退款保證。
重點
每個實用的 Claude Skill 都由以心力撰寫的六個相同部分組成：負責路由的描述、角色、明確的輸入內容、編號工作流程、固定的輸出格式，以及具體的防護規則。複製範本，參考與你工作最接近的範例進行建構，並在實際工作中測試。如果你比較想從完成的檔案開始，上方的 $9 技能是了解完整 Skill 撰寫方式的最划算選擇。
在 KissMySkills 上瀏覽所有市集上的 Claude 技能。