product-playbook 1.0.0

package/i18n/zh-TW/references/04c-mvp.md

@@ -0,0 +1,21 @@
+# 階段三：Develop — MVP 範圍定義
+
+## 3.7 MVP 範圍定義
+
+MVP 判斷標準：**能否驗證核心假設？能否讓目標用戶完整體驗 Primary JTBD？**
+
+```
+| 類別 | MVP 必須有 | V2 再加入 | 未來考慮 |
+|---|---|---|---|
+| 核心功能 | | | |
+| 用戶體驗 | | | |
+| 技術需求 | | | |
+```
+
+**Not Doing List（同等重要）：**
+
+```
+| 不做的事 | 不做的理由 |
+|---------|-----------|
+| | |
+```

package/i18n/zh-TW/references/05a-northstar-aha.md

@@ -0,0 +1,93 @@
+# 階段四：Deliver — North Star + Aha Moment
+
+## 4.1 Marty Cagan 的賦能型團隊原則（Empowered Teams）
+
+**適用於：高完整性 / 產出對象為老闆/跨部門**
+
+> 4.1 Empowered Teams 在產出對象為老闆/跨部門時才展示，否則跳過。
+
+```
+| 面向 | 功能型團隊（避免） | 賦能型團隊（目標） |
+|------|-----------------|-----------------|
+| 被分配到的 | 功能清單（Output） | 需要解決的問題（Outcome） |
+| 成功定義 | 按時交付功能 | 達成用戶和商業指標 |
+| PM 的角色 | 需求收集者和項目管理者 | 問題探索者和解法驗證者 |
+| 工程師的角色 | 執行規格 | 參與問題探索和解法設計 |
+```
+
+> 「真正的產品發現是與工程師和設計師**一起**做的，而不是 PM 一個人做完再交給他們。」— Marty Cagan
+
+**Lenny 的 PM 三職責：**
+- **Shape（塑形）**：整合用戶洞見、數據和市場資訊，決定做什麼
+- **Ship（交付）**：確保高品質產品按時上線，沒有意外
+- **Synchronize（同步）**：讓所有利害關係人對願景、策略、目標和路線圖保持一致
+
+## 4.2 成功指標框架（North Star + 三層訊號）
+
+北極星指標必須滿足：
+- 能反映用戶獲得的真實價值（不是虛榮指標）
+- 可以持續增長（不會天然達到上限）
+- 能讓整個團隊在同一個目標下對齊
+
+```
+| 公司 | 北極星指標 | 為什麼這個指標 |
+|------|----------|---------------|
+| Airbnb | 訂出的住宿晚數 | 代表主客雙方都獲得了價值 |
+| Spotify | 每月聆聽時長 | 代表用戶真正在使用和享受音樂 |
+| Facebook | DAU / MAU 比率 | 代表用戶習慣性回訪 |
+| Slack | 每週發送的訊息數 | 代表團隊真正在協作 |
+| Salesforce | 活躍客戶合約年度價值（ACV） | 代表客戶持續從產品獲得商業價值（B2B） |
+```
+
+**你的北極星指標：**
+```
+北極星指標：[一個數字，代表用戶和產品創造的核心價值]
+定義：[精確的計算方式]
+為什麼這個指標：[說明它為什麼代表真實用戶價值，而不只是商業結果]
+```
+
+### 📝 North Star 品質自檢清單
+- ✅ 是否反映用戶獲得的價值？（不是營收、不是 DAU）
+- ✅ 是否能持續增長？（不會天然到達上限）
+- ✅ 團隊每個人看到這個指標是否都知道自己該做什麼？
+- ✅ 是否可以被操弄？（如果可以，需要護欄指標）
+- ✅ B2B 產品：是否反映客戶組織層級的價值，而非只有個人使用者？
+- ❌ 常見問題：用營收當 North Star（營收是結果不是驅動因素）、指標太複合無法行動
+
+**三層訊號體系（必須依序達標）：**
+
+```
+| 層級 | 指標類型 | 定義 | B2C 目標值 | B2B 目標值 |
+|---|---|---|---|---|
+| 層級一（前提） | 核心動作成功率 | 用戶是否完成了產品的核心動作？ | 30-40%+ | 60-80%+（因為用戶更有動機） |
+| 層級二（價值代理） | D14 / D28 留存率 | 用戶是否持續回來使用？ | 消費產品 15-20%+ | Logo 留存 90%+；Net Revenue Retention 100%+ |
+| 層級三（熱情訊號） | Sean Ellis Score | 「如果失去這個產品，你會多難過？」 | 40%+ 回答「非常難過」 | 40%+ 回答「非常難過」 |
+| 護欄指標 | 防止過度優化 | 確保不傷害其他重要面向 | 視情況而定 | 視情況而定 |
+```
+
+說明：層級一是層級二的前提。如果核心動作成功率很低，留存率數據就沒有意義，因為用戶根本沒有機會體驗到產品價值。
+
+## 4.4 Aha Moment 設計
+
+```
+Aha Moment 定義：
+當用戶完成 [具體行為]，他們就體驗到了這個產品的核心價值。
+目標：在用戶進入產品的 [X 分鐘 / X 步驟] 內讓他們到達這個時刻。
+
+Aha Moment 到達率：[目標 %]
+當前障礙：[什麼阻止了用戶更快到達 Aha Moment？]
+改善計畫：[如何移除障礙？]
+```
+
+**範例：**
+| 產品 | Aha Moment | 時間目標 |
+|------|-----------|---------|
+| Slack | 團隊發送第 2,000 條訊息 | 前兩週 |
+| Dropbox | 第一個檔案同步到第二台裝置 | 首次使用 10 分鐘內 |
+| Zoom | 第一次一鍵加入會議且畫面流暢 | 第一次使用 |
+
+### 📝 Aha Moment 品質自檢清單
+- ✅ 是否是一個具體的、可追蹤的行為？（不是「感覺產品好用」）
+- ✅ 是否與 JTBD 的功能性工作直接相關？
+- ✅ 到達時間目標是否合理？（B2C 應在首次使用內；B2B 可能在試用期內）
+- ✅ 是否可以設計 Onboarding 來引導用戶更快到達？

