Tai-ch0802 計畫撰寫
來源：obra/superpowers
概覽
此技能提供將工作分解為清晰、可操作任務的框架，附帶驗證標準。
任務分解原則
1. 小而專注的任務
- 每個任務應花 2-5 分鐘
- 每個任務一個清晰的結果
- 可獨立驗證
2. 清晰的驗證
- 你怎麼知道它完成了？
- 你能檢查/測試什麼？
- 預期的輸出是什麼？
3. 邏輯排序
- 已識別依賴關係
- 盡可能平行工作
- 標示關鍵路徑
- 階段 X：驗證永遠是最後的
4. 專案根目錄的動態命名
- 計畫檔案以
{task-slug}.md儲存在專案根目錄 - 名稱來自任務（例如「add auth」→
auth-feature.md） - 絕不 放在
.claude/、docs/或暫存資料夾內
規劃原則（非範本！）
🔴 沒有固定範本。每個計畫都對其任務是唯一的。
原則 1：保持簡短
| ❌ 錯誤 | ✅ 正確 |
|---|---|
| 50 個任務和子子任務 | 最多 5-10 個清晰任務 |
| 列出每個微步驟 | 僅可操作項目 |
| 冗長描述 | 每個任務一行 |
規則： 如果計畫超過 1 頁，就太長了。簡化。
原則 2：具體而非通用
| ❌ 錯誤 | ✅ 正確 |
|---|---|
| 「設定專案」 | 「執行 npx create-next-app」 |
| 「新增驗證」 | 「安裝 next-auth，建立 /api/auth/[...nextauth].ts」 |
| 「美化 UI」 | 「在 Header.tsx 新增 Tailwind 類別」 |
規則： 每個任務應有清晰、可驗證的結果。
原則 3：基於專案類型的動態內容
新專案：
- 什麼技術堆疊？（先決定）
- 什麼是 MVP？（最少功能）
- 檔案結構是什麼？
功能新增：
- 哪些檔案受影響？
- 需要什麼依賴？
- 如何驗證可行？
Bug 修復：
- 根本原因是什麼？
- 要變更什麼檔案/行？
- 如何測試修復？
原則 4：腳本視專案而定
🔴 不要複製貼上腳本指令。根據專案類型選擇。
| 專案類型 | 相關腳本 |
|---|---|
| 前端/React | ux_audit.py、accessibility_checker.py |
| 後端/API | api_validator.py、security_scan.py |
| 行動 | mobile_audit.py |
| 資料庫 | schema_validator.py |
| 全端 | 根據你觸及的部分混合使用 |
錯誤： 每個計畫都加入所有腳本 正確： 僅與此任務相關的腳本
原則 5：驗證要簡單
| ❌ 錯誤 | ✅ 正確 |
|---|---|
| 「驗證元件運作正確」 | 「執行 npm run dev，點擊按鈕，看到 toast」 |
| 「測試 API」 | 「curl localhost:3000/api/users 回傳 200」 |
| 「檢查樣式」 | 「開啟瀏覽器，驗證暗色模式切換可用」 |
計畫結構（彈性，非固定！）
# [任務名稱]
## 目標
一句話：我們在建構/修復什麼？
## 任務
- [ ] 任務 1：[具體動作] → 驗證：[如何檢查]
- [ ] 任務 2：[具體動作] → 驗證：[如何檢查]
- [ ] 任務 3：[具體動作] → 驗證：[如何檢查]
## 完成條件
- [ ] [主要成功標準]
就是這樣。 除非真正需要，否則不需要階段、子區塊。 保持最少。僅在需要時增加複雜度。
備註
[任何重要考量]
---
## 最佳實踐（快速參考）
1. **從目標開始** — 我們在建構/修復什麼？
2. **最多 10 個任務** — 如果更多，分成多個計畫
3. **每個任務可驗證** — 清晰的「完成」標準
4. **專案特定** — 不要複製貼上範本
5. **隨時更新** — 完成時標記 `[x]`
---
## 何時使用
- 從零開始的新專案
- 新增功能
- 修復 bug（如果複雜）
- 重構多個檔案