spec-doclisted

# 產生開發需求規格文件 產生一份正式的需求規格文件，供開發團隊成員閱讀與討論。不限定於 Clarify 流程中使用，任何需要「把一個功能或改動整理成給同事看的規格」的時機皆可執行。 ## 需求來源 依以下優先序取用需求來源： 1. 對話 context 中 Clarify Agent 整理完的需求摘要（含需求背景、程式面/功能面項目、排除範圍、假設清單、驗收方向）。 2. 若對話 context 無 Clarify 整理內容，改讀取 `<work-root>/.local/ai-sessions/design.md`，以第 1 章「需求摘要」為主，並從 §2 系統設計、§7 已知盲點、§8 刻意排除擷取邊界與開放問題。 3. 若兩者均無，以**使用者口述範圍 + 程式碼盤點**為來源：請使用者以一至兩句描述功能範圍（或沿用本輪對話已討論的主題），掃描相關程式碼與設定補���現況行為、系統邊界與相依。此模式下資訊不足的欄位一律列入第 7 章「開放問題」，**禁止虛構需求細節**。 ## 執行步驟 ### 1. 取得需求來源 依上述優先序載入需求來源，識別其中的結構化元素： - 功能目標與使用者故事 - 功能需求清單 - 非功能需求（效能、安全性、可用性等） - 系統邊界與排除範圍 - 假設與前提條件 - 待解決的開放問題 ### 2. 產生規格文件 依照以下結構輸出，使用 Merge 模式寫入（若目標檔案已存在）： ```markdown # 開發需求規格：[功能名稱] > **文件狀態**：草稿 > **最後更新**：[今日日期 YYYY-MM-DD] ## 1. 背景與目標 [說明此功能的業務背景、解決的問題，以及預期達成的目標。] ## 2. 使用者故事 | 角色 | 行為 | 目的 | | --- | --- | --- | | 作為 [角色] | 我想要 [行為] | 以便 [目的] | ## 3. 功能需求 ### 3.1 [子功能名稱] - [需求描述，使用「系統應該...」或「使用者可以...」的格式] - [可驗證的具體行為描述] ### 3.2 [子功能名稱] ... ## 4. 非功能需求 | 類別 | 需求描述 | 驗收標準 | | --- | --- | --- | | 效能 | ... | ... | | 安全性 | ... | ... | | 可用性 | ... | ... | ## 5. 系統邊界 **納入範圍：** - [明確說明此次開發包含的項目] **排除範圍：** - [明確說明不在此次開發範圍內的項目] ## 6. 假設與前提條件 - [列出需求成立的假設，如「假設用戶已完成身份驗證」] ## 7. 開放問題 | 問題 | 負責人 | 截止日期 | 狀態 | | --- | --- | --- | --- | | [待釐清的問題] | | | 待確認 | ## 8. 驗收標準 [列出整體功能的驗收標準，每條應為可驗證的測試案例] - 驗收條件 1，描述可觀察的系統行為 - 驗收條件 2，描述可觀察的系統行為 ``` ### 3. 輸出規則 - **文件語言**：繁體中文（台灣用語），技術術語保留英文。 - **需求描述**：每條需求必須可驗證（有明確的輸入、行為、輸出）。 - **不寫空白欄位**：若某章節在需求來源中無對應資訊，略去該章節，不留「待補充」佔位符。 - **開放問題保留**：需求來源中標示為「待確認」或假設清單中的項