1.6 KiB

Raw Blame History

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」即可。