requirement-contextlisted

# 需求上下文盤點 當使用者提出需求、功能構想或改善方向，並要求先盤點背景、整理需求討論用的資訊、或確認可能牽涉哪些文件 / 程式碼 / 資料庫物件時，請套用本 Skill。 本 Skill 的產出是需求討論前的短期交接資料，不是正式規格文件、設計文件或完整專案文件。 ## 產出位置 固定寫入： ```text <work-root>/.local/ai-sessions/requirement-context.md ``` 寫入模式採覆寫模式。每一輪需求上下文只保留最新內容，避免舊需求殘留干擾後續討論。 ## 與其他 Skill / 文件的分工 | 項目 | 職責 | | --- | --- | | `requirement-context` | 針對單一需求盤點討論所需背景，輸出短期交接文件 | | `survey` | 掃描新專案或陌生專案，產出長期技術文件索引 | | `spec-doc` | 依需求摘要、design.md 或口述範圍產出給同事閱讀的需求規格 | | `design.md` | 作為 Implement 階段的工程設計基準 | | `CONTEXT.local.md` | 保存跨 Session 仍有價值的本機耐久資訊 | ## 執行流程 ### 1. 判定 work-root 依主規則判定 `<work-root>`。後續 `.local/ai-sessions/` 均以此為根目錄。 ### 2. 重述需求 以中性語句重述使用者目前提出的需求，僅描述已知目標與問題，不補猜未確認的需求決策。 若需求描述不足以判斷盤點方向，先詢問使用者補充核心目標或業務流程，不進行大範圍掃描。 ### 3. 盤點資料來源 依需求相關性由近到遠查閱： - 專案文件：README、`docs/`、既有規格、流程文件、API 文件。 - 程式碼：Controller / Endpoint、Service、Repository、DTO、ViewModel、前端頁面、API Client、Store、Route、Composable。 - 資料庫：資料表、View、Stored Procedure、Function、Trigger、索引、欄位關係。 - 測試：與需求相關的單元測試、整合測試、端對端測試。 只讀取與需求有明確關聯的來源。不得為了完整性掃描整個專案。 ### 4. 證據分級 輸出時必須區分： - **已查到**：有明確檔案、程式碼位置、資料庫物件或文件來源支撐。 - **合理推測**：依命名、架構或相鄰流程推斷，但尚未找到直接證據。 - **待確認**：需求討論時必須向使用者或後續 Agent 釐清的問題。 不得把合理推測寫成已查到的事實。 ### 5. 影響範圍分類 將可能影響範圍分為： - **直接影響**：需求極可能需要修改或討論的檔案、模組、API、資料表。 - **間接影響**：可能受資料流、呼叫鏈、共用型別或流程影響的項目。 - **僅供參考**：理解業務或系統背景有幫助，但目前沒有修改跡象的項目。 ### 6. 寫入 requirement-context.md 使用下列格式覆寫輸出檔： ```markdown # Requirement Context ## 1. 需求摘要 [以中性語句重述使用者提出的需求。] ## 2. 已查閱來源 | 類型 | 路徑 / 來源 | 關聯 | | --- | --- | --- | | 文件 | `docs/...` |