前言：為什麼寫這個系列

用 Claude 做事一段時間之後，我遇到最大的瓶頸不是模型不夠聰明，而是溝通成本：每次都要重新解釋「我的規則是什麼、什麼可以做、什麼不能做」。同樣的指示重打了幾十次之後我開始想：這些規則為什麼不能變成一個可以重複使用、可以測試、可以版本管理的東西？

這個東西就是 Agent Skill。這個系列用 30 天，從「看懂 skill」開始，到親手打造、測試、發布一支真的能被安裝使用的 skill 為止。而且不只是寫出來，還要「可驗證」：有 eval、有 CI、有 schema 驗證，工程等級的那種。

什麼是 Agent Skill

一句話：Skill 是把「怎麼做好一件事」的知識打包成 agent 可以按需載入的格式。

具體來說，一支 skill 是一個目錄，核心是 SKILL.md：

1. Frontmatter：name 和 description。description 是 agent 判斷「現在該不該用這支 skill」的唯一依據，寫得好不好直接決定 skill 會不會被正確觸發。
2. 指令本文：告訴 agent 執行這項任務的流程、護欄、輸出格式。
3. 附加資源：參考文件、腳本、資料檔，需要的時候才被讀取。

關鍵設計是 progressive disclosure（漸進式揭露）：常駐在 context 裡的只有 frontmatter 那幾行 metadata，幾十支 skill 也只佔一點點 token；真正厚重的指令和資料，在 skill 被觸發後才載入。這讓「給 agent 裝很多專業知識」這件事在 token 成本上變得可行。

為什麼不直接用 prompt 就好

我自己踩過的三個坑：

1. 重複性：同一段規則每天重打，打久了一定會開始偷工減料，品質就跟著漂。
2. 無法驗證：prompt 沒有版本、沒有測試。改了哪裡、為什麼改、改完有沒有變差，全靠印象。
3. Context 成本：把所有規則塞進每個對話，token 燒得快，模型還容易被不相關的規則干擾。

Skill 把這三件事一次解決：寫一次、重複用、可以 review、可以測試、需要的時候才載入。

這 30 天的路線圖

第一週「看懂 Skills」：SKILL.md 的結構、skill 和 prompt / subagent / MCP 的選型，並設計出我們的示範案例。
第二週「打造核心」：為什麼關鍵判斷要確定性（deterministic），實作 matcher 和資料驗證器。
第三週「測試與品質」：幫 skill 寫 eval、對抗性測資、用 GitHub Actions 做 CI 守門。
第四週「發布與生態」：打包發布、README、CHANGELOG、讓 skill 被社群收錄。
最後兩天：30 天的數據覆盤，以及 Agent Skills 下一步的展望。

示範案例：演唱會購票安全檢查

這個系列的實作主角是一支「演唱會購票安全檢查」skill。情境是虛構的粉絲社群：粉絲在社群裡看到售票連結，想快速判斷「這是不是官方管道」。詐騙票、假官方網站、相似域名（homoglyph）在票務場景裡都是真實存在的問題。

選這個題目有三個原因：

1. 它是資料驅動的：官方來源清單可以明確定義、可以過期、可以更新，很適合示範「資料新鮮度」的工程問題。
2. 判斷可以確定性：域名比對不需要 LLM 自由心證，規則引擎就能做，正好示範「什麼該交給模型、什麼不該」。
3. 測試空間豐富：假官網、相似域名、多語系頁面，全是現成的對抗性測資。

明天預告

Day 2 解剖 SKILL.md：frontmatter 的每個欄位在做什麼、指令怎麼分層、description 怎麼寫才會被正確觸發。

如果你也在用 Claude 或任何支援 skills 的 agent，歡迎留言告訴我你最想打包成 skill 的那件事是什麼，說不定會變成後面某一天的案例。