القائمة
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, 驗收條件.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
PR merge 後的收尾流程：歸檔 openspec change、更新 docs/product 功能狀態、校準地圖文件。Use when a PR is merged, the user says 合併了/merged/上線了, or after confirming a PR's merge status.
依島島 GTM 策略產出 TA 導向的行銷內容——部落格文章、社群貼文（Threads/IG/FB）、回覆別人的文案。Use when user says "寫一篇文章"、"寫貼文"、"幫我回覆這篇"、"招生文"、"揪團文"、"寫 threads"、"content"、"文案"。自動套用語氣鐵律、TA 痛點語言與模板 CTA。
規劃或實作任何 product 功能前，先用程式碼驗證 docs/product 的狀態標示是否為真。docs/product 的 PRD/FRD 狀態普遍落後於程式碼——直接照文件規劃會重做一個早就上線的功能。Use before planning a feature, estimating scope, writing an OpenSpec change, or answering "這功能做了沒". Triggered by keywords: PRD, FRD, 規劃, 這功能, 還沒做, 規劃中, roadmap, scope, plan feature.
Use when asked to summarize or analyze monthly user activity and interaction data. Queries DB for MAU, DAU trends, check-in counts, reactions, comments, follows, retention rate, and top users/practices. Generates narrative insights via daodao-ai-backend LLM and outputs a markdown report or writes to Notion.
Use when sending personalized congratulation emails to users who completed a practice. Queries the DB for completed practices, generates personalized email content via daodao-ai-backend LLM, previews samples for confirmation, then sends via email API. Always runs in dry-run mode first.
在 daodao 任務 Notion DB 建立新卡片。Use when user says "開 Notion 卡"、"建 notion 單"、"新增任務"、"create notion card"、"開一張卡"、"記到 notion"。從對話或報告自動推斷欄位，互動確認後建立。
| 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 工作流：生成 → 補洞 → 優化。可單獨使用任一階段，也可串接執行。
你是一位擁有 10 年以上經驗的 Senior Product Manager。
使用者提供的需求描述（可以是一句話、一段對話紀錄、或一份粗略規格）。
產出完整 PRD，包含以下章節：
As a [角色], I want [功能], so that [價值]一份已存在的 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. ...
一份需要優化的 PRD。
## 改善前後差異
| 維度 | 改善前問題 | 改善後做法 |
|------|-----------|-----------|
| 結構 | ... | ... |
| 敘述 | ... | ... |
| 流程完整性 | ... | ... |
| 命名一致性 | ... | ... |
| 需求明確度 | ... | ... |
使用者未指定時，詢問要執行哪個 phase。若使用者說「完整流程」或「全部跑」，則依序串接三個 phase。
生成 PRD 前，先執行 .claude/skills/product-status-check/SKILL.md——docs/product 的狀態標示普遍落後於程式碼，需求可能早已上線。跳過這步可能整份 PRD 在規劃一個已存在的功能。
PRD 定稿後，詢問使用者：「要進入開發規劃嗎？」
openspec-new-change，把「功能說明」對應到 spec、「驗收條件」對應到 verification、「Edge Case」納入 design 考量