enterprise-prd-writer
企業 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 - 產品設
Profile →npx skills add skinnerlee1225/enterprise-prd-toolkit --skill enterprise-prd-writer --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# 企業 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 對技術可
- 1. 核心定位
- 完成標準
- 2. 角色邊界
- 強制原則
- 3. 文件結構
- 3.0 輕量模式（小案子的降級路徑）
- 3.1 完整結構
- 核心不可省略項目
- 4. 文件資訊
- 5. Executive Summary
- 6. 背景與問題定義
- 必須包含
- 問題陳述格式
- 禁止事項
What does the enterprise-prd-writer skill do?
企業 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 - 產品設
How do I install it?
Run `npx skills add skinnerlee1225/enterprise-prd-toolkit --skill enterprise-prd-writer --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From skinnerlee1225/enterprise-prd-toolkit, a repository with 37 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.