任務拆分 是做什麼的？
將設計轉化為團隊中任何工程師都能獨立接取、完成並合併的 1 故事點待辦事項清單。
輸入
$ARGUMENTS
- 如果提供了路徑，則讀取該文件。
- 否則，使用此對話或磁碟上最新的 RFC 或來自生產力思考會議的
*.notes.md檔案。這些通常是本地的、未追蹤的檔案（請在 git 忽略的資料夾中尋找，例如.rfcs/，然後是docs/rfcs/、docs/adr/、rfcs/）。如果找不到，請詢問要拆分哪個文件或設計。 - 如果來源文件存在會阻礙拆分的缺口（例如未選擇的設計、沒有推出方法），請列出這些缺口並在編造答案前先詢問。較小的缺口可以改為創建探索型任務。
「1 故事點」的定義
當一個任務全部符合以下條件時，它才是 1 點。如果有一項不符合，就將其拆分：
- 一人、大約一天或更少，包含測試與審查修正。
- 一個可審查的 PR，具有單一目的。審查者無需閱讀其他未合併的 PR 就能理解。
- 可獨立合併。 合併後主線保持綠色且可發布，這通常意味著新行為位於功能開關之後或尚未串接。
- 可測試。 它包含 1–5 個非作者也能檢查的驗收標準。
- 無隱藏未知項。 如果實作者必須先研究才能知道該做什麼，那它是一個探索型任務，而非故事。
如果團隊有自己的點數定義，請遵循他們的定義，並在輸出頂部註明。
如何拆分
在拆分之前先閱讀程式碼：確認每個任務所觸及的檔案、模組、架構與測試確實存在，並在任務中明確指出它們的名稱。引用真實路徑的任務會更常被接取；模糊的任務則會滯留在待辦事項中。
從可步行骨架開始：最薄的端到端切片，能證明設計在生產環境中可行（通常放在功能開關後），然後再將其加厚。這樣做能將風險提前暴露，而不是等到最後一個任務才發現整合問題。
當一個任務太大時，以下拆分方法通常有效：
- 準備，然後變更。 先抽出純粹的重構（「讓變更變得容易，然後進行容易的變更」），並在重構前用測試鎖定當前行為。
- 擴展 / 遷移 / 收縮 用於架構與 API 變更：添加新欄位或端點、回填或雙重寫入、切換讀取，然後移除舊路徑。每個階段都是一個獨立的任務。
- 按功能開關後的層級：資料模型 → 服務邏輯 → API → UI，每個都可獨立合併，因為開關是關閉的。
- 先讀取路徑再寫入路徑，以及先快樂路徑再處理邊界案例與錯誤處理。
- 按變體：在第一個任務建立模式後，每個提供者、檔案類型或用戶端各一個任務。
- 用於未知項的探索型任務：設定時間盒（≤ 1 天），產出是決策加上後續的任務，而非生產程式碼。為每個探索型任務設定一個有答案的
問題：與時間盒。依賴於該決策的任務僅在安全的範圍內進行拆分，並附上備註說明待探索型任務決定後將再細化。將探索型任務放在前面：它們會阻塞其後的所有工作。
不要遺漏非功能程式碼的工作：功能開關的設定與移除、指標/警報/儀表板、Runbook 或文件更新、資料回填、分階段推出步驟，以及清理舊路徑。這些通常是「快完成了」的專案停滯不前的原因。
不要為了拆分而拆分：一個只有與另一個任務合併在一起才有意義的任務，應該合併為一個任務，或者應該沿著不同的界線重新切割這對任務。
輸出
- 使用 templates/tasks.md 將待辦事項清單寫入來源 RFC 旁邊的
<rfc-name>.tasks.md檔案。像 RFC 一樣，它是一個本地工作檔案，預設為未追蹤；如果其資料夾尚未被 git 忽略，請將其添加到.git/info/exclude。將任務編號為T-01、T-02……以便相依性可以引用它們，將所有狀態設為open，並填寫用於分支名稱的專案 slug。保持欄位名稱與模板完全相同，因為/implement-task和/deliver-project會讀取它們。 - 將任務分組到與 RFC 階段相符的里程碑中，每個里程碑都以可演示或可發布的結果結束。
- 包含相依性圖：哪些任務可以並行執行，以及關鍵路徑。當任務超過約 8 個時，一個小的 Mermaid 圖表會很有用。
- 在對話中提供一個簡短摘要：每個里程碑的任務數量、有多少可以立即開始、關鍵路徑、探索型任務，以及任何您不確定是否真的是 1 點數的任務。請用戶標記看起來太大、太小或順序錯誤的任務，並進行修改。
- 發布到團隊的追蹤系統。 假設團隊使用一個（Linear、Jira、GitHub Issues……）。一旦用戶對拆分結果感到滿意，提議透過已連接的追蹤工具進行發布；如果沒有連接任何工具，請說明哪種連接器會有幫助，並提供一個包含欄位
ID, 標題, 描述, 驗收標準, 故事點數, 里程碑, 依賴於, 標籤的 CSV 作為備用方案。僅在用戶確認後才發布，因為它對整個團隊是可見的。對於每個任務，建立一個議題（Issue），其中包含標題、一個獨立的描述（上下文、範圍、檔案、超出範圍、驗收標準）、估計值為 1、里程碑，以及若追蹤系統支援則設定阻塞關係的相依性。然後將每個議題的 ID 與連結寫入本地檔案中任務的追蹤器：欄位。 - 指向下一步：
/implement-task <任務-ID>用於單個任務，/spike-task <任務-ID>用於探索型任務，或/deliver-project <任務檔案>用於讓一群代理執行整個待辦事項清單。
如果來源 RFC 有執行計畫章節，請更新它以連結任務檔案，而不是重複列出清單。
探索型任務後的細化
當收到一個已決策的探索型任務的決策記錄（狀態為 decided）時，請更新待辦事項清單，而不是從頭開始：
- 套用記錄中批准的待辦事項變更：添加任務（繼續使用
T-NN編號，絕不重複使用 ID）、更改受影響任務的範圍、標準或相依性，並將已移除的任務標記為canceled並附上原因，而不是刪除它們。 - 重新檢查每個已更改或新的任務是否符合 1 點測試，並更新摘要、相依性圖與關鍵路徑。
- 更新記錄中列出的 RFC 章節。
- 同步追蹤系統：建立新的議題，更新已變更的議題，並取消已移除的議題，將新的金鑰寫入任務檔案中。如果用戶已一起批准了決策及其待辦事項變更，則此批准涵蓋同步；否則請先確認。
- 將探索型任務設為
done並用幾行字總結變更內容。