prd-generation

name	prd-generation
description	PRD 快速生成、需求補洞、優化顧問三合一工具。從需求產出完整 PRD，多角色檢視缺漏，再優化成工程師友善文件。Use when writing a new PRD, reviewing an existing PRD for gaps, or optimizing PRD readability. Triggered by keywords: PRD, 需求文件, 產品規格, 規格書, user story, acceptance criteria, 驗收條件.

PRD 快速生成工具

三階段漸進式 PRD 工作流：生成 → 補洞 → 優化。可單獨使用任一階段，也可串接執行。

---

Phase 1：PRD 快速生成

角色設定

你是一位擁有 10 年以上經驗的 Senior Product Manager。

輸入

使用者提供的需求描述（可以是一句話、一段對話紀錄、或一份粗略規格）。

輸出格式

產出完整 PRD，包含以下章節：

1. 需求背景 — 為什麼要做這件事、解決什麼問題
2. 目標 — 可量測的成功指標（KPI / OKR）
3. User Story — 格式：As a [角色], I want [功能], so that [價值]
4. 功能說明 — 每個功能點的詳細規格，含欄位、行為、權限
5. 流程描述 — 主流程 + 例外流程，以 numbered steps 或 mermaid flowchart 呈現
6. 驗收條件 (Acceptance Criteria) — Given / When / Then 格式
7. Edge Case — 列舉邊界情境及預期處理方式
8. 風險與注意事項 — 技術風險、相依性、時程風險、法規合規

注意事項

• 文件語言：繁體中文（技術術語可保留英文）
• 使用專業 PM 文件格式，層次分明
• 若需求資訊不足以產出完整 PRD，先列出需要釐清的問題再生成

---

Phase 2：需求補洞助手

輸入

一份已存在的 PRD（Phase 1 產出或使用者貼入）。

執行方式

站在以下五個角色逐一檢視：

角色	檢視重點
PM	需求完整性、優先級、scope 是否明確
UI/UX	互動流程、狀態、空狀態、錯誤提示、無障礙
Backend	API 設計、資料模型、效能、安全性、冪等性
Frontend	元件拆分、狀態管理、RWD、loading/error 狀態
QA	測試覆蓋、邊界值、regression 風險、測試資料準備

輸出格式

## 需求補洞報告

### PM 視角
- [ ] 缺漏 1
- [ ] 缺漏 2

### UI/UX 視角
- [ ] ...

### Backend 視角
- [ ] ...

### Frontend 視角
- [ ] ...

### QA 視角
- [ ] ...

### 開發前必確認問題
1. ...
2. ...

---

Phase 3：PRD 優化顧問

輸入

一份需要優化的 PRD。

優化維度

1. 結構 — 章節順序是否符合閱讀邏輯、是否容易快速定位資訊
2. 敘述 — 是否簡潔明確、無歧義、工程師一讀就懂
3. 流程完整性 — 主流程 + 例外流程是否都有覆蓋
4. 命名一致性 — 同一概念是否全文統一用詞
5. 需求明確度 — 是否每個功能點都有明確的行為定義、無模糊空間

輸出格式

1. 優化後的完整 PRD
2. 改善摘要表：

## 改善前後差異

| 維度 | 改善前問題 | 改善後做法 |
|------|-----------|-----------|
| 結構 | ... | ... |
| 敘述 | ... | ... |
| 流程完整性 | ... | ... |
| 命名一致性 | ... | ... |
| 需求明確度 | ... | ... |

---

使用指引

• 只需快速產 PRD → 執行 Phase 1
• 已有 PRD 想檢查漏洞 → 執行 Phase 2
• 已有 PRD 想讓工程師更好讀 → 執行 Phase 3
• 完整流程 → Phase 1 → Phase 2（補洞後修正） → Phase 3（最終優化）

使用者未指定時，詢問要執行哪個 phase。若使用者說「完整流程」或「全部跑」，則依序串接三個 phase。

前置：先驗證現狀

生成 PRD 前，先執行 .claude/skills/product-status-check/SKILL.md——docs/product 的狀態標示普遍落後於程式碼，需求可能早已上線。跳過這步可能整份 PRD 在規劃一個已存在的功能。

後續：銜接開發流程

PRD 定稿後，詢問使用者：「要進入開發規劃嗎？」

• Yes → 依變更所在 repo 銜接：
  1. 確認目標 repo（後端 API → daodao-server、AI 功能 → daodao-ai-backend、其他 → 詢問使用者）
  2. 目標 repo 有 openspec skill（daodao、daodao-server、daodao-ai-backend）→ 以 PRD 為輸入執行該 repo 的 openspec-new-change，把「功能說明」對應到 spec、「驗收條件」對應到 verification、「Edge Case」納入 design 考量
  3. 目標 repo 沒有 openspec（f2e / admin-ui / worker / storage）→ 把 PRD 交給使用者，建議直接以 PRD 的功能說明拆 task 實作
• No → 結束，告知 PRD 存放位置