[情報] Matt Pocock Skills v1.3：/implement-spec、/pr、/retro 三個新技能
一、v1.3 這次出了什麼
Matt Pocock 維護一套給 coding agent 用的 skills，裝進去之後 agent 會照裡面寫好的流程做事。
v1.3 把三個原本放在 in-progress 的技能正式收進 engineering 分類：/implement-spec、/pr、/retro。他說 /retro 在社群上反應最熱烈，自己用起來也覺得很強。
另一個要動手處理的改變是 CONTEXT.md 改名為 GLOSSARY.md。
二、/implement-spec：讓 agent 替你跑 ticket
他處理大型工作的流程分兩層。spec 描述最後要到哪裡，ticket 把目的地切成一段段、每段一個 agent session 就能做完的工作。
整份 spec 塞進同一個 agent，會掉進 context 太長、表現變差的區段，還可能觸發自動壓縮。他認為拆成 ticket 乾淨很多。
跑 ticket 有三種方式：
- 手動迴圈：你叫 agent 做第一張、等它做完、清 context、再叫它做第二張。人變成 for loop，他直說這不好玩。
- 確定性迴圈：寫一支 script 逐張讀 ticket、對每張跑 /implement。他最推薦這種，每次跑法都一樣、穩定又便宜，可是要花耐心調整，他覺得對新手太難。
- agent 迴圈：讓一個 agent 坐在那裡顧 ticket，每張交給 subagent 實作。這就是 /implement-spec。
他坦白說 agent 迴圈比確定性迴圈差，但很適合拿來練習人離開鍵盤、讓 agent 自己把整份 spec 做完。這招最近才可行，因為 subagent 現在可以再開自己的 subagent。
三、/implement-spec 的流程
他提醒用任何 skill 之前都該把整份讀完。這份不長，一共九個步驟。
ticket 之間有阻擋關係，構成一張任務圖，所以隨時都有一批沒被擋住、可以直接開工的 ticket。
流程大致是：讀 spec 和 ticket、用一個 subagent 探索程式碼、建立 integration branch，然後替每張可開工的 ticket 開一個 implementer subagent，各自在自己的 worktree 先寫測試再實作。完成的 ticket 由 merger subagent 合進 integration branch，新解鎖的 ticket 再開新的 subagent。
全部做完後，它對整條 branch 跑 code review 並修掉問題，清理 worktree，最後準備好 PR 給人看。
他說在還沒架好確定性 script 的專案上，自己用它的頻率比預期高很多。他也鼓勵大家拿它當基礎版本，改成自己的做法，例如改用 stacked PR。
官方 changelog 另外寫了兩個還沒解決的地方。結果會是一條很大的 branch；worktree 也沒有消除衝突，只是把衝突延到合併時才出現。
四、/pr：讓人類 review 變輕鬆
他認為 PR 仍是工作進到 main 的最大瓶頸。這個技能只做一件事，就是給 agent 一份寫 PR 內文的範本，目標是讓人類審得快。
靈感來自 Dex Horthy 的 show-me skill，那個技能會用精簡的圖和 pseudo code 幫人看懂目前的主題。
- Summary：用 show-me 風格的小圖、檔案樹或 pseudo code 說明改了什麼。
- Evidence：要有 before 和 after。他說主動要證據時，agent 常會多跑一個測試或多截一張圖；沒要的話，agent 很容易說「我讀過程式碼，應該可以」。他提到自己最近很在意驗證。
- Merge Danger：先問這是單向門還是雙向門。雙向門可以輕鬆 revert；單向門會在外部世界留下影響，例如刪資料，或回滾成本很高。再看 blast radius，也就是出事時波及多大。
雙向門加上小 blast radius 的 PR，就不必審得太細。他把這段放在最下面，讀者往往第一、二眼就會看到。
示範的 PR 是把兩個幾乎一樣的演算法合併成一個。內文列出檔案增刪和呼叫結構，before／after 顯示改完後多了開頭的 Intro 章節，判定為雙向門、blast radius 小。
他說這是他看過最穩定會被模型自動呼叫的技能之一，至少在 Opus 5.5 上每次都會用。已經有自己 PR 技能的人，也可以從這份挑想要的部分拿去用。
五、CONTEXT.md 改名為 GLOSSARY.md
domain-modeling 和 grill-with-docs 這類技能以前會寫 CONTEXT.md，現在改寫 GLOSSARY.md。
舊名字來自 Eric Evans《Domain-Driven Design》裡的 bounded context。他說自己實際上還是在用 DDD，只是 CONTEXT.md 太模糊，agent 不會在對的時機讀它，使用者也搞不懂。檔案內容後來也縮到只剩詞彙表。
行為沒有變，只改檔名。但很多技能都要看到 GLOSSARY.md 才會用上專案的領域用語，所以舊檔記得改名。
changelog 給的做法是 git mv CONTEXT.md GLOSSARY.md，CONTEXT-MAP.md 也一起改成 GLOSSARY-MAP.md。團隊最好在同一個 commit 裡改完，不然先更新技能的人，agent 會在舊檔旁邊另開一個空的 GLOSSARY.md。
六、/retro：回頭讀 agent session
他發現自己這套技能對使用者要求很多：維護 AGENTS.md、管理 skills、讓 repo 省 token、讓 agent 有安全的環境，還要有好的 lint 規則和好找的程式結構。他自己一直在手動做這些事，乾脆包成一個技能。
/retro 是 retrospective 的縮寫。對一段或多段 agent session 執行，它會建議下次可以改進的地方。因為讀的是真實紀錄，它看得到 agent 自己不會講的低效率。
他引用 André Staltz 在 X 上的貼文。André 說 agent 一路撞到很多沒被發現的問題，只是靠著堅持，功能最後還是做出來了。Matt 的解讀是 agent 不太會抱怨，也不會主動修自己的錯，需要另一個 agent 回頭檢查。
他在影片裡現場跑了一次，抓到的問題包括：
- agent 在他決定怎麼修之前就自己發了 release，所以 GitHub 上只有 1.3.1，沒有 1.3.0。他說這條他不太在意。
- 某個 repo 有 pnpm check 指令，卻沒有任何東西會執行它，建議補一條 CI。
- 長 session 經過多次壓縮後會遺失 context，建議把重複出現的指示收進一個專用 skill。他說這條一定會做。
- 他為課程影片管理器寫的自訂 CLI 浪費 token；另一個 wiki CLI 在本機沒有加進 PATH。
技能裡列出七個檢查方向：程式碼好不好找、能不能加自動檢查、能不能加 coding standard 給自動 reviewer、全域 AGENTS.md 健不健康、工具用起來划不划算、steering 檔裡有沒有寫了等於沒寫的指示、agent 拿不拿得到需要的資訊。
七、retro 要留人在迴圈裡
他提醒要用自己的判斷看結果。retro 認為最嚴重的那條 release 問題，對他來說只是再發一版就好。
幾乎每個人看到都說想自動化，他的回答是不要。自動化之後 agent 會一直找到誤判、一直修，把 repo 和 agent 帶到不該去的地方。
他建議有空時挑幾段最近的 session 跑一次，特別是出過錯或 agent 行為怪怪的那段。他說定期跑 retro 之後，自己的 token 效率和產出品質都明顯提升。
影片最後在宣傳他放在 aihero.dev 的 AI Coding Crash Course，當天會加一堂講 /implement-spec 的課。
※ 來源：YouTube／Matt Pocock《New Skills! v1.3 brings /pr, /implement-spec, and /retro》（14:34，2026-10-05）。補充細節參考 AI Hero 官方 changelog。內容依影片口述與畫面整理，逐字稿為自動語音辨識，可能有誤。