SKILL.md
PRD Review Skill
描述
PRD 審查技能，協助產品與工程團隊進行完整且深入的產品需求文件審查，確保需求清晰、可執行且風險可控。
職責
- 審查 PRD 的完整性與一致性
- 評估工程可行性與技術風險
- 檢查範疇定義與驗收標準
- 識別法遵、安全與隱私風險
- 評估交付計畫的合理性
- 提供具體的改善建議
能力
1. 目標與問題定義審查
確保需求的必要性與清晰度：
- 問題陳述：檢查是否清楚、可驗證（Problem Statement）
- 目標設定：確認 Goals 與 Non-goals 是否明確
- 成功指標：評估 Success Metrics / KPI 是否可衡量
- 價值對齊：確認需求動機、使用者價值與商業價值是否一致
2. 使用者與情境分析
評估使用者需求的完整性：
- 目標族群：確認 Persona / 目標族群是否清楚
- 使用情境：檢查 User Journey / Jobs-to-be-done 是否完整
- 極端情況：評估 Edge cases 是否被涵蓋
- 無障礙與國際化：確認 Accessibility 與 i18n 需求
3. 需求完整性與一致性
確保需求規格的品質：
- 功能需求：檢查 Functional Requirements 是否具體、可測試
- 非功能需求：評估 NFR（效能、可靠性、可用性、可維運性）
- 範疇衝突：識別與現有系統/流程的衝突或重疊
- 術語一致性：確認名詞與定義是否一致（Glossary）
4. 工程可行性評估
從技術角度審查需求：
- 需求與解法分離：檢查是否清楚區分，解法是否有替代方案
- 相依性管理：識別系統、團隊、第三方服務、資料來源相依性
- 資料流與權限：評估資料流、狀態管理、權限模型的合理性
- 擴充性考量：檢查 Scalability、可回溯/審計需求
5. 風險、法遵與安全審查
識別潛在風險與合規問題：
- 個資隱私：檢查 PII、資料保留與刪除政策
- 權限與濫用：評估 RBAC、濫用情境（Abuse cases）
- 法規合規：確認 GDPR/CCPA/在地法規需求
- 風險緩解：檢查風險清單、緩解策略與備援方案
6. 可交付性評估
評估執行計畫的合理性：
- MVP 定義：確認 MVP 定義清楚、可在合理時間交付
- 階段性上線：檢查 Milestones、Phased rollout 策略
- 部署策略：評估 Feature Flag、灰度/金絲雀、回滾方案
- 工作拆分：檢查是否提供 Epics/Stories 拆分與估算基準
7. 驗收標準與測試策略
確保可測試性：
- 驗收標準：檢查 Acceptance Criteria 是否明確且可測
- 測試策略：評估單元/整合/E2E 測試規劃
- 可觀測性：確認 logging/metrics/tracing 需求
- 上線後驗證：檢查 Post-launch validation 與 A/B Test
8. 文件品質評估
確保文件的可讀性與完整性：
- 結構清晰度：評估摘要、背景、需求、範疇、風險、驗收結構
- 視覺化需求：識別需要的圖表（流程圖、狀態圖、線框稿）
- 審核流程：確認需要的利害關係人（Eng/QA/Sec/Legal/Data）
- 未決問題：檢查 Open Questions 是否列出並指派 owner
工作流程
階段 1：快速掃描
- 檢查 PRD 結構完整性
- 閱讀摘要（TL;DR）與目標
- 識別明顯缺失的區段
階段 2：逐項審查
按照八大面向進行深度審查：
- 目標與問題定義
- 使用者與情境
- 需求完整性
- 工程可行性
- 風險與法遵
- 可交付性
- 驗收標準
- 文件品質
階段 3：風險評估
- 識別高風險項目
- 評估風險緩解策略
- 確認相依性與阻礙
階段 4：回饋產出
- 將問題分類：
- 🔴 Critical Issues：必須修正才能簽核/開發 - 🟡 Suggestions：建議改善的項目 - ✅ Good Practices：做得好的地方
- 為每個問題提供：
- 段落/章節位置引用 - 清楚的問題說明 - 建議補強的內容（可直接貼回 PRD 的範例） - 修改理由
輸出格式
## 🔴 Critical Issues - Must fix before sign-off / implementation
### Issue 1: [問題標題]
**位置**: §2.1 [章節名稱]
**問題說明**:
[清楚描述問題]
**建議補強**:[可直接貼回 PRD 的內容範例]
**修改理由**:
[解釋為什麼要改，對齊風險、成本、可測試性或可交付性]
---
## 🟡 Suggestions - Improvements to consider
[同上格式]
---
## ✅ Good Practices - What's done well
- [做得好的項目 1]
- [做得好的項目 2]最佳實踐
審查時注意
- 以「工程可行性」為核心視角
- 區分「必須有」與「最好有」
- 關注風險與相依性
- 提供可執行的改善建議
避免的反模式
- ❌ 只挑剔格式不關注實質內容
- ❌ 要求過度詳細的技術規格（應在技術設計文件）
- ❌ 忽略法遵與安全問題
- ❌ 不考慮時程與資源限制
審查檢查清單
使用此清單快速檢查 PRD 品質：
基本品質 (10%):
- 標題清楚描述功能
- 摘要能讓人快速理解核心內容
- 所有必填區段都已完成
內容品質 (30%):
- 問題陳述有數據支持
- 目標可衡量（SMART 原則）
- 非目標明確列出
- 成功指標定義清楚
技術可行性 (30%):
- 相依性都已識別
- 風險有緩解策略
- NFR（效能/安全/可靠性）已定義
- 驗收標準可測試
交付計畫 (20%):
- MVP 範圍清楚
- 上線策略明確
- 回滾方案可執行
- 監控告警已規劃
合規與安全 (10%):
- 個資處理符合法規
- 權限模型明確
- 濫用情境有防護