上一篇講了 mattpocock/skills 是什麼、為什麼這樣設計。這篇是實作：怎麼裝、/setup-matt-pocock-skills 到底在你的 repo 裡寫了哪些檔案、以及一條從「我想加個功能」到「commit 之前先被審一輪」的完整流程。
文中的設定檔內容是我自己這個部落格 repo 跑完 setup 之後的真實產出，不是示意。
前置需求
| 項目 | 說明 |
|---|---|
| Claude Code | plugin 路線需要；其他 agent 走 skills.sh 路線 |
| 一個 git repo | setup 會讀 git remote 判斷你的 issue tracker |
gh CLI |
如果 issue tracker 選 GitHub（多數情況），且要先 gh auth login |
步驟一：安裝
封面是示意圖，上面那行
npm install -g @mattpocock/skills不是真的安裝方式（沒有這個套件）。實際的兩條路線以下面為準。
兩條路線，只能選一條。README 明講了：兩種都裝的話每個 skill 會出現兩次。
路線 A：Claude Code plugin（訂閱）
1 | claude plugins install mattpocock-skills |
或在 session 裡：
1 | /plugin install mattpocock-skills |
它已經在 Claude Code 的官方 marketplace（claude-plugins-official）裡，所以不需要先 add 任何 marketplace，更新也會自動來。
路線 B：skills.sh（分叉）
1 | npx skills@latest add mattpocock/skills |
這條路適用於 Codex 和其他支援 Agent Skills 標準的 agent，也適用於「我就是想改成自己的版本」的人。它會把 skill 當成一般檔案寫進你的 repo，你擁有它們、可以隨便改，什麼都不會在背後自動變動。想跟上游就手動 npx skills update。
這條路線有個容易漏掉的地方：安裝程式會讓你勾選要裝哪些 skill，README 特別用粗體提醒——一定要把
setup-matt-pocock-skills勾進去，不然下一步就沒東西可跑。
確認你到底裝了什麼
這步值得做，因為很容易在不同機器上裝成不同版本。Claude Code 的安裝狀態記在：
1 | cat ~/.claude/plugins/installed_plugins.json |
我自己就踩到了：Windows 那台是走官方 marketplace 裝的 mattpocock-skills@claude-plugins-official，Mac 這台卻是更早以前手動 marketplace add 這個 repo 之後裝的 mattpocock-skills@mattpocock，版本停在 1.2.0，而上游當時已經是 1.2.3。兩台的 skill 內容其實不一樣。
1 | "mattpocock-skills@mattpocock": [ |
另外注意 scope 這欄：project 表示只在那個目錄底下生效，user 才是全域。裝完發現某個專案叫不出 skill，先看這裡。
步驟二：/setup-matt-pocock-skills
每個 repo 跑一次，在使用其他 engineering skill 之前。
1 | /setup-matt-pocock-skills |
它不是一支腳本，是一段引導流程：先探索你的 repo（讀 git remote、看有沒有 CLAUDE.md / AGENTS.md / CONTEXT.md / docs/adr/、判斷是不是 monorepo），把發現講給你聽，然後問你三個問題——而且每個問題都會先給推薦答案，你點頭就好。
它問的三件事
A. Issue tracker 在哪？ 它會先看 git remote：指向 GitHub 就推薦 GitHub，指向 GitLab 就推薦 GitLab。選項有 GitHub（用 gh CLI）、GitLab（用 glab）、Local markdown（寫在 .scratch/<feature>/ 底下，適合單人專案或沒有 remote 的 repo）、以及 Other（Jira、Linear 之類，你用一段話描述工作流，它照抄記下來）。
B. Triage 標籤用哪一組？ 只有在你也裝了 triage skill 時才會問。預設是五個角色標籤：needs-triage、needs-info、ready-for-agent、ready-for-human、wontfix。除非你的 tracker 已經有自己的命名（例如用 bug:triage 代表 needs-triage），否則直接用預設。
C. 領域文件怎麼擺？ 預設 single-context：根目錄一份 CONTEXT.md 加 docs/adr/。只有在偵測到 monorepo 訊號（pnpm-workspace.yaml、package.json 的 workspaces、有自己 src/ 的 packages/*）時，才會問你要不要改成 multi-context。
它寫出來的東西
回答完會先給你看草稿，確認後才寫。以我這個部落格為例，產出是三個地方：
1. CLAUDE.md 裡多一個 ## Agent skills 區塊（如果 CLAUDE.md 不存在但 AGENTS.md 存在，它會改 AGENTS.md；兩個都沒有才問你要建哪一個——它不會自己決定，也絕不會在已有 CLAUDE.md 時另外生一個 AGENTS.md）：
1 | ## Agent skills |
2. docs/agents/issue-tracker.md——把「操作 issue」翻譯成具體指令的對照表。這份檔案的密度比我預期高，摘幾條：
1 | - **Create an issue**: `gh issue create --title "..." --body "..."` |
裡面還有兩段值得注意的設計：
- 「PRs as a request surface」旗標，預設關閉。 意思是「要不要把外部 PR 也當成待分類的需求丟進 triage 佇列」。setup 時它刻意不問你，直接寫
no，想要的人自己去檔案裡改成yes——這是很好的預設值選擇：不要為了一個九成的人不需要的選項多問一題。 - GitHub 的 issue 和 PR 共用同一個編號空間，所以檔案裡直接寫明
#42可能是任一種，要先試gh pr view 42再退回gh issue view 42。這種細節就是「有人真的踩過」的痕跡。
3. docs/agents/domain.md——告訴 agent 探索程式碼前該先讀哪些文件。最關鍵的是這條規則：
If any of these files don’t exist, proceed silently. Don’t flag their absence; don’t suggest creating them upfront.
檔案不存在就安靜跳過，不要提醒、也不要建議你先建。文件是在 /domain-modeling 真的解決了某個術語或決策時才順手長出來的，不是一開始要求你填的表格。這個設計避免了大部分「文件框架」最後變成一堆空殼的下場。
步驟三：一條完整的流程
裝好、設定完，實際怎麼用？這是 engineering skill 串起來的主線：
flowchart TB U["我想做某個功能"] --> G["/grill-with-docs
被拷問到每個分支都有答案"] G --> S["/to-spec
把對話變成 spec 發到 issue tracker"] S --> T["/to-tickets
拆成一顆顆 tracer bullet，標好誰擋誰"] T --> I["/implement
照 ticket 施工"] I --> D["/tdd
在講好的接縫上紅燈到綠燈"] D --> R["/code-review
Standards 與 Spec 兩條軸線並行審"] R --> C["commit"] R -.->|審出設計問題| G
各步驟在做什麼：
/grill-with-docs——動手之前的拷問。它是 /grill-me 的加強版：同一場拷問，但過程中順手建立專案的共用語言，把 CONTEXT.md 和 ADR 就地更新。這是整條流程裡最該養成習慣的一步。
/to-spec——把當前這場對話變成一份 spec 發布到 issue tracker。它刻意不做訪談，只負責整理你們已經談過的東西——因為訪談是拷問 skill 的工作，職責分得很乾淨。
/to-tickets——把 spec 拆成一組 tracer bullet 式的 ticket，每一顆都聲明自己被誰擋住。如果 tracker 支援原生的相依關係就用原生的（GitHub 有 issue dependencies），不支援就退化成 ticket body 頂端的 Blocked by: #n 那一行。
/implement——照 spec 或 ticket 施工，在事先講好的接縫上驅動 /tdd，並且在 commit 之前先跑 /code-review 收尾。
/code-review——沿兩條軸線審查從某個定點（commit、branch、tag 或 merge-base）以來的 diff：Standards（有沒有遵守這個 repo 的規範 + Fowler 的 code smell 基線）和 Spec（有沒有忠實實作原始需求）。兩條軸線跑在各自獨立的 sub-agent 裡，避免互相汙染 context，最後才彙整成一份並排的報告。
不是每次都要走完整條。改一行 typo 不需要 spec，但「動手前先被拷問一輪」幾乎永遠划算。
步驟四：卡住的時候用哪一個
25 個 skill 記不住是正常的。與其背清單，不如照「我現在的處境」查：
| 我的處境 | 用這個 |
|---|---|
| 完全不知道該用哪個 | /ask-matt（它就是個路由器） |
| 要改東西，但自己也還沒想清楚 | /grill-me 或 /grill-with-docs |
| 剛剛討論完，想把結論存下來 | /to-spec |
| 有個大計畫，要拆成可執行的小塊 | /to-tickets |
| 工作量大到一個 session 裝不下 | /wayfinder |
| 有個難搞的 bug 或效能退化 | /diagnosing-bugs |
| 想確認某件事的正確做法 | /research（背景 agent，產出帶引用的 Markdown） |
| 不確定某個設計要不要這樣切 | /prototype 或 /codebase-design |
| 覺得程式碼開始變爛了 | /improve-codebase-architecture |
| 陷在 merge conflict 裡 | /resolving-merge-conflicts（逐個 hunk 依意圖解，絕不 --abort） |
| 對話太長，要換 session 接手 | /handoff |
| agent 講的話我看不懂 | /wait-what |
| 有些步驟只有人能做（開帳號、設 CI secret） | /wizard（生成互動式 bash 精靈帶你走） |
步驟五：更新與改造
plugin 路線：自動更新，但有個要知道的細節——官方 marketplace 的清單指向這個 repo 的 git URL，而且 sha 是釘住的。新版是在那個釘子往前移的時候才到你手上，不是作者一發布就到。所以你看到的版本落後幾個 commit 是正常的。
skills.sh 路線：npx skills update 手動拉。
想改成自己的：這是 skills.sh 路線的主場。skill 就是純 Markdown，改法很直觀——調整 SKILL.md 裡的指示、改 front matter 的 description 讓觸發時機更準、或是把 disable-model-invocation 加上去讓某個 skill 只能由你手動叫。
如果你走 plugin 路線但想改一兩個 skill，做法是在自己的 repo 裡建同名 skill 覆蓋掉，而不是去改快取目錄——那裡是唯讀的，而且下次更新就沒了。
幾個實際的注意事項
先跑 setup，再用其他 skill。 to-spec、to-tickets、triage、wayfinder 都要知道你的 issue tracker 在哪，沒 setup 過它們會不知道該把東西寫去哪裡。
setup 可以重跑，但通常不必。 它偵測得到自己先前的產出（docs/agents/），會就地更新而不是重複追加。不過想調整內容的話，直接編輯 docs/agents/*.md 更快——只有換 issue tracker 或整組重來才值得重跑。
兩台電腦要各自安裝。 plugin 裝在 ~/.claude/plugins/，不在專案裡，所以不會跟著 git 走。但 setup 的產出（CLAUDE.md、docs/agents/）是在 repo 裡的，會跟著 push——所以換機器要重裝 plugin，但不用重跑 setup。
別在同一個專案裝兩次。 這點值得再說一遍：plugin 和 skills.sh 都裝的話，每個 skill 都會有兩份，agent 會困惑，你也會。
上一篇：「Skills for Real Engineers」介紹：Matt Pocock 的 agent skills 在解決什麼問題。
留言