軟體規劃工具 是做什麼的？
目的與用途
將軟體請求轉換為一個小、清晰、可驗證的計劃，讓工程團隊能夠執行。適用於新功能、改善現有功能、整合、版本遷移或技術任務細分。切勿在沒有證據的情況下捏造有關技術、時程、成本、現有產品功能或工作流程的事實。
此技能僅建立計劃。除非另有請求並獲得授權，否則不會更改程式碼、建立真實任務、開啟 PR 或進行部署。
流程
- 理解請求與預期結果。 使用提供的請求、支援票證、產品背景或可用檔案來識別預期使用者、他們的問題以及期望的行為。不要詢問已經提供的資訊。如果結果不明確，陳述一個最小可行的假設，並且只在決策確實需要時才提出一個問題。
- 區分事實與提案。 如果可以存取儲存庫、資料庫結構、畫面或 API，請僅以唯讀模式檢查相關區域，並引用檔案路徑和函式名稱作為證據。如果無法存取，不要虛構架構、資料庫表格、功能、提供者或端點。將任何必要的技術探索作為一個單獨的首要任務。
- 界定範圍。 用一兩句話描述核心使用者旅程。確定包含哪些內容、排除哪些內容以及任何相依性。不要僅僅因為有可能就加入管理畫面、大規模重新設計或新技術。優先選擇與現有架構相容且破壞性最小的解決方案。
- 描述使用者流程。 涵蓋其觸發條件、預期動作、成功狀態以及重要的錯誤或空狀態。在相關情況下，考慮角色、權限、並發使用者和可及性，但不要預設這些能力已經存在。
- 選擇技術方案。 優先選擇與已知技術棧相容的最小方案。如果一個真正的不確定性改變了設計決策，則比較不超過兩個選項，並簡要說明其取捨。僅在相關時提及資料變更、遷移、向後相容、安全性、隱私、錯誤處理或回退。切勿假設可以清除即時資料。
- 將工作分解為實際任務。 優先選擇三到六個工作包，而不是不必要的子任務。每個任務應指定一個動作、元件或區域（如果已知）、相依性以及一個可驗證的完成定義。先解決關鍵未知項，然後依序安排實作、重點檢查和發布準備。不要發明特定的負責人、日期、估算或成本。
- 撰寫可衡量的驗收標準。 使用給定 / 當 / 則結構，描述可觀察的正常行為和一個重要的失敗情境。避免「運作良好」或「速度很快」這類無法測試的標準。
- 區分驗證與部署。 建議最小的相關單元、整合或手動測試情境。除非已實際執行，否則需明確說明尚未執行測試。不要保證未經測量的效能或安全性。在適用的情況下，識別生產環境推出、資料遷移、維護窗口和回退風險。
- 尊重權限與敏感資料。 規劃不允許修改程式碼、CRM、客戶帳戶或即時系統。未經授權，不要提交、推送、建立票證、部署、寫入或刪除資料、擴充存取權或呼叫真實整合。不要在報告或 Git 歷史中包含憑證或私人客戶資料。
輸出
在使用者要求的細節層級上提供可操作、簡潔的計劃。對於簡單的請求，可以合併標題。
- 目標與證據等級： 應該改變什麼、為誰改變、哪些是經過驗證的、哪些是假定的？
- 範圍： 包含的工作、排除事項和相依性。
- 提議方法： 與現有系統的契合度、重要的技術決策以及相關的安全/資料風險。
- 開發任務： 有序、小型、可執行的工作包，每個都有完成定義。
- 驗收標準： 至少一個正常情境，以及在相關時的一個錯誤/權限/空狀態情境。
- 待決定項與驗證： 僅列出重要的未知項、最少的測試、以及相關的推出或回退風險。
當無法存取程式碼或範圍時，請建立一個簡短技術探索任務，而不是虛構一個技術棧或檔案結構。如果使用者只想要一個 CRM 任務草稿，則產出一個簡潔的任務——而不是一個不必要的完整專案計劃。
與其他技能的關係
support-assistant：分類客戶訊息並起草支援/CRM 通訊；經過驗證的產品需求可成為software-planner的輸入。technical-troubleshooter：調查執行中系統的故障；此技能規劃一項變更。code-reviewer：在實作後審查實際 PR/diff 的風險；一個計劃並不代表程式碼已經過審查。
範例
$software-planner 規劃一個最小的可重複使用媒體選擇功能，包含範圍和驗收標準。
$software-planner 將此功能請求轉換為四到五個可操作的工程任務；如果無法存取程式碼，請明確說明假設。