使用方式
本篇把上游 mattpocock/skills 的 25 個官方 skills 放進具體情境。每一節都包含「何時使用」、「實際輸入」與「預期產出」。
以下示例假設目標 agent 已安裝對應 skill，並且支援 slash command。若你的 agent 不提供 slash command，請用自然語言描述同一個情境；Model-invoked skill 也可能由 agent 依任務自動採用。
Engineering：User-invoked
1. /ask-matt
情境： 你知道要完成一項工作，但不確定應該先規劃、除錯、研究還是直接實作。
使用：
/ask-matt
我需要替現有 API 加入批次匯出功能，目前還不確定要先做規格、架構調查或原型。預期產出： 依對話情境推薦合適的 user-invoked skills 與下一步順序。它是路由器，不是實作工具。
2. /grill-with-docs
情境： 新功能涉及多個團隊，術語與決策尚未統一，之後還需要讓其他 agent 接手。
使用：
/grill-with-docs
我們要新增訂閱方案，請先釐清使用者、帳務邊界與既有領域術語。預期產出： 透過逐步追問建立共享語言，並依 repo 設定更新 CONTEXT.md、ADR 或其他領域文件。
3. /triage
情境： Issue backlog 中有新回報與外部 PR，需要按照團隊規則分類與追問。
使用：
/triage
請處理 issue #142，確認它的類型、優先級、必要 labels，以及是否需要向回報者補問資訊。預期產出： 依 triage roles 推進 issue 狀態，套用設定好的 labels，並產生可交給後續 agent 執行的摘要。
4. /improve-codebase-architecture
情境： 專案可以運作，但模組越來越難修改，你想先找候選改善點，不想直接大規模重構。
使用：
/improve-codebase-architecture
請掃描目前的訂單模組，找出最值得深化的模組與原因。預期產出： 可分享的 HTML 架構調查報告，以及可供選擇的深化候選；選定候選後再進入追問與實作。
5. /setup-matt-pocock-skills
情境： 第一次在 repo 啟用這套 skills，還沒有 issue tracker、triage labels 或文件存放規則。
使用：
/setup-matt-pocock-skills預期產出： 互動詢問 GitHub、Linear 或本機檔案等 tracker 選擇、/triage labels 與文件儲存位置，並建立後續 skills 需要的 repo 設定。
6. /to-spec
情境： 對話中已經做完需求與設計決策，現在要把目前共識整理成可追蹤的規格。
使用：
/to-spec
請把剛才決定的快取失效策略整理成規格，包含範圍、驗收條件與風險。預期產出： 根據既有對話產生規格並發佈到設定好的 issue tracker；它不會重新進行完整訪談。
7. /to-tickets
情境： 一份規格太大，團隊需要一組可以逐步交付、並且宣告阻塞關係的 tickets。
使用：
/to-tickets
請把這份付款重構規格拆成 tracer-bullet tickets，標出每張 ticket 的阻塞邊。預期產出： 本機 ticket 檔案或 tracker 中的 tickets，並保留可執行順序與依賴關係。
8. /implement
情境： 規格或 tickets 已經明確，現在要依照既定邊界逐步完成程式碼與測試。
使用：
/implement
請依照已核准的規格與 ticket-001 開始實作，完成一個垂直切片後先執行測試。預期產出： 依規格實作工作，並在約定的 seams 驅動 /tdd、最後以 /code-review 收尾；開始前應確認即將修改的範圍。
9. /wayfinder
情境： 工作規模超過單一 agent session 可以安全容納，且前進路徑仍有多個架構決策待解。
使用：
/wayfinder
請為單體系統拆分成三個服務建立長期路線圖，先列出所有阻塞性的決策 tickets。預期產出： 一張共享的決策地圖；團隊逐一解決決策 tickets，直到實作路徑清楚。
Engineering：Model-invoked
10. /prototype
情境： 你不確定互動設計或狀態邏輯是否合理，想快速比較方案，不想先投入正式架構。
使用：
/prototype
請做一個可切換三種篩選流程的單頁 HTML 原型，讓我比較使用者操作成本。預期產出： 拋棄式、可分享的 HTML 原型；驗證設計問題後應丟棄或另行正式實作，不把原型當成生產程式碼。
11. /diagnosing-bugs
情境： Bug 可以重現但原因不明，或效能回歸可能有多個互相競爭的假設。
使用：
/diagnosing-bugs
訂單 API 偶爾超過 5 秒，請先建立可觀測的重現，再逐一驗證可能原因。預期產出： 由重現、最小化、假設、儀器化、修復到回歸測試的紀律化診斷迴圈，而不是直接猜一個修法。
12. /research
情境： 需要確認第三方 API、標準、版本行為或外部事實，且結果要能被團隊日後追溯。
使用：
/research
請查證這個 OAuth provider 對 refresh token rotation 的官方規則，限定使用一手來源並記錄引用。預期產出： 由背景 agent 進行的一手來源研究，以及帶引用的 Markdown 發現文件。
13. /tdd
情境： 新增行為或修復 Bug，需要讓測試回饋在每個垂直切片都可見。
使用：
/tdd
請先為「過期訂單不能付款」寫一個會失敗的測試，再用最小實作讓它通過。預期產出： red → green → refactor 的循環，並把測試放在穩定的介面或 seam 上。
14. /domain-modeling
情境： 團隊使用同一個詞表示不同概念，導致需求、程式碼與文件互相矛盾。
使用：
/domain-modeling
請檢查「訂閱」「方案」「帳戶」在目前 repo 中的用法，找出衝突並用邊界情境驗證定義。預期產出： 更精確的領域模型、詞彙與邊界情境，並依 repo 規則更新 CONTEXT.md 或 ADR。
15. /codebase-design
情境： 要設計一個新模組或重畫介面邊界，希望把複雜行為藏在小而穩定的介面後面。
使用：
/codebase-design
請為通知服務提出兩個截然不同的介面，評估 module depth、seam 與可測試性。預期產出： 使用深模組、資訊隱藏、乾淨 seam 與 design-it-twice 的設計比較，而不是只接受第一個介面想法。
16. /code-review
情境： 功能已完成，準備 commit 或 PR，需要確認程式碼標準與原始規格都沒有被偏離。
使用：
/code-review
請從 main 到目前 branch 的 diff 進行 Standards 與 Spec 雙軸審查。預期產出： 分開呈現 Standards 與 Spec 的問題清單；Fowler smells 是判斷建議，不會取代 repo 自己的規範。
17. /resolving-merge-conflicts
情境： merge 或 rebase 正在進行中，衝突同時涉及兩邊的意圖與功能變更。
使用：
/resolving-merge-conflicts
請逐個 hunk 追溯兩邊的意圖並解決目前衝突，完成操作，不要使用 --abort。預期產出： 依來源意圖完成每個 hunk 的解決，並在結束前確認狀態與測試；不會用任一側內容盲目覆蓋另一側。
18. /wizard
情境： 部署、設定憑證或第三方 dashboard 操作需要人類完成，agent 可以協助產生安全的逐步引導。
使用：
/wizard
請產生一個互動式 bash wizard，引導我設定 CI secret；secret 值只能由我手動輸入。預期產出： 只把人類必須做的步驟做成互動流程，不把密碼、token 或其他 secrets 寫入腳本。
Productivity：User-invoked
19. /grill-me
情境： 你有一個計畫或想法，但希望先被密集追問，直到重要分支與取捨都說清楚。
使用：
/grill-me
我要把後台改成多租戶，請不要先提方案，先逐題追問目標、限制與成功標準。預期產出： 針對計畫或設計的密集訪談；它不會自動建立完整的領域文件，需文件化時改用 /grill-with-docs。
20. /handoff
情境： session 即將結束，或要把工作交給另一位 agent／另一台機器，不能只留下零散聊天紀錄。
使用：
/handoff
請整理目前完成項目、未完成工作、關鍵決策、驗證結果與下一步，讓下一個 agent 可以直接接手。預期產出： 結構化交接文件，包含目前狀態與恢復工作所需的上下文。
21. /teach
情境： 你想用多個 session 學會一個新技術，並讓教學進度保留在目前工作目錄。
使用：
/teach
請用這個 repo 教我從零理解 event sourcing，分成多個 session，並在每次結束記錄學習進度。預期產出： 分階段教學、練習與持續的學習狀態，而不是一次貼一篇百科文章。
22. /to-questionnaire
情境： 你需要產品負責人或領域專家回答一組問題，但目前無法自行決定答案。
使用：
/to-questionnaire
請把付款失敗處理中需要財務主管決定的問題整理成可非同步填寫的 Markdown 問卷。預期產出： 針對「要發送什麼、由誰回答、需要回收什麼」設計的問卷，不會假裝替唯一決策者回答內容。
23. /wait-what
情境： agent 的說明沒有對準你的問題，或使用太多你不熟悉的術語，導致訊息沒有傳達成功。
使用：
/wait-what
你剛才的說明沒有讓我知道為什麼要改這個 module，請用目前 repo 的詞彙重新說明，先講影響再講細節。預期產出： 重新對齊脈絡、使用共享詞彙並降低不必要的複雜表述。
Productivity：Model-invoked
24. /grilling
情境： agent 正在進行需要多輪追問的流程，必須持續挑戰模糊假設與未解決的分支。
使用：
/grilling
請針對這個 API 版本遷移計畫逐題挑戰，直到相容性、回滾與驗收條件都明確。預期產出： 可重複使用的密集訪談能力；它是 /grill-me、/grill-with-docs、/triage 等流程可共用的底層紀律。
25. /writing-for-agents
情境： 要新增或改寫 AGENTS.md、CLAUDE.md、skill 或其他 agent 會讀取的文件，必須讓內容可執行且不與 canonical source 重複。
使用：
/writing-for-agents
請把這個 repo 的部署規則改寫成 agent 可直接遵循的文件，保留命令、限制與驗證條件。預期產出： 結構清楚、觸發條件明確、可被 agent 正確讀取的文件；不會把容易過時的實作細節重複複製到多個地方。
使用後的判斷
完成任一情境後，先檢查產出是否符合原始目標，再決定是否進入下一個 skill。例如：
/grill-with-docs → /to-spec → /to-tickets → /implement → /code-review
/diagnosing-bugs → /tdd → /implement → /code-review
/prototype → /codebase-design → /to-spec不要把所有 skills 串成固定流水線；只選擇能縮短回饋迴圈、降低不確定性或保留決策脈絡的步驟。