spec-to-tasks

name	spec-to-tasks
description	將一份需求規格拆成可執行任務（含驗收條件）。當使用者提供產品需求、功能規格或使用者故事時，將其分解成具體的開發任務。

需求規格拆解 (Specification to Tasks) 工作流程

本技能旨在將複雜的、高層次的需求規格轉化為一系列具體的、可執行的開發任務，每個任務都配有明確的驗收條件。

何時使用此技能

• 使用者提供了一份產品需求文件或功能規格（「請幫我把這份需求拆成任務」）
• 使用者提供了使用者故事或使用案例（「我想要實現 X 功能」）
• 使用者需要將一個大的專案分解為可管理的工作單位
• 使用者需要為開發團隊準備一份清晰的任務清單

工具需求

• 純文字處理（無需特定工具，主要依賴分析和結構化思維）
• artifacts.write_text（可選，用於將任務清單寫入檔案）

拆解工作流程

步驟 1: 理解和分析需求規格

仔細閱讀使用者提供的需求文件，並完成以下分析：

分析清單:

• 識別主要的功能模組和子功能
• 理解使用者的核心需求和痛點
• 識別系統邊界和相關的外部系統
• 找出隱含的需求（例如，性能要求、安全性考慮）
• 識別可能的依賴關係和優先級

步驟 2: 分解為功能模組

將大的需求分解為邏輯上獨立的功能模組。每個模組應該代表一個可以獨立開發和測試的功能單元。

分解原則:

• 每個模組應該有單一的責任
• 模組之間的耦合應該最小化
• 模組應該能夠獨立測試
• 優先考慮使用者可見的功能

步驟 3: 進一步細分為具體任務

對於每個功能模組，進一步細分為具體的開發任務。任務應該足夠小，使得一個開發者可以在 1-5 天內完成。

任務定義原則:

• 每個任務應該有明確的輸入和輸出
• 任務應該是可以獨立估算工作量的
• 任務應該有清晰的完成標準
• 避免過於細粒度的任務（例如，「修改一個變數名」）

步驟 4: 定義驗收條件 (Acceptance Criteria)

為每個任務編寫清晰、可量化、可驗證的驗收條件。驗收條件應該使用「Given-When-Then」的格式（BDD 風格）或簡單的檢查清單。

驗收條件範例:

任務: 實現使用者登入功能

驗收條件:
1. Given: 使用者在登入頁面
   When: 輸入有效的電子郵件和密碼，點擊「登入」按鈕
   Then: 使用者被重定向到首頁，並看到個人化的歡迎訊息

2. Given: 使用者在登入頁面
   When: 輸入無效的密碼，點擊「登入」按鈕
   Then: 顯示錯誤訊息「密碼不正確」，使用者留在登入頁面

3. Given: 使用者在登入頁面
   When: 輸入不存在的電子郵件，點擊「登入」按鈕
   Then: 顯示錯誤訊息「使用者不存在」，使用者留在登入頁面

4. 登入成功後，使用者的會話應該被記錄在伺服器端
5. 登入頁面應該在 2 秒內載入完成

步驟 5: 識別依賴關係和優先級

分析任務之間的依賴關係，並確定合理的執行順序。

依賴關係分析:

• 識別哪些任務必須在其他任務之前完成
• 識別可以並行執行的任務
• 根據業務優先級和技術依賴關係排序任務
• 標記高風險或複雜的任務，可能需要額外的資源

步驟 6: 估算工作量（可選）

為每個任務提供粗略的工作量估算，幫助團隊進行計劃。

估算方法:

• 使用相對估算（例如，故事點）
• 或使用時間估算（例如，小時或天數）
• 考慮團隊的經驗和技能水平

步驟 7: 產出任務清單

將所有信息整理成一份結構化的任務清單，可以是 Markdown、JSON 或其他格式。

任務清單格式範例:

# 專案任務清單

## 模組 1: 使用者認證系統

### 任務 1.1: 實現使用者登入功能
- **描述**: 開發一個登入頁面和後端認證邏輯
- **優先級**: 高
- **依賴**: 無
- **工作量估算**: 5 天
- **驗收條件**:
  - [ ] 使用者可以使用電子郵件和密碼登入
  - [ ] 無效的認證信息會顯示錯誤訊息
  - [ ] 成功登入後，使用者會被重定向到首頁
  - [ ] 登入頁面在 2 秒內載入完成
  - [ ] 單元測試覆蓋率 > 80%

### 任務 1.2: 實現使用者註冊功能
- **描述**: 開發一個註冊頁面和後端邏輯
- **優先級**: 高
- **依賴**: 無
- **工作量估算**: 4 天
- **驗收條件**:
  - [ ] 使用者可以使用電子郵件和密碼註冊
  - [ ] 系統驗證電子郵件格式和密碼強度
  - [ ] 重複的電子郵件會被拒絕
  - [ ] 註冊成功後，使用者被自動登入

## 模組 2: 使用者資料管理

### 任務 2.1: 實現使用者資料編輯功能
- **描述**: 允許使用者編輯其個人資料
- **優先級**: 中
- **依賴**: 任務 1.1（使用者必須先登入）
- **工作量估算**: 3 天
- **驗收條件**:
  - [ ] 使用者可以編輯其名稱、電子郵件、電話號碼
  - [ ] 修改被保存到資料庫
  - [ ] 使用者可以上傳個人頭像
  - [ ] 修改後顯示成功訊息

最佳實踐

1. 保持需求的完整性: 確保沒有遺漏任何隱含的需求。如果不確定，應該向使用者提出澄清問題。

2. 優先考慮使用者價值: 首先實現對使用者最有價值的功能，而不是技術上最簡單的功能。

3. 避免過度設計: 任務應該足夠具體，但不應該規定實現的細節。留出開發者的靈活性。

4. 考慮技術債務: 識別可能產生技術債務的任務，並在計劃中考慮償還時間。

5. 包含非功能需求: 不要忘記性能、安全性、可用性等非功能需求。

6. 定期審查和調整: 隨著項目進展，任務清單可能需要調整。保持清單的動態性。

7. 清晰的溝通: 確保所有利益相關者（開發者、產品經理、測試人員）都理解任務的內容和驗收條件。

常見的拆解陷阱

• 過於粗粒度: 任務太大，難以估算和執行
• 過於細粒度: 任務太小，導致管理開銷過大
• 不清晰的驗收條件: 導致對完成的理解不一致
• 忽略依賴關係: 導致任務執行順序混亂
• 忽略非功能需求: 導致後期的性能或安全問題
• 不現實的工作量估算: 導致項目延期