010. 導言｜Skills 的價值，不是把 agent 變成聽話機器
Eric Tech 這支影片談的是 Matt Pocock 的 Claude Code Skills，但真正的主題不是「又多了一包好用指令」。它其實在問一個更大的問題：當模型越來越強，我們還需要多重的流程框架、嚴密的步驟鎖定、長篇 system prompt 嗎？
影片的答案偏向「不一定」。Matt Pocock 的路線，不是把 agent 綁進一條從頭跑到尾的 pipeline，而是把常見軟體工作切成很短、很明確、可重組的 skills：Grooming 負責追問需求，to-spec 負責把共識寫下來，to-tickets 負責切 feature slice，implement 盡可能走 TDD，code-review 用 fresh context 審查，architecture skill 再看更底層的模組結構。
來源影片在這裡：Eric Tech：Matt Pocock's Claude Code Skills Beat Superpowers Now。
這篇導讀會保留一點編輯距離。影片中提到的「51+ skills」「13 million downloads」「frontier model 不需要太多 guardrails」等判斷，都是講者在影片中的說法；本文把它們當成觀點和案例來整理，不當作未經查證的既定事實。
021. 從大型框架到小型接口｜為什麼 Matt 不喜歡一條龍流程
影片一開始先指出一個日常痛點：你叫 AI 做東西，AI 做得很快，但常常不是你要的樣子。原因不是模型完全不會，而是它不知道完整 context。你的產品語氣、設計偏好、功能邊界、技術限制、團隊習慣，如果沒有被收集和固定下來，agent 就只能猜。
很多框架的解法，是把工作包成一條完整 pipeline。先 brainstorming，再 planning，再 spec，再 tickets，再 implementation，再 review。這種設計的好處是流程完整，缺點是它常常假設你會照順序走到底。
Matt Pocock 的不滿在這裡：如果第二步方向錯了，但你第六步才發現，難道要重跑整條鏈？如果你已經實作完，才想回頭補 spec 或重新做需求訪談，為什麼 skill 不能單獨被叫出來？
所以他選擇的不是「更大的框架」，而是「更小的接口」。每個 skill 只負責一件事，而且可以在任何時候被重新組合。
這個觀點對 Claude Code 使用者尤其重要。真正讓 agent 穩定的，不一定是把所有流程都自動化，而是讓每個關鍵決策點都有一個清楚的工作接口：該問問題時問問題，該寫規格時寫規格，該審查時換新 context 審查。
032. Grooming｜把「需求不清楚」變成一棵 decision tree
影片最先拆的是 Grooming skill。它的工作不是馬上動手，而是 relentless 地追問，直到使用者和 agent 達成 shared understanding。
Eric 把它整理成五條規則。第一，問題沒有釐清前持續追問。第二，一次只處理 decision tree 的一個 branch，不要同時跳 checkout page、about page、dashboard。第三，問完一題後等待回答，不連珠炮式問十題。第四，不丟空白問題，而是給建議與選項。第五，沒有使用者確認前不行動。
這其實是很好的 agent product design。Grooming skill 並沒有假裝自己比使用者懂業務，它做的是把模糊空間切小，讓人做決策、讓模型負責整理選項。每回答一題，decision tree 就少一個岔路；等到岔路收斂，後面的 spec 和 implementation 才有地基。
這也解釋了為什麼「問問題」不是拖慢，而是省錢。沒問清楚就開始寫 code，最後通常不是省了一輪訪談，而是多了三輪返工。
043. to-spec 與 to-tickets｜寫下共識，但不要把 code 塞進 spec
Grooming 完之後，to-spec 的任務是把剛才的共識 freeze 下來。影片說得很直：conversation 關掉後，剛才的追問、回答、權衡都會消失；如果不寫下來，下一個 session 只能重新猜。
但 Matt 的 to-spec 有一個關鍵限制：spec 裡不要放 code block。
這點很值得記。很多人寫 spec 時，會忍不住把實作片段也塞進去，彷彿這樣更精準。問題是 codebase 會變，spec 裡的 code 可能過時；agent 之後又很容易盲目跟著 spec 裡的舊 code 寫。比較好的 spec 應該固定 intent、constraints、edge cases、acceptance criteria，讓 agent 回到現有 codebase 裡自己 cross-reference。
to-tickets 則負責把 spec 拆成能執行的 tickets。影片中特別反對按 layer 切工作，例如 database 一張、API 一張、UI 一張。這種切法每一張 ticket 都可能只完成半成品，最後要等全部拼起來才知道能不能跑。
Matt 的取向是按 feature slice 切。第一張 ticket 就做一個可驗證的 login flow，第二張做一個完整的 checkout slice。每張 ticket 都應該盡量 end-to-end，這樣 agent 做完後就能測，團隊也比較容易調整優先順序。
054. TDD 與 code-review｜讓測試先失敗，讓審查換一個腦袋
implementation skill 的核心，是在可能時觸發 TDD。這裡不是宗教式地說所有 code 都必須先測試，而是對 agent 寫 code 特別有用：先把需求寫成會失敗的 tests，再讓 Claude 實作到 tests 通過。
如果先寫 code，再叫 agent 補 test，測試很容易只是確認它剛剛寫出來的行為。code 裡有 bug，test 也會跟著 bug 走。先讓 tests fail，至少可以把需求獨立固定在另一個地方，降低「自我驗證」的風險。
code-review skill 則處理另一個常見問題：同一個 context 裡剛寫完 code 的 agent，很難像真的 reviewer 一樣看自己的作品。Matt 的做法是開 fresh context window，依照 code review checklist 重新看。
影片提到這份 checklist 來自 Martin Fowler 的 Refactoring vocabulary，只有 12 個詞。Eric 舉了 shotgun surgery、feature envy、data clumps。這些詞的好處，是它們語意密度很高。你不必寫一長串「檢查修改是否散落多處」「檢查邏輯是否放錯檔案」「檢查資料是否重複成群傳遞」，只要用正確 vocabulary，就能喚起模型已知的審查 lens。
這也是 Matt skills 的共同風格：不是更長，而是更準。
065. writing-for-agents 與 architecture review｜短不是偷懶，是降低干擾
影片中段談到 writing-for-agents。Matt 的 skills 通常很短，因為他認為每個多餘字都可能成為 distraction，讓模型偏離真正要做的事。像「I would really appreciate it if you would...」這類禮貌但沒有控制力的文字，在 skill 裡沒有價值。
更好的寫法，是 prune 到最小，並使用有深層語意的詞。shotgun surgery、data clumps、feature envy 這類詞就是例子。它們短，但背後有整套工程判斷。
architecture review 則把問題拉到 codebase 結構。影片提到，AI 理解一段主流程時，常常要追很多小函式、小模組，context window 很快被耗掉。這不是說模組化不好；小函式依然方便 unit test。問題在於，如果主要流程沒有清楚入口，agent 會在十幾扇門之間來回找路。
Matt 的主張比較像「替 agent 建一扇主要入口」。內部仍然可以有多個檔案，但主流程要被 encapsulate，讓 agent 少跳檔、少浪費 tokens。improve-codebase-architecture skill 會看 Git log、hot files、deletion test，找出可以刪掉或合併的結構問題。
其中 deletion test 很實用：如果刪掉某個 module，測試仍然通過，代表它可能沒有存在必要；如果刪掉後測試失敗，代表它確實是 dependency。這種方法比只問 agent「這段 code 有沒有用」更可靠，因為它把判斷接回測試。
076. 編輯觀點｜模型越強，skill 越該像欄杆，不該像鐵軌
Eric 最後的 verdict 是：Matt Pocock 這種 modular skill mindset，可能更適合 frontier models。影片中的說法是，像 GPT-5.6、Fable 5、Opus 5 這類更強模型，已經不需要被大型框架手把手牽著走；skill 只需要 guard 和 guide，保留模型自己判斷的空間。
這個判斷可以討論，但方向值得重視。
舊式 agent workflow 常把 skill 當鐵軌：每一步都規定好，模型照著跑。這對弱模型或高風險流程很有用，因為你不希望它自己發明工作方法。但當模型本身能力變強，太多 guardrails 可能從保護變成限制。你以為你在減少錯誤，其實也可能壓掉模型更好的推理路線。
Matt Pocock 的 skills 比較像欄杆。它們不替模型決定整條路，只在關鍵位置定義工作邊界：問清楚再做、spec 不塞 code、ticket 按 feature slice、測試先失敗、review 換 context、用 vocabulary 做高密度審查。
對魚塘讀者來說，這支影片最有用的 takeaway 不是「去裝哪一包 skill」，而是回頭檢查自己的 agent workflow：哪些地方真的需要流程？哪些地方其實只需要一個短而準的 skill？哪些長篇 instructions 已經不是保護，而是在干擾？
AI 工具的下一階段，可能不是比誰的 prompt 最長，而是比誰更知道哪裡該少寫一點。
給讀者的 Takeaway
- Matt Pocock 的 skills 強調 modular、reusable、可任意重組，而不是從頭跑到尾的一條龍框架。
- Grooming skill 的價值，是把模糊需求拆成 decision tree，等 shared understanding 成形後再行動。
- spec 應該固定意圖與限制，不該塞容易過時的 code block。
- tickets 按 feature slice 切，比按 database / API / UI layer 切更容易 end-to-end 驗證。
- 對更強的 frontier models，skill 可能該更短、更語意密集，像欄杆一樣引導，而不是像鐵軌一樣控制。