plan-writing

name	plan-writing
description	結構化任務規劃，包含清晰的分解、依賴關係和驗證標準。用於實作功能、重構或任何多步驟工作。
allowed-tools	Read, Glob, Grep

計畫撰寫

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