tai-ch0802/plan-writing

計畫撰寫

來源：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（如果複雜）
- 重構多個檔案