メニュー
將一份需求規格拆成可執行任務（含驗收條件）。當使用者提供產品需求、功能規格或使用者故事時，將其分解成具體的開發任務。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | spec-to-tasks |
| description | 將一份需求規格拆成可執行任務（含驗收條件）。當使用者提供產品需求、功能規格或使用者故事時，將其分解成具體的開發任務。 |
本技能旨在將複雜的、高層次的需求規格轉化為一系列具體的、可執行的開發任務，每個任務都配有明確的驗收條件。
artifacts.write_text（可選，用於將任務清單寫入檔案）仔細閱讀使用者提供的需求文件，並完成以下分析：
分析清單:
將大的需求分解為邏輯上獨立的功能模組。每個模組應該代表一個可以獨立開發和測試的功能單元。
分解原則:
對於每個功能模組，進一步細分為具體的開發任務。任務應該足夠小，使得一個開發者可以在 1-5 天內完成。
任務定義原則:
為每個任務編寫清晰、可量化、可驗證的驗收條件。驗收條件應該使用「Given-When-Then」的格式（BDD 風格）或簡單的檢查清單。
驗收條件範例:
任務: 實現使用者登入功能
驗收條件:
1. Given: 使用者在登入頁面
When: 輸入有效的電子郵件和密碼，點擊「登入」按鈕
Then: 使用者被重定向到首頁，並看到個人化的歡迎訊息
2. Given: 使用者在登入頁面
When: 輸入無效的密碼，點擊「登入」按鈕
Then: 顯示錯誤訊息「密碼不正確」，使用者留在登入頁面
3. Given: 使用者在登入頁面
When: 輸入不存在的電子郵件，點擊「登入」按鈕
Then: 顯示錯誤訊息「使用者不存在」，使用者留在登入頁面
4. 登入成功後，使用者的會話應該被記錄在伺服器端
5. 登入頁面應該在 2 秒內載入完成
分析任務之間的依賴關係，並確定合理的執行順序。
依賴關係分析:
為每個任務提供粗略的工作量估算，幫助團隊進行計劃。
估算方法:
將所有信息整理成一份結構化的任務清單，可以是 Markdown、JSON 或其他格式。
任務清單格式範例:
# 專案任務清單
## 模組 1: 使用者認證系統
### 任務 1.1: 實現使用者登入功能
- **描述**: 開發一個登入頁面和後端認證邏輯
- **優先級**: 高
- **依賴**: 無
- **工作量估算**: 5 天
- **驗收條件**:
- [ ] 使用者可以使用電子郵件和密碼登入
- [ ] 無效的認證信息會顯示錯誤訊息
- [ ] 成功登入後，使用者會被重定向到首頁
- [ ] 登入頁面在 2 秒內載入完成
- [ ] 單元測試覆蓋率 > 80%
### 任務 1.2: 實現使用者註冊功能
- **描述**: 開發一個註冊頁面和後端邏輯
- **優先級**: 高
- **依賴**: 無
- **工作量估算**: 4 天
- **驗收條件**:
- [ ] 使用者可以使用電子郵件和密碼註冊
- [ ] 系統驗證電子郵件格式和密碼強度
- [ ] 重複的電子郵件會被拒絕
- [ ] 註冊成功後，使用者被自動登入
## 模組 2: 使用者資料管理
### 任務 2.1: 實現使用者資料編輯功能
- **描述**: 允許使用者編輯其個人資料
- **優先級**: 中
- **依賴**: 任務 1.1（使用者必須先登入）
- **工作量估算**: 3 天
- **驗收條件**:
- [ ] 使用者可以編輯其名稱、電子郵件、電話號碼
- [ ] 修改被保存到資料庫
- [ ] 使用者可以上傳個人頭像
- [ ] 修改後顯示成功訊息
保持需求的完整性: 確保沒有遺漏任何隱含的需求。如果不確定，應該向使用者提出澄清問題。
優先考慮使用者價值: 首先實現對使用者最有價值的功能，而不是技術上最簡單的功能。
避免過度設計: 任務應該足夠具體，但不應該規定實現的細節。留出開發者的靈活性。
考慮技術債務: 識別可能產生技術債務的任務，並在計劃中考慮償還時間。
包含非功能需求: 不要忘記性能、安全性、可用性等非功能需求。
定期審查和調整: 隨著項目進展，任務清單可能需要調整。保持清單的動態性。
清晰的溝通: 確保所有利益相關者（開發者、產品經理、測試人員）都理解任務的內容和驗收條件。
在使用者要設計網站、Web App 或元件介面時使用。常見觸發像「做 landing page」「設計 dashboard」「規劃 component UI」。輸出可上線介面與設計系統；不取代產品策略或純品牌研究。
在使用者要把模糊想法整理成可開發 spec 時使用。常見觸發像「整理需求成 spec」「補驗收條件」「拆分階段開發計畫」。輸出技術規格、白話規格與可直接貼用於 Codex / Claude Code 的分階段 instructions；不直接代替正式文件發布。
在非程式開發者要用 vibe coding 與 coding agent 協作時使用。常見觸發像「幫我整理開發準則」「定義交付邊界」「規劃驗證方式」。輸出需求表達、邊界與風險控管準則；不直接取代實作。
當使用者要拆解大型、混亂、跨部門、反覆卡關或高不確定性的難題，或明確要求做問題拆解、issue tree、根因與對策分層時使用。先分清楚現象、目標落差、真正問題與根因假設，再判斷問題是範疇型、分析型、動態系統型、研究型或交付型，最後用 issue tree/MECE、WBS、系統思考、驗收標準、依賴排程、資源分派與流動指標，產出可執行的問題拆解報告、工作包、關鍵路徑、並行策略與 PDCA 回饋節奏。
當使用者要替代解法、不同思路、更簡單或更穩定做法時使用。將現有方案重構成結構問題，提出多條可落地方案與最低摩擦解。
建立定期任務（每日晨報、每週回顧）。當使用者需要設定自動化的、定期執行的任務時使用。