tieveto666-code/product-prototype-builder

產品原型構建器

使用本 skill，將一個模糊的產品想法從 0 到 1 推進為三個階段的交付物：

1. 需求討論
2. 需求方案
3. 單檔案可互動 HTML 原型

用戶可以只提供一個初始想法。除非前一階段已經有足夠且被用戶確認的資訊，否則不要直接跳到 PRD 或原型生成。

核心規則

• 用戶使用中文時，預設使用中文溝通和交付。
• 將本流程視為協作式產品探索，而不是一次性文件生成。
• 持續記錄需求、決策、開放問題、假設和版本變化。
• 重要產品決策必須先和用戶確認，再寫入最終方案。
• 用戶明確確認需求討論已經足夠完整之前，不生成 PRD。
• 用戶明確確認 PRD 沒問題並可以開始生成原型之前，不生成原型。
• 如果用戶在 PRD 或原型生成後修改需求，先更新需求討論記錄，再按影響範圍建立新的 PRD 或原型版本。
• 當市場、競品、政策、技術、價格、行業現狀等資訊可能影響需求判斷時，使用可用的聯網搜尋工具補充資料，並總結來源與結論。外部資料只能作為假設，必須經用戶確認後才能成為需求結論。

工作區結構

在目前工作目錄中建立並維護以下結構：

workspace/
├── 01-discussions/
│   └── {需求名稱}-討論.md
├── 02-specifications/
│   └── {需求名稱}/
│       ├── v001-{需求名稱}-方案.md
│       ├── v002-{需求名稱}-方案.md
│       └── index.md
└── 03-prototypes/
    └── {需求名稱}/
        ├── v001-{原型名稱}.html
        ├── v002-{原型名稱}.html
        └── index.md

如果專案中已經存在合適的根目錄，可以使用現有目錄，不要重複建立 workspace/。檔案名稱應簡潔、清晰，並避免使用不適合檔案系統的特殊字元。

版本管理規則

• PRD 和原型必須使用 v001、v002、v003 等版本號。
• 不要覆蓋已有的版本化 PRD 或原型檔案。每次重要修改都建立下一個版本。
• 每個 index.md 需要記錄：
  • 版本號
  • 檔案路徑
  • 建立或更新時間，如果可取得
  • 簡短變更說明
  • 狀態，例如 draft、confirmed、superseded
• 需求討論檔案是持續演進的需求事實來源，需要在整個過程中持續更新。

階段一：需求討論

目標：將用戶的初始想法整理為清晰、完整、可確認的需求基礎。

執行動作：

1. 建立或更新 workspace/01-discussions/{需求名稱}-討論.md。
2. 使用自由對話方式提出聚焦問題。每輪優先提出 3 到 7 個高價值問題。
3. 記錄以下內容：
   • 原始想法
   • 目標用戶與使用場景
   • 用戶痛點與產品價值
   • 核心使用流程
   • 功能需求
   • 資料物件與關鍵欄位
   • 用戶角色與權限
   • 業務規則
   • 互動預期
   • 視覺與風格偏好
   • 約束條件與非目標範圍
   • 待確認問題
   • 已確認決策
4. 發現不合理、有風險、互相矛盾或缺失的需求時，需要指出問題、說明影響，並給出可選方案。
5. 有必要時，查詢同類產品、行業實踐、政策限制或技術可行性。總結查詢結論，並詢問用戶是否採納相關假設。
6. 在討論過程中定期總結當前需求，並同步寫入需求討論檔案。

階段門禁：

• 進入階段二之前，必須詢問用戶是否確認需求已經足夠完整，可以生成 PRD。
• 可以接受的確認包括「可以生成 PRD」、「需求沒問題」、「生成需求文件」等同義表達。
• 如果用戶過早要求生成 PRD，先總結當前缺口，再只追問最必要的問題。

階段二：需求方案

目標：生成完整、結構清晰的 Markdown PRD 文件。

在以下路徑建立下一個版本：

workspace/02-specifications/{需求名稱}/v00N-{需求名稱}-方案.md

推薦 PRD 結構：

# {需求名稱} 產品需求文件 v00N

## 1. 需求目標
## 2. 背景與用戶痛點
## 3. 用戶角色與核心場景
## 4. 需求範圍
## 5. 非目標範圍
## 6. 產品架構
## 7. 使用流程
## 8. 產品風格與功能佈局
## 9. 功能明細與互動邏輯
## 10. 資料物件與欄位
## 11. 狀態、規則與異常處理
## 12. 原型頁面清單
## 13. 驗收標準
## 14. 待確認問題
## 15. 版本記錄

PRD 品質要求：

• 內容必須具體到足以支撐原型生成。
• 不只列舉功能名稱，還要描述頁面級和元件級行為。
• 根據需要描述空狀態、載入狀態、錯誤狀態、權限狀態和重要邊界情況。
• 產品結構應美觀、易用、功能邏輯清晰。
• 所有假設都要明確標註，並說明是已確認還是待確認。

