要讓一個 coding agent 守規矩，過去大家的做法出奇一致：找一套大框架來接管整條開發流程。GSD、BMAD、Spec-Kit 這類工具賣的都是同一個承諾——你照它鋪好的軌道走，agent 就會乖乖先規劃、再實作、再驗收。聽起來很理想。真正用過的人都懂，麻煩藏在框架自己出包的那一天。

那種框架像一台看不到引擎蓋底下的自動駕駛車。順的時候很爽，一旦它把方向盤打歪，你連它為什麼這樣決定都讀不懂，更別說改。控制權早在你裝它的那一刻就交出去了。Matt Pocock 在 2026 年開源的 mattpocock/skills 就是衝著這件事來的，repo 標語嗆得很直接：Skills for real engineers，給真工程師用的，不是拿來 vibe coding。

它換了一個完全相反的思路。與其給你一台自動駕駛車，不如給你一盒工具，每支只做一件事，而且你隨時打得開來看裡面怎麼運作。這裡的「一支工具」就是一個 skill。講白一點，skill 就是一個 SKILL.md 檔：上半是 YAML 標頭寫 name 和 description，下半是 Markdown 內文，把「這件事要照哪些步驟做」寫成一本 SOP。Claude Code 讀進去，它就成了一個能被呼叫的行為。就這麼樸素。

差別在於誰按下開關。skill 分兩種觸發方式，這也是整個 repo 的分類主軸。一種是 user-invoked，只有人打指令才會動，它負責編排流程，好處是描述不佔 context，代價是你得自己記得它存在；另一種是 model-invoked，模型自己判斷該不該用，也能被別的 skill 叫起來，它持有的是可重用的紀律，代價是每一回合都佔一點 context。大框架是「全都給我聽指揮」，這套是「你要哪個才給哪個」。

作者在 README 直接點名用 agent 開發的四種死法：做出來的東西不是你要的；agent 有夠囉嗦，因為專案根本沒有一套共用語言；code 跑不動，因為缺一條回饋迴路；最後蓋出一坨爛泥，agent 幫你加速寫 code，也同步加速了架構腐爛。每一種死法背後都對著一本軟體工程經典。這套 skills，就是四帖對症的藥。

真正的重點不在它有幾支 skill。repo 裡有 39 個 SKILL.md，實際打包進 plugin 的是 engineering 和 productivity 兩袋共 22 個——但數量只是表面。它真正做的，是把 TDD、DDD、deep modules、系統化除錯這些累積幾十年的老功夫，固化成 agent「每次都照同一套紀律跑」的東西。你不用再每次開場都跟它耳提面命「先寫測試再寫實作」「找到根因才准動手」，叫一個 skill 就到位。作者自己把這件事講得最漂亮：一個 skill 存在的意義，是從一個隨機的系統裡把「可預測性」擰出來。

挑幾個最有料的看。diagnosing-bugs 這支表面在修 bug，骨子裡在逼你先蓋一條回饋迴路。它有六個階段，精髓卻全塞在 Phase 1：先做出一條「會對這個 bug 變紅」的 pass/fail 訊號，可以是 failing test、一句 curl、CLI 輸出的 diff，甚至 git bisect，人工 bash 腳本是最後手段。鐵律很硬——沒有一條能變紅的指令，不准進下一階段去猜 hypothesis。它信的就一句：回饋迴路建對了，bug 就修好九成。這跟大框架「你描述問題、我全包」的姿態剛好倒過來，它連你怎麼確認問題都要你先講清楚。

tdd 那支則把三個反模式講得有夠透。最容易中的是 tautological——你斷言時用跟程式碼一模一樣的算法重算一次期望值，expect(add(a,b)).toBe(a+b)，測試永遠 pass，卻什麼都沒驗到，笑死。還有 horizontal slicing，先把所有測試寫完再一次實作；它要你改走 vertical slice，一次一測一實作，每個測試都是一顆探路的曳光彈。這種「一次只前進一小步、每步都有訊號」的節奏，其實就是回饋迴路的另一個面向。

code-review 更講究。它開兩個 sub-agent 平行跑，一個只看 Standards（有沒有守 repo 文件化的規範，附 Fowler 十二個 code smell 當基準），一個只看 Spec（有沒有忠實做出當初 issue 要的東西），兩軸的發現故意不合併、不互相排名。理由很微妙：一個改動完全可能「每條標準都過，卻做錯了東西」，分開報，兩邊才不會互相遮蔽。旁邊還有一支叫 grilling 的原語更見功力——它把事實和決策分家，事實自己去環境查，決策一定丟給人類等答案，沒得到你點頭「達成共識」前不准動手。

連怎麼裝都藏著這套哲學。兩種方式，差別在心態，不在技術。一條是用 skills.sh 安裝器，npx skills@latest add mattpocock/skills，把檔案複製進你的專案，你能改成自己的版本，也能裝進 Codex 或其他吃 Agent-Skills 標準的環境。另一條是原生 plugin，/plugin install，唯讀、作者更新你就跟著更新，但不能碰。前者是「擁有並修改」，後者是「訂閱」。大框架通常只給你後者——你不會有把一整台自動駕駛車 fork 回來自己改的念頭。

這裡有個坑要先講。不管走哪種裝法，每個 repo 用之前都得先跑一次 /setup-matt-pocock-skills，它會問你用哪個 issue tracker、triage 要哪些 label、產出的 docs 放哪。沒設定，to-tickets、triage、code-review、wayfinder 這幾支會因為找不到設定檔直接卡住。別問我怎麼知道的。

還有一支 wayfinder 專門規劃「一個 session 裝不下」的超大工程，把 issue tracker 當成一張戰爭迷霧地圖，子任務都是「解出來是決策、不是交付物」的 decision ticket，每個限制在一個 10 萬 token 的 session 內解完。原則只有一句：Plan, don’t do——你開始想動手，通常代表你已經走到地圖邊緣，該交棒了。整套 skill 的設計語言都這樣，用一個模型早就熟到不行的詞（tight、red、fog of war、tracer bullet）當錨點，一個詞召喚一整區行為，省 token 又更穩。

用久了你會發現，這套東西真正改掉的不是你手上多幾個功能，而是你對「agent 該怎麼被管」的預設。大框架給你的是控制感的錯覺——流程很漂亮，直到它壞掉，而你讀不懂也改不動。一組小而可組合的 skill 給你的是另一種東西：每一支你都讀得懂、fork 得動、跟哪個模型搭配都行，而且每次都照同一套紀律跑。工程的基本功一直都在，TDD、找根因、code review，沒一樣是新的。新的是有人把它們固化成「每次都會發生」，而不再是「希望這次會發生」。說到底，真正值錢的是那份可預測性：每次都照同一套紀律跑。這波，真香。