Matt Pocock Skills 讓 Agent 穩定處理開發工單

把需求交給 Agent 後直接開始寫功能，常會到驗收時才發現雙方想的行為不同。使用 Matt Pocock Skills 時，我們可以先用 /grill-with-docs 討論需求並留下文件，再透過 /to-spec 整理規格、/to-tickets 拆工單，最後用 /implement 逐張實作。

這套 Matt Pocock Skills 由 Matt Pocock 開發，各個 Skill 可以分開使用，也能接成上述流程。本文以 GitHub Issues 作為工單管理工具，沿用 Android App 的範例說明從需求討論到實作的操作方式。指令與行為依 2026 年 9 月 16 日的官方文件核對。

安裝 Skills

開始前需要安裝 Git、Node.js 與 GitHub CLI，並確認 GitHub CLI 已登入有權限操作目標 Repository 的帳號。後續初始化會修改專案的 Agent 指令檔，也需要能在該 Repository 建立 Issues。

依照官方 README，Codex 使用 npx skills 安裝。開啟終端機並輸入：

1npx skills@latest add mattpocock/skills

安裝過程可以選擇要使用的 Agent，以及安裝到使用者目錄或目前專案。直接選取 Mattpocock Skills 整組安裝，就能一併取得初始化、需求討論、拆工單與實作時會用到的 Skills。

完成後開啟新的對話，確認 Agent 能找到 setup-matt-pocock-skills，再進行專案初始化。

初始化專案環境

先讓 Agent 知道工單要放在哪裡，以及專案文件採用什麼格式。在目標專案中呼叫 Setup Matt Pocock Skills，並加上文件與溝通語言的要求：

1/setup-matt-pocock-skills 此專案使用 GitHub Issues 管理工單，文件與溝通使用台灣繁體中文。請先確認目前 Repository 與既有 Agent 指令，保留原本的專案規則。

初始化會檢查 Repository、現有指令檔與文件配置，再提出設定讓我們確認。此時要看的是 GitHub Repository 是否正確，以及它準備把設定寫到哪個指令檔。已有 AGENTS.md 或 CLAUDE.md 的專案，應沿用既有安排。

設定完成後，工單位置會記錄在 docs/agents/issue-tracker.md，領域文件配置則放在 docs/agents/domain.md。有安裝 Triage 時也會設定工單標籤。後續 Skills 會讀取這些設定，不需要每次重新交代工單要開在哪裡。

用 Grill with Docs 釐清需求

假設我們要建立一個以 WebView 顯示網站的 Android App，可以先把想要的行為交給 /grill-with-docs，讓 Agent 逐步確認還沒決定的部分：

1/grill-with-docs 建立一個 Android App，啟動後顯示全螢幕 WebView，預設載入 https://vervecode.dev。同網域連結留在 WebView，前往其他網域的網頁連結使用 Custom Tabs 開啟。技術採用 Android Gradle + Kotlin，請先查目前環境與官方相容性文件，提出可用的版本組合。需要本機單元測試、Android 裝置測試與 GitHub Actions 建置。請用淺顯易懂的台灣繁體中文討論，每個問題附上建議答案，並將確認的術語與重要決策記錄到專案文件。這個階段先完成需求討論，不開始實作。

Agent 會把需求拆成一輪輪問題。已能從環境或程式碼查到的事實由它確認，需要我們決定的行為則留下來討論。像是「其他網域」是否包含子網域、返回鍵要先回上一頁還是直接離開 App，以及斷線時要顯示什麼畫面，都會影響最後做出來的結果。

回答時可以採用建議，也可以直接描述想要的行為。看不懂問題時就請它換成具體操作情境，例如「使用者點了站外連結後按返回鍵，會回到哪裡」。等這些行為確定，再繼續下一輪。

依照官方的 Grill with Docs 定義，這個 Skill 會結合需求訪談與 Domain Modeling。確認過的術語會寫進 CONTEXT.md，需要保留取捨理由的重要決策才會另外記成 ADR。CONTEXT.md 是詞彙表，完整功能規格會在下一步整理。

討論結束前，請 Agent 用一段話整理這次要做的功能與尚未確定的事項。我們確認雙方理解一致後，就可以把這段對話轉成 Spec。

用 To Spec 整理規格

留在剛才的對話中執行 /to-spec，讓 Agent 接著使用已確認的需求與決策：

1/to-spec 將剛才確認的 Android App 需求整理成 Spec，發布到此專案的 GitHub Issues。請包含使用者操作情境、實作與測試決策，以及這次不做的範圍。

