/enterprise-prd-writer

name: enterprise-prd-writer
description: |
  企業 PRD Writer — 受監管 / 金流 / 風控 / 跨職能團隊等級的產品需求文件撰寫與強化工具，
  用於產出可直接進入 Refinement、Engineering Design、Development、QA 與 UAT 的
  「施工藍圖」等級文件。相對於輕量版 prd-writer，此版本額外涵蓋權限矩陣、NFR、
  依賴管理、合規、Analytics/Observability、Rollout/Migration/Rollback 與 UAT/Release Readiness。
  預設以 interactive-html-report 規格輸出互動式 HTML（含常駐目錄側欄、捲動高亮）。

  ⚠️ 版本選擇（重要）：
  當使用者說「幫我寫 PRD」但未指明版本時，先問使用者要用「輕量版（prd-writer）」
  還是「企業版（本 skill）」再開始。判斷提示：個人專案 / 單一功能 / 無合規需求 → 輕量版；
  多團隊 / 金流 / 風控 / 合規 / 需上線維運全鏈路 → 企業版。使用者已明確指定版本時直接照做，不必再問。

  當使用者提出以下需求時，應優先使用此 skill：
  - 幫我寫 PRD
  - 產品需求文件
  - 寫 spec / feature spec
  - 功能規格 / 需求規格書
  - write a PRD / product requirements
  - 產品設計文件
  - 幫我整理這個功能的規格
  - 把這個想法寫成文件
  - 我要交一份產品文件給工程團隊
  - 寫個規格讓工程師可以直接開工
  - 補 AC / 驗收標準
  - 補 Out of Scope
  - 補畫面狀態
  - 補 Edge Cases
  - 補權限矩陣
  - 補 NFR
  - 補 Rollout / Rollback
  - 強化既有 PRD

  此 skill 的目標不是產出冗長文件，而是建立可執行、可測試、可追蹤、
  可討論且邊界明確的產品規格，降低因需求模糊造成的返工與認知落差。

  核心強制項目包含：
  - Acceptance Criteria
  - Edge Case Analysis
  - Screen / System States
  - In Scope / Out of Scope
  - Assumptions / Open Questions / Decisions
  - Dependencies
  - Roles & Permissions
  - Non-functional Requirements
  - Analytics / Observability
  - Rollout / Rollback
  - Complexity Assumption

企業 PRD Writer — 施工藍圖等級的產品需求文件

1. 核心定位

一份好的 PRD 不是單純的「想法整理」，也不是 PM 的個人思考筆記。

它應該是一份可供跨職能團隊共同使用的產品施工藍圖，用來明確定義：

• 要解決什麼問題
• 為誰解決
• 系統必須呈現什麼行為
• 哪些商業規則不可被誤解
• 哪些異常與邊界情境必須處理
• 哪些內容本期明確不做
• 哪些地方仍是假設、待確認或需技術評估
• 如何驗收、如何監控、如何上線、如何回退

完成標準

PRD 的完成，不以字數、頁數或圖表數量判斷，而以以下結果判斷：

1. 工程師可理解產品行為與商業規則，不需反覆追問本應由產品定義的內容。 2. QA 可根據文件直接拆出主要測試案例與邊界案例。 3. 設計師可理解各畫面、狀態、跳轉與例外情境。 4. 利害關係人清楚知道本期做什麼、不做什麼。 5. UAT 不應因需求語意模糊而出現大量「我以為」。 6. 所有不確定內容均被標記為 Assumption、Open Question 或 Pending Decision，而不是被 AI 擅自補成既定事實。

---

2. 角色邊界

PRD 應明確區分產品需求、產品建議與技術決策，避免 PM 越界指定技術實作，也避免工程團隊誤解哪些行為不可變更。

| 類型 | 定義 | 是否可由工程團隊調整 | |------|------|----------------------| | **Product Requirement** | 必須滿足的產品行為、商業規則、使用者結果、法規要求或 SLA | 不可直接變更，需與 Product 確認 | | **UX Requirement** | 互動流程、資訊架構、提示方式與可用性要求 | 可在不影響目標與 AC 的前提下討論 | | **Product Recommendation** | PM 對實作或流程的建議，不是強制技術方案 | 可由 Design / Engineering 提出替代方案 | | **Technical Decision** | 架構、資料結構、重試演算法、Queue、Cache、服務拆分等技術設計 | 由 Engineering 在 TDD / ADR 中決定 | | **Operational Requirement** | 後台操作、客服處理、稽核、人工介入與異常處置流程 | 需由 Product、Ops、Engineering 共同確認 |

強制原則

• 不應將技術建議寫成不可變更的產品要求。
• 不應要求 PRD 取代 Technical Design Document。
• 若某個技術細節會直接影響 SLA、合規、資金安全或使用者體驗，則可列入 PRD，但需說明其產品理由。
• Engineering 對技術可行性、效能、架構與最終技術複雜度擁有最終評估權。

---

3. 文件結構

3.0 輕量模式（小案子的降級路徑）

**觸發條件（符合任一即啟用）：** 個人專案、單一功能、無合規/金流/風控需求、單人或單團隊開發。

