prd-generation

スター0

フォーク0

更新日2026年7月18日 04:50

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 ページを確認してインストールできます。

ソース

daodaoedu

daodaoedu/daodao

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

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 銜接：
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 存放位置

このリポジトリの他の Skills

同じリポジトリ

post-merge-wrapup

daodaoedu/daodao

PR merge 後的收尾流程：歸檔 openspec change、更新 docs/product 功能狀態、校準地圖文件。Use when a PR is merged, the user says 合併了/merged/上線了, or after confirming a PR's merge status.

2026-07-180

gtm-content

daodaoedu/daodao

依島島 GTM 策略產出 TA 導向的行銷內容——部落格文章、社群貼文（Threads/IG/FB）、回覆別人的文案。Use when user says "寫一篇文章"、"寫貼文"、"幫我回覆這篇"、"招生文"、"揪團文"、"寫 threads"、"content"、"文案"。自動套用語氣鐵律、TA 痛點語言與模板 CTA。

2026-07-100

product-status-check

daodaoedu/daodao

規劃或實作任何 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.

2026-07-060

monthly-insights

daodaoedu/daodao

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.

2026-06-020

practice-completion-email

daodaoedu/daodao

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.

2026-06-020

notion-card

daodaoedu/daodao

在 daodao 任務 Notion DB 建立新卡片。Use when user says "開 Notion 卡"、"建 notion 單"、"新增任務"、"create notion card"、"開一張卡"、"記到 notion"。從對話或報告自動推斷欄位，互動確認後建立。

2026-05-100

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 定稿後，詢問使用者：「要進入開發規劃嗎？」

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 存放位置