| 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，包含以下章節：
- 需求背景 — 為什麼要做這件事、解決什麼問題
- 目標 — 可量測的成功指標（KPI / OKR）
- User Story — 格式：
As a [角色], I want [功能], so that [價值]
- 功能說明 — 每個功能點的詳細規格，含欄位、行為、權限
- 流程描述 — 主流程 + 例外流程，以 numbered steps 或 mermaid flowchart 呈現
- 驗收條件 (Acceptance Criteria) — Given / When / Then 格式
- Edge Case — 列舉邊界情境及預期處理方式
- 風險與注意事項 — 技術風險、相依性、時程風險、法規合規
注意事項
- 文件語言：繁體中文（技術術語可保留英文）
- 使用專業 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。
優化維度
- 結構 — 章節順序是否符合閱讀邏輯、是否容易快速定位資訊
- 敘述 — 是否簡潔明確、無歧義、工程師一讀就懂
- 流程完整性 — 主流程 + 例外流程是否都有覆蓋
- 命名一致性 — 同一概念是否全文統一用詞
- 需求明確度 — 是否每個功能點都有明確的行為定義、無模糊空間
輸出格式
- 優化後的完整 PRD
- 改善摘要表：
## 改善前後差異
| 維度 | 改善前問題 | 改善後做法 |
|------|-----------|-----------|
| 結構 | ... | ... |
| 敘述 | ... | ... |
| 流程完整性 | ... | ... |
| 命名一致性 | ... | ... |
| 需求明確度 | ... | ... |
使用指引
- 只需快速產 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 銜接：
- 確認目標 repo（後端 API → daodao-server、AI 功能 → daodao-ai-backend、其他 → 詢問使用者）
- 目標 repo 有 openspec skill（daodao、daodao-server、daodao-ai-backend）→ 以 PRD 為輸入執行該 repo 的
openspec-new-change，把「功能說明」對應到 spec、「驗收條件」對應到 verification、「Edge Case」納入 design 考量
- 目標 repo 沒有 openspec（f2e / admin-ui / worker / storage）→ 把 PRD 交給使用者，建議直接以 PRD 的功能說明拆 task 實作
- No → 結束，告知 PRD 存放位置
