/requirement-gap-finder

name: requirement-gap-finder
description: |
  需求補洞助手（探路模式）— 專用於「白紙一張、還沒有 PRD」的場合：站在 PM、UIUX、
  Backend、Frontend、QA 五個角色，掃描需求的缺漏、容易誤解的敘述、沒考慮到的 Edge Case，
  以及開發前一定要確認的問題，把還沒想到的東西攤開。

  ✅ 適用場合（符合任一才觸發）：
  - 全新產品 / 全新架構，還沒有任何 PRD 可審
  - 面試 take-home、產品設計題，且風險/邊界識別本身就是交付物
  - 使用者不熟的領域，需要靠五角色補自己的盲點
  - 沒有可問的需求方，使用者要自己扮演甲方

  當使用者說「幫我找需求缺漏」、「這個需求有什麼沒想到的」、「補洞」、「盤點 Edge Case」、
  「這是白紙設計，幫我掃一輪」、「find gaps」、「what am I missing」時，觸發此 skill。

  ❌ 不適用（改用別的 skill）：
  - 已經有一份 PRD，要檢查完整度 / AC 能不能測 / 缺哪章 → 用 enterprise-prd-writer
    的 Gap Analysis 與 Definition of Ready，不要用本 skill
  - 要把需求寫成正式文件 → 用 prd-writer（輕量版）或 enterprise-prd-writer

  這個 skill 只負責「發散——把問題找出來」，不做格式檢查、不寫 PRD、不替使用者做決定。

需求補洞助手

這個 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**：純前端樣式調整、純文案修改，可標「❌ 無」。

標「❌ 無」的角色，在後面的掃描直接寫**「本次無（因為 ⋯⋯）」一行帶過**， 不要為了湊數硬生出問題。

Step 2：對「參與」的角色逐一掃描

只跑 Step 1 判定為「✅ 參與」的角色。每個參與的角色**至少產出 3 個、至多 10 個**發現。 判定為「❌ 無」的角色不掃描、不湊數。

掃描時的心態：**假設這份需求明天就要交給工程師開發，你要找出他明天第一天 就會回頭問 PM 的所有問題。**

Step 3：優先級分流

每個發現標一個等級：

| 等級 | 定義 | 判準 | |---|---|---| | **P0** | 開發前必須有答案 | 不同答案會導致不同的資料模型 / 架構 / API 設計 | | **P1** | 影響設計，但可以先做假設 | 不同答案只影響 UI 或文案，改動成本低 | | **P2** | 可以先假設，之後再修 | 屬於優化、極端罕見情境、或明顯可以進 Phase 2 |

**P0 不能超過 10 個。** 超過就代表你把 P1 誤標成 P0，重新分級。

Step 4：輸出（見下方格式）

Step 5：交棒

探路模式沒有外部甲方——**使用者自己就是甲方**。輸出結尾一律引導使用者拍板，再進 PRD：

1. 請使用者針對 **P0 清單**自己逐條拍板（這一步取代 grill-me——grill-me 需要一個「被問的人」， 白紙案子那個人就是使用者本人） 2. P0 一鎖定 → 建議接著用 **enterprise-prd-writer**（金流/風控/合規案）或 **prd-writer 輕量版** （個人/小案）把拍板結果寫成 PRD，本 skill 列的建議答案可直接當 PRD 的預設值 3. 若有可問的真實甲方（罕見，但如面試官願意澄清），才建議把 P0 純問題清單拿去逐題確認

Step 6：品質自檢

輸出前逐項確認：

• [ ] 最前面有「角色參與判斷表」嗎？
• [ ] 每個「✅ 參與」的角色都至少有 3 個發現嗎？
• [ ] 每個「❌ 無」的角色都寫了「本次無（因為 ⋯⋯）」，而不是硬湊發現嗎？
• [ ] 有沒有任何一條是通用廢話（「要考慮 X」）？有的話刪掉或改具體
• [ ] 每個問題都附了有立場的建議答案嗎？
• [ ] 有沒有問到「答案已經在使用者材料裡」的問題？
• [ ] P0 是不是 ≤ 10 個？
• [ ] 有沒有把「該不該做這個功能」的策略問題混進來？（那是 pre-mortem 的事，不是這裡）

---

五角色檢查清單

以下是掃描時的提示清單，**不是要全部問一遍**——挑真正適用於這個需求的。

**只跑 Step 1 判定為「✅ 參與」的角色。** 判定為「❌ 無」的角色跳過整份清單， 在輸出中只保留一行「本次無（因為 ⋯⋯）」。

PM 視角：範圍與邊界

