القائمة
將一份需求規格拆成可執行任務（含驗收條件）。當使用者提供產品需求、功能規格或使用者故事時，將其分解成具體的開發任務。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
在使用者要設計網站、Web App 或元件介面時使用。常見觸發像「做 landing page」「設計 dashboard」「規劃 component UI」。輸出可上線介面與設計系統；不取代產品策略或純品牌研究。
在使用者要把模糊想法整理成可開發 spec 時使用。常見觸發像「整理需求成 spec」「補驗收條件」「拆分階段開發計畫」。輸出技術規格、白話規格與可直接貼用於 Codex / Claude Code 的分階段 instructions；不直接代替正式文件發布。
在非程式開發者要用 vibe coding 與 coding agent 協作時使用。常見觸發像「幫我整理開發準則」「定義交付邊界」「規劃驗證方式」。輸出需求表達、邊界與風險控管準則；不直接取代實作。
當使用者要拆解大型、混亂、跨部門、反覆卡關或高不確定性的難題，或明確要求做問題拆解、issue tree、根因與對策分層時使用。先分清楚現象、目標落差、真正問題與根因假設，再判斷問題是範疇型、分析型、動態系統型、研究型或交付型，最後用 issue tree/MECE、WBS、系統思考、驗收標準、依賴排程、資源分派與流動指標，產出可執行的問題拆解報告、工作包、關鍵路徑、並行策略與 PDCA 回饋節奏。
當使用者要替代解法、不同思路、更簡單或更穩定做法時使用。將現有方案重構成結構問題，提出多條可落地方案與最低摩擦解。
建立定期任務（每日晨報、每週回顧）。當使用者需要設定自動化的、定期執行的任務時使用。
| 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 天
- **驗收條件**:
- [ ] 使用者可以編輯其名稱、電子郵件、電話號碼
- [ ] 修改被保存到資料庫
- [ ] 使用者可以上傳個人頭像
- [ ] 修改後顯示成功訊息
保持需求的完整性: 確保沒有遺漏任何隱含的需求。如果不確定，應該向使用者提出澄清問題。
優先考慮使用者價值: 首先實現對使用者最有價值的功能，而不是技術上最簡單的功能。
避免過度設計: 任務應該足夠具體，但不應該規定實現的細節。留出開發者的靈活性。
考慮技術債務: 識別可能產生技術債務的任務，並在計劃中考慮償還時間。
包含非功能需求: 不要忘記性能、安全性、可用性等非功能需求。
定期審查和調整: 隨著項目進展，任務清單可能需要調整。保持清單的動態性。
清晰的溝通: 確保所有利益相關者（開發者、產品經理、測試人員）都理解任務的內容和驗收條件。