我前陣子一直有個困擾：明明用的是同一個模型，有時候它像很可靠的同事，有時候又像急著交作業的新人。後來看 Matt Pocock 整理 Agent Skills，才覺得問題可能不只是 prompt 寫得漂不漂亮，而是我有沒有把「先重現、再判斷、改完要驗證」這些工作習慣真的交代清楚。
平常使用 AI 寫程式，我們很容易把同一套要求重複貼進對話：先問清楚需求、遇到 bug 不要亂猜、改完記得跑檢查。Agent Skill 就是把這些可重複的做事方式整理成檔案，需要時再交給 agent 使用。
Matt Pocock 的 Skills for Real Engineers 收錄了除錯、TDD、需求訪談和問題分類等內容。它們不是神奇 prompt，也不會讓 AI 永遠答對；比較像是替 AI 準備的工作清單，提醒它照著一套順序處理問題。
Skill 和一般 prompt 最大的差別，在於它可以跟著專案保存、版本控制和重複使用。對團隊來說，真正有價值的可能不是下載別人的 skill，而是把自己團隊常用的檢查步驟慢慢整理起來。
它比較像 SOP，不是魔法咒語
以除錯 skill 為例，內容通常不會告訴 AI 某個 bug 的答案，而是要求先重現、縮小範圍、確認假設，再動手修改。這些本來就是工程師的基本功，只是 agent 很容易急著改程式，所以把流程寫下來仍然有用。
Skill 也不適合寫得太包山包海。如果一份檔案同時規定架構、測試、命名、部署和回覆語氣，agent 每次都得讀一大篇，很難知道這次真正重要的是什麼。小而明確、需要時才載入，通常比較接近它原本的用途。
至於要不要直接採用別人的 skill，我會把它當參考範本。裡面的做法未必符合每個團隊，像 TDD、commit 習慣和工具都可能不同。看懂後留下適合自己的部分，比原封不動複製更有意義。
我覺得最適合先寫成 skill 的，反而是團隊每次 review 都會重複留言的事。例如資料庫 migration 前要備份什麼、改 API 後要更新哪些 client、視覺修改要截哪些斷點。這些規則已經存在，只是散落在人腦和聊天室裡。
寫完後也要看 agent 是否真的照做。如果 skill 每次都被忽略，可能不是模型不聽話，而是觸發條件太模糊、內容太長，或要求互相衝突。把 skill 當程式一樣迭代，比把它當一次寫完的公司規章更合理。