輕量模式下**只產出以下章節**，其餘章節整份標記 `N/A（輕量模式略過）`，不強制填寫：

• §5 Executive Summary（可壓縮成 3–5 句）
• §9 Scope（In / Out of Scope）
• §13 Functional Requirements
• §14 Acceptance Criteria
• §15 Edge Case Analysis（只跑相關類型，不強制 28 項全查）
• §17 Screen / System States（只列實際存在的狀態）

**不啟用**權限矩陣、NFR、Dependencies、Analytics、Rollout/Migration/Rollback、UAT/Release Readiness 等企業級章節，除非使用者明確要求。

> 目的：避免幫個人小工具寫 PRD 時，吐出一份 20 章的巨獸。若不確定是否為小案子，先問使用者一句「這是要走輕量還是完整企業級？」。

3.1 完整結構

PRD 應根據產品規模調整深度，但以下章節為標準結構：

1. 文件資訊
2. Executive Summary
3. 背景與問題定義
4. 產品目標與成功指標
5. 使用者與使用情境
6. Scope
   ├── In Scope
   ├── Out of Scope
   └── Phase Boundary
7. Assumptions / Open Questions / Decisions
8. Dependencies
9. Roles & Permissions
10. Functional Requirements
    ├── 功能描述
    ├── 商業規則
    ├── Acceptance Criteria
    ├── Edge Cases
    └── Out of Scope
11. User Flow / System Flow
12. Screen / System States
13. Data & Integration Requirements
14. Non-functional Requirements
15. Analytics & Observability
16. Risk & Mitigation
17. Rollout / Migration / Rollback
18. MVP / Roadmap / Complexity Assumption
19. UAT & Release Readiness
20. Appendix

核心不可省略項目

• Acceptance Criteria
• Edge Case Analysis
• Screen / System States
• In Scope / Out of Scope
• Assumptions / Open Questions
• Dependencies
• Roles & Permissions
• 後台安全控制清單（金融級，涉及後台/admin 時強制）
• NFR
• Rollout / Rollback
• Complexity Assumption
• Final Validation Checklist

---

4. 文件資訊

每份 PRD 開頭需包含基本治理資訊：

| 欄位 | 內容 | |------|------| | Document Title | 文件名稱 | | Owner | Product Owner / PM | | Status | Draft / In Review / Approved / Deprecated | | Version | 文件版本 | | Last Updated | 最後更新日期 | | Reviewers | Design / Engineering / QA / Ops / Compliance 等 | | Target Release | 預計版本或日期 | | Related Documents | Wireframe、TDD、API Spec、ADR、Research、Ticket 等 | | Decision Log | 關鍵決策與日期 |

---

5. Executive Summary

用最短篇幅回答以下問題：

• 這個產品或功能解決什麼問題？
• 目標使用者是誰？
• 為什麼現在要做？
• 預期帶來什麼結果？
• 本期交付的核心範圍是什麼？

避免在此處放入大量細節。Executive Summary 的目的，是讓決策者在 1–3 分鐘內理解需求價值與交付邊界。

---

6. 背景與問題定義

必須包含

• 現況
• 使用者痛點
• 商業痛點
• 現有流程的問題
• 數據或事實依據
• 不處理的代價
• 問題陳述

問題陳述格式

[目標使用者] 在 [情境] 下，因為 [根本原因]，
目前無法有效完成 [核心任務]，
導致 [使用者 / 商業 / 風險結果]。

禁止事項

• 不得把解法當成問題。
• 不得僅寫「老闆希望做」。
• 若缺乏數據，需明確標記為 Assumption，不得虛構數字。

---

7. 產品目標與成功指標

目標

每個目標應具備：

• 明確對象
• 明確行為
• 明確結果
• 可觀測性
• 與問題陳述的直接關聯

KPI 表格

| 指標 | 定義 | Baseline | Target | Measurement Window | Data Source | Owner | |------|------|----------|--------|--------------------|-------------|-------| | [指標名稱] | [計算方式] | [目前值] | [目標值] | [觀察週期] | [事件 / DB / BI] | [Owner] |

指標分類

• Business Metrics
• Product Adoption
• Conversion
• Retention
• Operational Efficiency
• Error Rate
• Latency
• Risk / Compliance
• Customer Support Impact

若 Baseline 或 Target 不確定，標記為 `TBD`，並列入 Open Questions。

---

8. 使用者與使用情境

使用者定義

| User Type | 目標 | 痛點 | 使用頻率 | 主要權限 | |-----------|------|------|----------|----------| | [角色] | [目標] | [痛點] | [頻率] | [權限] |

使用情境

每個主要情境需描述：

• Actor
• Trigger
• Preconditions
• Main Flow
• Alternate Flow
• Success Outcome
• Failure Outcome

---

9. Scope 管理

In Scope

明確列出本期交付內容。

Out of Scope

明確列出本期不處理的內容，避免利害關係人、設計與工程自行延伸。

**Out of Scope（[功能名稱]）：**
1. [不做的事]
2. [延後到後續階段的內容]
3. [由其他系統或團隊負責的內容]

分期表格

| 階段 | In Scope | Out of Scope | Entry Criteria | Exit Criteria | |------|----------|--------------|----------------|---------------| | MVP |