# Spec-Driven 四階段說明

## 為什麼要閘門

邊想邊寫碼會讓範圍漂掉。四份文件各解一個問題：

| 文件 | 回答的問題 | 讀者 |
|------|------------|------|
| requirements | 我們要什麼？不要什麼？ | 產品 / 你自己 |
| spec | 系統對外行為是什麼？ | 實作者 + 審查 |
| plan | 分幾段交付、依賴與風險？ | 排程 |
| task | 下一小時具體改什麼？ | 動手 agent / 人 |

## 閘門 checklist

### 需求通過

- [ ] 一句話產品目標清楚  
- [ ] In / Out of scope 無互相打架  
- [ ] P0 可獨立交付價值  
- [ ] 成功標準可驗收（不是「更好用」）  
- [ ] 開放問題已列出（可帶預設假設）  

### Spec 通過

- [ ] 主要實體與狀態可畫出  
- [ ] 關鍵使用者路徑有行為描述  
- [ ] Retain / Replace / Remove 對現況有交代  
- [ ] 錯誤、權限、時間、分頁等跨切約定有寫  
- [ ] 沒有偷偷寫實作步驟當規格  

### Plan 通過

- [ ] 里程碑順序合理、依賴無環  
- [ ] 每里程碑有驗收方式  
- [ ] 風險與不做清單明確  
- [ ] 對應 task 區間可預估  

### Tasks 通過

- [ ] 每 task 單一 Done  
- [ ] 預估 100–200 行級（過大已拆）  
- [ ] Inputs / Outputs / 不做 / 驗收齊  
- [ ] INDEX 可追蹤狀態  

## 與現有技能的關係

| 技能 | 關係 |
|------|------|
| `/design` | 偏設計文件 + PR Plan；本 skill 偏產品需求→小 task |
| `/execute-plan` | 可在 **plan/tasks 批准後** 用來並行實作，非必須 |
| `/check-work` | 單一 task 做完後驗證 |

第一版 **不必** 自動串 execute-plan；使用者說「實作 T003」即可。