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？

其他一律不問——那是 grill-me 的工作，你的工作是找洞。

Step 1：先判斷哪些角色會參與

掃描前，先看這份需求實際上會動到哪幾個角色，在輸出最前面列一張「角色參與判斷表」：

角色	是否參與	判斷依據
PM	✅ 參與	一律參與（範圍與邊界永遠要盤）
UIUX	❌ 無	純 API / 排程 / 資料遷移，沒有任何畫面
Backend	✅ 參與	有資料寫入與狀態變化
Frontend	❌ 無	無前端互動
QA	✅ 參與	一律參與（可測性永遠要盤）

判斷原則：

• PM 與 QA 一律參與。 任何需求都有範圍邊界，也都要能驗收，這兩個角色不會標「無」。
• UIUX：只要完全沒有畫面（純後端 API、排程 job、資料遷移、內部函式），就標「❌ 無」。
• Frontend：沒有前端互動就標「❌ 無」。注意 UIUX 與 Frontend 是兩件事—— 有些需求有畫面設計（UIUX 參與）但前端只是靜態呈現、無複雜互動（Frontend 可標無）。
• Backend：純前端樣式調整、純文案修改，可標「❌ 無」。