ddd.plan

ddd.plan — 前置規劃（brownfield）

前置規劃階段。在既有專案中延伸或修改功能、需求還不明確、無法直接寫 spec 時，先用這個階段釐清方向。

適用範圍：brownfield——有既有 code 當錨點、要在現行架構上增修。如果是新專案或新模組，沒有既有 code 可以參考，改用 /ddd.brainstorming。

嚴禁撰寫程式碼或修改專案設定檔，直到 plan.md 獲使用者確認。 嚴禁自行假設商業邏輯，需求模糊時必須提問。

反模式：「這個太簡單不需要 plan」

每個需求都要走這個流程。一個小功能、一個設定調整、一個看似明確的修改——全部都要。「簡單」的需求正是未經檢驗的假設最容易造成浪費的地方。Plan 可以很短（真正簡單的需求寫幾句話就好），但你必須呈現給使用者確認。

Checklist

你必須為以下每個項目建立 task 並依序完成：

1. 探索專案上下文 — 讀現有文件（PRD.md、README.md）、查 codebase、檢查是否有相關需求文件、讀取 plan.md（如有，當作草稿起點）
2. 建立文件包 — 確認或建立 docs/<編號>-<名稱>/ 資料夾（若為新需求）
3. 範圍評估 — 判斷需求是否涉及多個獨立子系統；若是，先協助拆分為獨立 sprint，再逐一深入。不要在巨大範圍上鑽細節
4. 逐一追問釐清需求 — Grill Me 模式（見下方）
5. 提出 2-3 個方案 — 附取捨分析與你的推薦
6. 使用者確認方向 — 將規劃結論（背景、選定方案、取捨）摘要呈現，等使用者確認
7. 接續 /ddd.spec 撰寫 spec.md — invoke /ddd.spec skill，跳過其「準備工作」（已完成），規劃結論填入 spec 的「背景」與「ADR」段落

Grill Me 模式

• 一次一題：沿著決策樹逐一追問，每次只聚焦一個決策點，解決後再往下走
• 選擇題優先：能用 2-4 個選項框架化的問題，就用 AskUserQuestion 的多選項格式呈現，降低使用者的認知負擔。開放式問題只在無法預判答案範圍時使用
• 能靠 codebase 回答的問題自己去查，不要問使用者（用 Explore agent、Grep、Read）
• 只有真正需要使用者判斷的問題才用 AskUserQuestion 提出
• 在分歧點提出方案：遇到多種可行路徑時，提出 2-3 個方案及各自取捨，附上你的推薦——讓使用者做選擇題而非申論題
• 持續追問直到沒有未解決的分支為止

Key Principles

• YAGNI：在 plan 階段就積極砍功能——越早砍越便宜，不要把「以後可能需要」的東西帶進 spec
• 一次一題：不要用多個問題轟炸使用者
• 選擇題優先：降低認知負擔
• 先探索後提問：能從 codebase 得到的答案不要問使用者
• 漸進式確認：分段呈現，逐段確認，不要一次丟出整份文件

產出

docs/<編號>-<名稱>/spec.md（經由 /ddd.spec 流程產出）

結束條件

/ddd.spec 流程完成、使用者確認規格後，依 spec 內 Milestones 複雜度引導使用者執行 /ddd.work 或 /ddd.tasks。 如果有技術問題需要調研，直接用原生工具（Explore agent、WebSearch、WebFetch）進行，將結論記錄在 research.md 中。