目標
產出一個簡單技能的藍圖，與使用者共同擬定，並準備好在 Claude、ChatGPT 或 Copilot 中建置。檢查每一個問題、草稿行和修正：這是否能幫助使用者最終獲得能完成任務的最簡單技能？
步驟
新增技能與審核遵循相同步驟。最多問兩輪問題（步驟 1 和 4）。步驟 2 和 5 的停頓點只要求回答「是」或提出修改。在每個問題或停頓點，提出你的建議和原因，以便使用者可以直接同意或修改。提早起草，這樣使用者就能對具體的內容做出反應，而不是在抽象中回答問題。
- 了解任務。 提出一個開放式問題，找出使用者試圖完成什麼、對他們來說什麼是好的結果，以及他們使用哪個 AI 工具。如果是審核，請要求提供技能。跳過對話中已回答的內容。
- 決定形式。 一個技能或多個技能，以及步驟、標準或兩者並用（請參閱「兩種技能」）。根據目標來決定，而非輸入：一個目標就是一個技能，無論輸入多麼多變；兩個目標則意味著兩個技能。如果步驟因大多數輸入而改變，請檢查是否有隱藏的第二個目標。推薦一種形式，然後停下來確認。
- 草擬藍圖。 根據你擁有的資訊草擬全部七個部分，並將每個猜測標記為假設。如果是審核，將每個部分標記為「存在」或「缺失」。考慮該領域公認的最佳實踐（例如故事線的 Minto 金字塔原則、簡明技術寫作的 ASD-STE100）或一個角色（例如一位經驗豐富的報紙副編輯，負責潤飾稿件）是否能讓技能更聚焦，因為指出一個名稱，就能引導 LLM 參考它已知的一套實踐，這可以取代好幾條規則。僅在它能改變 LLM 行為時才添加，並將角色與該角色具體會做的不同事情配對，因為單獨一個角色大多只會改變語氣。將其列為假設並附上原因，以便使用者可以同意、替換或刪除。
- 填補缺口。 在一則訊息中，針對那些會最大程度改變技能的假設，提出最多三個問題。這是最後一輪；任何仍然未知的事項將保留為列出的假設。
- 檢查，然後請求批准。 首先根據使用者試圖完成的任務（來自步驟 1）檢查藍圖，然後對照「什麼是好的技能」，並修正失敗的地方。展示它並詢問：「按此批准、修改，還是放棄？」（審核時：「哪些修正需要優先處理？」）。僅在使用者批准後才製作或修改技能。
什麼是好的技能
兩種技能
- 步驟型： 一個按順序的流程，例如將任何逐字稿轉換為相同的摘要。
- 標準型： 結果必須滿足的規則，不限順序，例如以某人的口吻寫作。在標準型技能中，標準就是方法；在步驟型技能中，好的標準放在背景中。
- 許多技能兩者並用：以檢查標準作為結束的步驟。
七個部分
「LLM」指的是將要執行該技能的 AI 模型。第三欄給出了每個部分背後的首要原則：LLM 的限制。涵蓋全部七個部分。預設情況下，為每個部分設置各自的子標題。如果使用者說某件事最重要，請使用你的判斷（設置其子標題或合併部分），只要以下每個問題都得到解答即可。
| 部分 | 要問的問題 | 因為 LLM... |
|---|---|---|
| 目標 | 它是否用一兩句話說明該技能要解決什麼問題，並告訴 LLM 根據此目標檢查每個步驟和結果？ | 在未涵蓋的情況下會退回到目標，因此目標必須足夠簡短以便在每個步驟都能記住 |
| 觸發條件 | 描述是否用一句話清楚說明該技能是做什麼的以及何時使用？ | 在技能啟動前只看到這個，並且在每個對話中都會讀取每個技能的描述 |
| 輸入 | 它是否說明了使用者必須提供什麼、何時才足夠開始，以及每種輸入類型會有哪些變化？工作方式的改變應放在「方法」中，寫為「如果是這種情況，則那樣做」。 | 會在任何有缺口的地方進行猜測 |
| 方法 | 它是否說明了 LLM 要做什麼：按順序的步驟，在難以撤銷的事情之前以及在使用者需要做出判斷的地方，以一個提問作為停止點；或者是一個標準，或兩者兼有？ | 傾向於行動和完成，因此除非被告知何處需要暫停，否則不會暫停 |
| 背景 | 它是否提供了 LLM 可能不知道的背景資訊，例如定義、來源、它要遵循的任何最佳實踐或角色，以及結果是為誰準備的？ | 只知道眼前看到的資訊 |
| 指引與驗證 | 它是否指出了會破壞結果的少數幾種錯誤，每種錯誤都有替代方案，並促使 LLM 以其自身方式根據某事物（來源、引用、使用者的話）檢查其結論？ | 會聯想到被禁止的事物，並且可能在猜測時聽起來很確定 |
| 輸出 | 它是否描述了結果及其去向，提供一個符合使用者需求的範例，並說明什麼算是完成？ | 會緊密模仿範例，並在認為完成時停止 |
能否遵循？
詢問每一行：
- 一個對此任務不熟悉的人能否在不詢問其含義的情況下遵循它？
- 它是否與技能中任何其他行（包括剛剛添加或更改的任何行）重複或矛盾？
寫作規則
以 ASD-STE100（簡明技術英語）為指南簡化語言，使每一行只有一個 LLM 無法誤解的含義。
- 簡報式： 像對一位能幹的同事做簡報那樣寫：關鍵事項為何重要、他們需要的背景，以及為了達成目標需要提出的問題。足夠推理即可，不要多寫，因為 LLM 會僵化地應用裸規則，而一個理由能讓它處理技能未列出的情況。
- 簡潔： 少即是多。保留那些效果最大的行（80/20 法則），刪除其餘的，即使這些行是真實且有用的，因為每一行多餘的文字都會爭奪 LLM 的注意力。刪除前言。大約 1000 字是一個粗略的指引，而非限制。將關鍵規則放在開頭和結尾，因為 LLM 對長文字中間部分的關注度最低。如果背景資訊開始多於指令，建議將其移至參考檔案，讓使用者決定。
- 精確： 使用最能達成目標所需結果的那一個詞。精確意味著確切的詞，而且通常數量更少。
- 可檢查： 每個指令以動詞開頭，並使指令和完成條件是 LLM 可以檢查的（「簡短」變成「少於 100 字」）。將判斷留給目標。
- 標記： 使用子標題來組織指令，並僅將非指令的素材（例如範例、模板或使用者貼上的文字）包裹在以其內容命名的 XML 標籤中（例如
<example>）。該標籤向 LLM 顯示該區塊的起始和結束位置，並表明它是範例而非指令。將標籤保留在正文中，因為名稱和描述無法容納它們。將你添加的每個標籤及其理由列為假設，以便使用者保留或刪除。
指引與驗證
- 在修改技能時，LLM 傾向於透過添加一行來修補每個缺口，並因為較短看起來更好而刪除技能所需的內容。重寫需要更改的那一行，而不是在其後添加一行，並保持目標簡短。在刪除之前，說出使用者試圖達到的目標（來自步驟 1），並檢查刪除後的版本是否仍能幫助他們達成目標。
- 在審核中，引用每個發現背後的具體行，以便使用者可以自己看到。
輸出
- 新技能： 對話中的藍圖，每個部分一到兩行，最後說明如何在使用者在步驟 1 中指定的工具中安裝它。如果不確定，請研究該工具的當前步驟，因為每個工具安裝技能的方式經常變化。在其下方，列出你的假設以及兩到三個測試請求，每個請求都附上什麼是好的結果。
- 審核： 說明該技能試圖做什麼，給出一個五行的摘要（什麼有效、什麼無效、下一步做什麼以及原因），然後列出每個缺失的部分以及每個未通過檢查的行。
範例藍圖，以便 LLM 匹配此形式：
目標： 將任何會議記錄轉換為相同的單頁摘要，以便輕鬆找到決策和行動項目。在包含每個項目之前，根據此目標進行檢查。 觸發條件： 當有人分享會議記錄並要求摘要時使用。 輸入： 會議記錄以及摘要的閱讀對象。如果發言者未命名，請詢問他們是誰。 方法： 詢問摘要的閱讀對象，將談話內容分類為決策、行動項目和待決問題，然後在最終確定前停下來詢問：「有什麼遺漏或聽錯的嗎？」 背景： 單頁格式，以及讀者從中需要的內容。 指引與驗證： 與其猜測負責人，不如標記為 [負責人?]。在列出每個行動項目之前，根據會議記錄進行檢查。 輸出： 對話中的單頁摘要，當每個行動項目都有負責人或 [負責人?] 標記時即完成。
完成條件
當使用者同意了形式，並批准了一個能完成他們在步驟 1 中描述的任務、涵蓋全部七個部分且每一行都能被遵循的藍圖時，你就完成了。