以前換一台新電腦，我們會先安裝瀏覽器、Office、VS Code 或 Python。缺少什麼功能，就把對應的工具裝進去。
到了 AI Agent 的世界，事情開始變得有點奇怪。
現在有人分享的不只是「這個軟體很好用」，而是：
這是我平常怎麼找出程式錯誤的方法，你可以裝進 Agent。
這是我怎麼把模糊需求問清楚的方法，也可以裝。
這是我從規劃、實作到檢查的整套流程，居然還是可以裝。
以前我們安裝的是工具。現在連「拿到工具之後要怎麼做事」，都開始被整理成可以安裝的形式。
這就是今天要談的 Skill。中文可以先把它理解成：
一套可以重複載入的工作方法。
它不是把某個人的大腦下載進電腦，也不是讓 AI 突然取得十年經驗。比較準確的說法是：有人把自己做某類工作時常用的步驟、判斷原則與參考資料整理起來，讓 Agent 遇到相似任務時可以照著做。
從 Day 18 到 Day 20，我們其實一直在替 Agent 補齊工作環境。
Day 18 的 API，讓自己的程式可以取得模型能力。Day 19 的 CLAUDE.md、AGENTS.md 與 Hooks，讓 Agent 知道這個專案長期要遵守哪些規則。Day 20 的 MCP，則讓 AI 應用透過比較一致的方式連接外部工具與資料。
走到這裡，Agent 很像一位剛到職的新同事：腦袋有了，員工守則讀了，門禁卡和工具也拿到了。
接著它問：
所以，這件工作通常要怎麼做？
假設今天要找出一個難以重現的程式錯誤。Agent 可以讀程式、執行測試，也能查資料；但它應該先重現問題，還是看到可疑程式就直接修改？修正後要不要補測試？連續三次都失敗時，是繼續亂試，還是停下來重新檢查假設？
工具回答的是「可以用什麼」。
Skill 開始處理的是「這類事情通常怎麼做」。
Day 8、Day 9 談過 Prompt。Prompt 是使用者這一次交給 AI 的要求，例如：
請幫我檢查這段程式。
先找出問題原因，不要直接修改。
如果這只會用一次，留在目前的 Prompt 很合理。
但如果你每次除錯都要重講「先重現、縮小範圍、一次只改一件事、最後補測試」，它就不再只是這次任務的要求，而是一套會反覆使用的方法。這時便有機會把它整理成 Skill。
所以兩者不是互相取代：
Prompt：這一次要完成什麼
Skill：遇到這一類任務時，通常按照什麼方法做
一個符合 Agent Skills 開放規格的 Skill，最少是一個資料夾，裡面放一份 SKILL.md。
我們用 grill-me 當例子。這是我很常使用的一種方法：當計畫還有模糊處時，不要急著給答案，而是一次問一題，逐步把沒有說清楚的決定找出來。
為了讓第一次接觸 Skill 的讀者看懂，下面把它的核心精神整理成一份簡化示意。它不是 Matt Pocock 儲存庫目前版本的逐字內容。
---
name: grill-me
description: 逐步追問計畫或設計。當使用者想釐清想法時使用。
---
一次只問使用者一個問題。
每一題都提供你的建議答案與理由。
如果答案可以從目前專案找到，先查資料，不要反問。
繼續追問，直到重要假設都已經說清楚。
先不用急著自己建立。今天只觀察這份檔案的三個部分。
name 是 Skill 的名稱，而且要和資料夾名稱相符。description 是用途說明，不只要寫「它會做什麼」，也要交代「什麼情況適合使用」。下方的 Markdown 正文，才是 Agent 選中這個 Skill 後真正要遵循的工作方法。
這也是為什麼 description 不能只寫：
很厲害的 Skill。
這句話和履歷上寫「本人能力很好」差不多。很有自信，但不知道該把工作交給你，還是請你先回家等通知。
還記得 Day 12 的 Context 嗎？它是模型在這次工作中能看到的整體資料，包括系統規則、對話、檔案內容、工具說明與工具結果。
Skill 也可能成為其中一部分，但不一定從一開始就把完整內容全部塞進去。以開放規格描述的流程來看，可以先抓住這五步：
Agent 先知道 Skill 的名稱與用途
↓
使用者提出需要釐清計畫或設計的要求
↓
Agent 判斷 grill-me 可能適合
↓
完整工作指示被載入目前的 Context
↓
Agent 按照指示，一次只問一個問題
也就是說，description 不只是寫給人看的介紹，也會協助 Agent 判斷「現在是不是該把這套方法拿出來」。
不過要注意：這是理解 Skill 的共同方向，不代表所有 AI 產品都有完全相同的尋找、觸發與載入方式。有些產品會自動判斷，有些可以由使用者直接指定，支援的欄位也可能不同。使用時仍要查看目前產品的文件。例如 Claude Code 的 Skill 文件便說明了自動載入與手動呼叫的方式。
如果安裝了五十個 Skill，Agent 每次改一個錯字以前，是不是都要先讀完除錯、研究、簡報、測試、職涯規劃和旅行安排？
如果真是這樣，還沒把「的」改成「得」，Context 可能已經先開完一場跨部門高峰會。
Agent Skills 規格採取的方向是「需要多少，再載入多少」，英文稱為 progressive disclosure。Agent 一開始先取得名稱與用途；任務符合時，再載入完整 SKILL.md；若 Skill 還附帶參考文件、程式腳本或素材，也可以等真正需要時再取用。
最小的 Skill 只有 SKILL.md 就夠了。等工作真的變複雜，才可能增加：
scripts/ 可以執行的程式
references/ 需要時查閱的資料
assets/ 範本、圖片或其他輸出素材
因此 Skill 不只是「比較長的 Prompt」。它是一個可以被找到、按需要載入，也可以帶著其他資源一起工作的資料夾。
Skill 最有趣的地方，不只是多了一種 Agent 功能，而是大家開始把原本藏在個人經驗、團隊習慣與工作流程裡的東西寫出來。
有些專案把「怎麼問」整理成 Skill；有些把「怎麼做完一整件事」串成流程；有些拆開「一個團隊如何分工」的不同視角；也有人試著整理「某個人經常怎麼判斷」。
感覺萬物正在被 Skill 化。
下面四個不是 Skill 的官方分級，也不是從小到大的必經路線。它們比較像個人的四個觀察角度。
同一個專案可以同時有工作方法、流程、角色分工與知識整理；差別只在於，它最想把哪一部分工作經驗交給 Agent。把它們排在一起，不是要替 Skill 排大小，而是想看看「工作方法」可以被裝進去的範圍有多大。
Matt Pocock 的 Skills強調小型、可組合，也鼓勵使用者依自己的工作方式修改。其中的 grill-me 不急著替你完成計畫，而是透過追問先處理「我們是不是根本還沒說清楚要做什麼」。
它封裝的不是答案，而是問問題的方法。
以前我們可能想請 AI 幫忙寫答案。現在連「先不要回答，繼續問我」都可以裝起來。
obra/superpowers 把多個可組合的 Skill 串成軟體開發方法：先釐清需求、形成設計、寫出計畫，再進入實作、檢查與驗證。
單一 Skill 像一張工作清單；多個 Skill 有了順序，前一步的結果又成為下一步的輸入，就開始像一套完整流程。
原本只想裝一張除錯說明書，回過神來，專案已經要求你先開需求會議、寫設計、做測試，再接受審查。很麻煩，但也很像真的上班。
garrytan/gstack 把產品、工程、設計、品質、安全與發布等不同視角整理成一組方法。專案自己將它形容成一支「虛擬工程團隊」：不同角色負責挑戰產品問題、檢查架構、找出設計問題、測試流程或檢查安全風險。
這些角色不等於真的聘請了一位執行長、資深設計師和安全專家。比較準確的理解是：同一個 Agent 在不同階段載入不同的問題清單與工作責任。
一個人坐在電腦前，資料夾打開卻像部門主管全員到齊。以前怕會議沒人來，現在可能要怕大家同時發言。
Nuwa Skill 把邊界推得更遠。依照專案自己的說法，它會從公開資料中整理表達方式、心智模型、判斷方法、反對什麼，以及已知限制，再產生可供 Agent 使用的 Skill。
這是專案提出的方法與目標，不代表它真的複製了某個人的大腦。它自己也列出誠實邊界：公開表達不等於真實想法，整理出的內容只是資料蒐集當下的快照，框架可以整理，直覺與靈感卻不一定能被複製。
Steve Jobs 的公開訪談可以整理；但他累積多年的品味、犯過的錯，以及看到某個設計時突然覺得「不對」，不會因為下載一個資料夾就完整出現在你的 Agent 裡。
不過，這個嘗試仍然提出了一個很有意思的問題：
到底有多少人的工作方式，可以被整理成 Agent 能載入的形式？
把四個例子放在一起，比較好的理解不是「Skill 會從一本說明書一路長成一家公司」。
而是：同樣是 Skill，它可以保存一種提問方法，也可以串接一整套流程；它可以帶入不同職務的檢查角度，也可以嘗試整理某種判斷框架。這些面向會重疊，而不是排成一條由小到大的階梯。
例如 Superpowers 裡既有個別方法，也有整套開發流程；gstack 既有角色視角，也有從規劃到發布的工作順序；Nuwa 除了最後產出的觀點 Skill，前面本身也有蒐集、提煉與驗證的流程。
它真正有趣的地方是：很多以前只存在於「老師傅就是知道」、「我們公司一直都這樣做」或「做久了你就懂」裡面的經驗，開始被迫寫清楚。
你做這件事時先看什麼？什麼情況要停下來？哪一步不能交給 AI 猜？失敗以後怎麼知道應該換方法？
只要其中一部分能被說清楚，就可能被整理成 Agent 可以重複使用的工作方法。
這不是未來式。現在已經有人把工程師的除錯流程、團隊的發布檢查、老師的提問方式，甚至自己反覆失敗後留下的教訓整理成 Skill。
真正正在改變的，是 SOP 的身份。以前它只是放在雲端硬碟裡，等下一位同事有空再讀的文件；現在它開始變成 Agent 可以在需要時載入、執行、驗證，甚至慢慢改版的組織記憶。
這也逼出一個更難的問題：流程可以寫下來，但例外為什麼是例外呢？
如果只把「平常怎麼做」裝進 AI，卻沒有把「什麼時候不該這樣做」一起交接，我們可能只是把資深者的盲點，變成一個跑得更快的自動化流程。
看到熱門 Skill 時，很容易產生一種衝動：除錯裝一位大神，產品裝一位大神，設計再裝一位大神，最後打開 Skills 資料夾，裡面像復仇者聯盟。
但 Skill 終究是某個人寫下的方法。安裝前仍要確認來源、閱讀內容、注意它可能使用哪些工具與權限，也要判斷它適不適合現在的問題。未來最值錢的，可能不是你有多少 Skill，而是你能不能把「什麼時候不要照 Skill 做」也說清楚。
拿到別人的方法，不等於擁有他的判斷。
走到 Day 21，Agent 已經開始有模型能力、工作規則、外部工具，以及可以按任務載入的方法。
以前開始工作時，我們先問：
這件事我要怎麼做？
現在也許要先多問一次：
AI 本身是不是早就會做？
有沒有現成工具或方法可以使用？
人的工作開始從「每一步都親自完成」，慢慢增加另一種責任：判斷問題應該交給誰、採用什麼能力，以及哪些部分仍然必須由自己負責。
Day 22，我們就來問一個可能有點不舒服的問題：
你還在從零開始？全世界可能早就做好一半了。
grill-me Skill
iThome鐵人賽
看影片追技術