package/i18n/zh-TW/references/05b-pmf-gtm.md

@@ -0,0 +1,102 @@
+# 階段四：Deliver — PMF + GTM + 商業模式
+
+## 4.3 Todd Jackson（First Round Capital）的四級 PMF 框架
+
+```
+| 等級 | 名稱 | 特徵 | 你的任務 | 典型公司階段 |
+|-----|------|------|---------|------------|
+| Level 1 | Nascent PMF（初萌的 PMF） | 找到 3-5 個願意為解法付費的客戶 | 深度服務這些早期用戶，找到可重複的模式 | Pre-seed / Seed |
+| Level 2 | Developing PMF（發展中的 PMF） | 開始有口碑傳播，但增長還不穩定 | 找到可規模化的獲客渠道，提升留存 | Seed / Series A |
+| Level 3 | Strong PMF（強 PMF）| 「魚兒自己跳進船裡」，轉介紹成為主要增長來源 | 建立規模化需求渠道，提升效率指標 | Series A / B |
+| Level 4 | Extreme PMF（極端 PMF）| 指標穩健，公司超過 100 人，考慮擴展 TAM | 進入新市場或推出新產品 | Series C+ |
+```
+
+**Four P's（在 Level 1-2 階段找 PMF 的關鍵四問）：**
+1. Problem：你要解決的問題，是否真的足夠急迫、足夠重要？
+2. Promise：你的產品向用戶許下了什麼承諾？用戶相信嗎？
+3. Product：你的產品是否真的兌現了這個承諾？
+4. Pitch：你如何讓目標用戶發現並相信你的產品？
+
+## 4.7 GTM 策略（Go-to-Market）
+
+**適用於：完整模式 / 高完整性 / 產出對象為老闆/業務/行銷**
+
+產品做出來之後，如何讓目標用戶知道並開始使用？
+
+### 獲客渠道選擇
+
+```
+| 渠道類型 | 適合情境 | 典型方法 | 衡量指標 |
+|---------|---------|---------|---------|
+| 產品驅動增長（PLG） | 用戶自助能體驗到價值的產品 | 免費試用、Freemium、病毒式邀請 | 註冊轉換率、啟用率、邀請率 |
+| 內容與社群 | 目標用戶有共同的資訊需求或社群 | 部落格、SEO、社群運營、KOL | 流量、內容轉換率、社群活躍度 |
+| 付費獲客 | 需要快速驗證或有明確 ROI | SEM、社群廣告、再行銷 | CAC、ROAS、LTV/CAC |
+| 銷售驅動 | B2B 高客單價、需要 demo 和談判 | SDR、AE、Demo、企業合約 | Pipeline、Close rate、ACV |
+| 合作夥伴 | 目標用戶集中在某些平台或生態系 | API 整合、分潤、共同行銷 | 合作渠道轉換率、合作夥伴數 |
+```
+
+### 初始 100 位用戶獲取計畫
+
+```
+目標用戶畫像：[從 Persona 來]
+在哪裡找到他們：[他們聚集的線上/線下場所]
+用什麼 Hook 吸引他們：[從 PR-FAQ 的 Aha Moment 來]
+怎麼讓他們試用：[降低門檻的方法]
+初始目標：[X 天內獲得 Y 個試用用戶]
+```
+
+### Launch 策略
+
+| 策略 | 說明 | 適合情境 |
+|------|------|---------|
+| Closed Beta | 手動邀請 10-50 人，深度收集反饋 | PMF Level 1，產品還在調整 |
+| Open Beta | 公開但標明 Beta，降低期待管理 | PMF Level 1-2，需要更多數據 |
+| Soft Launch | 在特定市場或渠道低調上線 | 需要真實環境測試但不想全面曝光 |
+| Full Launch | 全渠道正式推出 | PMF Level 2-3，產品穩定 |
+
+## 4.8 商業模式與定價
+
+**適用於：完整模式 / 高完整性 / 產出對象為老闆/業務**
+
+### 收費模式選擇
+
+```
+| 模式 | 運作方式 | 適合產品類型 | 關鍵指標 |
+|------|---------|------------|---------|
+| Freemium | 基礎免費 + 進階收費 | 用戶量大、免費版能展示價值 | 免費→付費轉換率（目標 2-5%） |
+| Subscription | 按月/年訂閱 | 持續提供價值的工具或服務 | MRR/ARR、Churn rate |
+| 按用量（Usage-based） | 用多少付多少 | API、雲端服務、交易平台 | 每用戶平均消費、用量增長率 |
+| 一次性付費 | 買斷 | 工具型軟體、課程 | 客單價、回購率 |
+| 交易抽成 | 每筆交易收取比例 | 平台、市場 | GMV、Take rate |
+| 按座位（Per-seat） | 依使用人數收費 | B2B 協作工具 | 每帳戶平均座位數、擴展率 |
+```
+
+### 價值定價對齊
+
+```
+定價核心問題：
+1. 你的產品幫用戶省了/賺了多少？（價值錨定）
+2. 用戶現在為替代方案付多少錢？（競爭參照）
+3. 你的定價是否與用戶獲得的價值成正比？（公平感）
+
+定價策略：
+  - 模式選擇：[Freemium / Subscription / 按用量 / ...]
+  - 價格區間：[依據價值錨定和競爭參照]
+  - 免費層包含什麼：[足以到達 Aha Moment，但不足以滿足進階需求]
+  - 付費觸發點：[什麼使用行為或使用量觸發升級？]
+
+⚠️ 常見定價錯誤：
+  - 定價太低（傳遞「不值錢」的訊號）
+  - 免費版太強（沒有升級動機）
+  - 價格和價值不對齊（功能定價 vs 價值定價）
+  - B2B 沒有年度合約折扣（錯失現金流穩定性）
+```
+
+---
+
+## 📎 本階段的檔案整合提示
+
+| 上傳內容 | 整合到 | 整合動作 |
+|---------|-------|---------|
+| 財務數據 / 營收報表 | 4.8 商業模式 | 用真實營收結構替代假設，評估定價合理性 |
+| 行銷渠道數據 | 4.7 GTM | 用 CAC、轉換率等真實數據評估渠道選擇 |

