取得任務
概述
get-tasks 將已核准的 PRD 轉換為一組可執行的任務。每個任務都會寫入自己的檔案，大小適合一個專注的工作階段，按依賴關係排序，並附帶驗收標準、驗證步驟、阻擋列表和回滾程序。
這個技能之所以獨立存在，是因為：PRD 不是一個計劃。PRD 說明系統做什麼以及為什麼做。它完全沒有提及工作順序、哪些部分可以平行建構、風險點在哪裡，或者如何證明某個切面已完成。將 PRD 直接轉換成程式碼，不是產生一個英雄式的單次變更，就是一個任意順序，然後在中途失敗。
get-tasks 提供了缺失的層面。它讀取 PRD，繪製真實的依賴結構，將工作切割成垂直切面，並將每個切面寫成一個獨立的工件，讓代理（或人類）無需重新閱讀整個 PRD 即可接手。
此技能借鑒了三個來源：
- 依賴優先分解與垂直切割 — 建立依賴圖，進行垂直而非水平切割，調整每個任務的大小，並設置檢查點。這確保了正確的順序。
- 驗證驅動的執行 — 每個任務都宣告如何透過多種驗證類型來驗證，而不僅僅是「測試通過」，並包含當步驟失敗時的重規劃程序。
- 阻擋邊界與追蹤子彈 — 每個任務都明確說明它被什麼阻擋，因此任何其阻擋者已完成的任务都可以立即開始。
輸出是一個任務檔案目錄：tasks/<name>/task-01.md、task-02.md，依此類推，按依賴順序編號，加上 tasks/<name>/plan.md 作為索引。阻擋任務會獲得較低的編號。
本技能的範圍
get-tasks 刻意設計得全面。它吸收了幾個較窄技能各自部分完成的內容，以便使用者只需一個技能就能從核准的 PRD 過渡到可追蹤、可執行的計劃。此處的所有內容都與這個單一任務相關：
| 關注點 | 處理位置 |
|---|---|
| 讀取 PRD 並提取承諾 | 階段 1 |
| 依賴結構與排序 | 階段 2 |
| 垂直切割與追蹤子彈 | 階段 3 |
| 大規模重構（擴展、遷移、收縮） | 階段 3 |
| 每個任務的規格 | 階段 4 |
| 大小調整與分割規則 | 階段 5 |
| 檢查點與閘門 | 階段 5 |
| 平行化分類 | 平行化分類法 |
| 人類可讀的計劃摘要、風險、決策 | 階段 6 |
| 追蹤器 vs. 檔案目標 | 任務清單目標 |
| 寫入前使用者核准 | 階段 7 |
| 寫入、同步與驗證工件 | 階段 8 |
| 處理失敗與重新規劃 | 任務失敗時重新規劃 |
它故意設計得很長。長度就是重點：任何一個遺漏了這些項目的分解，都會產生看似完成但實際上並未完成的任務。如果你傾向於略讀到模板，請改為閱讀階段 2、3 和 5——這些才是分解實際上會失敗的地方。
本技能不做的事：它不編寫程式碼，不執行任務，也不取代 PRD。它將一份文件轉換為一組文件。
何時使用
在以下情況使用此技能：
- 存在 PRD、規格或需求文件，且工作需要轉換為可執行的任務
- 使用者說「get tasks」、「breakdown PRD」、「pecah jadi task」、「bikin task list」或「turn this into tasks」
- 任務感覺太大而無法開始，需要分解
- 你需要估計範圍、排序工作，或找出可以平行進行的部分
- 你即將開始實作會觸及多個檔案的事項，且尚無任務清單
何時不使用：
- 尚無 PRD — 先執行
get-prd，然後再回來 - 變更從任何角度來看都是一個單一任務（一個檔案，一個明顯的編輯）— 直接做就好了
- 完整的任務分解已存在於
tasks/中，且你已準備好開始實作 — 直接按順序執行任務
流程
get-tasks 分為九個階段運行。每個階段都有退出條件。在條件未滿足之前，不要進入下一個階段。
0. 定位 PRD -> 哪個文件是來源？
1. 讀取並提取 -> PRD 承諾我們要做什麼？
2. 依賴圖 -> 什麼依賴什麼？
3. 垂直切面 -> 追蹤子彈，而非水平層
4. 撰寫每個任務 -> 每個任務一個檔案，完全指定
5. 排序、大小調整、檢查點 -> 順序、大小和驗證閘門
6. 撰寫計劃文件 -> 索引任務的人類可讀摘要
7. 詢問使用者 -> 粒度、阻擋邊界、合併或分割
8. 寫入並驗證 -> 磁碟上的檔案，待辦事項已同步，驗證器綠色
任務分解的通用原則
- 自然語言節奏： 以使用者使用的語言（印尼語或英語）呈現分解和對話式摘要，同時保持檔案名稱、git 術語和程式碼記號為標準形式（
task-01.md、branch、commit、TDD）。 - 可自主執行： 在
tasks/<feature>/task-*.md中生成的每個任務檔案都必須完全自包含。任何一個編碼代理都應該能夠只閱讀該單一任務檔案，就知道要編輯哪些檔案、執行哪些測試，以及必須滿足哪些完成條件，而無需猜測。 - 優先垂直切割而非水平層： 切勿建立純粹是「設定後端」或「設定前端」的任務，如果它們無法端到端驗證的話。垂直切割（例如「儲存和查詢 SKU 端點與 UI 觸發器」），以便每個任務都能提供可測試的價值。
規劃是唯讀的。 階段 0 到 7 只產生文件和問題，不產生程式碼。在這些階段期間，請勿建立、編輯或刪除任何原始碼檔案。在使用者核准之前，僅允許在 tasks/ 下寫入任務檔案。如果你在分解工作時發現自己在修復錯誤或新增函數，請停下來：這屬於核准後的實作階段，並且屬於你尚未撰寫的任務。
階段 0：定位 PRD
在執行任何其他操作之前，先找到來源文件。
- 依慣例優先。
get-prd儲存到docs/prd/<name>.md。先查看那裡。 - 然後擴大搜尋。 如果
docs/prd/是空的，請尋找使用者命名的 PRD。接受問題主體或貼上的需求文件——此技能不受格式限制，只有階段 1 中的提取會假設 PRD 章節名稱。 - 如果有多個候選文件，不要猜測。列出它們並詢問哪個文件管轄此工作。
- 如果沒有任何文件存在，請停下來並說明原因。不要發明需求。引導使用者執行
get-prd以進行完整的訪談到 PRD 的過程。
記錄你正在處理的確切路徑。後續的每個階段都會引用它。
對於一個多模組的專案，如果 PRD 按模組 id 分割（docs/prd/identity.md、docs/prd/billing.md），請確認此分解涵蓋哪個模組。每個模組一個分解，按照能力圖宣告的建構順序進行。
退出條件： 已識別出單一來源文件，並且其路徑已記錄在案。
階段 1：讀取並提取
完整閱讀 PRD。然後，明確提取驅動分解的內容：
| PRD 章節 | 你從中提取的內容 |
|---|---|
| 目標 | 每個任務最終服務的最終狀態 |
| 使用者故事 | 必須可行的可觀察行為，候選驗收標準 |
| 技術決策 | 模組、介面、架構變更、合約——這些定義了任務之間的實際邊界 |
| 專案結構 | 工件存放位置，這限制了「可能觸及的檔案」 |
| 指令 | 每個任務將引用的具體驗證指令 |
| 測試策略 | 什麼是好的測試，以及測試應放在哪裡 |
| 邊界 | 總是 / 先詢問 / 絕不 — 絕不項目會成為每個任務的硬性限制 |
| 超出範圍 | 明確的非目標；這裡沒有任何東西會成為任務 |
| 成功標準 | 最終閘門；最後一個檢查點會根據它進行驗證 |
規則：
- 現在還不要開始分割。 先提取，再分解。邊閱讀邊分割會產生根據你閱讀文件的順序來塑造的任務。
- 將模糊的項目轉換為可檢查的陳述。 如果 PRD 說「儀表板應該很快」，任務的驗收標準就應該是一個數字，如果 PRD 沒有給出數字，則應將其作為阻擋事項提出，而不是默默地選擇一個數字。
- 標記缺口。 如果某個需要的章節缺失或為空，請命名它。缺少測試策略意味著每個任務的驗證區塊將在之後被發明出來；現在就提出來。
- 絕不發明需求。 如果 PRD 沒有說，它就不是一個任務。
退出條件： 提取表已填入，並且任何缺口都已向使用者提出。
階段 2：繪製依賴圖
在撰寫任何任務之前，先繪製什麼依賴什麼。這是決定順序並防止最昂貴的錯誤類型的階段：在生產者存在之前就建構消費者。
繪製圖表。具體，而非抽象：
資料庫架構
|
+-- API 模型和型別
| |
| +-- API 端點
| | |
| | +-- 前端 API 客戶端
| | |
| | +-- UI 元件
| |
| +-- 驗證邏輯
|
+-- 種子資料和遷移
規則：
- 邊線指向生產者到消費者。 箭頭表示「目標需要先有來源」。
- 無循環。 如果兩個東西互相需要，它們就是一個任務，或者必須先將它們之間的介面定義為一個獨立的任務。
- 介面即邊界。 當兩個任務在一個合約（型別、端點形狀、架構）處相遇時，在較早的任務中定義合約，並在較晚的任務中使用它。切勿讓兩個任務獨立發明它。
- 找到前緣。 前緣是所有阻擋者都已完成的任务。這是現在可以開始的事項。對於線性鏈，前緣只有一個任務寬；對於大型專案，它可能有好幾個。
- 命名平行機會和硬序列。 獨立的切面可以平行進行。遷移、共享狀態變更以及任何觸及相同合約的事項都必須按順序進行。
退出條件： 依賴圖已存在，具有清晰的前緣，且無循環。
階段 3：垂直切割
將工作切割成追蹤子彈：穿過該功能所需的每個層級的狹窄但完整的路徑。
水平切割是預設的錯誤。 它看起來整齊，但直到最後一個任務才產生可運行的東西：
錯誤（水平）：
任務 1：建立整個資料庫架構
任務 2：建立所有 API 端點
任務 3：建立所有 UI 元件
任務 4：連接所有東西
在任務 3 結束時，沒有任何東西能運作。沒有人可以展示任何東西。任務 1 中的錯誤假設在任務 4 中才被發現。
垂直切割在每一步都會產生可運作的軟體：
正確（垂直）：
任務 1：使用者可以建立帳戶 （註冊的架構 + API + UI）
任務 2：使用者可以登入 （驗證的架構 + API + UI）
任務 3：使用者可以建立任務 （任務的架構 + API + UI）
任務 4：使用者可以查看任務清單 （查詢 + API + 清單檢視的 UI）
一個好的切面的規則：
- 它穿過該行為所需的每個層級 — 資料、邏輯、介面、測試。
- 它可以獨立展示或驗證。 如果你無法描述如何確認它有效，那它就不是一個切面。
- 它適合一個專注的工作階段 — 大約一個全新的上下文視窗。
- 它提供行為，而不是結構。 「新增使用者資料表」不是一個切面；「使用者可以註冊」才是。
大規模重構是例外。 大規模重構是一種機械性的變更（重新命名欄位、重新鍵入共享符號），其影響範圍遍及整個程式碼庫，因此沒有任何垂直切面可以順利通過。不要強迫它變成追蹤子彈。將其排序為擴展、遷移、收縮：
- 擴展 — 在舊的旁邊添加新的形式，這樣什麼都不會中斷。
- 遷移 — 按影響範圍批次（按套件、按目錄）移動呼叫端，每個批次都是一個獨立的任務，被擴展任務阻擋，並且由於舊形式仍然存在，因此批次之間能保持建構綠色。
- 收縮 — 當不再有呼叫者時刪除舊形式，這是被每個遷移批次阻擋的任務。
即使批次本身無法單獨保持綠色，也請保持相同的順序，但讓它們共享一個整合分支，該分支所有批次都阻擋一個最終的整合與驗證任務，其中保證綠色。
退出條件： 每一項工作都恰好屬於一個任務，並且每個任務都是一個垂直切面或一個宣告的大規模重構步驟。
階段 4：撰寫每個任務
將每個任務寫入自己的檔案。始終是一個任務一個檔案——絕對不要使用包含所有任務的單一組合文件。
輸出路徑： tasks/<name>/task-NN.md，其中 <name> 與 PRD 的名稱相符（因此位於 docs/prd/billing.md 的 PRD 會產生 tasks/billing/task-01.md）。從 01 開始編號，按依賴順序——阻擋任務獲得較低的編號。
任務檔案模板：
# 任務 NN：<簡短描述性標題>
**來源：** docs/prd/<name>.md — <此任務實作的 PRD 章節>
**要建構的內容：** 此任務使能運作的端到端行為，從使用者的角度來看。不是按層次劃分的實作清單。如果你無法將其描述為使用者或呼叫者可以觀察到的行為，請重新調整任務。
## 驗收標準
- [ ] <特定、可測試的條件>
- [ ] <特定、可測試的條件>
每個標準都必須可以由未撰寫該任務的人檢查。「正常運作」不是一個標準。「使用者可以使用電子郵件和密碼註冊，並被重新導向到儀表板」才是。
## 驗證
- [ ] 測試通過：<儲存庫的聚焦測試指令或要先撰寫的新測試>
- [ ] 建構成功：<儲存庫的建構指令>
- [ ] 輸出相符：<預期的模式或必須存在的工件>
- [ ] 無回歸：<完整測試套件或相關子集>
- [ ] 品質與安全性：<輸入驗證、認證邊界、遵循……
……（由於原文截斷，此處結尾不完整，但翻譯會忠於原文格式）