prd-writer

name	prd-writer
description	協助撰寫完整、結構化、可執行的 PRD（產品需求文件），確保工程可行性、風險管理、範疇清晰與驗收方式明確。

PRD Writer Skill

描述

PRD 撰寫技能,協助產品與工程團隊撰寫完整、結構化且可落地執行的產品需求文件,確保需求清晰、可測試且可交付。

職責

• 引導完成 PRD 結構與內容
• 確保需求的完整性與可測試性
• 協助定義清晰的範疇（Scope）與非範疇（Out-of-scope）
• 識別風險並提供緩解策略
• 提供 PRD 模板與範例
• 進行 PRD 品質自我檢查

能力

1. PRD 結構引導

協助建立完整的 PRD 結構：

• 基本資訊：標題、狀態、作者、最後更新、相關連結
• 摘要（TL;DR）：一句話描述、關鍵資訊
• 目標與問題定義：Problem Statement、Goals、Non-goals、Success Metrics
• 使用者與情境：Personas、User Journey、Edge Cases
• 需求規格：功能需求（FR）、非功能需求（NFR）
• 解法與架構：系統架構、資料模型、相依性
• 風險與法遵：風險清單、個資隱私、法規合規、濫用情境
• 交付計畫：MVP 定義、上線策略、回滾方案
• 驗收標準：Acceptance Criteria、測試策略、監控告警
• 附錄：術語表、未決問題、變更歷史

2. 需求撰寫原則指導

確保需求品質：

• Why before What：先解釋「為什麼要做」，再說明「做什麼」
• Testable：所有需求都應可測試、可驗證
• Scoped：清楚定義範圍內/外（In-scope / Out-of-scope）
• Risk-aware：識別風險並提供緩解策略
• Deliverable：可在合理時間內交付，支援分階段上線

3. 功能需求撰寫

協助撰寫具體的功能需求：

• 描述：清楚說明功能做什麼
• 觸發條件：何時/如何觸發
• 輸入：需要哪些輸入參數/資料
• 輸出：產生什麼結果/狀態變化
• 驗收標準：可測試的標準（Given-When-Then 格式）

4. 非功能需求撰寫

協助定義 NFR：

• 效能：回應時間、吞吐量、資料量
• 可靠性：可用性、錯誤率、資料一致性
• 可擴展性：橫向擴展、負載預估
• 安全性：認證/授權、資料加密、稽核日誌
• 可觀測性：日誌、指標、追蹤、告警
• 可維運性：部署方式、回滾策略、資料遷移

5. 風險識別與緩解

協助識別並管理風險：

• 風險清單：識別潛在風險（技術、業務、法遵）
• 嚴重性評估：評估風險的嚴重性與機率
• 緩解策略：提供具體的緩解方案
• 備援計畫：規劃 Fallback/Rollback 方案

6. 交付計畫撰寫

協助規劃可執行的交付計畫：

• MVP 定義：清楚定義最小可行產品範圍
• 里程碑規劃：設定階段性目標
• 上線策略：Feature Flag、灰度發佈、金絲雀部署
• 回滾方案：定義回滾觸發條件與步驟

7. 驗收標準撰寫

協助撰寫可測試的驗收標準：

• 功能驗收：使用 Given-When-Then 格式
• 非功能驗收：定義效能、安全、可靠性標準
• 測試策略：規劃單元、整合、E2E 測試
• 監控告警：定義關鍵指標與告警規則

8. PRD 品質檢查

提供自我檢查清單：

• 基本品質：標題、摘要、必填區段
• 內容品質：問題陳述、目標、成功指標
• 技術可行性：相依性、風險、NFR、驗收標準
• 交付計畫：MVP、上線策略、回滾方案、監控
• 合規與安全：個資、權限、法規、濫用情境

工作流程

階段 1：需求收集

1. 與使用者確認問題陳述
2. 識別目標使用者（Persona）
3. 釐清核心目標與成功指標
4. 定義範疇（In-scope / Out-of-scope）

階段 2：PRD 框架建立

1. 複製 PRD 模板
2. 填寫基本資訊與摘要
3. 完成目標與問題定義區段
4. 撰寫使用者與情境

階段 3：需求規格撰寫

1. 撰寫功能需求（FR）
2. 定義非功能需求（NFR）
3. 提供參考解法（選填）
4. 識別相依性

階段 4：風險與交付規劃

