sprint-plan
作者 phuryn使用 sprint-plan，將 backlog 轉成切實可行的 sprint 計畫，涵蓋容量估算、故事挑選、相依性對應與風險檢視。這個技能很適合專案管理情境，當你需要一份 sprint-plan 指南，協助篩掉尚未就緒的工作、在範圍與速度之間取得平衡，並以更少猜測完成 sprint planning。
這個技能的評分是 78/100，代表它已經足夠成熟，適合列入需要 sprint 規劃支援的目錄。它有明確的使用觸發、具體的規劃流程與實用的決策步驟，但若要降低導入時的猜測成本，仍可再補強支援素材與邊界情境說明。
- 觸發條件明確：前言清楚指出可用於 sprint planning、capacity estimation、story selection、dependency mapping 與 risk identification。
- 作業流程具體：將規劃拆成容量估算、待辦項目篩選、相依性對應，以及風險／緩解檢視。
- 對 agent 的引導效果佳：提供可直接執行的限制條件，例如 Definition of Ready 檢查、15-20% 的容量緩衝，以及在容量達標時停止。
- 未提供支援檔案或參考資料，因此使用者必須直接依賴 SKILL.md 的流程，缺少範例、範本或驗證輔助。
- 摘錄中的風險指引有截斷情況，且限制與實務指引的訊號量僅屬中等，因此部分執行細節仍可能需要自行判讀。
sprint-plan 技能總覽
sprint-plan 的作用
sprint-plan 技能可以幫你把零散的 backlog 轉成可落地的 sprint 計畫。它著重在容量估算、故事挑選、依賴關係梳理與風險檢視，讓你在 sprint 開始前就能判斷哪些工作真的排得進去。
適用對象
當你需要一次快速、結構化的規劃流程時，sprint-plan 很適合用在 Project Management 情境：例如 Scrum Master、PM、工程主管，或是根據 backlog 匯出檔、velocity 註記、團隊行事曆、前一個 sprint 資料來工作的 agent。
為什麼這個技能有用
一般的 prompt 常常只會列出一串 stories，卻不會檢查團隊到底能不能真的做完。sprint-plan 在需要做決策時更有價值：它會先確認 capacity、篩掉尚未就緒的工作，並及早找出阻礙因素。
最佳適用情境與限制
如果你已經有一些規劃輸入，例如優先順序、估點與可用性，這個技能就特別強。若你想做的是完整的 backlog grooming、roadmap planning，或是不受 sprint 限制的細部 task 拆解，sprint-plan 就沒那麼適合。
如何使用 sprint-plan 技能
安裝 sprint-plan
使用 npx skills add phuryn/pm-skills --skill sprint-plan 安裝 sprint-plan 技能。接著先開啟 pm-execution/skills/sprint-plan/SKILL.md，因為那裡定義了規劃流程，以及這個技能預期會拿到的上下文。
需要提供什麼
這個技能最適合搭配具體的規劃素材，而不是只丟一句「幫我排 sprint」。請提供 sprint 長度、團隊成員名單、PTO 或 on-call 覆蓋情況、最近的 velocity、已排序的 backlog、story points 或工時備註，以及任何已知的依賴或風險。
如何下提示詞更有效
好的 prompt 會清楚說明模型正在規劃哪一個 sprint，以及手上有哪些輸入資料。例如：Use sprint-plan to plan Sprint 24 for a 6-person team. Review this backlog, use the last 3 sprints of velocity, subtract PTO days, keep a 20% buffer, and call out any stories not ready for commitment.
建議工作流程
先把可用的來源檔案餵給這個技能，再要求它先估算 capacity、列出能放得進去的 stories，並整理依賴與風險摘要。若 backlog 很雜，先請它把已可承諾的 stories 和需要再釐清的候選項分開，不要太早逼它產出最後版本的計畫。
sprint-plan 技能 FAQ
sprint-plan 只適合 Scrum 團隊嗎？
不是。只要你需要一個有界限、受 capacity 限制的交付計畫，sprint-plan 都很有用，即使團隊沒有嚴格遵循 Scrum 典禮也一樣。若是開放式的 roadmap 工作，它的幫助就比較有限。
這跟一般 prompt 有什麼不同？
一般 prompt 也許能產出一份看起來合理的 sprint 清單，但 sprint-plan 的設計重點是一次同時檢查就緒度、capacity、依賴關係與風險。當你需要的是可重複的規劃流程，而不是一次性的答案時，它就更適合做安裝決策評估。
如果我沒有 velocity 資料怎麼辦？
你還是可以用 sprint-plan，改以團隊可用性和保守 buffer 來規劃，但結果的準確度會下降。如果缺少 velocity，請提供你手邊最接近的替代指標，例如最近完成的工作量，並請技能明確標示不確定性。
適合新手嗎？
可以，只要你能提供 backlog 和基本團隊背景就行。主要的失敗原因通常是輸入不完整，不是技能本身太複雜。
如何改進 sprint-plan 技能
提供更乾淨的規劃輸入
品質提升最大的地方，通常來自更好的來源材料。請提供已排序的 stories、驗收條件、估點、依賴關係與 owner；如果 backlog 條目太模糊，技能就得自己猜，通常最後會排出不切實際的計畫。
把容量限制說清楚
如果團隊有會議、PTO、突發支援或 on-call 工作，請一開始就講明。當 sprint-plan 能把這些限制換算成可用 capacity，而不是假設全員滿載可投入時，結果會明顯更準。
要它做決策，不只是摘要
第一次跑完後，可以要求它輸出最終承諾清單、尚未就緒清單，以及每個被排除項目的原因。這樣 sprint-plan 的結果會比泛泛的規劃總結更能直接拿來行動。
針對弱點反覆調整
如果結果太樂觀，就請它提高 buffer，並依風險重新排序 stories。若結果太保守，就問它哪些項目在依賴解除後可以替換進來。這是讓 sprint-plan 最快貼近你們團隊真實交付節奏的方法。