菜单
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 页面并帮你完成安装。
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 考量