| name | to-tickets |
| description (EN) | Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published to the configured tracker (edges as text in one file per ticket locally, or native blocking links on a real tracker). |
| 說明 (繁中) | 把計畫、規格說明或目前的對話拆成一組曳光彈 tickets，每個都宣告自己的阻塞邊，發佈到設定的追蹤器——在本機是每個 ticket 一個檔案、以文字表示邊，或在真正的追蹤器上用原生阻塞連結。 |
| disable-model-invocation | true |
Break a plan, spec, or conversation into a set of tickets: tracer-bullet vertical slices, each declaring the tickets that block it.
把計畫、規格說明或對話，拆成一組tickets——曳光彈垂直切片，每個都宣告阻塞它的 tickets。
The issue tracker and triage label vocabulary should have been provided to you. If not, tell the user to run /setup-matt-pocock-skills.
Issue 追蹤器與分診標籤詞彙應該已經提供給你——如果沒有，執行 /setup-matt-pocock-skills。
Work from whatever is already in the conversation context. If the user passes a reference (a spec path, an issue number or URL) as an argument, fetch it and read its full body and comments.
從對話上下文中已有的內容出發。如果使用者以參數傳入一個參考（規格說明路徑、issue 編號或 URL），就把它取來，讀取它的完整內文與評論。
If you have not already explored the codebase, do so to understand the current state of the code. Ticket titles and descriptions should use the project's domain glossary vocabulary, and respect ADRs in the area you're touching.
如果你還沒探索過程式碼庫，就去探索，以了解程式碼目前的狀態。Ticket 標題與描述應該使用專案的領域詞彙表詞彙，並尊重你接觸區域的 ADR。
Look for opportunities to prefactor the code to make the implementation easier. "Make the change easy, then make the easy change."
尋找預先重構程式碼的機會，讓實作更容易。「先讓改動變容易，再做容易的改動。」
Break the work into tracer bullet tickets.
把工作拆成曳光彈 tickets。
Give each ticket its blocking edges: the other tickets that must complete before it can start. A ticket with no blockers can start immediately.
給每個 ticket 它的阻塞邊——必須先完成才能開始的其它 tickets。沒有阻塞者的 ticket 可以立即開始。
Wide refactors are the exception to vertical slicing. A wide refactor is one mechanical change (rename a column, retype a shared symbol) whose blast radius fans across the whole codebase, so a single edit breaks thousands of call sites at once and no vertical slice can land green. Don't force it into a tracer bullet; sequence it as expand–contract. First expand: add the new form beside the old so nothing breaks. Then migrate the call sites over in batches sized by blast radius (per package, per directory), each batch its own ticket blocked by the expand, keeping CI green batch to batch because the old form still exists. Finally contract: delete the old form once no caller remains, in a ticket blocked by every migrate batch. When even the batches can't stay green alone, keep the sequence but let them share an integration branch that all block a final integrate-and-verify ticket; green is promised only there.
大範圍重構是垂直切片的例外。 大範圍重構是單一的機械式變更——重新命名欄位、重新標記共享符號——其影響半徑擴散到整個程式碼庫，因此單一次編輯會同時破壞數千個呼叫點，任何垂直切片都無法保持綠燈。別硬塞進曳光彈；把它排成擴展–收縮。先擴展：在舊形式旁邊加入新形式，讓什麼都不破壞。然後依影響半徑分批遷移呼叫點（每個套件、每個目錄一批），每批是自己的一張 ticket、被擴展所阻塞，並因為舊形式仍然存在而讓 CI 一批接一批保持綠燈。最後收縮：一旦沒有呼叫者留下，就刪除舊形式，放在一張被每個遷移批次阻塞的 ticket 中。當連批次都無法單獨保持綠燈時，保留這個順序，但讓它們共享一條集成分支，而全部批次都阻塞一張最終的整合與驗證 ticket——只有在那裡才保證綠燈。
Present the proposed breakdown as a numbered list. For each ticket, show:
把建議的拆解呈現為編號清單。每個 ticket 顯示：
Ask the user:
詢問使用者：
Iterate until the user approves the breakdown.
反覆調整，直到使用者認可這個拆解。
Publish the approved tickets. How depends on the tracker /setup-matt-pocock-skills configured; the tickets are the same either way, only the shape of the blocking edges changes:
發佈被認可的 tickets。怎麼發佈取決於 /setup-matt-pocock-skills 所設定的追蹤器——兩種方式下 tickets 都相同，只有阻塞邊的形狀會改變：
.scratch/<feature-slug>/issues/<NN>-<slug>.md, numbered from 01 in dependency order (blockers first). Each file's "Blocked by" lists the numbers/titles it depends on. Use the per-ticket file template below: one ticket per file, never a single combined file.ready-for-agent triage label unless instructed otherwise; the tickets are agent-grabbable by construction..scratch/<feature-slug>/issues/<NN>-<slug>.md 下寫一個檔案，依依賴順序從 01 開始編號（阻塞者優先）。每個檔案的「Blocked by」列出它所依賴的編號／標題。使用下方的逐 ticket 檔案範本——每個檔案一張 ticket，絕不合成單一檔案。ready-for-agent 分診標籤——這些 tickets 天生就可供代理認領。Work the frontier: any ticket whose blockers are all done. For a purely linear chain that means top to bottom.
處理前沿：任何阻塞者都已完成的 ticket。對純線性的鏈條而言，這表示從上到下。
Do NOT close or modify any parent issue.
不要關閉或修改任何父 issue。
What to build: the end-to-end behaviour this ticket makes work, from the user's perspective, not a layer-by-layer implementation list.
Blocked by: the numbers/titles of the tickets that gate this one, or "None (can start immediately)".
Status: ready-for-agent
要建置什麼： 這張 ticket 讓之運作的端對端行為，從使用者的視角出發——不是逐層的實作清單。
阻塞於： 阻擋這張票的 tickets 的編號／標題，或「無——可以立即開始」。
狀態： ready-for-agent
A reference to the parent issue on the tracker (if the source was an existing issue, otherwise omit this section).
The end-to-end behaviour this ticket makes work, from the user's perspective, not layer-by-layer implementation.
追蹤器上父 issue 的參考（如果來源是既有 issue，否則省略這個區段）。
這張 ticket 讓之運作的端對端行為，從使用者的視角出發——不是逐層的實作。
In either form, avoid specific file paths or code snippets: they go stale fast. Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it and note briefly that it came from a prototype. Trim to the decision-rich parts, not a working demo, just the important bits.
無論哪種形式，都避免具體的檔案路徑或程式碼片段——它們很快就會過時。例外：如果原型產出了一個比散文更能精確編碼決策的片段（狀態機、reducer、schema、型別形狀），就把它內嵌進去，並簡短註明它來自原型。只保留富含決策的部分——不是可運作的示範，只是重要的片段。