依照官方的 To Spec 定義，這一步會整理現有對話，不會重新進行需求訪談。它仍會確認要從哪個層級測試功能，再將 Spec 發布到設定好的工單管理工具。

打開產出的 Spec Issue，沿著實際操作順一次：啟動 App、開啟同網域頁面、前往站外連結，再按返回鍵。這些行為應該和剛才的討論一致，也要看得出哪些項目不在這次範圍內。例如尚未討論離線快取，就不應在規格裡突然多出完整離線閱讀功能。

有缺漏時先修正 Spec，再拆工單。接下來即使另開 Task，也能直接提供 Spec Issue 連結，讓 Agent 讀取已確認的內容。

用 To Tickets 拆成實作工單

Spec 確認後，執行 /to-tickets 並附上剛才產出的 Issue 連結。以下角括號內容請換成自己的連結：

1/to-tickets <Spec Issue 連結>

Agent 會先提出拆分方式，列出每張工單交付的行為與依賴關係，讓我們確認粒度後才建立 Issues。按照官方的 To Tickets 定義，一般功能會拆成能獨立展示或驗證的小段完整流程。

以這個 App 為例，第一張可以先做到「啟動 App 後載入預設網站」，包含必要的專案設定與測試。後續再加入站外連結導向 Custom Tabs 的行為。這樣每完成一張工單，就有一段能實際操作的結果，也比較容易確認問題出在哪一步。

檢查拆分時，要確認驗收條件是否具體，以及依賴是否合理。站外連結處理需要先有可運作的 WebView，就應依賴前一張工單。確認後讓 Agent 建立 Issues，工單預設會套用 ready-for-agent 標籤。

依 Issue 標籤決定下一步

工單建立後，先看標籤再決定要繼續討論，還是交給 Agent 實作。依照官方的 Triage 定義，bug 與 enhancement 用來區分工作類型，另外五個狀態標籤則表示目前需要誰做什麼。以下以 Issue 的預設標籤為例，初始化時若有自訂名稱，請對照專案的 docs/agents/triage-labels.md。

例如工單同時標記 enhancement 與 needs-triage，代表這項改善還需要評估。可以先輸入以下指令，讓 Agent 讀取工單與既有討論，再確認還缺哪些決策：

1/triage 請評估 <Issue 連結>，確認需求、驗收條件與目前狀態。需要補充設計決策時，再帶我進行 Grilling，並把確認的結論寫回工單。

需求完整且適合交給 Agent 時，才轉成 ready-for-agent。已經確認過的問題不用重新問一輪，缺少提報資訊的工單則先停在 needs-info，等資訊補齊後再評估。每張經過 Triage 的 Issue 應有一個工作類型與一個狀態，狀態互相衝突時先釐清。

ready-for-agent 也仍要搭配「Blocked by」判斷。優先處理沒有阻擋條件，或前置工單都已完成的項目。非必要時我會逐張處理，讓每次實作與驗收的範圍保持清楚。

用 Implement 逐張實作

先確認目前分支是預期的開發分支，再建立新的 Task，提供一張可以開始處理的實作工單：

1/implement <實作工單連結> 請讀取工單與母 Spec，確認前置依賴已完成，只實作這張工單的範圍，依驗收條件執行測試並回報結果。

官方的 Implement 定義 會要求 Agent 在適合的地方採用 TDD，過程中執行型別檢查與相關測試，最後跑完整測試並呼叫 Code Review。完成後會 Commit 到目前分支，因此開始前就要確認分支，不能預期它會替我們另開一支。

實作完成時，除了看測試結果，也要對照工單的驗收條件操作。Android 裝置測試需要模擬器或實機，環境無法執行時應明確列為未驗證，補上測試後再判定完成。接著依專案流程審查、合併並確認 Issue 狀態，再處理下一張已解除依賴的工單。

做到一半需要改需求，可以先停下來討論，更新 Spec 與受影響的工單後再繼續。只在實作對話裡口頭更改，下一個 Task 讀到的仍會是舊規格。

總結

Matt Pocock Skills 這套流程先用 /grill-with-docs 把需求問清楚並留下文件，再用 /to-spec 整理成可確認的規格，接著透過 /to-tickets 拆成有驗收條件與依賴關係的工單，最後用 /implement 逐張完成。

這套 Skills 是我工作上持續使用的工具。Agent 可以協助整理需求、寫程式與執行測試，我們則在規格、工單與實作結果之間確認方向。多花一點時間把每個階段看過，後續開發才有明確依據，也比較容易在需求變動時知道要改哪裡。

Ted Liou

Unity 現役工程師，Unity、AI 技術開發經驗分享與諮詢。