TL;DR
- 本文解決:GitHub 上一個 166k star 的個人 skill 庫(mattpocock/skills)在講什麼、跟官方 Superpowers 有什麼不同、值不值得裝
- 推薦給:已經在用 Claude Code / Codex,想找一套「不是幫你寫功能,而是幫你守工程紀律」的 skill 組合的人
- 讀完你會知道:這個庫拆解出的 4 個 AI agent 常見失控問題、6 個核心 skill 各自怎麼解、跟 obra/superpowers 該怎麼分工
📌 目錄
🎯 這是什麼:一個人的 .claude 目錄開源了
mattpocock/skills 的 GitHub 簡介只有一句話:「Skills for Real Engineers. Straight from my .claude directory.」
查證當下(2026 年 7 月)的實際數字:166k stars、14.3k forks、957 人 watching、MIT license。這些數字直接來自 gh repo view 抓的 GitHub API,不是估的。
它不是一個框架、不是一個 CLI 工具,是一堆 Markdown 檔案 —— Claude Code / Codex 的 skill 機制,把「怎麼做某件事」寫成一份可以被 agent 讀取、觸發、遵循的說明文件。整個 repo 的核心就是 skills/ 目錄下一份份 SKILL.md。
我原本聽到的說法是「用 5 個 skill 把模糊想法推到完成開發」,但實際翻過 README 之後,這個框架站不住——repo 裡沒有「5 個 skill 一條龍」這種敘事,也查無公開的下載量數字(GitHub 沒有下載計數這種公開指標,750 萬這個數字完全找不到來源)。真正的結構是:README 開頭列了 4 個「你正在遇到的問題」,每個問題底下對應到具體的 skill。這是本文採用的角度 —— 按實際查證到的東西寫,不是按聽到的說法硬套。
👤 作者是誰:Matt Pocock
Matt Pocock 是 Total TypeScript 的作者,在 TypeScript 教學圈小有名氣,同時也經營一份技術 newsletter(aihero.dev,約 6 萬訂閱)。這個 skill 庫是他把自己每天實際在用的 .claude 目錄整份公開,不是為了推廣寫的教材,是「我自己每天在吃這套狗糧」的產物 —— repo 裡的 CHANGELOG.md 顯示他還在頻繁迭代(查證當下最新 release 是 v1.1.0)。
這也是為什麼這個 repo 讀起來不像官方文件,更像一份「一個資深工程師覺得 AI agent 老是搞砸這幾件事,所以寫了流程把它按住」的筆記。
🧩 4 個問題,6 個核心 skill 拆解
README 開頭點名的 4 個失敗模式,以及各自對應的 skill:
| # | AI Agent 常見失控 | 對應 skill | 一句話解法 |
|---|---|---|---|
| 1 | 需求沒對齊就動手,寫到一半才發現理解錯 | to-spec | 先把模糊需求逼成結構化 spec 文件,再往下走 |
| 2 | 一次改一大包,PR 大到沒人審得動、也沒法獨立驗證 | to-tickets | 把 spec 拆成「垂直切片」(vertical slice)的小票,每張票獨立可驗證 |
| 3 | 沒有測試邊界,agent 到處加 mock、測到實作細節 | tdd | 強制先跟你確認「seam」(測試邊界)才准寫測試,test-first 循環 |
| 4 | Code review 沒有章法,不是漏看規格就是拘泥小節 | code-review | 雙軸並行審查:一軸看有沒有符合團隊規範,一軸看有沒有做到 spec 要求 |
implement(依 spec/tickets 實際動手,串接 tdd + code-review)跟 grill-with-docs(先逼問清楚需求再查文件,避免 agent 亂猜 API)兩個輔助 skill,一起構成完整鏈路。
to-spec:把「模糊」變成「白紙黑字」
to-spec 產出的 spec 文件有固定骨架:Problem Statement → Solution → User Stories → Implementation Decisions → Testing Decisions → Out of Scope → Further Notes。
Out of Scope 這個區塊 —— 明確寫下「這次不做什麼」,這是我自己寫 spec 時最容易漏掉的部分,也是 agent 最容易「順手多做」(scope creep)的地方。
to-tickets:垂直切片,不是切功能層
這是這個庫裡設計最細的一個 skill。核心規則:每張票要切過完整的一條路徑(schema、API、UI、測試),不是切一層(例如「這張票只寫後端」)。理由很直接 —— 一張只切到後端的票,沒辦法自己驗證、自己 demo,永遠得等下一張票才算數。
skill 裡還處理了一個例外情況:wide refactor(改一個共用型別、rename 一個欄位,牽動整個 codebase 的機械式改動)。這種改動天生沒辦法切成垂直切片,官方定義的處理方式是 expand-contract:先「擴張」(新舊兩種形式並存,不 break 任何呼叫端),再分批「遷移」呼叫端(每批一張獨立票,批次大小照爆炸半徑抓,例如按 package 或目錄分),最後「收縮」(舊形式沒人用了才刪掉)。整個過程保證每一步 CI 都是綠的。
tdd:先問邊界,再動筆
流程只有一句話核心:紅燈在綠燈前面,而且只寫剛好能讓紅燈變綠的最小實作。
但真正的重點是 seam(測試邊界)的概念 —— 動筆前先寫下「這次要測哪些公開介面」,跟你確認過才准開始寫測試。skill 文件裡列了三種要避開的反模式:
- 跟實作細節綁死:mock 內部協作物件、測私有方法,或繞道去查資料庫而不是走介面 —— 特徵是重構沒改行為,測試卻壞了
- 套套邏輯:斷言用跟程式碼一樣的算法重算一次期望值,永遠不會跟程式碼吵架
- 橫向切測試:一次寫完所有測試,才一次寫完所有實作 —— 測的是「你想像中的行為」,不是「一步步驗證出來的行為」
code-review:雙軸,不合併
code-review 的設計哲學很清楚:Standards(是否符合本 repo 規範) 跟 Spec(是否做到規格要求) 是兩件完全獨立的事,一個 PR 可能規範全過但做錯方向,也可能完全照規格做但踩了團隊慣例。兩軸各自跑一個 sub-agent,不互相污染 context,最後並排列出結果,不合併成一個總評分。
Standards 軸除了讀 repo 自己的 CODING_STANDARDS.md,還內建了一份 Fowler code smell 基準清單(來自《Refactoring》第三章),即使 repo 什麼規範都沒寫也會拿這份當底線:Mysterious Name、Duplicated Code、Feature Envy、Data Clumps、Primitive Obsession、Repeated Switches、Shotgun Surgery、Divergent Change、Speculative Generality、Message Chains、Middle Man、Refused Bequest —— 每一項都是「這是什麼味道 → 怎麼改」的判斷式提示,不是死板規則(repo 自己的規範優先於這份基準)。
⚖️ 跟 obra/superpowers 怎麼分工
尊上的 blog 之前寫過 obra/superpowers(Anthropic 官方收編、121k stars),兩個庫容易搞混,但定位不一樣:
| 維度 | mattpocock/skills | obra/superpowers |
|---|---|---|
| 性質 | 個人 .claude 目錄開源,持續迭代中 | Anthropic 官方 marketplace 收編 plugin |
| 觸發方式 | 大多是 disable-model-invocation: true,靠使用者主動打 /to-spec、/tdd 等指令 | 被動觸發為主,Claude 自己判斷情境拉進來 |
| 核心關注 | 工程紀律鏈路:spec → 拆票 → TDD → review,偏「怎麼把一個大需求安全地做完」 | 涵蓋更廣:debugging、collaboration、meta(教 Claude 寫 skill)都有 |
| 安裝方式 | npx skills@latest add mattpocock/skills | /plugin install superpowers@claude-plugins-official |
to-spec/to-tickets/tdd/code-review 這條鏈路。兩者都是 Markdown skill,理論上可以同時裝,沒有 repo 層級的衝突。
🛠️ 怎麼裝、怎麼用
安裝一行:
npx skills@latest add mattpocock/skills裝完之後,skills/ 目錄下的 skill 就能用 /to-spec、/to-tickets、/tdd、/code-review、/implement 這些指令主動觸發(這幾個 skill 都標了 disable-model-invocation: true,代表不會被動自動觸發,要你自己打指令喊出來)。
實際工作流大致是這樣串起來:
/to-spec → 寫成結構化 spec(Problem/Solution/User Stories/...)
/to-tickets → 把 spec 拆成 vertical slice 票,每票宣告 blocked-by
/implement → 一張票一張票做,内部走 /tdd 紅綠循環
/code-review → 每個階段跑雙軸審查(Standards + Spec)to-tickets 特別強調一次只清一張票、做完清 context 再開下一張,理由是每張票被設計成「能塞進一個全新的 context window」—— 這跟一口氣丟一個大需求給 agent、然後看它邊做邊亂的做法是反著來的。
🕳️ 這套東西的局限
沒有現成的 issue tracker 整合就要手動搭。to-tickets 跟 code-review 都提到需要 docs/agents/issue-tracker.md 這份設定檔告訴 skill 你的票要發到哪裡(本地檔案還是 GitHub/Linear),沒設好的話系統會提示你先跑設定流程 —— 這代表這套東西假設你願意花時間做一次性配置,不是拿來就能用。
主動觸發意味著你要記得用。跟 Superpowers 的被動觸發比,disable-model-invocation: true 的設計代表 Claude 不會自己想到要用 /to-spec,忘記喊出來,這條紀律鏈就形同虛設。
vertical slice 的紀律需要人維持。skill 文件裡把「wide refactor」明確列成例外情況,代表作者自己也承認:不是所有工作都能乾淨切成垂直切片,遇到跨整個 codebase 的機械式改動,還是得靠人去判斷該走 expand-contract,而不是無腦硬套。
❓ 常見問題
Q1:166k stars 是真的還是灌水?
這個數字來自 gh repo view mattpocock/skills 直接查 GitHub API,是可重現、可驗證的公開數據。至於「750 萬次下載」這個說法完全查無來源 —— GitHub 沒有公開的下載量指標,npm 套件才有下載統計,而這個 repo 本身不是發布成 npm 套件的形式(是用 npx skills@latest add 這個社群工具拉取 skill 檔案,不是傳統 npm install 一個套件)。這個數字目前找不到任何一手來源可以佐證,本文不採用。
Q2:是不是要裝 5 個 skill 才算用完整?
不是。查證後的實際結構是「4 個常見失控問題,對應到 6 個核心 skill(加上 grill-with-docs、implement 兩個輔助 skill)」,repo 本身沒有「5 個 skill 一條龍」這種框架敘事。這篇文章特地按查到的真實結構寫,不是照搬「5 個 skill」的說法硬套。
Q3:跟 Anthropic 官方的 skill-creator 有關係嗎?
沒有直接關係。skill-creator 是 Anthropic 官方教你怎麼寫 skill 的 meta 工具;mattpocock/skills 是個人已經寫好、可以直接拿來用的一套 skill 內容。兩者可以一起用 —— 用 skill-creator 學怎麼寫,用 mattpocock/skills 當現成範本或直接安裝使用。
Q4:一定要是 TypeScript 專案才能用嗎?
不一定。這套 skill 談的是工程流程(spec、拆票、TDD、review),不綁定特定語言或框架,任何用 Claude Code / Codex 開發、且願意照這套紀律走的專案都能用。作者本身是 TypeScript 生態出身,但 skill 內容本身是語言無關的流程描述。
📚 延伸資源
- GitHub repo:mattpocock/skills — 直接看
skills/目錄下每份SKILL.md原始內容 - README:repo 首頁完整說明 4 個失敗模式與對應 skill 清單
- 安裝指令:
npx skills@latest add mattpocock/skills - Matt Pocock 的 newsletter:aihero.dev — 作者本人持續產出的 AI 工程內容
- 對照閱讀:Superpowers vs 手寫 skill,該選哪個? — 本站另一篇拆解 Anthropic 官方收編的 obra/superpowers
結論一句:這不是「5 個 skill 打天下」的神話,是一個人把自己每天在擋 AI agent 亂寫程式的 4 道關卡攤開來給你抄作業 —— 值得參考的是這套紀律的結構(先對齊、再拆小、測試先行、雙軸審查),不是數字本身。