文章目錄
mattpocock/skills 是一套軟體工程用的 Skills，由 Matt Pocock 開發，是基於 GitHub / GitLab Issues 建立的一套工作流。它的設計偏向人工協作，先藉由 wayfinder、to-spec、to-tickets 等 Skills 來開好一系列工單後，我們必須一單一單手動操控 AI Agent 來執行。
本文操作於 2026 年 9 月 1 日依 mattpocock/skills 官方 README與各工程 skill 文件重新核對。開始前需要 Git、Node.js、可操作目標 repository 的 GitHub CLI，以及能修改專案 instruction files 的權限；安裝方式與 skill 名稱仍可能隨版本調整。
安裝 Skills
於 Codex 中，有兩種安裝方式：
透過外掛市集安裝
開啟 Codex App，進入外掛程式介面，點擊右上角的新增 > 新增市集。
在來源貼上 https://github.com/mattpocock/skills.git，點擊新增市集。
新增好市集後，回到外掛程式介面，先切換到個人，再安裝剛才新加入的 mattpocock-skills。
完成安裝後，於新 Session 就可正常呼叫 Matt Pocock 的 Skills 了！
透過 npx skills 安裝
另一種做法是透過 npx skills 安裝，安裝中可自己控制要安裝在 User 目錄或專案中。
開啟終端機，電腦需先安裝 Node.js，再輸入指令：
1npx skills@latest add mattpocock/skills
直接選取 Matt Pocock Skills 的分類，全部安裝：
初始化專案環境
為了讓 Agent 後續能正確操作 GitHub Issues（需預先安裝 GitHub CLI），我們要使用 Setup Matt Pocock Skills 來初始化專案環境。請開啟 Codex App，切換到 GPT 5.6 Terra High 或更強的模型設定，輸入以下提示詞：
1/setup-matt-pocock-skills 追加限制此專案使用正體中文語言來撰寫文件與溝通
初始化過程中會需要同意一些決策，基本上一律回「是」、「AGENTS.md」或「CLAUDE.md」。
提出規劃
假設我要建立的是一個全新 Android App 專案，可以使用 Wayfinder Skill 來進行，他會先分析需求並建立一系列詢問（Grilling）、研究（Research）性質的工單。請參考提示詞：
1/wayfinder 建立一個 Android App 專案，啟動 App 後顯示全螢幕 WebView，網頁預設位址設定 https://vervecode.dev，若網頁或超連結導向非預設位址的網域則使用 Custom Tabs 進行。技術採用 Android Gradle + Kotlin，版本選擇以目前環境最高能支援為基準，需建立 tests 與 androidTests，tests 與建置輸出需使用 GitHub Actions。以上為專案需求，規劃時請自主決定技術細節，僅詢問涉及設計方向的問題。
過程中他會提出一些問題要你回答，通常問題都不少，但因為我於提示詞有提到「規劃時請自主決定技術細節，僅詢問涉及設計方向的問題」，Agent 就會自動收斂技術細節。
Wayfinder 完成後會建立幾個屬於研究或詢問的工單：
請開一個新的 Task，呼叫 Wayfinder 並貼上有 wayfinder:map 標籤的 Map Issue 連結，例如：
1/wayfinder https://github.com/tedliou/app.vervecode.dev/issues/1
工單會有 Grilling 與 AFK 兩種，前者會問一些決策問題，後者只要放著他會自己研究。此階段一個 Task 只會處理一個工單。如果有多個工單要處理，只要反覆建立新 Task 並輸入以上的提示詞，Wayfinder 會根據 Map Issue 內容自動認領與處理。
Agent 在詢問決策問題時，你可以回應「是」、「採用」、「同意」或直接描述你的想法，如果看不懂 AI 在說什麼（Claude Opus 5 最近都不說人話），可以叫他重新用淺顯易懂、精簡扼要的方式說明。
建立實作工單
當所有規劃單都完成後，可以讓 AI 開始建立實作用的 Issue，請輸入：
1/to-tickets
過程中他會問你拆工單的粒度，通常可以直接採用。完成工單建立後，即可在 GitHub Issues 中看到完整的實作規劃。各個工單之間可能會有依賴關係，必須做完前一個工單才能進行下一個，非必要的話我不建議平行處理多個單，比較容易不穩。
開始實作
建立新 Task，切換到 GPT 5.6 Luna Extra High 或更強的模型，輸入提示詞來實作第一項工單，例如：
1/implement https://github.com/tedliou/app.vervecode.dev/issues/22
實作開始時可能會和我們對一下需求，通常 Issue 開好就不會歪，可以直接放行。實作中基本上是以 TDD 進行，完成後除了測試要全過之外，也會叫兩個子代理來跑 Review（一個看原始碼，另一個看規格）。
到這階段時，只要反覆用 /implement 並貼上 Issue 連結來逐步完成工單即可。Matt Pocock Skills 這套技能其實很彈性，假設實作到中間你的需求變了，隨時可以中斷他，讓他重新規劃與評估 Issue。工單做完有時候他不會自己關掉，需要適時的人工介入。
如何判斷每個階段完成
初始化完成後，專案中應出現 skill 需要的 issue tracker、domain 與 label 設定，後續指令不再猜測 Issues 放在哪裡。Wayfinder 完成時，Map Issue 的研究與決策工單都要有結論；/to-tickets 完成時，應看到可獨立實作、帶依賴關係的 ready-for-agent 工單。/implement 則只處理一張 ticket，測試與 review 通過後 commit 到目前分支；官方文件也特別提醒，它不會自動建立分支或關閉 Issue。
流程卡住時，先確認目前 Task 對應的是哪一張 Issue，以及 repository、branch 與 label 是否正確。Agent 開始處理別張工單，通常要回到 Map Issue 或 tracker 設定檢查認領狀態；實作內容偏離需求時，直接停止該 Task，更新 Issue 的驗收條件後再開新 Task，不要讓同一個上下文一路猜下去。
這套流程的復原單位是 branch、commit 與 Issue。開始 /implement 前先切到預期分支；結果不符合需求時保留失敗紀錄，從 Git 檢視實際 diff，再依專案既有方式修正或回復。不要把「刪除整批工單」當成預設復原方式，因為規劃決策與失敗原因仍有追蹤價值。
總結
這個技能是我目前工作上穩定使用的好工具，於企業中追求的除了速度就是穩定性，多一點人工介入，可以少一點未來會讓你抓狂的問題。網路上許多只會做雛形的 KOL 或號稱某某大佬會跟你說「全部都給 AI 做」或「沒在看 AI Code」的話語，在現階段模型仍然會不定時抽風的狀況下，如果想要在 Deadline 前提交穩定可看的成果，還是得依靠專業判斷，而非盲目追隨外人所說的「趨勢」。
