# Requirement Gap Finder

> |

- **Type:** Skill
- **Install:** `agentstack add skill-skinnerlee1225-enterprise-prd-toolkit-requirement-gap-finder`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [skinnerlee1225](https://agentstack.voostack.com/s/skinnerlee1225)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [skinnerlee1225](https://github.com/skinnerlee1225)
- **Source:** https://github.com/skinnerlee1225/enterprise-prd-toolkit/tree/main/skills/requirement-gap-finder
- **Website:** https://skinnerlee1225.github.io/enterprise-prd-toolkit/

## Install

```sh
agentstack add skill-skinnerlee1225-enterprise-prd-toolkit-requirement-gap-finder
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 需求補洞助手

## 這個 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 視角

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

欄位規範：

- **缺漏項**：一句話，說「什麼沒寫」，不是「該注意什麼」
- **風險後果**：如果不解決，實際會發生什麼壞事。要具體到可以想像的畫面
- **必須確認的問題**：一個問題，可以用一兩句話回答
- **建議預設答案**：**要有立場**。格式「建議 X，因為 Y」
- **等級**：P0 / P1 / P2

### 收斂區（表格之後）

```
## 📌 開發前必須拍板（P0 清單）

1. [問題] → 建議：[答案]
2. ...

## ⚠️ 最容易被誤解的三處敘述

| 原文 | 可能被理解成 | 建議改寫 |
|------|-------------|---------|

## 🎯 下一步

[1. 請使用者針對 P0 逐條拍板  2. 拍板後接 enterprise-prd-writer 或 prd-writer 輕量版寫成 PRD]
```

「最容易被誤解的三處敘述」是必要區塊——直接引用使用者原文中含糊的句子
（「盡快」、「大量」、「異常時」、「自動處理」這類），指出工程師會怎麼誤讀。

---

## 語言與格式偏好

- 一律使用繁體中文，專有名詞保留英文
- 表格優先於長段落
- 老花友善：段落短、重點粗體、避免整段密集文字
- P0 一律用粗體標示

## 輸出載體

- 預設直接輸出在對話中（因為這是要立刻拿去跑 grill-me 的工作稿）
- 發現數超過 25 個，或使用者說「整理成文件」時，
  改用 `interactive-html-report` skill 輸出成可篩選、可勾選的互動報告

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [skinnerlee1225](https://github.com/skinnerlee1225)
- **Source:** [skinnerlee1225/enterprise-prd-toolkit](https://github.com/skinnerlee1225/enterprise-prd-toolkit)
- **License:** MIT
- **Homepage:** https://skinnerlee1225.github.io/enterprise-prd-toolkit/

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** yes
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-skinnerlee1225-enterprise-prd-toolkit-requirement-gap-finder
- Seller: https://agentstack.voostack.com/s/skinnerlee1225
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.