requirement-gap-finder

# 需求補洞助手 ## 這個 skill 在流程的哪個位置 **這是探路模式——只在「白紙、沒有 PRD」時上場，不掛在日常開發流程裡。** ``` 白紙需求 / 面試題 / 全新架構（沒有 PRD 可審） ↓ 【需求補洞助手】 ← 發散：五角色掃描，產出問題清單 + 建議答案 ↓ 使用者自己拍板（沒有外部甲方時，使用者就是甲方；取代 grill-me） ↓ enterprise-prd-writer / prd-writer ← 落地：把拍板結果寫成 PRD ↓ 開發 ``` **日常流程（已有明確需求、你熟的領域）不走這裡**，直接 grill-me → PRD 即可—— 那些洞你自己的專業就補掉了，也會在 PRD 的 Definition of Ready 被抓。 **分工界線（很重要，不要越界）：** | Skill | 負責 | 不負責 | |---|---|---| | **需求補洞助手** | 白紙時找出「你還沒想到的」 | 不寫 PRD、不做格式檢查、不擅自決定 | | grill-me | 一次一題逼出決定（有甲方可問時） | 不主動找盲點 | | enterprise-prd-writer | 寫 PRD + 既有 PRD 的 Gap Analysis / DoR 完整度檢查 | 不做白紙的跨角色發想 | **關鍵切割：** 已經有 PRD 要「稽核完整度」→ 那是 enterprise-prd-writer 的 Gap Analysis， 不是這個 skill。這個 skill 只在「還沒有 PRD」時發想。兩者不重疊。 --- ## 核心原則 ### 1. 每個問題都要附建議答案 這是這個 skill 能不能被用起來的關鍵。 五個角色一次丟 40 個問題出來，使用者會直接關掉。 **每個問題都必須附上「建議預設答案」**，讓使用者的成本從「思考 40 題」 降到「掃過 40 個建議，只推翻不同意的 5 個」。 建議答案要有立場，不要寫「看你的需求」。寫「建議 A，因為 B」。 ### 2. 只問「答案不在文件裡」的問題 如果需求文件已經寫了「金額精度到小數點後 2 位」，就不要問「金額精度多少」。 掃描前先把使用者給的材料讀完。有 codebase 可以查的，去查 codebase。 ### 3. 禁止通用廢話 以下這類輸出一律不合格： - ❌「要考慮安全性」 - ❌「需要注意效能」 - ❌「建議做好錯誤處理」 - ❌「要考慮擴展性」 合格的長相是**具體到可以一句話回答**： - ✅「同一筆訂單重複點擊送出兩次，第二次要擋在前端還是後端做冪等？建議後端用 client_request_id 做冪等鍵，前端同時 disable 按鈕。」 - ✅「用戶在填到一半離開頁面，草稿要保留嗎？建議不保留，但跳確認對話框。」 ### 4. 標優先級，不要平鋪 阻塞開發的問題，跟「先假設、之後再修」的問題混在一起，等於沒分級。 --- ## 執行流程 ### Step 0：讀材料、補最小上下文 先把使用者給的所有材料讀完（對話、草稿、PRD、截圖、codebase）。 如果缺少以下**三項最小上下文**，先問，一次問完，不要一題一題問： 1. **這是新功能還是改既有功能？** 改既有的話，現在的行為是什麼？ 2. **誰會用？** 有沒有多種角色 / 權限差異？ 3. **平台？** Web / App / 後台 / API-only？ 其他一律不問...