package/i18n/zh-TW/references/05c-validation-spec.md

@@ -0,0 +1,117 @@
+# 階段四：Deliver — 假設驗證 + 產品規格摘要
+
+## 4.5 假設驗證計畫
+
+**適用於：中/高完整性 / 產出對象為資料科學家/自己**
+
+```
+| 核心假設 | 驗證方法 | 驗證時間點 | 成功標準 | 如果假設錯誤，我們將... |
+|---------|---------|-----------|---------|----------------------|
+| | Alpha 用戶訪談 / 數據 | | | |
+```
+
+原則：質化驗證（用戶訪談、日記研究）+ 量化驗證（數據）並重；對自己的確認偏誤保持警惕。
+
+## 4.6 產品規格摘要
+
+產品規格摘要是所有模式的最終產出（快速模式產出一頁式方向摘要，結構不同但精神一致）。
+產品規格摘要分為三個區塊，對應不同閱讀深度：
+
+### 區塊一：決策摘要（30 秒能看完）
+
+```
+**產品一句話**：[PR-FAQ 標題]
+**為誰**：[目標 Persona 一句話描述]
+**核心價值**：[JTBD 功能性工作 + 情感性工作，一句話]
+**北極星指標**：[指標名稱 + 定義]
+**PMF 目前等級**：[Level 1-4 + 一句話說明]
+```
+
+### 區塊二：執行邊界（2 分鐘能看完）
+
+```
+**核心 JTBD 陳述**：[Target Customer] + 想要在 [Job Context] + 完成 [Job]
+**Aha Moment**：當用戶完成 [行為]，他們體驗到核心價值。目標在 [X] 內到達。
+**MVP 必須有**：[3-5 個最關鍵的功能/能力]
+**Not Doing（此版本刻意不做）**：[明確排除項 + 理由]
+**關鍵假設**：[需要驗證的 2-3 個核心假設]
+**Pre-mortem 主要風險**：[最可能導致失敗的 2-3 個原因]
+**Hero Metric**：[1-2 個最重要的成功指標 + 目標值]
+```
+
+### 區塊三：深度參考（需要時查閱）
+
+```
+**JTBD 細分**：
+  - 功能性 Job：
+  - 情感性 Job：
+  - 社交性 Job：
+**April Dunford 定位**：
+  - 真實競爭替代品：
+  - 我們的獨特屬性：
+  - 對目標用戶的核心價值：
+  - 目標市場特徵：
+  - 市場類別：
+**核心 HMW 問題**：[從 Define 階段得出]
+**解決方案描述**：[從 PR-FAQ 摘要]
+**商業模式**：[收費模式 + 價格策略，若已執行]
+**GTM 策略**：[初始獲客渠道 + Launch 策略，若已執行]
+```
+
+完成三個區塊後，Claude **必須主動補充以下三個區塊**，不等使用者要求：
+
+---
+
+### ⚠️ 風險清單
+
+根據整個企劃流程中識別到的所有風險，整合列出（來源：Pre-mortem + 機會評估 + 假設驗證）：
+
+```
+| 風險類型 | 風險描述 | 嚴重程度（高/中/低）| 目前有無對策 |
+|---------|---------|-------------------|------------|
+| 市場風險 | | | |
+| 用戶假設風險 | | | |
+| 技術風險 | | | |
+| 競爭風險 | | | |
+| 執行風險 | | | |
+```
+
+---
+
+### 🔍 不完整之處 & 待釐清盲點
+
+Claude 根據整個對話流程，主動識別出以下類型的缺口：
+
+```
+| 類型 | 說明 | 建議的下一步行動 |
+|------|------|----------------|
+| 未執行的步驟 | [哪些框架沒有跑，可能造成什麼盲點] | |
+| 資料不足 | [哪些判斷是基於假設而非真實用戶資料] | |
+| 邏輯跳躍 | [哪個地方的推導缺少中間論證] | |
+| 尚未驗證的假設 | [列出所有還沒有驗證方法的核心假設] | |
+| 定義不清楚 | [哪些概念還需要更精確的定義才能執行] | |
+```
+
+---
+
+### 💡 補充建議
+
+Claude 根據產品的特性、階段和已知風險，提供 3-5 條具體可執行的建議：
+
+```
+1. [最優先建議]：[具體行動] — 建議原因：[為什麼這件事最重要]
+2. [次優先建議]：[具體行動] — 建議原因：
+3. [第三建議]：[具體行動] — 建議原因：
+...
+```
+
+建議範圍可涵蓋：用戶驗證方法、MVP 邊界調整、競爭策略、指標設計、團隊分工、下一個里程碑的重點。
+
+---
+
+## 📎 本階段的檔案整合提示
+
+| 上傳內容 | 整合到 | 整合動作 |
+|---------|-------|---------|
+| 用戶行為數據（CSV / Excel） | 4.2 North Star + 4.3 PMF | 用真實留存率、活躍度數據判斷 PMF 等級；校準 North Star 基準值 |
+| Sean Ellis 問卷結果 | 4.3 PMF + 4.2 三層訊號 | 直接計算 Score，填入層級三 |

