02｜工程流程全家桶（mattpocock/skills）
🎯 一句話：不是 24 個獨立工具，而是一條主流程——先把需求逼問清楚（grill）→ 寫成規格 → 拆成票 → TDD 實作 → 兩軸 Review。
- Repo：https://github.com/mattpocock/skills（MIT）
- 作者：Matt Pocock（aihero.dev）
- 分為
skills/engineering/與skills/productivity/兩類
副標直接表態：「我每天用來做真正工程的 agent skills——不是 vibe coding」。開頭段落還點名 GSD、BMAD、Spec-Kit 這些方法論，說明它想解決同一批問題但走不同路線。
作者背景
Matt Pocock（英國 Oxford）是全職的 TypeScript 教育者：
- Total TypeScript 作者——業界公認的 TS 學習標準課程
- 前 Vercel developer advocate、XState 核心團隊成員
- 現在經營 AI Hero，把 web 工程師訓練成 AI 工程師；其 AI Coding Cohort 有 2,500+ 學員用 Claude Code 實作兩週
- 入行前是聲音教練——這大概能解釋為什麼他的 Skill 這麼在意「怎麼問問題」
repo 的副標是 "Straight from my .agents directory"——這是他自己每天在用的東西，不是為了教學而寫的示範，這也是它比多數 skill 收藏可靠的原因。
它想解決的四種失敗
| 失敗模式 | 症狀 | 對應 Skill |
|---|---|---|
| Misalignment | Agent 誤解你要什麼，寫完才發現方向錯 | grill-me、grill-with-docs |
| Verbosity / 沒有共同語言 | 每次都要重講一遍領域名詞 | domain-modeling（CONTEXT.md + ADR） |
| Broken Code | 沒有回饋迴圈，改一處壞三處 | tdd、diagnosing-bugs |
| Architectural Decay | 檔案越長越淺，越改越難改 | codebase-design、improve-codebase-architecture |
主流程
grill-me / grill-with-docs ← 逼問，直到達成共識
↓
to-spec ← 對話變規格（PRD），發到 issue tracker
↓
to-tickets ← 規格拆成 tracer-bullet 票，標註 blocking 邊
↓
implement ← 照票實作，在約定的 seam 上跑 /tdd
↓
code-review ← Standards 軸 + Spec 軸，兩個子 agent 平行跑
第一次使用要先跑 setup-matt-pocock-skills，替這個 repo 設定 issue tracker（預設 GitHub，也支援本地 markdown）、triage 標籤字彙、領域文件位置。
使用者手動呼叫的 Skill
| Skill | 特性 |
|---|---|
| ask-matt | 路由器。「我現在該用哪個 skill？」不記得整套流程時先問它 |
| grill-me | 把計畫攤成決策樹，一次問一題、每題附上建議答案，答完才准動手；能自己查的事實自己查，只把「決策」留給你 |
| batch-grill-me | 同樣的決策樹，但改成一輪問完整個 frontier（所有前置已決的問題），適合你有整段時間可以一次回完 |
| grill-with-docs | 逼問的同時把術語與決策寫進 CONTEXT.md 與 ADR——訪談結束就有文件 |
| to-spec | 不再訪談，純粹把當前對話合成一份規格並發到 tracker |
| to-tickets | 拆票，每張票是一顆 tracer bullet（垂直切片），並宣告它被哪些票 blocking |
| implement | 依規格／票實作，規律跑型別檢查與單一測試檔，最後跑一次完整測試 |
| triage | 把 issue 與外部 PR 推過一台狀態機：分類 → 驗證 → 必要時 grill → 產出 agent 可直接接手的 brief。PR 被視為「附程式碼的 issue」 |
| wayfinder | 給「一個 session 裝不下」的大工程：先命名 destination，再把路線畫成 tracker 上的決策票，一次解一張，直到路徑清晰。強調 plan, don't do |
| improve-codebase-architecture | 掃描 codebase 找 deepening 機會，產成視覺化 HTML 報告，選一個再 grill 進去 |
| handoff | 把對話壓縮成交接文件（存到 OS 暫存目錄），含「建議下一個 agent 使用哪些 skill」，且不重複已存在的 artifact，只給路徑 |
| claude-handoff | 同樣的交接摘要，但直接 claude --bg --name "..." 開一個背景 agent 接手 |
| teach | 有狀態的教學：把當前目錄當成教室，跨 session 保存學習進度 |
| edit-article | 把文章切成段落，視為有向無環圖排序（先備知識先講），先與作者確認章節再改稿 |
| setup-matt-pocock-skills | 每個 repo 跑一次的初始化 |
| writing-great-skills | 寫 Skill 的方法論：核心價值是可預測性（每次走同樣流程，而非產同樣輸出），附 GLOSSARY.md |
模型可自動觸發的 Skill
| Skill | 特性 |
|---|---|
| tdd | 紅→綠→重構。重點不在迴圈本身，而在「什麼是值得留下的測試」、測試放哪、反模式清單；探索程式碼時會先讀 CONTEXT.md 讓測試命名對齊領域語言 |
| diagnosing-bugs | 難 bug 與效能退化的紀律：建立回饋迴圈 → 最小化 → 假設 → 埋 instrument → 修 → 補回歸測試。跳過任何一階都要說明理由 |
| code-review | 兩軸審查：Standards（符合此 repo 的規範 + Fowler code smell 基線）與 Spec（是否忠實實作原始 issue／PRD），兩個子 agent 平行跑避免互相污染 context，最後彙整 |
| codebase-design | deep module 的共同字彙：小介面、大行為、乾淨 seam、可透過介面測試。明確要求不要用「component / service / API / boundary」代換術語 |
| domain-modeling | 主動打磨領域模型：挑戰用詞、用邊界情境壓力測試、當場更新 CONTEXT.md 與 ADR。只是「讀」CONTEXT.md 不算，這個 Skill 是用來改模型的 |
| resolving-merge-conflicts | 逐個 hunk 依「雙方原始意圖」解衝突（讀 commit message、PR、issue），衝突不可調和時選符合這次 merge 目標的一方並記錄取捨；永遠不准 --abort，最後跑專案的自動檢查 |
| prototype | 拋棄式原型：先確認「要回答的是哪個問題」，再決定形狀——邏輯／狀態問題做成可跑的終端機小程式，UI 問題做成幾個可切換的版本 |
| research | 開背景 agent 去讀一手來源（官方文件、原始碼、規格、first-party API），把附引用的發現寫成 repo 內的 Markdown，並沿用專案既有的存放慣例 |
最值得學的三個觀念
- 決策樹式訪談：一次一題、附建議答案、事實自己查——把人的時間只花在決策上。
- 兩軸 Review：「合不合規範」與「有沒有做到需求」是兩件事，要分開跑、分開報。
- 可預測性 > 產出一致：
writing-great-skills的立場是，Skill 的價值在於強迫每次走同一套流程。