to-ticketslisted

# 拆解為 Tickets 把計畫、規格說明或對話，拆成一組**tickets**——曳光彈垂直切片，每個都宣告**阻塞**它的 tickets。 Issue 追蹤器與分診標籤詞彙應該已經提供給你——如果沒有，執行 `/setup-matt-pocock-skills`。 ## 流程 ### 1. 收集上下文 從對話上下文中已有的內容出發。如果使用者以參數傳入一個參考（規格說明路徑、issue 編號或 URL），就把它取來，讀取它的完整內文與評論。 ### 2. 探索程式碼庫（選用） 如果你還沒探索過程式碼庫，就去探索，以了解程式碼目前的狀態。Ticket 標題與描述應該使用專案的領域詞彙表詞彙，並尊重你接觸區域的 ADR。 尋找預先重構程式碼的機會，讓實作更容易。「先讓改動變容易，再做容易的改動。」 ### 3. 草擬垂直切片 把工作拆成**曳光彈** tickets。 <vertical-slice-rules> - 每個切片在每一層（schema、API、UI、測試）中切出一條狹窄但**完整**的路徑——是垂直的，而**不是**單一層的水平切片 - 完成的切片可以獨立展示或驗證 - 每個切片的大小要能放進單一的乾淨上下文視窗 - 任何預先重構都應該先做 </vertical-slice-rules> 給每個 ticket 它的**阻塞邊**——必須先完成才能開始的其它 tickets。沒有阻塞者的 ticket 可以立即開始。 **大範圍重構是垂直切片的例外。** **大範圍重構**是單一的機械式變更——重新命名欄位、重新標記共享符號——其**影響半徑**擴散到整個程式碼庫，因此單一次編輯會同時破壞數千個呼叫點，任何垂直切片都無法保持綠燈。別硬塞進曳光彈；把它排成**擴展–收縮**。先擴展：在舊形式旁邊加入新形式，讓什麼都不破壞。然後依影響半徑分批遷移呼叫點（每個套件、每個目錄一批），每批是自己的一張 ticket、被擴展所阻塞，並因為舊形式仍然存在而讓 CI 一批接一批保持綠燈。最後收縮：一旦沒有呼叫者留下，就刪除舊形式，放在一張被每個遷移批次阻塞的 ticket 中。當連批次都無法單獨保持綠燈時，保留這個順序，但讓它們共享一條集成分支，而全部批次都阻塞一張最終的整合與驗證 ticket——只有在那裡才保證綠燈。 ### 4. 詢問使用者 把建議的拆解呈現為編號清單。每個 ticket 顯示： - **標題**：簡短具描述性的名稱 - **阻塞於**：哪些其它 tickets（如果有的話）必須先完成 - **交付內容**：這張 ticket 讓之運作的端對端行為 詢問使用者： - 粒度感覺對嗎？（太粗／太細） - 阻塞邊正確嗎——每張 ticket 是否只依賴真正阻擋它的 tickets？ - 應該再合併或拆分任何 tickets 嗎？ 反覆調整，直到使用者認可這個拆解。 ### 5. 把 tickets 發佈到設定的追蹤器 發佈被認可的 tickets。**怎麼發佈**取決於 `/setup-matt-pocock-skills` 所設定的追蹤器——兩種方式下 tickets 都相同，只有阻塞邊的形狀會改變： - **本機檔案** → 每個 ticket 在 `.scratch/<feature-slug>/issues/<NN>-<slug>.md` 下寫一個檔案，依依賴順序從 `01` 開始編號（阻塞者優先）。每個檔案的「Blocked by」列出它所依賴的編號／標題。使用下方的逐 t