package/i18n/zh-TW/references/06-html-report.md

@@ -0,0 +1,123 @@
+# HTML 產品企劃報告產出
+
+當使用者說「產出報告」或確認最後一個階段內容無誤後觸發。
+
+## 設計規範
+
+採用**現代設計風格**，單一 HTML 檔案（CSS 與 JS 全部內嵌），確保離線也能閱讀。
+
+**整體風格：**
+- 漸層背景的 Hero 區塊（含執行模式、產出對象、日期標籤）
+- 卡片式排版（圓角 + 陰影），每個區塊像是一張獨立的資訊卡
+- 清晰的字體層級和舒適的閱讀間距
+- 響應式設計，手機上也能順暢閱讀
+
+**配色方案：**
+- 主色調：深藍系 `#1a1a2e` → `#16213e` → `#0f3460`
+- 強調色：`#e94560` 或 `#533483`
+- 內容區背景：`#f8f9fa`，卡片：白色帶 `box-shadow`
+
+**中文字體：** 優先從 Google Fonts CDN 載入 Noto Sans TC，失敗時 fallback 到系統字體：
+```css
+/* 在 <head> 中加入 */
+<link href="https://fonts.googleapis.com/css2?family=Noto+Sans+TC:wght@400;500;700&display=swap" rel="stylesheet">
+
+/* CSS 中 */
+font-family: "Noto Sans TC", system-ui, -apple-system, "Microsoft JhengHei", "PingFang TC", sans-serif;
+```
+> 這是唯一允許的外部 CDN 依賴。如果 Google Fonts 不可用，頁面仍可正常顯示。
+
+## 頁面結構（依已完成的階段動態呈現）
+
+```
+┌──────────────────────────────────────────────────────────────┐
+│  Hero 區塊（產品名稱、一句話描述、執行模式、產出對象、日期）       │
+├──────────────────────────────────────────────────────────────┤
+│  目錄導航（Sticky，只顯示已完成的區塊）                          │
+├──────────────────────────────────────────────────────────────┤
+│  🧭 策略層區塊（若有執行）                                       │
+│     ├─ Strategy Blocks 層級圖                                  │
+│     ├─ Rumelt 好策略內核（診斷/方針/行動）                       │
+│     └─ Shreyas 三層次產品工作                                   │
+│  ✅ 機會評估區塊（若有執行）                                     │
+│  🔍 Discovery 區塊（若有執行）                                   │
+│     ├─ Persona Table（卡片式表格）                              │
+│     ├─ Persona 卡片（每人一張）                                  │
+│     ├─ JTBD 分析表（四種類型）                                   │
+│     ├─ Opportunity Solution Tree（視覺化樹狀）                   │
+│     └─ User Journey Map（概覽表 + 手風琴詳述）                  │
+│  🎯 Define 區塊（若有執行）                                      │
+│     ├─ 痛點彙整表                                               │
+│     ├─ April Dunford 定位框架卡片                               │
+│     ├─ HMW 問題卡片（含 JTBD 類型標籤）                          │
+│     └─ 機會評估表（機會成本視角標注）                            │
+│  💡 Develop 區塊（若有執行）                                     │
+│     ├─ PR-FAQ 卡片（模擬新聞稿格式）                             │
+│     ├─ 解法發想（三欄平行方案卡片）                              │
+│     ├─ Pre-mortem 風險表（高/中風險色彩標示）                    │
+│     ├─ GEM 矩陣 + Impact/Effort 四象限圖                        │
+│     ├─ RICE 優先排序表（若有執行）                               │
+│     ├─ User Story 表（若有執行）                                 │
+│     └─ MVP 範圍（三欄卡片 + Not Doing List）                    │
+│  🚀 Deliver 區塊（若有執行）                                     │
+│     ├─ Aha Moment 定義卡片（醒目呈現）                          │
+│     ├─ North Star Metric 卡片                                   │
+│     ├─ 三層訊號指標表                                           │
+│     ├─ PMF 等級判定（四級框架視覺化 + 目前位置標記）              │
+│     ├─ GTM 策略（渠道選擇 + 初始 100 位用戶計畫，若有執行）      │
+│     ├─ 商業模式與定價（收費模式 + 定價策略，若有執行）            │
+│     ├─ 假設驗證計畫表（若有執行）                               │
+│     └─ 產品規格摘要（三區塊結構：決策摘要 / 執行邊界 / 深度參考）│
+│  ⭐ 最佳切入點分析（完整邏輯鏈視覺化）                            │
+├──────────────────────────────────────────────────────────────┤
+│  頁尾：產出日期 + 執行模式 + 框架來源說明                        │
+└──────────────────────────────────────────────────────────────┘
+```
+
+## 各區塊設計細節
+
+**表格樣式：** 斑馬紋、深色表頭、圓角、Hover 高亮
+
+**Persona 卡片：** 每個 Persona 獨立一張，痛點用紅色左邊框，JTBD 用藍色/紫色色塊強調
+
+**Opportunity Solution Tree：** 用 CSS 或輕量 SVG 繪製樹狀結構，清楚呈現目標→機會→解法的層級關係
+
+**PMF 等級圖：** 用進度條或步驟圖呈現四個等級，標注用戶目前所在位置
+
+**PR-FAQ 卡片：** 模擬新聞稿格式，有標題、副標題、引言，視覺上像真實文件
+
+**Pre-mortem 風險表：** 高風險項目用紅色警示，中風險用黃色
+
+**最佳切入點邏輯鏈：** 視覺化完整推導鏈，每個節點一張小卡片，箭頭連接
+
+## 互動效果
+
+- `scroll-behavior: smooth` — 目錄點擊平滑滾動
+- Intersection Observer — 滾動時目錄高亮當前區塊
+- 卡片 hover 微微上浮（`transform: translateY(-2px)` + `transition`）
+- 手風琴展開/收合（User Journey Map 各階段，`<details>/<summary>`）
+- `@media print` — 列印時隱藏互動元素、確保表格不被截斷
+
+## 注意事項
+
+- 所有 CSS 和 JS 內嵌在 HTML 中，除 Google Fonts CDN 載入 Noto Sans TC 外不依賴任何外部資源
+- 如果某個階段沒有完成，不要放空白區塊，直接跳過
+- 頁面 Hero 區塊標明「執行模式」和「產出對象」，讓閱讀者一眼看到這份文件的定位
+- 頁面總長度可能很長，目錄導航很重要，確保使用者能快速跳轉
+
+## 框架來源與延伸學習（放在頁尾）
+
+| 思想家 | 核心貢獻 | 出處 |
+|--------|---------|------|
+| Teresa Torres | Continuous Discovery、Opportunity Solution Tree | Lenny's Podcast + 《Continuous Discovery Habits》 |
+| Shreyas Doshi | LNO Framework、Pre-mortem、三層次產品工作、機會成本思維 | Lenny's Podcast Ep.3 |
+| Gibson Biddle | DHM Model、GEM Prioritization | Lenny's Podcast |
+| April Dunford | Positioning Framework | Lenny's Podcast + 《Obviously Awesome》 |
+| Todd Jackson | 四級 PMF 框架、Four P's | Lenny's Podcast（First Round Capital） |
+| Richard Rumelt | Good Strategy / Bad Strategy 好策略內核 | Lenny's Podcast + 《Good Strategy Bad Strategy》 |
+| Marty Cagan | Empowered Teams、Product Discovery | Lenny's Podcast + 《Inspired》《Empowered》 |
+| Chandra Janakiraman | Strategy Blocks | Lenny's Newsletter（Headspace / Meta） |
+| Clayton Christensen | Jobs to Be Done | 《Competing Against Luck》 |
+| Amazon | Working Backwards / PR-FAQ | 《Working Backwards》 |
+| Sean Ellis | Sean Ellis Score、ICE Scoring | 《Hacking Growth》 |
+| Lenny Rachitsky | Shape / Ship / Synchronize、North Star 思維 | Lenny's Newsletter + Podcast |

