# Plan Writing

> 結構化任務規劃，包含清晰的分解、依賴關係和驗證標準。用於實作功能、重構或任何多步驟工作。

- Skill: `tai-ch0802/plan-writing` (Agent Skill)
- Install (CLI): `npx skillmds@latest add tai-ch0802/plan-writing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tai-ch0802/plan-writing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Tai-ch0802 (https://skillmd.com/u/tai-ch0802)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/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（如果複雜）
- 重構多個檔案