spec-to-tasks - SKILL.md Agent Skill

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 天
- **驗收條件**:
  - [ ] 使用者可以編輯其名稱、電子郵件、電話號碼
  - [ ] 修改被保存到資料庫
  - [ ] 使用者可以上傳個人頭像
  - [ ] 修改後顯示成功訊息

最佳實踐

保持需求的完整性: 確保沒有遺漏任何隱含的需求。如果不確定，應該向使用者提出澄清問題。
優先考慮使用者價值: 首先實現對使用者最有價值的功能，而不是技術上最簡單的功能。
避免過度設計: 任務應該足夠具體，但不應該規定實現的細節。留出開發者的靈活性。
考慮技術債務: 識別可能產生技術債務的任務，並在計劃中考慮償還時間。
包含非功能需求: 不要忘記性能、安全性、可用性等非功能需求。
定期審查和調整: 隨著項目進展，任務清單可能需要調整。保持清單的動態性。
清晰的溝通: 確保所有利益相關者（開發者、產品經理、測試人員）都理解任務的內容和驗收條件。

常見的拆解陷阱

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