package/i18n/zh-TW/references/07a-handoff-core.md

@@ -0,0 +1,152 @@
+# 開發銜接 — 核心交接包
+
+> 當使用者說「進入開發」「產出開發交接包」「幫我建專案」「接到 Claude Code」時觸發。
+> 讀取此檔案，整合整個產品規劃流程的產出，生成可直接在 Claude Code CLI 中使用的開發交接包。
+
+## 環境限制與銜接策略
+
+**關鍵事實：Claude Chat / Cowork 和 Claude Code 是獨立的運行環境，無法從 Chat 內直接啟動 Claude Code。**
+
+因此銜接策略是：**產出結構化的開發交接包（一組檔案）**，使用者下載後放入專案資料夾，在 Claude Code 中一句話即可啟動整個開發流程。
+
+銜接方式視使用者環境而定：
+
+| 使用者環境 | 銜接方式 |
+|-----------|---------|
+| **Claude Chat（Web/App）** | 產出 zip 檔供下載，使用者解壓到專案目錄後開啟 Claude Code |
+| **Claude Cowork（Desktop）** | 同上，但可直接將檔案寫入使用者指定的本地路徑 |
+| **已在 Claude Code 中** | 直接在專案目錄中建立所有檔案（此情境下此 skill 多半由 CLAUDE.md 引用） |
+
+---
+
+## 開發交接包組成
+
+產出以下檔案組合，所有檔案放在專案根目錄：
+
+```
+[project-name]/
+├── .gitignore             # 版控排除清單（.env、secrets、進度檔等，模板見 references/07c-architecture-setup.md）
+├── CLAUDE.md              # Claude Code 的專案記憶檔：產品上下文 + 開發規範
+├── TASKS.md               # 功能拆解 + Phase 分期 + 逐 Task 驗收標準
+├── TICKETS.md             # 開票內容：每張票的標題、描述、驗收標準，PM 可直接開票
+├── docs/
+│   ├── PRD.md             # 完整 PRD（從 04-develop.md 產出格式整合）
+│   ├── ARCHITECTURE.md    # 技術架構：目錄結構 + DB schema + API endpoints + 安全架構
+│   └── PRODUCT-SPEC.md    # 產品規格摘要（從 05-deliver.md → 4.6 整合）
+└── scripts/
+    └── setup.sh           # 一鍵初始化腳本（建立目錄 + 安裝 dependencies）
+```
+
+---
+
+## 📄 CLAUDE.md 模板
+
+CLAUDE.md 是 Claude Code 的專案記憶檔，Claude Code 每次啟動時會自動讀取。必須包含：
+
+```markdown
+# [產品名稱] — 專案指引
+
+## 產品上下文
+
+**一句話描述**：[PR-FAQ 標題]
+**目標用戶**：[Persona 一句話描述]
+**核心 JTBD**：[Target Customer] 想要在 [Job Context] 完成 [Job]
+**Aha Moment**：當用戶完成 [行為]，他們體驗到核心價值
+**北極星指標**：[指標名稱 + 定義]
+
+## 技術棧
+
+- **前端**：[框架 + 版本]
+- **後端**：[框架 + 版本]
+- **資料庫**：[類型 + 版本]
+- **部署**：[平台]
+- **套件管理**：[工具]
+
+## 開發規範
+
+- 使用 [語言] 開發
+- 遵循 [風格指南/lint 規則]
+- commit message 格式：`[type]: [description]`（type: feat / fix / refactor / docs / test）
+- 分支策略：[main / develop / feature-xxx]
+- 每個功能必須有對應的 User Story 編號（見 TASKS.md）
+
+## MVP 邊界
+
+**必須有（P0）**：
+- [功能 1]
+- [功能 2]
+- [功能 3]
+
+**明確不做**：
+- [排除項 1] — 原因：[理由]
+- [排除項 2] — 原因：[理由]
+
+## 關鍵決策記錄
+
+| 決策 | 選擇 | 理由 | 日期 |
+|------|------|------|------|
+| [例：資料庫選擇] | [PostgreSQL] | [需要關聯查詢 + JSON 支援] | [日期] |
+
+## 風險警示（來自 Pre-mortem）
+
+- ⚠️ [風險 1]：[預防措施]
+- ⚠️ [風險 2]：[預防措施]
+
+## 安全性備註
+
+> 完整安全性檢查清單見 `references/08-security-checklist.md`，以下為本產品的關鍵安全性決策：
+
+- 認證方式：[JWT / Session / OAuth]
+- CORS 政策：[允許的 Origins]
+- Rate Limiting：[策略摘要]
+- 敏感資料：[處理方式]
+
+## 開發流程
+
+請依照 `TASKS.md` 的 Phase 順序逐步執行。每完成一個 Phase：
+1. 確認所有 Task 的驗收標準都通過
+2. 詢問使用者是否要進入下一個 Phase
+3. 如果遇到架構問題，參考 `docs/ARCHITECTURE.md`
+```
+
+---
+
+## 技術棧確認流程
+
+產出開發交接包前，必須確認技術棧。如果使用者沒有指定，依以下順序詢問：
+
+### 必問（影響所有產出）
+
+```
+1. 這是什麼類型的應用？
+   □ Web App（瀏覽器）
+   □ Mobile App（iOS / Android / 跨平台）
+   □ Desktop App
+   □ API / Backend Service
+   □ CLI 工具
+   □ 其他
+
+2. 你有偏好的技術棧嗎？
+   （如果沒有，我會根據產品特性推薦）
+```
+
+### 推薦邏輯（使用者沒有指定時）
+
+| 應用類型 | 推薦技術棧 | 推薦理由 |
+|---------|-----------|---------|
+| Web App（MVP 快速驗證） | Next.js + Tailwind + Supabase | 全端一體、部署簡單、內建 Auth |
+| Web App（複雜後端邏輯） | React + Node.js/Express + PostgreSQL | 靈活性高、生態系成熟 |
+| Web App（Python 團隊） | React + FastAPI/Django + PostgreSQL | Python 生態系、Django 內建 Admin |
+| Mobile App（跨平台） | React Native / Flutter | 單一 Codebase 覆蓋雙平台 |
+| API Service | FastAPI / Express / Go | 輕量、高效能 |
+
+> Claude 推薦時應說明理由，並提醒使用者可以覆蓋推薦。
+
+### 選填（根據產品需求追問）
+
+```
+3. 需要用戶認證嗎？（影響 Auth 方案選擇）
+4. 有即時性需求嗎？（WebSocket / SSE）
+5. 需要檔案上傳/處理嗎？（影響 Storage 選擇）
+6. 預計部署在哪裡？（Vercel / Railway / AWS / 自建）
+```