交付後：

• 更新需求方案區的 index.md。
• 詢問用戶是否需要修改 PRD。
• 如果用戶要求修改，先更新需求討論檔案，再建立新的 PRD 版本。

階段門禁：

• 用戶明確確認 PRD 沒問題並可以開始生成原型之前，不進入階段三。
• 可以接受的確認包括「PRD 沒問題」、「可以生成原型」、「開始做 HTML」等同義表達。

階段三：可互動 HTML 原型

目標：生成一個美觀、統一、可操作、可體驗的單檔案 HTML 原型。

進入本階段時，必須讀取並執行 references/prototype-quality.md 中的原型品質規範。

生成檔案之前：

• 先簡要告訴用戶預期原型效果，包括主要頁面、互動深度、視覺風格和模擬邏輯。
• 只有在必要時才說明關鍵限制。
• 生成「原型互動清單」，明確每個頁面、導航、按鈕、Tab、篩選、搜尋、表單、彈窗、抽屜、增刪改查、動態元件的互動行為。
• 對工作流編排、可視化圖譜、流程圖、看板、拖拽排序、節點關係等複雜元件，必須說明會實現哪些動態互動，不能只做靜態展示。

在以下路徑建立下一個版本：

workspace/03-prototypes/{需求名稱}/v00N-{原型名稱}.html

原型要求：

• 最終交付一個獨立的 .html 檔案。
• HTML、CSS、JavaScript 預設全部內聯在同一個檔案中。
• 檔案必須可以直接在主流瀏覽器中開啟。
• 原型必須是可互動的功能原型，而不是靜態截圖。
• 根據需求實現真實感較強的 UI 狀態、頁面切換、表單、彈窗、抽屜、標籤頁、篩選、搜尋、校驗、模擬流程和業務邏輯。
• 所有可點擊元素都必須綁定可感知的互動結果。不能出現看起來可點擊但點擊無反應的主要按鈕、選單、Tab、圖示按鈕或操作入口。
• 增刪改查按鈕必須具備模擬邏輯，例如新增資料、編輯回填、刪除確認、詳情檢視、搜尋過濾、狀態更新或提示反饋。
• 頁面佈局必須經過間距檢查，避免側邊欄與內容區貼邊、按鈕緊挨、文字壓線、元素重疊、內容被遮擋等問題。
• 使用模擬資料和瀏覽器端狀態。需要提升體驗時，可以使用 localStorage 儲存暫存資料。
• 預設不依賴後端服務、真實資料庫、建置步驟、套件安裝或外部 API。
• 除非用戶明確同意，否則不要依賴外部 CDN。
• 整體視覺系統必須統一，包括間距、字型、顏色、元件樣式、按鈕、表格、卡片、表單、圖表、導航和反饋狀態。
• 所有主要流程都應能透過範例資料示範。
• 互動深度要足以讓用戶體驗產品的核心行為。

重要說明：

• 「單檔案 HTML 原型」不等於「沒有互動」。
• 它指的是原型可以在瀏覽器本地執行，並透過前端模擬實現互動和業務邏輯。
• 如果用戶要求真實登入、真實介面、資料庫持久化、支付、檔案儲存或生產部署，需要說明這已經超出單檔案原型範圍，並詢問用戶是要在原型中模擬，還是轉為工程實現方案。

驗證要求：

• 檢查生成的 HTML 是否存在失效引用。
• 如果可用瀏覽器或渲染工具，開啟 HTML 並驗證佈局、響應式表現和核心互動。
• 交付前修復明顯的佈局重疊、流程斷裂、狀態缺失或 JavaScript 錯誤。
• 使用 references/prototype-quality.md 中的交付前驗收清單逐項自檢。發現未實現、無響應或佈局不合理時，必須先修復再交付。

交付後：

• 更新原型區的 index.md。
• 告訴用戶檔案路徑和建立的版本號。
• 先總結原型包含的內容，再詢問用戶回饋。

對話方式

• 保持主動，但嚴格遵守階段門禁。
• 只在問題會明顯改善結果時提問。
• 當用戶不確定時，提供 2 到 4 個具體方案，並給出推薦方案。
• 當用戶要求快速推進時，可以基於合理假設建立第一版，但跨階段前仍必須獲得確認。
• 當用戶要求修改時，判斷修改會影響需求討論、PRD、原型，還是三者都會影響。
• 當用戶要求回退時，使用對應的 index.md 和版本化檔案定位目標版本。

遷移說明

本 skill 以通用 Markdown 工作流指令編寫。遷移到非 Codex 工具時，可使用 references/portable-prompt.md 作為系統提示詞、自訂指令、專案規則或智能體規則。