1. 建立風險清單與緩解策略
2. 檢查法遵與安全需求
3. 定義 MVP 與交付計畫
4. 撰寫驗收標準與測試策略

階段 5：審查與迭代

1. 執行品質自我檢查
2. 與工程團隊 review 可行性
3. 根據回饋更新 PRD
4. 確認所有未決問題都已處理

PRD 模板結構

# [功能名稱] PRD

**文件狀態**: Draft | In Review | Approved | Implemented  
**作者**: [姓名]  
**最後更新**: YYYY-MM-DD  
**相關連結**: [Jira/GitHub Issue] | [設計稿] | [技術規格]

---

## 📋 摘要 (TL;DR)

**一句話描述**: [功能做什麼、為誰解決什麼問題]

**關鍵資訊**:
- **目標使用者**: [Persona]
- **主要價值**: [解決的核心問題]
- **預計交付**: [時間/里程碑]
- **核心指標**: [1-2 個關鍵成功指標]

---

## 🎯 1. 目標與問題定義

### 1.1 問題陳述
[具體描述問題，附上數據或案例]

### 1.2 目標
**核心目標**:
1. [可衡量的目標 1]

### 1.3 非目標
- ❌ [不做的功能 1]

### 1.4 成功指標
- [指標]: [目標值]

---

## 👥 2. 使用者與情境

### 2.1 目標族群
[Persona 描述]

### 2.2 使用情境
[User Journey 步驟]

### 2.3 例外處理
[Edge Cases]

---

## 📦 3. 需求規格

### 3.1 功能需求
#### FR1: [功能名稱]
**描述**: [功能做什麼]  
**驗收標準**:
- [ ] [Given...When...Then]

### 3.2 非功能需求
#### 效能
- **回應時間**: [目標值]

#### 安全性
- **認證/授權**: [權限模型]

---

## ⚠️ 5. 風險、法遵與安全

### 5.1 風險清單
| 風險 | 嚴重性 | 緩解策略 |
|------|--------|----------|
| [風險 1] | High | [策略] |

### 5.2 個資與隱私
- **個資類型**: [收集哪些]
- **使用目的**: [為何需要]

---

## 🚀 6. 交付計畫

### 6.1 MVP 定義
**Phase 1 (MVP)**:
- ✅ [核心功能 1]

### 6.2 上線策略
- **灰度發佈**: [比例與時程]
- **Feature Flag**: [Flag 名稱]
- **回滾方案**: [觸發條件與步驟]

---

## ✅ 7. 驗收標準與測試策略

### 7.1 驗收標準
- [ ] [Given...When...Then]

### 7.2 測試策略
- **單元測試**: [覆蓋率目標]
- **整合測試**: [測試範圍]

### 7.3 監控與告警
- `metric.name`: [描述]

---

## 📄 8. 附錄

### 8.1 術語表
| 術語 | 定義 |
|------|------|
| [Term] | [定義] |

### 8.2 未決問題
- [ ] **Q1**: [問題] - Owner: [@person]

### 8.3 變更歷史
| 日期 | 版本 | 變更內容 |
|------|------|----------|
| YYYY-MM-DD | v0.1 | 初稿 |

最佳實踐

撰寫時注意

• 使用清晰、具體的語言
• 提供數據支持問題陳述
• 區分需求與解法
• 使用可測試的驗收標準
• 考慮風險與相依性

避免的反模式

• ❌ 混淆「需求」與「解法」
• ❌ 使用模糊詞彙（「盡可能」、「更好」、「優化」）
• ❌ 缺少成功指標或驗收標準
• ❌ 忽略 Edge Cases、錯誤處理、權限管理
• ❌ 未考慮相依性與整合點

品質檢查清單

撰寫完成後自我檢查：

基本品質 (必須):

• 標題清楚描述功能
• 摘要能讓人快速理解
• 所有必填區段都已完成

內容品質 (必須):

• 問題陳述有數據支持
• 目標可衡量（SMART）
• 非目標明確列出
• 成功指標定義清楚

技術可行性 (必須):

• 相依性都已識別
• 風險有緩解策略
• NFR 已定義
• 驗收標準可測試

交付計畫 (必須):

• MVP 範圍清楚
• 上線策略明確
• 回滾方案可執行
• 監控告警已規劃

合規與安全 (必須):

• 個資處理符合法規
• 權限模型明確
• 濫用情境有防護

相關資源

• Product Requirements Document Template
• Writing Effective User Stories
• SMART Goals
• Risk Management