planning-and-task-breakdown
作者 addyosmaniplanning-and-task-breakdown 技能可將規格、功能需求或混亂的目標，整理成具明確相依關係與驗收標準、可依序執行的任務。它特別適合用於 Project Management、平行分工與範圍估算的 planning-and-task-breakdown，在實作前先降低判斷落差與不必要的猜測。
此技能獲得 78/100，代表它是相當穩健的目錄收錄候選：使用者能快速判斷何時該啟用，且 repo 提供了足夠的流程細節，相較一般提示詞更能減少摸索成本。對於規劃比重高的工作應該很有幫助，但實際使用時，仍需依自己的程式碼庫與任務型態調整流程。
- 觸發時機明確：說明清楚指出，當你手上有 spec、需要任務拆解、範圍估算，或要安排可平行進行的工作時，就適合使用。
- 操作流程具體：它會指示 agent 進入 plan mode、維持 read-only、梳理相依關係，並在開始寫程式前先產出計畫。
- 有助於安裝決策：內容篇幅充實、結構清楚，包含多個標題段落，顯示這不是占位用說明，而是真正提供工作流程指引。
- 未提供 install command、支援檔案或參考資料，因此是否採用幾乎完全仰賴 SKILL.md 的內容品質。
- 此技能偏向規劃與拆解工作；若只是單純的單檔修改，或任務本身已經界定清楚，相關性就較低。
planning-and-task-breakdown 技能總覽
planning-and-task-breakdown 技能能幫助 agent 把規格、功能需求，或是雜亂的目標，整理成一組有順序、可執行的任務。對於 planning-and-task-breakdown 的專案管理流程來說，當重點在範圍、相依性與執行順序，而不是立刻寫程式時，這個技能特別有用。它的核心工作很單純：在實作前先降低歧義，讓工作更容易估時、平行處理、驗證與交接。
這個技能最適合什麼情境
當你已有明確需求，但交付路徑仍然很大、很繞，請使用 planning-and-task-breakdown 技能。它很適合功能開發、多步驟重構、跨團隊協作，以及任何「順序一錯就要重做」的任務。若變更很小，而且實作路徑一目了然，這個技能就沒那麼必要。
它和一般提示詞有什麼不同
一般的「幫我拆解」提示詞，常常只會產出很空泛的條列。這個技能的設計重點是強迫模型做相依性映射、切出更小的任務規模，並明確寫出驗收條件。這樣輸出的內容才更像真正可執行的工作計畫，而不只是腦力激盪。
安裝前，讀者最在意什麼
使用者通常會想知道 planning-and-task-breakdown 技能到底能不能真的省時間、會不會把流程變得太重，以及它能不能幫 agent 避免太早開始寫程式。如果你想要的是先規劃、再動手，而且重視清楚的順序與可驗證任務，這個技能很適合。
如何使用 planning-and-task-breakdown 技能
planning-and-task-breakdown 的安裝與首次閱讀
先把 planning-and-task-breakdown 技能安裝到你的 skills manager，然後先打開 SKILL.md。在這個 repository 裡，沒有額外的 rules/、resources/ 或 scripts/ 資料夾，所以主要的權威來源就是技能檔本身。先讀這個檔案，理解規劃時的限制，再讓模型產出任務。
這個技能需要什麼輸入
請提供具體的規格、問題描述或目標，並附上周邊限制。好的輸入包括：
- 期望達成的結果
- 已知會用到的檔案或模組
- 時程、團隊邊界或技術棧限制
- 不能變動的部分
- 任何測試、發佈或審查需求
不好的輸入像是：「幫我規劃這個功能。」
好的輸入像是：「幫既有的 React app 規劃一個 dashboard filter 功能，保留目前的 URL routing，避免變更後端 schema，並且包含可測試的驗收條件。」
實際可行的規劃流程
先以唯讀方式使用這個技能。請它先檢視規格、辨識模式與相依性，並在寫任何程式之前先輸出計畫。好的 planning-and-task-breakdown 使用流程如下：
- 用一段話總結目標
- 要求相依性映射
- 要求列出任務順序與驗收條件
- 在實作前確認高風險假設
如果工作可以平行進行，就請技能把獨立任務和會卡住後續的任務分開。若範圍不夠清楚，就請它列出未知項與待決策點，不要自行猜測。
先看哪些檔案與訊號
在這個 repo 裡，SKILL.md 是第一個要讀的關鍵檔案。最重要的線索是「When to Use」指引、「Plan Mode」限制，以及 dependency-graph 步驟。這些內容會告訴你該怎麼構造提示詞，以及可以期待 planning-and-task-breakdown 技能產生什麼樣的輸出。
planning-and-task-breakdown 技能 FAQ
planning-and-task-breakdown 只適合大型專案嗎？
不完全是。它對中型與大型任務最有價值，但如果小需求背後藏著相依性或驗證步驟，它也一樣有幫助。若工作真的很小，而且很直觀，這個技能反而可能增加額外負擔。
這和單純要求一份任務清單有什麼不同？
planning-and-task-breakdown 技能比隨口列任務清單更嚴謹。它強調先讀再規劃、相依順序，以及明確的驗收條件。這使它更適合拿來執行，而不只是拿來發想。
這個技能對初學者友善嗎？
可以，只要使用者能清楚描述目標。初學者會受益，因為這個技能會強迫計畫說清楚先做什麼、什麼依賴什麼，以及什麼叫做「完成」。主要限制是，如果提問太模糊，產出的計畫還是會很弱。
什麼情況下不該用這個技能？
單檔修改、範圍很明確的工作，或是規格已經提供完整實作清單的情境，都不建議使用。這些情況下，先做規劃層反而可能拖慢交付，卻不會讓結果更好。
如何改進 planning-and-task-breakdown 技能
一開始就給更清楚的邊界
品質提升最大的關鍵，是輸入要更精準。請明確告訴模型哪些屬於範圍內、哪些不屬於範圍內，以及哪些部分不能變動。對於 Project Management 的 planning-and-task-breakdown 來說，這通常表示要點名利害關係人、順序限制與審查關卡，讓計畫更貼近現實。
要求相依性，不只是步驟
最常見的失敗模式，是只列出一份沒有順序邏輯的平面 checklist。你可以直接要求相依性映射、阻塞點，以及哪些項目可以平行進行，來改善結果。這樣產出的計畫，無論是人還是其他 agent 都更容易直接拿來執行。
加上驗收條件與風險註記
如果你想要真正可用的任務，請要求每個任務都要有清楚的完成條件，以及已知風險。輸入越扎實，任務切分通常越準，後面驚喜就越少。例子像是：「每個任務都要能獨立測試，註明任何 schema 或 API 相依性，並指出需要確認的假設。」
第一版之後要反覆調整
把第一次輸出當草稿，不要直接視為最終排程。若計畫切得太粗，就請它把任務拆得更細；若切得太細，就把相鄰項目合併；若順序看起來不對，就請技能在實作前重新檢查 dependency graph。