TS 大神 Matt Pocock 開源自己的 AI Skills，主打反 Vibe Coding
整理版優先睇
Matt Pocock 開源 AI Skills，用反 Vibe Coding 方式強化工程紀律
呢篇文章介紹咗 TypeScript 大神 Matt Pocock 開源嘅 Skills 倉庫，佢嘅理念同主流嘅 BMAD、Spec-Kit 等 AI 編程框架好唔同。Matt 認為呢啲框架將流程變成黑盒，開發者失去控制權；而 Skills 係一系列細粒、容易改、自由組合嘅技能片段，你可以揀幾個塞入 project 就用得，唔需要全套接受。佢嘅目標係幫助開發者掌握 AI 協作嘅主動權，唔係靠感覺 Vibe Coding。
文章詳細拆解咗四個 AI 編程嘅常見頑疾：AI 做錯嘢、Token 浪費、代碼寫錯、架構變爛。針對每個問題，Matt 畀咗對應嘅 Skills，例如用 grill-me 做需求澄清、用 CONTEXT.md 統一術語、用 TDD 垂直切片確保代碼正確、用 improve-codebase-architecture 定期清淤。佢仲強調咗「反饋迴路」嘅重要性，認為 debug 嘅關鍵係先搞掂穩定復現。
整體嚟講，呢篇文唔單止係工具介紹，更加係一套工程思維嘅示範。Matt 想傳達嘅係：AI 唔係取代工程紀律，而係用來強化佢。如果你用緊 Claude Code 或者 Codex，呢個倉庫好值得 clone 落嚟參考，特別係入面關於 TDD、CONTEXT.md 同 ADR 嘅做法。
- Skills 倉庫核心係「反 Vibe Coding」，將控制權還返畀開發者，流程透明可改。
- 四大頑疾：AI 做錯要求 / Token 浪費 / 代碼不對 / 架構腐壞，每個都有對應 Skill。
- grill-me 技能用「AI 拷問開發者」嘅方式做需求澄清，確保理解一致。
- TDD 提倡垂直切片：逐個測試逐個實現，避免水平切片導致測試失真。
- Caveman 模式同 Git Guardrails 呢啲小工具，分別幫手慳 token 同防止 agent 誤操作。
Grill-Me Core Prompt
一次問一個問題，將決策樹每個分支都行完，每個問題都畀出推薦答案。用嚟做需求澄清。
Git Guardrails for Claude Code
一個 PreToolUse hook，攔截 git push --force、git reset --hard 等危險操作，避免 agent 推飛 main 分支。
Triage 五態機
Issue 狀態機：needs-triage → needs-info → ready-for-agent → ready-for-human → wontfix，每條 AI 留言強制加前綴以免混淆。
開源背景：一個 TypeScript 大神嘅反 Vibe Coding 宣言
如果你寫 TypeScript，應該好難唔識 Matt Pocock — Total TypeScript、TypeScript 錯誤翻譯器、各種類型體操教學，佢幾乎一手撐起英文社區嘅 TS 教學。最近佢低調開源咗一個新倉庫（mattpocock/skills），副標題寫明：「Skills For Real Engineers」，翻譯過嚟就係「畀真正做工程嘅人用嘅技能」。呢句說話聽落有啲串，但佢喺 README 已經講得好白：呢啲 Skills 係用嚟做真實開發，唔係用嚟 Vibe Coding 嘅。
一句講曬：BMAD 嗰類係「我幫你定義流程」，Skills 係「我將工程師嘅好習慣拆畀你，你自己拼」。
四大頑疾與對應 Skills：點樣先叫「真係用得着」？
成套 Skills 嘅設計邏輯，係圍繞 Matt 觀察到嘅四個 AI 編程失敗模式。呢部分係 README 嘅靈魂，值得講清楚。
頑疾 1：AI 冇做你想要嘅事。呢個係最高頻嘅失敗模式 — 你諗 A，描述變 B，AI 理解成 C，寫出嚟係 D。
Matt 引用咗《程序員修煉之道》一句話：「冇人確實知道自己想要咩。」AI 時代呢句話仲係成立，只係甲方換咗 agent。佢嘅解法叫 Grilling Session，即係 AI 反過嚟「拷問」你。
- 1 /grill-me：agent 好似面試官咁輪流追問你嘅設計，每個分支都問到你畀明確答案為止。
- 2 /grill-with-docs：升級版，會將你嘅回答同項目嘅 CONTEXT.md 做對照，發現術語衝突即刻指出。
Interview me relentlessly about every aspect of this plan until we reach a shared understanding.
Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.
For each question, provide your recommended answer.
Ask the questions one at a time.頑疾 2：AI 太囉嗦，token 嘩嘩燒。Matt 引用 Eric Evans《領域驅動設計》：團隊入面開發同領域專家一開始講嘅唔係同一種語言。
跟住落嚟嘅頑疾 3：寫出嚟嘅代碼就係唔啱。呢個時候問題唔喺溝通，而喺反饋迴路。Matt 嘅解法係 TDD 嘅紅綠重構循環，對應 skill 係 /tdd。佢特別強調一個反模式叫「水平切片」：一次過寫曬所有測試，然後一次過寫曬實現。咁做會產出垃圾測試，測試測到嘅係想像中嘅行為，唔係真實行為。
正確做法係垂直切片（追蹤彈）：寫一個測試，寫最少嘅代碼令佢通過；再寫下一個測試，再寫最少嘅代碼。一顆一顆試射，唔好一彈夾一次打完。
- 錯誤（水平）：RED: test1, test2, test3, test4, test5 → GREEN: impl1, impl2, impl3, impl4, impl5
- 正確（垂直）：RED→GREEN: test1→impl1, RED→GREEN: test2→impl2, ...
另一個相關 skill 係 /diagnose，專門調難搞嘅 bug。佢將調試拆成六個階段，最強調 Phase 1：反饋迴路。如果有個快、確定、agent 自己 run 到嘅 pass/fail 信號，你一定揾到 bug；如果冇，再點睇 code 都冇用。排序優先級：失敗測試 > curl script > CLI 調用 > headless 瀏覽器 > 流量回放 > 一次性 harness > fuzz test > git bisect。人肉 click 放最後，萬不得已先用。
頑疾 4：項目變成一坨爛泥。AI 寫 code 快，爛得都快，複雜度增長速度比以往任何時候都猛。
Matt 畀嘅解決方案係從根上重新關心 code 設計：/to-prd 整理 PRD，/zoom-out 畀你相關模塊地圖，/improve-codebase-architecture 揾「深化機會」。佢引用 John Ousterhout《軟件設計哲學》嘅觀點：好模塊係深嘅，複雜功能收喺簡單接口後面。判斷方法叫「刪除測試」：假想 delete 呢個模塊，複雜度消失咗，即係佢本來只係穿透層；複雜度反而出現喺 N 個 caller 入面，即係佢認真做緊嘢。呢個 skill 建議每隔幾日 run 一次，定期清淤。
幾款眼前一亮嘅小工具：Caveman 模式同 Git Guardrails
除咗四大核心技能，個倉庫仲有幾個得意小工具。首先係 /caveman 穴居人模式：叫 agent 好似穴居人咁講嘢，delete 曬所有 a/an/the、客套話同緩衝詞。Matt 話可以慳 75% token。一個對比例子：
普通模式：「Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by...」
穴居人模式：「Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:」
技術資訊一字不少，水分全部蒸發。呢個 skill 喺 context 好緊張嘅長對話入面出乎意料咁實用。
另一個係 /git-guardrails-claude-code，專為 Claude Code 設計嘅 PreToolUse hook，攔截危險嘅 git 操作：git push（包括 --force）、git reset --hard、git clean -f、git branch -D、git checkout . / git restore .。被攔落嚟時，AI 會見到一句「你冇權限執行呢個命令」，然後乖乖揾你確認。一行 command 搞掂之後，唔使再擔心 agent 一時手癢推飛 main 分支。
仲有 /write-a-skill 腳手架，幫你產出符合規範嘅 SKILL.md；/triage 五態機（needs-triage、needs-info、ready-for-agent、ready-for-human、wontfix），每條 AI 留言強制帶前綴 *This was generated by AI during triage.*，避免人類被混淆。呢套流程更適合維護 open source 項目嘅人。
總結：AI 幫手強化工程紀律，唔係取代佢
過去一年 Vibe Coding 呢個詞俾人反覆提起 — 憑感覺同 AI 傾幾句就生 code，爽係爽，但維護起嚟邊個用邊個知。Matt 今次開源 Skills，本質上係畀社區一個反 Vibe 嘅樣板：AI 唔係用嚟取代工程紀律，而係用嚟強化工程紀律。
如果你最近都喺度搞 Claude Code、Codex 或者類似 agent，建議直接 clone 個倉庫落嚟睇一遍。就算你唔打算照搬，入面對 TDD、CONTEXT.md、ADR 嘅工程理解，都好值得參考。
倉庫地址：https://github.com/mattpocock/skills
如果你寫 TypeScript，應該好難避開 Matt Pocock 呢個名。Total TypeScript、TypeScript 錯誤翻譯器、各種類型體操教學，佢幾乎一手撐起咗英文社區裏面 TS 教學嘅半邊天。
最近佢低調開源咗一個新倉庫，叫 mattpocock/skills，副標題寫得好直接：Skills For Real Engineers。翻譯過嚟就係「俾真正做工程嘅人用嘅技能」。
呢句說話聽落有啲串，但佢確實在 README 入面將自己嘅態度寫得好清楚：呢啲 Skills 係用嚟做真實開發嘅，唔係用嚟 Vibe Coding 嘅。
點解係 Skills，而唔係 BMAD、Spec-Kit、GSD？
呢兩年湧現嘅 AI 編程方法論唔少。BMAD、Spec-Kit、GSD 呢類框架都嘗試將「點樣同 AI 協作寫 Code」呢件事流程化。佢哋提供完整嘅工作流，agent 一步一步跟住流程行。
Matt 喺 README 入面直接點咗名：呢啲方法論嘅問題係佢哋幫你攞走咗控制權。流程係黑盒，一旦中間有一步出咗 bug，你好難鑽入去修。
佢嘅思路完全相反。Skills 係一組好細、好容易改、可以自由組合嘅技能片段。你唔需要全套接受，揀幾個順手嘅塞入項目就用得。佢哋唔綁死特定模型，Claude Code、Codex 都行得。底層邏輯其實係幾十年嘅工程經驗沉澱，唔係咩 AI 時代獨有嘅新魔法。
一句話總結：BMAD 呢類係「我幫你定義流程」，Skills 係「我將工程師嘅好習慣拆俾你，你自己砌」。
30 秒裝好：一行命令搞掂
npx skills@latest add mattpocock/skills
跑完之後會叫你揀要裝邊啲 Skills、裝去邊個 agent 度（Claude Code 或 Codex）。**有個必選項叫 /setup-matt-pocock-skills**，佢係初始化器，會問你三個關鍵問題：
你想用邊款 issue tracker（GitHub、Linear，定係本地 markdown 文件） 你 triage 時用咩 label（默認係 needs-triage、ready-for-agent 呢套五態機） 你想將生成嘅文件放喺邊個目錄
行完呢一步，其餘嘅 Skills 先會知道呢個倉庫嘅「語境」。呢個設計都幾聰明，避免咗 Skills 之間因為約定唔統一而互相打架。
Matt 想解決嘅四個 AI 編程頑疾
成套 Skills 嘅設計邏輯，係圍繞佢觀察到嘅四個 AI 編程失敗模式嚟嘅。呢部分內容係 README 嘅靈魂，值得拎出嚟講。
頑疾 1：AI 冇做你諗緊嗰件事
呢個係最高頻嘅失敗模式。你個腦諗緊 A，描述出嚟變成 B，AI 理解成 C，寫出嚟係 D。等你見到產出，往往已經離題十萬八千里。
Matt 引用咗《程序員修煉之道》入面一句話：「冇人確實知道自己想要乜。」AI 時代呢句話依然成立，只係甲方換咗做 agent。
佢嘅解法叫 Grilling Session，即係叫 AI 反過嚟「拷問」你。對應兩個 Skill：
** /grill-me**：叫 agent 好似面試官咁輪住追問你嘅設計，每個分支都問到你俾出明確答案為止** /grill-with-docs**：升級版，會將你嘅回答同項目入面現有嘅CONTEXT.md（領域語言文檔）做對照，發現術語衝突即刻指出嚟
grill-me 嘅核心 prompt 簡單到令人意外，就一段話：
“Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
Ask the questions one at a time.
翻譯過嚟就係「一次問一個問題，將決策樹每個分支都行曬，每個問題都俾返你推薦嘅答案」。Matt 話呢個係佢用得最多嘅兩個 Skill，每次要做改動之前都會先嚟一輪。
呢個思路其實喺傳統軟件工程入面有個老名，叫需求釐清。AI 將佢自動化咗。
頑疾 2：AI 太長氣，token 嘩嘩燒
Matt 引用咗 Eric Evans 嘅《領域驅動設計》：喺團隊入面，開發同領域專家一開始講嘅唔係同一種語言。AI 都係。將 agent 掟入項目，佢要用大量 token 去推斷你嘅「行話」。
舉個佢自己嘅例子。喺佢嘅 course-video-manager 項目入面，有一個概念叫「課程章節入面嘅某節課俾咗真實文件系統位置時出現嘅問題」，呢一長串話每次描述都要燒一堆 token。後嚟喺 CONTEXT.md 入面將呢個概念改名做 materialization cascade（具體化級聯），之後一句「materialization cascade 出咗 bug」就搞掂。
呢個共享語言帶嚟嘅好處唔止慳 token：
變量、函數、檔案命名會更一致 agent 喺程式碼庫入面導航更順 agent 思考時佔用嘅 token 都更少
/grill-with-docs 喺拷問你嘅同時，會將呢啲術語沉澱入 CONTEXT.md，硬啲嘅架構決策就寫入 docs/adr/ 目錄。Matt 話呢個可能係成個倉庫最強嘅一招，「好難解釋佢有幾有用，你試嚇就知」。
ADR 寫唔寫有三個判斷標準，三個都滿足先寫：
決策唔容易反悔 之後睇 code 嘅人會奇怪「點解咁搞」 係真係有過權衡嘅結果
寫少好過亂寫。
頑疾 3：寫出嚟嘅 code 就係錯
需求對齊咗，AI 都係寫衰，點算？呢個時候問題唔喺溝通，係喺反饋迴路。
Matt 嘅解法好經典：TDD 嘅紅綠重構循環。對應 Skill 係 /tdd。
但佢特別強調咗一個反模式叫「水平切片」。好多人理解嘅 TDD 係：將所有測試寫曬，再寫所有實現。呢種做法佢認為會產出垃圾測試：
批量寫出嚟嘅測試測嘅係想像中嘅行為，唔係真實行為 你最後只會測到數據結構同函數簽名呢啲「形狀」，測唔到用戶實際感受到嘅行為 改動行為時測試過到，冇改行為時測試反而死
正確做法叫垂直切片或者叫追蹤彈：寫一個測試，寫最少嘅 code 令佢通過，再寫下一個測試，再寫最少嘅 code。一粒一粒試射，唔好一次過打曬成個彈匣。
錯誤（水平）：
RED: test1, test2, test3, test4, test5
GREEN: impl1, impl2, impl3, impl4, impl5
正確（垂直）：
RED→GREEN: test1→impl1
RED→GREEN: test2→impl2
...
另一個相關嘅 Skill 係 /diagnose，專門用嚟調難搞嘅 bug。佢將除錯拆成六個階段，最強調嘅係 Phase 1 反饋迴路：
“呢一步係成套技能嘅核心。其他都係機械操作。如果你有一個快、確定、agent 自己行到嘅 pass/fail 信號，你一定揾到 bug。如果冇，再點樣睇住 code 都救唔到你。
排序優先級係：失敗測試 > curl 腳本 > CLI 調用 > headless 瀏覽器 > 流量回放 > 一次性 harness > 模糊測試 > git bisect。人手點擊放喺最後，唔到最後關頭唔好用。
寫過幾個難搞 bug 嘅人會即刻有共鳴：90% 嘅精力其實應該花喺「點樣穩定重現」上，其餘 10% 先係修。
頑疾 4：項目變成一嚿爛泥
最後一個問題係架構腐爛。AI 寫 code 快，爛得都快。程式碼庫嘅複雜度增長速度比以往任何時候都勁。
Matt 俾出嘅解決方案係由根本重新關心 code 設計：
/to-prd：將當前對話整理成 PRD，會先問你打算改啲咩模塊/zoom-out：叫 agent 跳出當前檔案，俾你一張相關模塊同調用方嘅地圖/improve-codebase-architecture：喺現有 code 入面揾「深化機會」
呢度佢引用咗 John Ousterhout 喺《軟件設計哲學》嘅核心觀點：好模塊係深嘅，複雜功能收埋喺簡單接口後面。佢將呢套理念翻譯成一個具體嘅判斷方法叫「刪除測試」：將呢個模塊假想刪咗，複雜度消失咗，即係佢本來就係一個穿透層；複雜度反而出現喺 N 個調用方度，即係佢認真做緊嘢。
/improve-codebase-architecture 呢個 Skill 佢建議每隔幾日就喺項目行一次，定期清淤。
幾個令人眼前一亮嘅小工具
除咗上面四類核心 Skill，倉庫仲有幾個得意嘅小嘢。
/caveman 穴居人模式
叫 agent 好似穴居人咁講嘢，刪曬所有 a/an/the、客套、緩衝詞。Matt 聲稱可以慳 75% 嘅 token。一個對比例子：
普通模式：
"Sure! I'd be happy to help you with that. The issue you're
experiencing is likely caused by..."
穴居人模式：
"Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:"
技術資訊一字唔少，水份全部蒸發。呢個 Skill 出乎意料咁實用，尤其係上下文緊張嘅長對話入面。
/git-guardrails-claude-code
呢個搞中好多前端同學嘅痛點。俾 Claude Code 裝個 PreToolUse hook，攔截危險嘅 git 操作：
git push（包括--force）git reset --hardgit clean -fgit branch -Dgit checkout ./git restore .
被攔落嚟時，AI 會見到一句「你冇權限執行呢個指令」，乖乖哋去揾你確認。一行指令裝好之後，唔使再擔心 agent 一時手滑將 main 分支推飛。
/write-a-skill
寫新 Skill 嘅腳手架。佢會引導你產出符合規範嘅 SKILL.md，描述字段必須包含觸發關鍵詞，因為呢個往往係 agent 揀加載邊個 Skill 時睇到嘅全部資訊。呢種「自舉」設計好 Matt 風格。
/triage
Issue 五態機：needs-triage、needs-info、ready-for-agent、ready-for-human、wontfix。每條機械人留言強制帶 > *This was generated by AI during triage.* 前綴，避免人類被 AI 評論搞亂。呢套流程更適合維護開源項目嘅人，普通業務開發未必用得上。
過去一年，Vibe Coding 呢個詞成日俾人提起。佢指嘅係嗰種「憑感覺同 AI 傾嚇計就將 code 生出來」嘅方式。爽就真係爽，但維護起嚟邊個用邊個知。Matt 今次開源 Skills，本質上係俾社區一個反 Vibe 嘅樣板：AI 唔係用嚟代替工程紀律嘅，而係用嚟強化工程紀律嘅。
更值得諗嘅係，呢套嘢出自一個 TypeScript 教育者之手，唔係 AI 公司嘅產品經理。佢代表咗一線工程師對 AI 協作嘅真實訴求：可控、可改、可組合，反對任何將流程變黑盒嘅做法。
如果你最近都喺度搞 Claude Code、Codex 或者類似嘅 agent，建議直接將倉庫 clone 落嚟翻一次。就算你唔打算照搬，入面對 TDD、CONTEXT.md、ADR 嘅工程理解，都值得睇幾次。
倉庫地址：https://github.com/mattpocock/skills
如果你寫 TypeScript，應該繞不開 Matt Pocock 這個名字。Total TypeScript、TypeScript 錯誤翻譯器、各種類型體操教學，他幾乎一手撐起了英文社區裏 TS 教學的半邊天。
最近他低調開源了一個新倉庫，叫 mattpocock/skills，副標題寫得很直白：Skills For Real Engineers。翻譯過來就是"給真正幹工程的人用的技能"。
這話聽上去有點衝，但他確實在 README 裏把自己的態度寫得很明白：這些 Skills 是用來做真實開發的，不是用來 Vibe Coding 的。
為什麼是 Skills，而不是 BMAD、Spec-Kit、GSD？
這兩年湧現的 AI 編程方法論不少。BMAD、Spec-Kit、GSD 這類框架都試圖把"怎麼和 AI 協作寫代碼"這件事流程化。它們提供完整的工作流，agent 一步一步按照流程跑。
Matt 在 README 裏直接點了名：這些方法論的問題是它們替你拿走了控制權。流程是黑盒，一旦中間某一步出了 bug，你很難鑽進去修。
他的思路完全相反。Skills 是一組很小、很容易改、能自由組合的技能片段。你不需要全套接受，挑幾個順手的塞進項目裏就能用。它們不綁死特定模型，Claude Code、Codex 都能跑。底層邏輯其實是幾十年的工程經驗沉澱，不是什麼 AI 時代獨有的新魔法。
一句話總結：BMAD 那一類是"我幫你定義流程"，Skills 是"我把工程師的好習慣拆給你，你自己拼"。
30 秒裝好：一行命令搞定
npx skills@latest add mattpocock/skills
跑完之後會讓你勾選要裝哪些 Skills、裝到哪個 agent 上（Claude Code 或 Codex）。**有一個必選項叫 /setup-matt-pocock-skills**，它是初始化器，會問你三個關鍵問題：
你想用什麼 issue tracker（GitHub、Linear，還是本地 markdown 文件） 你 triage 時用什麼 label（默認是 needs-triage、ready-for-agent 這套五態機） 你想把生成的文檔放在哪個目錄
跑完這一步，剩下的 Skills 才知道這個倉庫的"語境"。這個設計挺聰明的，避免了 Skills 之間因為約定不統一而互相打架。
Matt 想解決的四個 AI 編程頑疾
整套 Skills 的設計邏輯，是圍繞他觀察到的四個 AI 編程失敗模式來的。這部分內容是 README 的靈魂，值得展開聊。
頑疾 1：AI 沒幹你想要的事
這是最高頻的失敗模式。你腦子裏想的是 A，描述出來變成 B，AI 理解成 C，寫出來是 D。等你看到產出，往往已經偏離十萬八千里。
Matt 引用了《程序員修煉之道》裏的一句話："沒有人確切知道自己想要什麼。"AI 時代這句話依然成立，只是甲方換成了 agent。
他的解法叫 Grilling Session，也就是讓 AI 反過來"拷問"你。對應兩個 Skill：
** /grill-me**：讓 agent 像面試官一樣輪流追問你的設計，每個分支都問到你給出明確答案為止** /grill-with-docs**：升級版，會把你的回答和項目裏已有的CONTEXT.md（領域語言文檔）做對照，發現術語衝突立刻指出來
grill-me 的核心 prompt 簡單到讓人意外，就一段話：
“Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
Ask the questions one at a time.
翻譯過來就是"一次問一個問題，把決策樹每個分支都走完，每個問題都給出你推薦的答案"。Matt 說這是他用得最多的兩個 Skill，每次要做改動前都會先來一輪。
這個思路其實在傳統軟件工程裏有個老名字，叫需求澄清。AI 把它自動化了。
頑疾 2：AI 太囉嗦，token 嘩嘩燒
Matt 引用了 Eric Evans 的《領域驅動設計》：在團隊裏，開發和領域專家一開始說的不是同一種語言。AI 也是。把 agent 丟進項目裏，它要花大量 token 去推斷你的"行話"。
舉個他自己的例子。在他的 course-video-manager 項目裏，有一個概念叫"課程章節裏的某節課被賦予真實文件系統位置時出現的問題"，這一長串話每次描述都要燒一堆 token。後來在 CONTEXT.md 裏把這個概念命名為 materialization cascade（實體化級聯），之後一句"materialization cascade 出 bug 了"就完事。
這個共享語言帶來的好處不止省 token：
變量、函數、文件命名會更一致 agent 在代碼庫裏導航更順 agent 思考時佔用的 token 也更少
/grill-with-docs 在拷問你的同時，會把這些術語沉澱進 CONTEXT.md，硬一點的架構決策則寫進 docs/adr/ 目錄。Matt 說這可能是整個倉庫裏最強的一招，"很難解釋它有多管用，你試一下就知道"。
ADR 寫不寫有三個判斷標準，三個全滿足才寫：
決策不容易反悔 之後看代碼的人會奇怪"為什麼這麼搞" 是真有過權衡的結果
少寫比亂寫強。
頑疾 3：寫出來的代碼就是不對
需求對齊了，AI 還是寫崩，怎麼辦？這時候問題不在溝通，在反饋迴路。
Matt 的解法很經典：TDD 的紅綠重構循環。對應 Skill 是 /tdd。
但他特別強調了一個反模式叫"水平切片"。很多人理解的 TDD 是：先把所有測試寫完，再寫所有實現。這種做法他認為會產出垃圾測試：
批量寫出來的測試測的是想象中的行為，不是真實行為 你最後只會測到數據結構和函數簽名這種"形狀"，測不到用戶實際能感知的行為 改動行為時測試通過，沒改行為時測試反而掛
正確做法叫垂直切片或者叫追蹤彈：寫一個測試，寫最少的代碼讓它通過，再寫下一個測試，再寫最少的代碼。一顆一顆試射，不要把一彈夾一次打完。
錯誤（水平）：
RED: test1, test2, test3, test4, test5
GREEN: impl1, impl2, impl3, impl4, impl5
正確（垂直）：
RED→GREEN: test1→impl1
RED→GREEN: test2→impl2
...
另一個相關的 Skill 是 /diagnose，專門用來調難 bug。它把調試拆成六個階段，最強調的是 Phase 1 反饋迴路：
“這一步是整套技能的核心。其他都是機械操作。如果你有一個快、確定、agent 能自己跑的 pass/fail 信號，你一定能找到 bug。如果沒有，再怎麼盯着代碼看也救不了你。
排序優先級是：失敗測試 > curl 腳本 > CLI 調用 > headless 瀏覽器 > 流量回放 > 一次性 harness > 模糊測試 > git bisect。人肉點擊放在最後，不到萬不得已不上。
寫過幾個難 bug 的人會立刻共鳴：90% 的精力其實應該花在"怎麼穩定復現"上，剩下的 10% 才是修。
頑疾 4：項目變成一坨爛泥
最後一個問題是架構腐壞。AI 寫代碼快，爛得也快。代碼庫的複雜度增長速度比以往任何時候都猛。
Matt 給出的解決方案是從根上重新關心代碼設計：
/to-prd：把當前對話整理成 PRD，會先問你打算改哪些模塊/zoom-out：讓 agent 跳出當前文件，給你一張相關模塊和調用方的地圖/improve-codebase-architecture：在已有代碼裏找"深化機會"
這裏他引用了 John Ousterhout 在《軟件設計哲學》裏的核心觀點：好模塊是深的，複雜功能藏在簡單接口後面。他把這套理念翻譯成了一個具體的判斷方法叫"刪除測試"：把這個模塊假想刪掉，複雜度消失了，說明它本來就是個穿透層；複雜度反而出現在 N 個調用方里，說明它在認真幹活。
/improve-codebase-architecture 這個 Skill 他建議每隔幾天就在項目上跑一次，定期清淤。
幾個讓人眼前一亮的小工具
除了上面四類核心 Skill，倉庫裏還有幾個有意思的小東西。
/caveman 穴居人模式
讓 agent 像穴居人一樣說話，刪掉所有 a/an/the、客套、緩衝詞。Matt 聲稱能省 75% 的 token。一個對比例子：
普通模式：
"Sure! I'd be happy to help you with that. The issue you're
experiencing is likely caused by..."
穴居人模式：
"Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:"
技術信息一字不少，水分全部蒸發。這個 Skill 出乎意料地實用，尤其是上下文吃緊的長會話裏。
/git-guardrails-claude-code
這個戳中很多前端同學的痛點。給 Claude Code 裝個 PreToolUse hook，攔截危險的 git 操作：
git push（包括--force）git reset --hardgit clean -fgit branch -Dgit checkout ./git restore .
被攔下來時，AI 會看到一句"你沒有權限執行這個命令"，乖乖去找你確認。一行命令安好之後，再也不用擔心 agent 一時手抖把 main 分支推飛。
/write-a-skill
寫新 Skill 的腳手架。它會引導你產出符合規範的 SKILL.md，描述字段必須包含觸發關鍵詞，因為這往往是 agent 選擇加載哪個 Skill 時能看到的全部信息。這種"自舉"設計很 Matt 風格。
/triage
Issue 五態機：needs-triage、needs-info、ready-for-agent、ready-for-human、wontfix。每條機器人留言強制帶 > *This was generated by AI during triage.* 前綴，避免人類被 AI 評論搞混。這套流程更適合維護開源項目的人，普通業務開發未必用得上。
過去一年，Vibe Coding 這個詞被反覆提起。它指的是那種"憑感覺跟 AI 聊一聊就把代碼生出來"的方式。爽是真爽，但維護起來誰用誰知道。Matt 這次開源 Skills，本質上是給社區一個反 Vibe 的樣板：AI 不是用來代替工程紀律的，而是用來強化工程紀律的。
更值得琢磨的是，這套東西出自一個 TypeScript 教育者之手，不是 AI 公司的產品經理。它代表了一線工程師對 AI 協作的真實訴求：可控、可改、可組合，反對任何把流程變黑盒的做法。
如果你最近也在折騰 Claude Code、Codex 或者類似的 agent，建議直接把倉庫 clone 下來翻一遍。哪怕你不打算照搬，裏面對 TDD、CONTEXT.md、ADR 的工程理解，也值得看幾遍。
倉庫地址：https://github.com/mattpocock/skills