兩種呼叫方式
User-invoked 只在你主動輸入時執行，負責編排流程；Model-invoked 可由你呼叫，也可能由 agent 在適合時自動套用。
Matt Pocock Skills
使用教學
這不是一條會接管專案的自動化框架，而是一組可組合的小型 agent skills。這份網頁把安裝、主流程、Vibe Coding 使用方式與 repository 中的全部 41 個技能整理成可搜尋的參考手冊。
01 · Mental Model
先理解這套系統
技能的價值不在「把所有 skill 都跑一遍」，而在於針對目前風險選擇最小、最合適的流程。
一次設定
每個 repository 先跑一次 /setup-matt-pocock-skills，讓 tickets、labels、CONTEXT.md 與 ADR 有固定位置。
規劃與實作分流
grill → spec → tickets 適合保留同一完整 context；每張 ticket 的 /implement 則使用新的 context。
審查範圍要正確
code-review 看固定起點後的 diff；improve-codebase-architecture 才是全 codebase 的架構普查。
最重要的界線：需求未清楚時，不要急著寫 spec；架構候選尚未選定時，也不要直接要求
codebase-design「整理整個專案」。02 · Setup
安裝與初始化
Claude Code plugin 與 skills.sh 是兩種不同哲學：前者由作者維護並更新，後者會把可編輯檔案複製到你的專案。不要同時安裝兩份。
Claude Code
安裝官方 Marketplace plugin：
claude plugins install mattpocock-skills也可在 session 中執行：
/plugin install mattpocock-skillsCodex 與其他 agents
把可編輯 skills 加入專案：
npx skills@latest add mattpocock/skills日後手動更新：
npx skills update每個 repository 再執行一次
/setup-matt-pocock-skills它會詢問 issue tracker、triage labels 與文件位置。個人 Vibe Coding 專案可選 local Markdown tickets；需要 Gitea 時，依 setup 提供的自訂 tracker 選項記錄操作方式。
03 · Core Flow
核心新功能流程
箭頭不是自動連鎖。每個 user-invoked skill 都要由你依序啟動。
/grill-with-docs→
/to-spec→
/to-tickets→
/implement
domain-modeling讓 problem domain 的名詞一致。
codebase-design在 spec 前釐清 module、interface 與 seam。
tddimplement 時以 red–green–refactor 完成一條行為。
code-reviewimplement 收尾時審查本張 ticket 的 diff。
規劃 Context
grill-with-docs → to-spec → to-tickets 儘量在同一個完整 context 中完成，避免重要決策在壓縮或轉述時遺失。
執行 Context
每張 ticket 開新的 context，只帶 ticket、spec 與必要文件。這能限制 scope drift，也讓 review fixed point 更清楚。
Ticket 形狀
採用可獨立 demo 的 vertical slice，不要切成「先 models、再 repositories、再 UI、最後 tests」的水平層。
04 · Router
我現在該用哪個 Skill？
先從「目前的不確定性在哪裡」判斷，而不是從你想做的程式檔案種類判斷。
小而明確的修改/implement需求已清楚，直接在一個 ticket 範圍內實作、驗證、review。
一般新功能/grill-with-docs → /to-spec → /to-tickets → /implement先對齊需求，再規格化與切成可驗證的小片。
困難或偶發 BUG/diagnosing-bugs先建立可穩定失敗的 feedback loop，再找根因。
需要先看 UI／操作感/prototype做可丟棄變體，保留結論，不保留 prototype code。
需要官方技術事實/research用第一方來源研究，將結論留下。
整體架構是否健康/improve-codebase-architecture掃描 codebase hot spots，而不是只看本次 diff。
已選定一個架構問題/codebase-design設計 module、interface 與 seam，再進入 spec。
外部 issue 尚未整理/triage驗證回報、補資訊並決定交給 agent 或人類。
大型工作看不清完整路徑/wayfinder先解決決策依賴，等道路清楚後再寫 spec。
Git merge／rebase 衝突/resolving-merge-conflicts依雙方意圖逐 hunk 解決並完成操作。
05 · Your Current Project
BirdGamePrototype 的建議用法
你目前已有可執行原型，主要在修改 UI 與 BUG。這個階段不需要每次都跑完整 planning pipeline，但要保留清楚的 ticket 範圍與 Git fixed point。
日常 UI／BUG 修正
Step 1
一張明確 Ticket
寫清楚可觀察問題、預期行為、驗收方式與不在範圍內的項目。
→
Step 2
/implement
讓 agent 實作、執行既有 feedback loops，並在既定 seam 上補 regression test。
→
Step 3
Review 與 Commit
implement 本身應在收尾時呼叫 code-review。確認 findings 已處理，再建立可回復 checkpoint。
一個里程碑完成後
/code-review <fixed point>→
/improve-codebase-architecture→
選一個 Strong 候選→
/codebase-design
不要要求「全部修乾淨」。先選一個近期反覆修改、確實造成 BUG 或 AI 導航困難的 Strong 候選，再把它當成獨立工作走
to-spec → to-tickets → implement。06 · Deep Modules
Codebase Design 放在哪裡？
它是一套精確語言，不是全專案掃描程序。當你已經知道「哪個區域有問題」，但還不能說清楚誰應承擔複雜度時使用。
- Module
- 對外承擔明確責任、隱藏內部實作的一組程式結構，不等於單一檔案或 class。
- Interface
- caller 必須知道的全部事實：簽名、前置條件、錯誤模式、順序、效能與副作用。
- Depth
- 以小 interface 隱藏大量行為。深度是 interface 的性質，不取決於內部是否拆成很多小零件。
- Seam
- 不修改該處程式碼就能改變行為的位置，也是正式 caller 與測試應共同跨越的地方。
- Adapter
- seam 某一側的具體實作。只有一個 adapter 時，這個 seam 多半仍是假設。
- Locality
- 同一概念的知識應集中在少數位置，避免每次修改都散落到許多 caller。
Deletion Test
想像刪除某個 module。若複雜度跟著消失，它可能只是 pass-through；若複雜度重新散落到 N 個 callers，它正在賺取存在價值。
一個 Adapter 是假設
不要只因「未來可能支援第二種系統」就切 seam。等第二個真實 adapter 出現，再從具體差異提取 interface。
07 · Complete Catalog
全部 41 個技能索引
預設展開 22 個穩定技能。可依名稱、用途、狀態或呼叫方式搜尋與篩選。
Engineering｜工程日常軟體工程的核心技能。 17 個
專案初始化
/setup-matt-pocock-skills
穩定
需主動呼叫
每個 repository 執行一次，設定 issue tracker、triage labels 與文件位置。
使用判斷與來源
- 適合
- 剛把這套 skills 加入新專案，尚未決定 tickets 與 CONTEXT.md／ADR 的存放方式。
- 避免
- 已完成設定且專案規則沒有改變時，不必重複執行。
流程路由
/ask-matt
穩定
需主動呼叫
根據你現在的狀態，推薦應使用的 skill 或完整流程。
使用判斷與來源
- 適合
- 你知道要做什麼，但不確定該走 implement、diagnosing-bugs、wayfinder 或其他流程。
- 避免
- 已經明確知道下一個 skill 時。
需求對齊
/grill-with-docs
穩定
需主動呼叫
逐題釐清需求，同步磨利專案名詞並更新 CONTEXT.md 與 ADR。
外部回報整理
/triage
穩定
需主動呼叫
把外部 issue／PR 由原始回報整理為可由 agent 或人類處理的狀態。
使用判斷與來源
- 適合
- 玩家、客戶或外部貢獻者提出尚未驗證、資訊不完整的回報。
- 避免
- to-tickets 已產生的 agent-ready ticket，不需要再次 triage。
架構普查
/improve-codebase-architecture
穩定
需主動呼叫
掃描整個 codebase 的架構摩擦與 deepening opportunities，產生視覺化 HTML 報告。
使用判斷與來源
- 適合
- 里程碑完成、同一區域反覆出 BUG、修改一個行為需要碰很多檔案，或 AI 經常改錯位置。
- 避免
- 只想檢查單一 ticket 的 diff；那是 code-review 的工作。
規格化
/to-spec
穩定
需主動呼叫
把目前已談清楚的對話整理成規格；本身不重新訪談。
工作切片
/to-tickets
穩定
需主動呼叫
把 spec 切成可獨立驗證的 tracer-bullet vertical slices，並標示 blockers。
使用判斷與來源
- 適合
- 工作超過一個 agent session，或需要明確追蹤多個交付切片。
- 避免
- 不要按 model／repository／UI／tests 技術分層切票。
執行
/implement
穩定
需主動呼叫
依 spec 或 ticket 實作，在既定 seam 上使用 TDD，完成檢查、code review 與 commit。
大型探索
/wayfinder
穩定
需主動呼叫
把超大型未知工作整理成 decision tickets，逐步找出通往目標的路。
快速試驗
/prototype
穩定
模型可自動使用
建立可丟棄的 terminal prototype 或多個明顯不同的 UI 變體，回答一個設計問題。
根因除錯
/diagnosing-bugs
穩定
模型可自動使用
使用 reproduce → minimise → hypothesise → instrument → fix → regression-test 的診斷循環。
技術研究
/research
穩定
模型可自動使用
依高可信第一方來源研究問題，將有引用的結論保存為 Markdown。
測試驅動
/tdd
穩定
模型可自動使用
以 red–green–refactor 迴圈，一次完成一條可驗證的 vertical slice。
使用判斷與來源
- 適合
- 新增行為、修 regression，且已有適合的 test seam。
- 避免
- 若只能測 private details，先檢查 seam 或 module 設計。
領域語言
/domain-modeling
穩定
模型可自動使用
建立並磨利 problem domain 的共同詞彙，透過情境壓力測試後更新 CONTEXT.md 與 ADR。
使用判斷與來源
- 適合
- 同一概念有多種叫法、名詞語意含糊，或業務規則難以簡潔表達。
- 避免
- 不要用它處理 module/interface 的程式結構問題；那是 codebase-design。
模組設計
/codebase-design
穩定
模型可自動使用
深模組設計的共同語言：module、interface、depth、seam、adapter、leverage、locality。
使用判斷與來源
- 適合
- 已選定某個架構候選，要縮小 interface、集中行為、決定 seam 或改善 test surface。
- 避免
- 它不是全 codebase 掃描器，也不是完整重構程序。
差異審查
/code-review
穩定
模型可自動使用
從固定起點到 HEAD 檢查 diff，分開進行 Standards 與 Spec 兩條審查軸。
Git 衝突處理
/resolving-merge-conflicts
穩定
模型可自動使用
依雙方原始意圖逐個 conflict hunk 解決 merge／rebase 衝突，並完成正在進行的操作。
Productivity｜生產力跨專案的一般訪談、交接、教學與 skill 編寫工具。 5 個
一般訪談
/grill-me
穩定
需主動呼叫
對非程式計畫或沒有 codebase 的題目進行逐題深度訪談。
使用判斷與來源
- 適合
- 要釐清計畫、設計或決策，但不需要更新 repo 文件。
- 避免
- 有 codebase 且希望同步 CONTEXT.md／ADR 時，改用 grill-with-docs。
跨 Session 交接
/handoff
穩定
需主動呼叫
把目前 conversation 壓縮成可由另一個 agent 或新 session 接手的文件。
長期教學
/teach
穩定
需主動呼叫
以目前目錄作為有狀態的教學 workspace，跨多個 session 教授技能或概念。
Skill 作者指南
/writing-great-skills
穩定
需主動呼叫
編寫與修改 agent skills 的設計參考，提升觸發、邊界與行為的可預測性。
訪談底層
/grilling
穩定
模型可自動使用
grill-me 與 grill-with-docs 底層共用的逐題訪談紀律。
In Progress｜實驗中尚未穩定，可能發生破壞性變更或被放棄；不建議用於關鍵正式流程。 9 個
實驗訪談
/batch-grill-me
實驗中
需主動呼叫
改為按輪次詢問目前所有無 blocker 的決策，而非一次只問一題。
實驗交接
/claude-handoff
實驗中
需主動呼叫
透過 claude --bg 將當前工作交給新的背景 Claude agent。
工作流設計
/loop-me
實驗中
需主動呼叫
跨多個 session 訪談，將循環式工作塑造成可實作的 workflow spec。
TS 模組約束
/setup-ts-deep-modules
實驗中
需主動呼叫
把 dependency-cruiser 接入 TypeScript repo，強制 package 只能透過 entry points 使用。
非同步問卷
/to-questionnaire
實驗中
需主動呼叫
把自己無法完整回答的決策轉成供他人非同步填寫或會議使用的問卷。
人工流程工具
/wizard
實驗中
需主動呼叫
為人工程序生成互動式 Bash wizard，可開網址、收集值並寫入設定。
實驗寫作
writing-beats
實驗中
未分類／特定用途
把文章視為一連串敘事 beats，以選路方式逐段推進。
實驗寫作
writing-fragments
實驗中
未分類／特定用途
透過訪談收集異質寫作碎片，累積為未來文章的原始材料。
實驗寫作
writing-shape
實驗中
未分類／特定用途
將 Markdown 原始材料逐段塑造成文章，逐一辯論段落形式與位置。
Deprecated｜已淘汰作者已不再使用；保留只為歷史參考。 4 個
已淘汰
design-an-interface
已淘汰
未分類／特定用途
舊版：用平行子代理產生多種 module interface 設計。現可用 codebase-design 的 Design It Twice 思路取代。
已淘汰
qa
已淘汰
未分類／特定用途
舊版：互動式 QA，將使用者回報寫成 GitHub issues。現改用 triage／diagnosing-bugs。
已淘汰
request-refactor-plan
已淘汰
未分類／特定用途
舊版：訪談後建立細粒度 refactor plan。現改用 architecture survey → design → spec → tickets。
已淘汰
ubiquitous-language
已淘汰
未分類／特定用途
舊版：從對話擷取 DDD glossary。現改用 domain-modeling／grill-with-docs。
Misc｜低頻工具作者保留但很少使用，也不在主要 plugin 中推廣。 4 個
安全護欄
git-guardrails-claude-code
低頻工具
未分類／特定用途
為 Claude Code 設定 hooks，在執行前阻擋 push、reset --hard、clean 等危險 Git 指令。
特定遷移
migrate-to-shoehorn
低頻工具
未分類／特定用途
把 TypeScript 測試中的 as assertions 遷移至 @total-typescript/shoehorn。
課程腳手架
scaffold-exercises
低頻工具
未分類／特定用途
建立 sections、problems、solutions 與 explainers 的教學練習目錄。
提交前檢查
setup-pre-commit
低頻工具
未分類／特定用途
設定 Husky、lint-staged、Prettier、typecheck 與 tests 的 pre-commit pipeline。
Personal｜作者個人直接綁定作者個人偏好或本機環境，必須先修改才能移植。 2 個
個人流程
edit-article
作者個人
未分類／特定用途
作者個人的文章重整與逐節編輯流程，包含其特定段落長度偏好。
個人流程
obsidian-vault
作者個人
未分類／特定用途
作者個人 Obsidian vault 的搜尋、建立與 wikilink／index 管理規則，含其本機路徑。
沒有符合目前條件的技能。請清除搜尋字或篩選條件。
08 · Copy & Use
可直接複製的指令模板
模板的目的不是把所有決策交給 agent，而是明確限制此次 skill 的工作邊界。
一般新功能
/grill-with-docs
我要新增【功能名稱】。
目前可觀察到的行為：【現況】
希望使用者能做到：【目標】
已知限制：【限制】
請釐清需求、domain 名詞、錯誤狀態、
測試方式與 out of scope。不要開始實作。困難 BUG
/diagnosing-bugs
問題：【現象】
重現步驟：【步驟】
預期：【預期結果】
實際：【實際結果】
已嘗試：【曾做過的修正】
在建立可穩定失敗的 feedback loop 前，
不要修改正式程式。架構健康檢查
/improve-codebase-architecture
這是一個已有可執行原型的專案。
優先檢查近期 hot spots、UI／遊戲狀態耦合、
行為是否散落、shallow modules、test seams，
以及 AI 是否需要跳轉太多檔案。
遵守 YAGNI，不要全面重寫，也不要直接改程式。選定候選後設計
/codebase-design
針對架構報告中的【候選名稱】進行設計。
1. 說明現有 module 與 interface
2. 執行 deletion test
3. 找出 deepening opportunity
4. 提出至少兩種設計
5. 比較 depth、locality、testability
6. 不建立只有一個 adapter 的假設性 seam
7. 此階段不要修改程式碼單一 Ticket 實作
/implement
實作【ticket 路徑或 issue 編號】。
只處理這張 ticket，不提前完成後續 tickets。
使用既定 testing seam，完成測試、typecheck、
code review 與 commit。手動重跑 Code Review
/code-review <fixed-point>
請分開呈現：
1. Standards findings
2. Spec findings
只審查 fixed point 到 HEAD 的變更，
不要把既有全專案問題混成本次 regression。09 · Failure Modes
常見錯誤用法
需求還沒談清楚，就直接執行 /to-spec
to-spec 只會整理目前已有的討論，不會補做完整訪談。應先使用 grill-with-docs。
把 tickets 切成技術層
「建立 models → repositories → UI → tests」會讓前幾張票無法獨立驗證。改切成可 demo 的端到端使用者行為。
同一個 context 連續實作全部 tickets
長 context 會讓臨時假設與 scope 汙染後續工作。每張 ticket 使用 fresh context，規格與 ticket 才是 durable memory。
把 code-review 當成全專案架構掃描
code-review 檢查 fixed point 後的 diff；全專案 hot spots 應交給 improve-codebase-architecture。
看到架構報告就要求全部重構
只挑一個有真實修改頻率與痛點的 Strong 候選。Speculative 候選先忽略，尤其不要為假想未來建立 seam。
把 prototype code 留進 production
prototype 的產物是設計答案。保留結論與被否決方向，丟棄為快速學習而刻意省略保障的程式碼。
把 to-tickets 產生的票再送去 triage
這些 tickets 已經是 agent-ready。Triage 只處理外部、尚未驗證與整理的 incoming requests。
10 · Sources
資料來源與版本說明
內容依官方 GitHub repository 的 README、skills 目錄與 engineering docs 整理；中文的「適合／避免」包含依 skill 定位做出的實務解讀。
主要來源
統計基準
- Engineering：17
- Productivity：5
- In Progress：9
- Deprecated：4
- Misc：4
- Personal：2
總計 41；其中穩定核心 22。