前言
最近在研究 mattpocock/skills。這個 repository 收集了 Matt Pocock 日常使用的 Agent Skills，希望讓 Claude Code、Codex 等 AI coding agent 依照較穩定的工程節奏工作，而不是每次都靠臨時 prompt 指揮。
這篇文章本身也實際用了專案中的 research skill：主流程繼續整理網站內容，同時讓背景 agent 閱讀專案第一手資料，再把查證結果存成附來源的 Markdown。這種「把可重複的工作方式寫成 skill」正是整個專案的核心。
mattpocock/skills 是什麼？
它不是新的 AI 模型、coding agent 或自動開發平台，而是一組以 SKILL.md 寫成的工程工作流程。相容的 agent 讀取 skill 後，會在適合的任務中遵循裡面的步驟、限制與完成條件。
例如：
grill-with-docs要求先透過訪談釐清需求，並更新 domain model 與 ADR。diagnosing-bugs要求先建立能穩定重現問題的 feedback loop，再提出假設。tdd定義測試應放在哪些 seam，以及紅燈、綠燈的實作節奏。code-review依 repository 標準與原始規格兩個方向檢查變更。handoff將接近 context 上限的對話整理成文件，交給新 session 繼續。
這些 skill 不負責提供更強的模型能力，而是嘗試讓 agent 在不同 session 中重複使用相同的工程紀律。官方 README 將設計方向定位為小型、可修改與可組合，而不是由單一 methodology 接管所有開發決策。
專案實際包含哪些內容
查核版本共有 41 份 SKILL.md，但不是每一份都會正式發佈。Repository 依用途分為：
engineering/：17 個日常工程 skill。productivity/：5 個日常生產力 skill。misc/、personal/：少用或只適合作者個人環境的內容。in-progress/：尚未完成的草稿。deprecated/：已退役的 skill。
目前 Claude Code plugin 只列出 engineering 與 productivity 的 22 個 promoted skills，不會把草稿、個人與 deprecated 內容一起安裝。Repository 的 bucket 規則 與 plugin manifest 都有記錄這項限制。
從想法到交付的主要流程
ask-matt 是整套 skills 的路由器。它整理的主要 idea-to-ship 流程大致如下：
- 使用
grill-with-docs釐清需求、詞彙與重要決策。 - 無法只靠討論決定的狀態、邏輯或 UI，可先做 throwaway
prototype。 - 多 session 工作使用
to-spec將對話轉成規格。 to-tickets再把規格拆成有 blocking edges 的垂直切片。- 每張 ticket 開新的 context，交給
implement執行。 implement使用tdd建立 feedback loop，完成後呼叫code-review再 commit。
小型工作不需要為了遵守流程而硬做 spec 和 tickets，可以在同一個 session 直接進入 implement。如果是大型 greenfield 專案，連要做哪些決定都還不清楚，則先使用 wayfinder 把未知項目整理成共享的 decision map，等路徑清楚後再回到 spec 與 tickets。ask-matt 的完整流程 可查看不同入口的分流方式。
常見情境與對應 skill
| 情境 | 建議 skill | 主要產出 |
|---|---|---|
| 想法還很模糊 | grill-with-docs |
釐清的需求、domain model、ADR |
| 需要查文件或原始碼 | research |
附第一手來源的研究筆記 |
| 問題很難重現 | diagnosing-bugs |
最小重現、假設、修正與 regression test |
| 要把討論變成可執行工作 | to-spec、to-tickets |
規格、垂直切片與依賴關係 |
| 要開始實作 | implement、tdd |
通過驗證的程式碼與測試 |
| 要檢查 branch 或 PR | code-review |
Standards 與 Spec 兩軸 review |
| 工作超過單一 context | handoff |
可供新 session 接手的 Markdown |
| 專案太大、路徑仍不清楚 | wayfinder |
逐步消除未知的決策地圖 |
這張表是入口，不代表每次都要把全部 skill 跑一遍。真正重要的是依工作的規模與不確定性選擇最短、仍有足夠 feedback 的流程。
User-invoked 與 model-invoked 的差別
專案沒有把所有 skill 都交給 agent 自動啟動，而是分成兩類：
User-invoked
只有使用者明確輸入 skill 名稱時才能執行，通常負責 orchestrate 一整段工作，例如 grill-with-docs、to-spec、implement 和 wayfinder。
Model-invoked
使用者可以直接呼叫，agent 也能在任務符合 description 時自行選用，例如 research、tdd、domain-modeling 和 code-review。
Claude Code 使用 disable-model-invocation 控制；Codex 則在各 skill 的 agents/openai.yaml 設定是否允許 implicit invocation。User-invoked skill 可以組合 model-invoked skill，但不應在未經使用者操作時啟動另一段 user-invoked flow。官方 invocation 規則 有完整定義。
因此，安裝 skills 不代表 agent 會自動接管所有工作；但 model-invoked skills 確實可能依目前任務被自動加入流程。
Codex 與其他 Agent 的安裝方式
通用安裝指令是：
npx skills@latest add mattpocock/skills
安裝時可選擇需要的 skills 和目標 agent。官方建議包含 setup-matt-pocock-skills，並在每個 repository 第一次使用前執行 setup，設定 issue tracker、triage labels 與 domain docs 位置。Quickstart 有完整步驟。
Claude Code 另提供原生 plugin：
/plugin marketplace add mattpocock/skills
/plugin install mattpocock-skills@mattpocock
兩種安裝方式的取捨不同：skills CLI 會複製可修改的檔案，適合自行調整和固定版本；Claude plugin 則是 read-only、跟隨上游更新的 bundle。
目前沒有原生 Codex plugin，但不是 Codex 不能使用。官方 ADR 說明，Codex plugin manifest 只能指定單一 skill 路徑，無法精確選出分散在兩個 bucket 的 promoted set，因此暫時仍以 skills CLI 作為 Codex 安裝管道。Plugin ADR 記錄了這項決策。
Setup 會對 Repository 做什麼
setup-matt-pocock-skills 不是只讀檢查，也不是固定輸出的安裝 script。它會先探索現有 repository，向使用者確認後再修改：
- 既有
CLAUDE.md或AGENTS.md中的## Agent skills區塊。 docs/agents/issue-tracker.md。docs/agents/domain.md。- 有使用 triage 時的
docs/agents/triage-labels.md。
若 CLAUDE.md 和 AGENTS.md 都不存在，skill 必須先詢問要建立哪一個，不能自行決定。這些設定會告訴後續 skills 應把 issue 寫到 GitHub、GitLab 或 .scratch/，以及 CONTEXT.md 和 ADR 應放在哪裡。setup skill 原始內容 可查看實際寫入規則。
後續 workflows 也可能修改原始碼、測試、規格、tickets、domain 文件和 issue tracker；implement 甚至明確要求完成 review 後 commit。它不是一套只提供建議、不碰 repository 的 prompts。
導入前要注意的安全問題
Agent Skill 本質上是會改變 agent 行為的第三方指令，審查方式應接近 shell script、CI workflow 或 automation：
- 確認 skill 被允許使用哪些工具與外部服務。
- 檢查是否會寫入 repository、建立 issue、commit 或發送訊息。
- 使用可修改 copy 時，記錄自己與上游版本的差異。
- 使用自動更新 plugin 時，注意新版本可能改變工作流程。
- 團隊若已有 ticket、ADR、review 與 release 規範，應先調整 skill，避免兩套規則互相衝突。
正式導入時，建議固定 release 或 commit、review 更新 diff，並從權限較低的小型 repository 開始測試。模型是否會照規則執行，仍取決於 context、宿主工具與當下 repository 狀態，不能把自然語言 instruction 當成強制安全邊界。
它能解決什麼，不能解決什麼
這套 skills 最有價值的地方，是把容易被忽略的工程活動變成 agent 可反覆使用的流程：先對齊需求、建立共同語言、縮短 feedback loop、控制 context，再透過測試與 review 收尾。
不過它無法保證：
- Agent 一定正確理解產品需求。
- 寫出的測試真的有價值，而不是只驗證實作細節。
- 每個 repository 都適合完整 idea-to-ship 流程。
- 不同 agent 對同一份自然語言 skill 會有完全一致的行為。
- 安裝全部 skills 就能省略人的決策、review 與驗收。
README 強調保持可組合與使用者控制，但完整工作流本身仍有不少階段。我的看法是，應該先挑一兩個明確痛點導入，例如難以釐清需求就用 grilling、常常修錯 bug 就用 diagnosing、缺乏交接就用 handoff，再觀察是否真的改善成果。
專案成熟度與我的看法
截至 2026 年 7 月 21 日，GitHub 顯示 repository 約有 313 個 commits、4 個 releases，最新公開 release 是 v1.1.0。查核的 main 已繼續開發下一版：Claude plugin manifest 標示 1.2.0，但 package.json 和最新 release 仍是 1.1.0。這表示直接跟隨 main、使用 released plugin 或複製特定 commit，取得的內容可能不同。Releases、plugin manifest 與 package.json 可交叉確認。
專案採 MIT License，可以修改與商業使用，但需要保留授權聲明。
相較於只收集零散 prompts，這個 repository 已具備清楚的分類、invocation 規則、setup、Changelog、docs 與 release 流程，工程化程度相當高。它最適合希望保留開發控制權，又想讓 AI coding 工作方式更可重複的使用者；如果期待安裝後讓 agent 全自動接管產品開發，方向就完全相反了。