我原本以為 AI 寫程式最爽的是「叫它寫就好」，結果 Gary 直接點破：真正浪費時間的是你在一張一張貼 tickets、等它跑完、再貼下一張，根本是人肉迴圈。這支影片拆 Matt Pocock 的 skill 1.3 版，新增 implement-spec、pr、retro 三個，Gary 自己裝完跑了幾天，把痛點跟解法都講得很白。

影片時間軸

1. 01:09回顧舊流程五步：grill、to-spec、to-tickets、implement、code-review
2. 01:50Gary 說自己早就寫過 implement-tickets，還私訊問過 Matt 多線並行
3. 02:48示範一行指令 implement-spec 加 spec 編號，十張 tickets 全自動跑完
4. 03:23解釋並行原理：先分析依賴關係，獨立的任務丟給子 Agent 各自 worktree 施工
5. 04:06進到 pr skill，先科普 PR 是什麼，再講 AI 產出的 PR 為什麼難審
6. 05:38拆 PR 範本三段：摘要附圖、強制驗收證據、標示能不能退回與影響範圍
7. 07:31retro skill 復盤兩部分：檢查 Context Engineering、建立長期防護欄
8. 08:47Matt 提醒 retro 不要全自動化，Gary 補白話版改造與工作流全貌

implement-spec 把排隊變成並行

Gary 講得很直接：一份 spec 拆出七八張 tickets 開在 GitHub 上，你只能一張一張叫 Agent 處理，等它跑完、檢查、清空、再下一個 prompt，說穿了就是人肉版的 loop。implement-spec 會先分析任務卡之間的依賴關係，把互不相干的任務丟給子 Agent 在各自 worktree 同時施工，原本三倍時間壓到三分之一。就算沒用 Matt 的 skill，在 prompt 裡請 AI 先拆細項、標註依賴關係再並行處理，這招一樣能用。

PR 要逼 AI 把證據攤開

Matt 認為現在開發瓶頸不在寫程式，而在人類審 PR。Claude Code 內建的 PR 範本很陽春，Test Plan 常常只是沒打勾的待辦清單。pr skill 把 PR 規範成三段：第一段用一張最小的圖講清楚改了什麼架構，第二段強制附截圖或前後數據對比當驗收證據，第三段標示出事退不退得回來、影響範圍多大。退得回來又影響小的快速放行，動到核心資料的才停下來細看。Gary 還幫團隊改了一版給技術小白看的白話版。

retro 抓出 AI 沒說的浪費

AI 很會硬撐，過程中重試一堆、浪費大量 Token、踩了一堆沒人知道的坑，下次開新對話同樣的錯再犯一次。retro 會翻工作日誌復盤兩件事：一是檢查 Context Engineering，看 AI 找檔案是不是瞎找、AGENTS.md 是不是肥到塞了一堆無效指令；二是把固定錯誤做成 Lint 規則或 pre-commit hook 硬擋，只有需要主觀判斷的才寫進檔案。但 Matt 提醒千萬別全自動化，AI 天天自我反省會吹毛求疵，把專案帶去奇怪方向，提案一定要自己審。

值得下載嗎：值得，尤其你已經在用 Claude Code 跑多步驟任務的話。三個 skill 的思維都能拆出來搬進自己的工作流，光並行派工跟 PR 證據化這兩段就夠本了。