mattpocock/skills 比較像一包給 coding agent 用的工作習慣，而不是一套龐大的開發方法論。它把常見的 agent 失誤拆成幾個小技能：先問清楚需求、用測試縮短回饋、診斷 bug、整理 issue、把對話交接給下一個 agent。對已經在用 Codex、Claude Code 或其他 coding agent 的人來說，這種小而可組合的設計，比再裝一個「全自動開發流程」更容易落地。
這個 repo 是什麼
mattpocock/skills 是 Matt Pocock 公開的一組 agent skills。README 的一句話很明確：這些是他每天用來做 real engineering 的 skills，不是 vibe coding。
它不是要把你的專案接管成某個固定流程，而是把一些容易重複出錯的環節做成可呼叫的技能。例如需求還不清楚時用 /grill-me 或 /grill-with-docs；要修難 bug 時用 /diagnose；要用紅綠重構節奏做功能或修 bug 時用 /tdd；想把一段討論變成 PRD 或 issue 時，才叫 /to-prd 或 /to-issues。
它解決的不是「寫更多程式」
這包 skills 最有意思的地方，是它不把 agent 當成只會多打字的工具。README 裡反覆提到幾種失敗模式：agent 沒聽懂你要什麼、回答太冗、產出的程式沒有回饋迴路、專案逐漸變成難改的泥球。
所以這組 skills 的重點其實是「讓 agent 在對的時間做對的事」。不是每個任務都要開 TDD，也不是每個想法都要寫 PRD。你可以把它想成一組工作台上的小工具：螺絲起子、水平尺、萬用表。東西不大，但拿對了會省很多時間。
先看這幾個 skills 就好
| skill | 適合什麼時候叫 | 它會改變什麼 |
|---|---|---|
/setup-matt-pocock-skills | 每個 repo 第一次使用前 | 建立 issue tracker、標籤、文件位置等共用設定 |
/grill-with-docs | 需求不清、術語混亂、要做設計決策 | 讓 agent 先問問題，並把語言與決策寫進文件 |
/diagnose | bug 很硬、效能退化、現象不穩定 | 逼 agent 走重現、縮小、假設、儀器化、修正、回歸測試 |
/tdd | 要做新功能或修 bug，且能寫測試 | 用紅綠重構降低「改完才發現壞掉」的機率 |
/zoom-out | agent 迷路、只盯著局部檔案看 | 把眼光拉回整體架構與上下文 |
/handoff | 長任務要換 session 或換 agent 接手 | 把上下文壓成可交接文件，少靠記憶硬撐 |
如果只是想試水溫，我會先裝 /setup-matt-pocock-skills、/grill-with-docs、/diagnose、/tdd、/handoff。這幾個覆蓋了多數 agent 開發裡最容易翻車的地方：對齊、除錯、回饋、交接。
安裝方式很短，但最好不要全裝全開
README 提供的 quickstart 是透過 skills.sh 安裝：
npx skills@latest add mattpocock/skills安裝時可以選要放到哪些 coding agent，也可以選要安裝哪些 skills。repo 特別提醒要選 /setup-matt-pocock-skills，因為它會先問 issue tracker、triage label、文件保存位置。這一步其實很重要：沒有 repo 級設定，後面的 /triage、/to-prd、/to-issues 很容易變成各說各話。
我不建議第一次就把所有 skill 都當快捷鍵亂叫。比較好的方式是按痛點裝：常常需求講不清楚，就先用 grilling 類；bug 常修歪，就先用 diagnose；長任務常斷線，就先用 handoff。
它和一般 prompt collection 差在哪
很多 prompt collection 像是「幫我寫一段更好的提示詞」。mattpocock/skills 更像是把一段工程流程包成技能。技能本身會要求 agent 做事前訪談、讀文件、更新 issue、建立 PRD、跑測試或交接上下文。它不是只改一句 prompt，而是改 agent 的工作姿勢。
這也是它適合工程專案的原因。工程工作不是只有產生程式碼，還包含界定問題、命名語言、保留決策、設計回饋迴路、控制變更範圍。這些地方如果全靠 agent 自覺，結果通常很飄；做成 skill 之後，至少每次可以把流程拉回來。
使用前先知道的幾件事
- 它不是只給 Claude Code。README 明確提到 Claude Code、Codex 與其他 coding agents；實際能不能順手，取決於你的 agent 是否支援這種 skill 目錄與觸發方式。
- 它會要求你建立 repo 文件與工作規則。這是優點，也是門檻。沒有文件習慣的人，第一次會覺得有點囉嗦。
- 它比較適合真正在維護的專案。只是一次性小腳本，可能不需要完整 triage、PRD、ADR 流程。
- skills 不是魔法。它們能降低 agent 亂跑的機率，但還是要有測試、版本控制、review 和人的判斷。
適合誰先試
如果你已經在用 coding agent 寫比較大的專案，而且開始遇到「它做很快，但方向常常歪掉」的問題，這包 skills 很值得試。特別是多人或多 agent 協作、長任務、常需要把討論變成 issue 的專案，它會比單純加長 system prompt 更有用。
如果你只是想讓 agent 幫你改一個 CSS、寫一個小函式，那先不用急著全套導入。挑一兩個最常用的技能就好。小工具的價值，是需要時拿起來，不是把工作台塞滿。