• 成功的定義是什麼？用什麼數字判斷這功能有沒有做對？
• 這個功能不做什麼？（Out of Scope 的雛型）
• 有沒有既有功能會被這個取代 / 影響？舊資料怎麼遷移？
• 分幾期做？MVP 的最小可用邊界在哪？
• 有沒有法遵 / 風控 / 稽核的要求？（KYC、金流、個資、留存期限）
• 有沒有外部依賴？（第三方 API、其他團隊、營運手動流程）
• 誰有權限做這件事？有沒有審核關卡？
• 上線後誰負責維運？出事找誰？

UIUX 視角：狀態與感受

• **六種畫面狀態都定義了嗎？**（空白 / 載入中 / 正常 / 成功 / 失敗 / 邊界）
• 這個畫面的進入點有幾個？從不同入口進來行為一樣嗎？
• 空狀態要引導用戶做什麼？（新用戶第一次看到的就是這個）
• 錯誤訊息的文案是什麼？用戶看到後知道怎麼補救嗎？
• 不同權限的角色看到的畫面差在哪？
• 需要 RWD 嗎？手機上這個表格 / 圖表怎麼呈現？
• 需要多語系嗎？文字變長 1.5 倍版面會不會爆？
• 操作要幾秒才有反應？超過 1 秒有沒有 loading？超過 10 秒要不要改成非同步 + 通知？
• 有沒有不可逆的操作？要不要二次確認？

Backend 視角：資料與一致性

• 資料模型長什麼樣？哪些欄位是必填？
• 有沒有狀態機？**兩個狀態轉換同時發生怎麼辦？**
• 冪等性：同一個請求送兩次，結果一樣嗎？用什麼當冪等鍵？
• 併發：兩個人同時操作同一筆資料，誰贏？樂觀鎖還是悲觀鎖？
• 交易邊界在哪？跨服務的話怎麼保證一致性？補償機制是什麼？
• 第三方 API 掛掉 / 逾時 / 回傳異常格式時，系統做什麼？
• 需要限流嗎？被打爆時降級成什麼？
• 稽核 log 要記什麼？誰在什麼時候改了什麼？留多久？
• 資料量成長：一年後這張表多大？查詢還跑得動嗎？
• **時區**：儲存用 UTC 還是本地時間？「今天」的定義是哪個時區的今天？
• **金額 / 數值精度**：小數幾位？四捨五入還是無條件捨去？誰吃掉尾差？

Frontend 視角：互動與同步

• 資料怎麼來？REST 輪詢 / WebSocket / SSE？多久更新一次？
• 需要樂觀更新（optimistic update）嗎？失敗要不要 rollback？
• 快取什麼時候失效？別的分頁改了資料，這個分頁怎麼知道？
• 表單驗證在前端還後端？兩邊規則會不會不一致？
• 重複點擊送出按鈕怎麼擋？
• 表單填一半離開頁面，要不要留草稿 / 跳確認？
• 需要深連結（deep link）嗎？直接貼網址進來，狀態要能還原嗎？
• 列表要分頁還是無限捲動？排序 / 篩選條件要不要寫進 URL？
• 大量資料的畫面要不要虛擬捲動？

QA 視角：可測與可驗

• 這個功能怎麼測？有沒有無法用 UI 觸發的路徑？
• 測試資料怎麼準備？需要第三方 sandbox 嗎？
• **邊界值**：0、負數、空字串、超長字串、最大值 +1 各是什麼行為？
• **規則衝突**：兩條規則同時成立時，優先級是什麼？
• 這個改動會影響到哪些既有功能？回歸測試範圍多大？
• 上線後怎麼確認它真的正常？看哪個指標 / log？
• 什麼情況該發告警？告警給誰？
• 需要 feature flag 嗎？出事怎麼回滾？

---

輸出格式

開頭：角色參與判斷表（一律先出這張）

## 👥 本次參與角色

| 角色 | 是否參與 | 判斷依據 |
|---|---|---|
| PM | ✅ | 一律參與 |
| UIUX | ❌ 無 | 純資料遷移，無任何畫面 |
| Backend | ✅ | 涉及資料表結構與搬遷邏輯 |
| Frontend | ❌ 無 | 無前端互動 |
| QA | ✅ | 一律參與 |

主表格（每個「✅ 參與」角色一張）

### 🧭 PM 視角

| # | 缺漏項 | 風險後果 | 必須確認的問題 | 建議預設答案 | 等級 |
|---|--------|---------|---------------|-------------|------|
| 1 | 未定義失敗後的重試 | 用戶卡住，客服爆量 | 失敗後能重試幾次？ | 建議 3 次，之後鎖 24h | **P0** |

**「❌ 無」的角色不出表格**，只寫一行：

### 🎨 UIUX 視角

本次無（純資料遷移，沒有任何使用者可見的畫面）。

欄位規範：

• **缺漏項**：一句話，說「什麼沒寫」，不是「該注意什麼」
• **風險後果**：如果不解決，實際會發生什麼壞事。要具體到可以想像的畫面
• **必須確認的問