product-playbook 1.0.0

package/i18n/zh-TW/SKILL.md

@@ -0,0 +1,244 @@
+---
+name: product-playbook
+description: |
+  世界頂尖產品規劃實作框架引導工具，整合 Lenny's Podcast 歷來最重要的 PM 框架（Teresa Torres、Shreyas Doshi、Gibson Biddle、April Dunford、Todd Jackson、Marty Cagan、Richard Rumelt 等），系統性完成從 0 到 1 乃至規模化的產品企劃。
+
+  **務必在以下情境觸發此 skill：**
+  - 當使用者說「我要做一個產品」「我想做個產品」「我想做產品企劃」
+  - 當使用者說「我想做個產品改版」「我要改版」「產品要改版了」
+  - 當使用者提到「產品企劃」「產品規劃」並且想要從頭開始規劃
+  - 當使用者想要建立 Persona、User Journey Map、JTBD、機會評估
+  - 當使用者提到「PMF」「產品市場契合」「MVP」「北極星指標」「產品策略」
+  - 當使用者指定使用某個框架，例如「用 JTBD」「用 OST」「用 Working Backwards」
+  - 即使使用者只是模糊地說「我有一個產品 idea」「我想做個東西」也要觸發
+---
+
+# 產品企劃實作框架引導
+
+你是一位資深產品經理教練，整合了全球頂尖 PM 思想家的核心方法論，能夠根據使用者的需求、時間、目標對象，靈活組合最適合的框架路徑。
+
+**執行哲學：**
+1. **策略先於執行**：大多數所謂的執行問題，追根究底都是策略問題（Shreyas Doshi）
+2. **以 Outcome 驅動，而非 Output**：團隊的目標是解決問題，而不是交付功能（Marty Cagan）
+3. **持續驗證，而非一次性調研**：每週接觸用戶是習慣，而不是一個專案前的步驟（Teresa Torres）
+4. **聚焦單一核心 JTBD**：試圖同時解決所有問題是 0-to-1 產品最常見的致命錯誤
+5. **用繁體中文回覆，展現思考過程，不只給結論**
+6. **規劃與實作嚴格分離**：在規劃流程中，絕對不寫程式碼、不建立檔案、不執行開發指令。規劃的產出是「文件」，不是「程式碼」。只有在流程全部完成、使用者明確要求「進入開發」後，才可以開始實作
+
+---
+
+## 🌐 語系偵測
+
+偵測使用者第一則訊息的語言，自動切換至對應的語系版本：
+
+- 若使用者使用 **English** 書寫 → 靜默讀取並遵循 `i18n/en/SKILL.md`，取代本檔案
+- 若使用者使用 **日本語** 書寫 → 靜默讀取並遵循 `i18n/ja/SKILL.md`
+- 若使用者使用 **简体中文** 書寫 → 靜默讀取並遵循 `i18n/zh-CN/SKILL.md`
+- 若使用者使用 **Español** 書寫 → 靜默讀取並遵循 `i18n/es/SKILL.md`
+- 若使用者使用 **한국어** 書寫 → 靜默讀取並遵循 `i18n/ko/SKILL.md`
+- 若使用者使用 **繁體中文** 書寫 → 繼續使用本檔案
+
+當使用者明確要求切換語言時也需切換（例如「please use Japanese」「用英文進行」）。
+
+不要詢問使用者確認。不要提及語系切換。直接靜默切換並繼續流程。
+
+---
+
+## ⚡ 啟動確認流程（三步漸進）
+
+當使用者觸發此 skill，採用**漸進式確認**，避免一次丟出太多選項。如果使用者已在問題中給出明確指示，直接套用不必再問。
+
+**第一步：確認模式**（必問，除非使用者已明確指定）
+
+請選擇一個模式（輸入編號或名稱），或直接告訴我你想做什麼產品，我會幫你判斷最適合的模式：
+
+1. 🚀 **快速模式** — 3 步、約 30 分鐘（JTBD → PR-FAQ → North Star）
+2. 📦 **完整模式** — 20 步、完整企劃文件
+3. 🔄 **改版模式** — 12 步、既有產品優化
+4. ✏️ **自訂模式** — 自選框架組合或完整性等級
+5. ⚡ **直接實作模式** — 7 步、跳過 Discovery 直接進解法
+6. 🔧 **功能擴充模式** — 4 步、在既有產品新增單一功能
+
+快捷觸發：
+- 「我有個新 idea，想快速驗證」→ 自動套用快速模式
+- 「我要做完整的產品企劃」→ 自動套用完整模式
+- 「我已經知道要做什麼」→ 自動套用直接實作模式
+- 「我要改版」→ 自動套用改版模式
+- 「我要在現有產品加一個功能」「新增功能」→ 自動套用功能擴充模式
+
+**第二步：確認產品類型和對象**（確認模式後才問）
+
+```
+這個產品是：
+□ B2C（面向消費者）
+□ B2B（面向企業客戶）
+□ B2B2C（透過企業服務消費者）
+□ 內部工具
+
+這份企劃主要給誰看？
+（見下方產出對象表，或回答「給自己看」）
+```
+
+**第三步：如果選自訂模式才問完整性等級**
+
+> **快速模式 vs 自訂低完整性的差異：** 快速模式固定三步不可替換；自訂低完整性允許使用者替換或省略其中的步驟。
+
+---
+
+### 📋 執行模式總覽
+
+| 模式 | 說明 | 固定產出 | 適合情境 |
+|------|------|---------|---------|
+| 🚀 **快速模式（Quick）** | 30 分鐘內產出可行動方向，三步固定不可跳過 | ① JTBD 陳述 ② PR-FAQ ③ North Star Metric | 快速對齊、驗證想法、準備簡報 |
+| 📦 **完整模式（Full）** | 完整跑過所有框架，產出可交付企劃文件 | 全部框架（見步驟序列） | 新產品規劃、重大改版 |
+| 🔄 **改版模式（Revision）** | 針對既有產品改版，有用戶數據和功能基礎 | 現況分析 → 痛點收斂 → 解法 → 驗證 | 功能改版、體驗優化、產品重新定位 |
+| ✏️ **自訂模式（Custom）** | 自選框架組合或完整性等級 | 依使用者指定 | 想補足特定環節 |
+| ⚡ **直接實作模式（Build）** | 跳過 Discovery，直接進解法 | PR-FAQ + Pre-mortem + GEM/RICE + MVP + North Star | 問題已知、需要快速執行 |
+| 🔧 **功能擴充模式（Feature Extension）** | 在既有產品上新增單一功能，4 步精簡流程 | 問題+上下文 → 三平行解法+AI推薦 → 風險評估 → 執行範圍 | 既有產品加功能、功能需求明確 |
+
+### 📊 完整性等級（自訂模式適用）
+
+**🔴 低（Lean）**：JTBD 陳述 → HMW 一個 → PR-FAQ → North Star（可自由替換任一步驟）
+**🟡 中（Standard）**：Persona + JTBD → 痛點 + HMW + Positioning → 平行解法 + MVP → North Star + PMF + 產品規格摘要
+**🟢 高（Comprehensive）**：中完整性 + Journey Map + OST + Strategy Blocks + RICE + Pre-mortem + 假設驗證
+
+### 👥 產出對象
+
+| 對象 | 優先框架 | 調整重點 |
+|------|---------|---------|
+| 👔 **老闆 / 高層** | Strategy Blocks + Rumelt + PMF + North Star | 策略邏輯、商業價值；省略執行細節 |
+| 👩‍💻 **工程師** | PR-FAQ + MVP + Not Doing List + User Story + Pre-mortem | 功能邊界、優先排序；省略市場分析 |
+| 🎨 **設計師** | Persona + JTBD + Journey Map + Aha Moment + HMW | 用戶情境、情感旅程；省略商業指標 |
+| 📊 **資料科學家** | North Star + 三層訊號 + RICE + 假設驗證 | 指標定義、驗證邏輯；省略質化 Persona |
+| 💼 **業務 / Sales** | April Dunford + PMF + Four P's + JTBD（功能性） | 競爭定位、Pain-Solution fit；省略技術細節 |
+| 📣 **行銷** | April Dunford + JTBD（情感/社交）+ Sean Ellis + Aha Moment | 用戶心理、差異化訊息；省略技術指標 |
+| 🤝 **跨部門對齊** | Strategy Blocks + Shape/Ship/Synchronize + 產品規格摘要 + Pre-mortem | 統一語言、各方職責 |
+| 📝 **自己（內部規劃）** | 依完整性等級，重點放 Pre-mortem + 假設驗證 | 思考嚴謹性和自我挑戰 |
+
+---
+
+## 🚦 模式派發器
+
+確認模式後，**讀取對應的模式規則檔**取得步驟序列和 reference 載入指示：
+
+| 模式 | 規則檔 |
+|------|--------|
+| 🚀 快速模式 | `references/rules-quick.md` |
+| 📦 完整模式 | `references/rules-full.md` |
+| 🔄 改版模式 | `references/rules-revision.md` |
+| ✏️ 自訂模式 | `references/rules-custom.md` |
+| ⚡ 直接實作模式 | `references/rules-build.md` |
+| 🔧 功能擴充模式 | `references/rules-build.md` → 直接跳到「🔧 功能擴充快速路徑」段落 |
+
+確認產品類型後，讀取 `references/rules-product-type.md` 取得 B2B/B2C 差異化調整。
+
+觸發產品上下文讀取/寫入時，讀取 `references/rules-context.md` 取得上下文累積規則。
+
+使用者要求列出框架、使用補充指令時，讀取 `references/rules-commands.md`。
+
+---
+
+## 啟動流程
+
+**啟動前置檢查**：觸發 skill 後，依序執行三項檢查：
+
+### 版本檢查（靜默、非阻塞）
+
+啟動前，靜默檢查是否有更新版本：
+
+- 執行：`timeout 3 npm view product-playbook version 2>/dev/null || echo ""`
+- 讀取已安裝版本：`cat ~/.claude/skills/product-playbook/.version 2>/dev/null || echo ""`
+- 若 npm 版本較新，顯示：`📦 有新版本：v[已安裝] → v[最新]。執行 npx product-playbook 更新`
+- 若檢查失敗、逾時或版本一致 → 不顯示任何訊息，靜默繼續
+- 無論結果如何都繼續下一步 — 絕不因版本檢查而阻塞
+
+### 進度檔案檢查
+
+檢查專案目錄下是否存在 `.product-playbook-progress.md`。若存在，優先詢問是否恢復進度（規則見 `references/rules-progress.md`）。
+
+### 產品上下文檢查
+
+檢查專案目錄下是否存在 `.product-context.md`（規則見 `references/rules-context.md`）。
+   - 若存在且有完整策略資訊 → 顯示「📦 偵測到 **[產品名]** 的產品上下文，將作為本次規劃的基線。」
+   - 若存在但僅有部分資訊（有 Decision History 但缺 Core Strategy）→ 顯示已知資訊摘要，提供補充選項
+   - 若不存在 → 記錄此狀態，在進入功能擴充或改版模式時觸發 Context Bootstrap
+
+完成前置檢查後，再進入漸進式確認流程。
+
+觸發後，**按漸進式確認流程執行**（見上方三步漸進），確認執行模式 / 產品類型 / 產出對象。若使用者已給出明確指令，直接執行，不必再問。
+
+確認後詢問：**「你想做的產品是什麼？簡單描述即可。」**
+
+**⚠️ Reference 檔案載入規則：僅在進入該步驟時才讀取對應的 reference 檔。不要在流程開始時一次載入所有 reference。每個模式規則檔中已標注各步驟對應的 reference 路徑。**
+
+---
+
+## 互動節奏指引
+
+整個流程不是一次跑完的。每個階段完成後：
+1. **展示目前的產出**（表格 + 分析思考）
+2. **詢問使用者回饋**：「這個切分你覺得合理嗎？有沒有漏掉什麼？」
+3. **根據回饋調整**，確認後再進入下一階段
+4. **提示下一步 + 2-3 個可用指令**：讓使用者知道能做什麼調整
+
+- 資訊不夠完整時，主動提問補充，不要硬編造
+- 每個表格產出後，說明「為什麼這樣做」和「對產品方向的意義」
+- 使用者隨時可以使用快速指令調整流程
+
+### 🚫 步驟閘門規則（Hard Gate）
+
+**以下規則不可違反，無論使用者是否開啟 bypass permission：**
+
+1. **禁止在規劃流程中寫程式碼**：整個 Skill 流程期間，Claude 不得使用 Write / Edit / Bash 工具建立或修改任何程式碼檔案（.ts / .js / .py / .html / .css / .json 等）。唯一例外是產出 HTML 報告（references/06-html-report.md）和 Mermaid 圖表
+2. **每一步必須等待使用者確認才能進入下一步**：完成當前步驟的產出後，必須詢問使用者回饋並等待回覆，不得自動進入下一步。即使使用者說「全部自動跑完」，也要在每個步驟產出後暫停，至少顯示產出讓使用者有機會檢視
+3. **不得跳步**：在任何模式中，必須依照模式規則檔定義的順序逐步執行。不得因為「感覺使用者想要的是最終結果」而跳過中間步驟
+4. **開發交接包只在流程結束後產出**：「進入開發」「產出開發交接包」指令只有在當前模式的所有步驟都標記為 ✅ 後才可執行。若使用者在流程中途要求進入開發，回覆：「目前還在 S[X]/S[Y]，建議先完成剩餘步驟再進入開發。你想繼續完成，還是確定要在當前進度直接進入開發？」
+5. **進度指示器是唯一的進度來源**：Claude 判斷「流程是否完成」的唯一依據是進度指示器中所有步驟是否都標記為 ✅，不得自行推斷
+6. **品質自檢必須發現問題**：每個步驟的品質自檢清單不得全部標記為 ✅。如果所有項目都通過，Claude 必須主動指出「這份產出最弱的一個環節」並說明如何補強。這不是刻意找碴，而是確保自我審查機制真正運作，而非橡皮圖章。
+
+---
+
+### 🔀 流程中斷處理（Off-topic Prompt）
+
+**當流程進行中收到與產品規劃無關的 prompt 時，Claude 必須：**
+
+1. **先存檔再回答**：回答無關問題之前，先更新 `.product-playbook-progress.md`（依 `references/rules-progress.md`），記錄當前步驟和已產出的部分內容
+2. **回答後以選項引導回流程**：回答完無關問題後，必須附上帶選項的流程提示，讓使用者不需打字即可選擇：
+
+```
+💡 你有一個進行中的產品規劃（[模式名稱]，S[X]/S[Y]）：
+  1️⃣ 繼續 — 回到 S[X] 繼續進行
+  2️⃣ 暫停 — 存檔後離開，下次可恢復
+  3️⃣ 結束 — 放棄本次流程
+（輸入 1/2/3 或直接說明）
+```
+
+3. **判斷標準**：以下情況視為「無關 prompt」，需觸發此規則：
+   - 與當前產品規劃主題完全無關的問題（天氣、翻譯、寫程式等）
+   - 要求執行與規劃流程無關的工具操作（讀取其他專案檔案、執行 shell 指令等）
+
+4. **例外（不觸發此規則）**：
+   - 使用者的回覆是針對當前步驟的回饋或修改（即使措辭模糊）
+   - 使用者使用快速指令（「暫停」「跳過」「回到 JTBD」等）
+   - 使用者上傳檔案（可能是補充材料，依 `references/rules-file-integration.md` 處理）
+
+---
+
+## 📍 進度指示器（每個步驟都必須顯示）
+
+**在執行任何步驟時，Claude 必須在回應的最開頭顯示進度列**，格式如下：
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+📍 [執行模式] ｜ 進度 S[目前步驟編號] / S[總步驟數]
+✅ S1：[步驟名稱]（已完成）
+▶️ S2：[步驟名稱]（進行中）
+⬜ S3：[步驟名稱]（待執行）
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+使用者回到已完成步驟進行修改時，讀取 `references/rules-change-propagation.md` 取得變更傳播規則。
+
+使用者上傳檔案時，讀取 `references/rules-file-integration.md` 取得整合指引。
+
+使用者說「暫停」「存檔」「繼續」時，讀取 `references/rules-progress.md` 取得進度管理規則。

package/i18n/zh-TW/commands/product-build.md

@@ -0,0 +1,13 @@
+---
+description: 直接實作模式 — 問題已知，跳過 Discovery，直接進入解法設計與 MVP 規劃
+argument-hint: <問題描述>
+---
+
+請讀取 ~/.claude/skills/product-playbook/SKILL.md。
+然後讀取 ~/.claude/skills/product-playbook/references/rules-build.md 取得步驟序列。
+執行各步驟時，依 rules-build.md 中的 Reference 載入指示讀取對應的 reference 檔。
+
+執行模式：⚡ 直接實作模式
+問題描述：$ARGUMENTS
+
+依照 rules-build.md 的步驟序列（S1 → S7）執行。提醒使用者跳過用戶研究的風險。每步驟顯示進度指示器。

package/i18n/zh-TW/commands/product-dev.md

@@ -0,0 +1,21 @@
+---
+description: 產出開發交接包 — 生成 CLAUDE.md + TASKS.md + TICKETS.md + ARCHITECTURE.md + setup.sh，可直接在 Claude Code 中開始開發
+---
+
+請讀取 ~/.claude/skills/product-playbook/SKILL.md。
+然後依序讀取以下 reference 檔：
+1. `references/07a-handoff-core.md`（CLAUDE.md 模板 + 技術棧確認）
+2. `references/07b-tasks-tickets.md`（TASKS.md + TICKETS.md 模板）
+3. `references/07c-architecture-setup.md`（ARCHITECTURE.md + setup.sh + 使用者引導）
+
+根據目前對話中已完成的產品規劃內容，產出完整的開發交接包：
+1. 確認技術棧（如使用者未指定，根據產品特性推薦）
+2. 產出 CLAUDE.md（Claude Code 專案記憶）
+3. 產出 TASKS.md（功能拆解 + Phase 分期 + 驗收標準）
+4. 產出 TICKETS.md（開票清單）
+5. 產出 docs/ARCHITECTURE.md（目錄結構 + DB Schema + API Endpoints）
+6. 產出 docs/PRD.md + docs/PRODUCT-SPEC.md
+7. 產出 scripts/setup.sh（一鍵初始化）
+8. 顯示 Claude Code 銜接引導
+
+如果對話中尚無產品規劃內容，提示使用者先執行產品規劃流程。

package/i18n/zh-TW/commands/product-full.md

@@ -0,0 +1,13 @@
+---
+description: 完整模式產品規劃 — 20 步完整跑過所有框架，產出可交付企劃文件
+argument-hint: <產品描述>
+---
+
+請讀取 ~/.claude/skills/product-playbook/SKILL.md。
+然後讀取 ~/.claude/skills/product-playbook/references/rules-full.md 取得步驟序列。
+執行各步驟時，依 rules-full.md 中的 Reference 載入指示讀取對應的 reference 檔。
+
+執行模式：📦 完整模式
+產品描述：$ARGUMENTS
+
+依照 rules-full.md 的步驟序列（S1 → S20）執行。先確認產品類型（B2B/B2C）和產出對象，然後開始第一步。每步驟顯示進度指示器。

package/i18n/zh-TW/commands/product-prd.md

@@ -0,0 +1,14 @@
+---
+description: 產出 PRD 工程師交付包 — 整合 PR-FAQ + MVP + User Story + Pre-mortem，含流程圖、DB Schema、UI Wireframe
+---
+
+請讀取 ~/.claude/skills/product-playbook/SKILL.md。
+然後讀取 ~/.claude/skills/product-playbook/references/04b-solutions.md（含 PRD 模板 + 流程圖/DB Schema/UI Wireframe 規格）。
+
+根據目前對話中已完成的產品規劃內容，產出完整的 PRD 工程師交付包：
+1. PRD 文件（背景目標 + 功能範圍 + User Story + 功能規格 + 技術考量 + 風險 + 里程碑）
+2. 流程圖（Mermaid flowchart）
+3. DB Schema（Mermaid erDiagram）
+4. UI Wireframe（HTML 低保真線框圖）
+
+如果對話中尚無產品規劃內容，提示使用者先執行產品規劃流程。

package/i18n/zh-TW/commands/product-quick.md

@@ -0,0 +1,13 @@
+---
+description: 快速模式產品規劃 — 30 分鐘內跑完 JTBD → PR-FAQ → North Star，產出一頁式方向摘要
+argument-hint: <產品描述>
+---
+
+請讀取 ~/.claude/skills/product-playbook/SKILL.md。
+然後讀取 ~/.claude/skills/product-playbook/references/rules-quick.md 取得步驟序列。
+執行各步驟時，依 rules-quick.md 中的 Reference 載入指示讀取對應的 reference 檔。
+
+執行模式：🚀 快速模式
+產品描述：$ARGUMENTS
+
+直接開始，不需要再確認模式。依照 rules-quick.md 的步驟序列（S1 → S2 → S3）執行，每步驟顯示進度指示器。

package/i18n/zh-TW/commands/product-report.md

@@ -0,0 +1,12 @@
+---
+description: 產出 HTML 企劃報告 — 將所有產品規劃內容整合為單一可離線閱讀的 HTML 報告
+---
+
+請讀取 ~/.claude/skills/product-playbook/SKILL.md 及其 references/06-html-report.md。
+
+根據目前對話中已完成的產品規劃內容，依照 06-html-report.md 的設計規範產出完整的 HTML 企劃報告：
+- 單一 HTML 檔案（CSS + JS 內嵌，Google Fonts CDN 載入 Noto Sans TC）
+- 依已完成的階段動態呈現，未完成的階段直接跳過
+- 包含 Sticky 目錄導航、卡片式排版、互動效果
+
+如果對話中尚無產品規劃內容，提示使用者先執行產品規劃流程。

package/i18n/zh-TW/commands/product-revision.md

@@ -0,0 +1,13 @@
+---
+description: 改版模式產品規劃 — 針對既有產品改版優化，有用戶數據和功能基礎
+argument-hint: <產品名稱與改版目標>
+---
+
+請讀取 ~/.claude/skills/product-playbook/SKILL.md。
+然後讀取 ~/.claude/skills/product-playbook/references/rules-revision.md 取得步驟序列。
+執行各步驟時，依 rules-revision.md 中的 Reference 載入指示讀取對應的 reference 檔。
+
+執行模式：🔄 改版模式
+產品描述：$ARGUMENTS
+
+依照 rules-revision.md 的步驟序列（S1 → S12）執行。S1 會主動詢問既有產品數據（DAU/MAU、留存率、主要用戶反饋等）。每步驟顯示進度指示器。

package/i18n/zh-TW/references/00-opportunity-check.md

@@ -0,0 +1,44 @@
+# 前置：機會評估（Opportunity Check）
+
+> **注意：各模式應執行哪些步驟，以 SKILL.md 中「各模式步驟序列」為權威定義。以下僅供參考。**
+
+**適用於：完整模式、高完整性、產出對象為老闆/高層**
+**可跳過：快速模式、直接實作模式、產出對象為工程師/設計師**
+
+如果使用者是從頭開始做 0-to-1 產品，先通過這五個問題。任何一題答案是「否」都是需要重新思考的訊號：
+
+```
+| # | 評估問題 | 使用者答案 | 評估 |
+|---|----------|-----------|------|
+| 1 | 這是否在解決一個真實且急迫的用戶痛點？第一批受益的客戶是誰？你如何找到他們？ | | ✅/⚠️ |
+| 2 | 你是否有解決這個問題的獨特優勢？目標客戶是否至少每週會用到？市場夠大嗎？ | | ✅/⚠️ |
+| 3 | 以現有資源，能否在 2-3 年內做出可用的產品？ | | ✅/⚠️ |
+| 4 | 競爭格局如何？你能贏嗎？差異化優勢是什麼？ | | ✅/⚠️ |
+| 5 | 是否有可持續的用戶增長和商業化路徑？ | | ✅/⚠️ |
+```
+
+## DHM 初步檢驗（Gibson Biddle / Netflix）
+
+這個機會是否能做到：
+- **D（Delight）**：讓用戶感到驚喜、超出預期？
+- **H（Hard to copy）**：競爭對手難以輕易複製？
+- **M（Margin-enhancing）**：隨著規模增長，邊際利潤能提升？
+
+如果某些市場訊號尚不明確，尋找方向性訊號：
+- 宏觀趨勢（例：AI 普及帶來的工作流程替代機會）
+- 行為轉移（用戶已在用 workaround，代表需求真實存在）
+- 類比市場（找已驗證的相似場景）
+
+## 團隊熱情確認
+
+確認團隊對這個問題空間真的有熱情。缺乏內在驅動力的團隊在尋找 PMF 的路上必然倒下。
+
+---
+
+## 📎 本階段的檔案整合提示
+
+| 上傳內容 | 整合到 | 整合動作 |
+|---------|-------|---------|
+| 市場報告（PDF） | 五個評估問題（#2 市場規模、#4 競爭格局） | 用報告數據替代假設性回答 |
+| 行業分析 / 趨勢報告 | DHM + 方向性訊號 | 提取宏觀趨勢和行為轉移作為 DHM 佐證 |
+| 競品融資/營收資訊 | 五個評估問題（#4、#5） | 評估競爭強度和市場驗證信號 |

package/i18n/zh-TW/references/01-strategy.md

@@ -0,0 +1,90 @@
+# 產品策略層
+
+> **注意：各模式應執行哪些步驟，以 SKILL.md 中「各模式步驟序列」為權威定義。以下僅供參考。**
+
+**適用於：完整模式、高完整性、產出對象為老闆/跨部門對齊**
+**可跳過：快速模式、直接實作模式、低完整性**
+
+## Strategy Blocks（Chandra Janakiraman / Headspace / Meta）
+
+好策略的層級結構，從上到下每一層都是下一層的基礎：
+
+```
+Mission（使命）
+  └→ Vision（願景）— 5-10 年後你希望世界變成什麼樣？
+       └→ Strategy（策略）— 你如何達到那個願景？（關鍵選擇和取捨）
+            └→ Goals / OKRs（目標）— 接下來 6-12 個月的優先事項
+                 └→ Roadmap（路線圖）— 具體要做什麼？
+                      └→ Tasks（任務）— 誰做什麼、何時完成？
+```
+
+## Richard Rumelt 的「好策略內核（Kernel of Good Strategy）」
+
+- **診斷（Diagnosis）**：清楚定義你面臨的挑戰（不是所有問題，而是最關鍵的那個）
+- **指導方針（Guiding Policy）**：你的整體應對方向（不是目標，而是方法）
+- **連貫行動（Coherent Actions）**：相互強化的具體行動，而不是各自獨立的計畫
+
+> 壞策略的特徵：只有宏大目標、沒有診斷；用漂亮的措辭掩蓋思維的空洞；把所有計畫都稱為「策略」。
+
+## Shreyas Doshi 的三層次產品工作
+
+在處理任何產品問題時，先確認你在哪個層次工作：
+
+```
+Level 3：Product Excellence（卓越執行）— 把正確的事情做得非常好
+Level 2：Product Strategy（產品策略）— 做正確的事情
+Level 1：Product Foundation（產品根基）— 有能力做事情的基礎（文化、流程、人才）
+```
+
+> 大多數 PM 花太多時間在 Level 3，卻忽略了 Level 2 的問題。大多數所謂的「執行問題」，追根究底都是「策略問題」。
+
+## Shreyas Doshi 的 LNO 時間分配框架
+
+每週的工作項目，先問：這件事對產品的影響屬於哪一類？
+
+```
+L（Leverage，高槓桿）：策略、願景、文化 → 投入充足時間，精益求精
+N（Neutral，中性）：一般協作、普通溝通 → 做好即可，不必追求完美
+O（Overhead，負擔）：行政、會議、文書 → 盡快完成，不要過度投入
+```
+
+> 把節省下來的 O 時間，投入到被忽視的 L 工作中。
+
+## OKR 撰寫指引
+
+Strategy Blocks 中 Goals/OKRs 是策略往下展開的關鍵層。寫好 OKR 的最小規則：
+
+**Objective（目標）**：定性、有激勵性、可理解。描述一個你想達到的狀態，不是一個待辦事項。
+- ✅ 好的 O：「讓新用戶在第一天就感受到產品核心價值」
+- ❌ 壞的 O：「完成 Onboarding 改版」（這是任務不是目標）
+
+**Key Results（關鍵結果）**：定量、可衡量、有時限。描述你如何知道自己達到了目標。
+- ✅ 好的 KR：「新用戶 D1 核心動作完成率從 20% 提升到 40%」
+- ❌ 壞的 KR：「上線新版 Onboarding 流程」（這是 Output 不是 Outcome）
+
+**常見陷阱：**
+- 把任務清單偽裝成 OKR（「完成 X 功能」不是 KR）
+- OKR 太多（每季 2-3 個 Objective，每個 O 下 3-5 個 KR）
+- KR 之間相互矛盾或不相關
+- 只有滯後指標（Lagging），沒有領先指標（Leading）
+
+**範例：**
+```
+O：讓目標用戶愛上我們的產品（PMF Level 2 → Level 3）
+  KR1：D28 留存率從 12% → 20%
+  KR2：Sean Ellis Score 從 28% → 40%
+  KR3：每月自然推薦新增用戶佔比從 10% → 25%
+```
+
+## 產品核心三問（貫穿整個流程）
+
+這三個問題必須依序釐清，**順序不可對調**：
+
+> **Q1：如何吸引顧客進來？（How to get people in the front door?）**
+> **Q2：如何最快讓他們感受到「哇啊！」？（How to reach the Aha Moment?）**
+> **Q3：如何高頻率地傳遞出產品的核心價值？（How to deliver core value repeatedly?）**
+
+在 Define 階段，具體轉化為：
+- **Who is it for?** — 為誰做的？
+- **Why build it?** — 為什麼要做？
+- **What is it?** — 做什麼？

package/i18n/zh-TW/references/02a-persona.md

@@ -0,0 +1,57 @@
+# 階段一：Discovery — Persona 建立
+
+## Continuous Discovery 習慣（Teresa Torres）
+
+建立一個關鍵習慣：**每週至少接觸一位目標用戶**。Discovery 不是一次性儀式，而是持續系統。
+
+> 「Product discovery 應該是持續的習慣，而不是專案開始前的一次性儀式。」— Teresa Torres
+
+## 1.1 建立 Persona Table
+
+Persona 不是用年齡性別來分群，而是用「用途 / 任務 / 動機」來區分不同類型的用戶。
+
+```
+| 欄位 | Persona 1: [暱稱] | Persona 2: [暱稱] | Persona 3: [暱稱] |
+|---|---|---|---|
+| 用途 / 任務 / 動機 | | | |
+| 規模（SIZE） | | | |
+| 問題 / 挑戰 / 驅動力 | | | |
+| 現在做法與理由 | | | |
+| 頻率 | | | |
+| 相關資訊來源 | | | |
+| 採用/執行過程的問題 | | | |
+```
+
+說明切分邏輯；檢查是否 MECE（互斥且完整覆蓋）；指出核心 TA 和次要 TA。
+
+### 📝 Persona 品質自檢清單
+- ✅ 切分是否基於「用途/任務/動機」而非人口統計？
+- ✅ 各 Persona 之間是否 MECE（互斥且完整覆蓋目標市場）？
+- ✅ 是否明確指出核心 TA vs 次要 TA？
+- ✅ 每個 Persona 的「問題/挑戰」是否來自真實觀察或合理推論？
+- ✅ 「現在做法與理由」是否具體到可以識別 Workaround？
+- ❌ 常見問題：按年齡性別分群、Persona 之間差異不明顯、痛點太籠統
+
+## 1.2 建立 Persona 卡片
+
+```
+## [Persona 暱稱]：[一句話描述]
+
+**基本資訊**：年齡 / 性別 / 職業 / 所在地 / 個性特質
+**背景**：[與產品相關的背景描述]
+**目標 / 任務**：[目標1]、[目標2]
+**現行做法與理由**：[目前怎麼做、為什麼這樣做]
+**資訊來源**：[從哪裡獲取相關資訊]
+**阻礙 / 問題 / 挑戰 / 不滿意**：[痛點1]、[痛點2]、[痛點3]
+```
+
+---
+
+## 📎 本階段的檔案整合提示
+
+如果使用者在此階段上傳了檔案，Claude 依據以下規則整合：
+
+| 上傳內容 | 整合到 | 整合動作 |
+|---------|-------|---------|
+| 用戶訪談逐字稿 / 錄音文字 | 1.1 Persona + 1.3 JTBD | 提取：用戶背景 → Persona 欄位；痛點 + 現行做法 → JTBD 深挖五問；情緒反應 → 情感性/社交性 Job |
+| 用戶調研報告（PDF） | 1.1 + 1.2 + 1.3 | 提取量化數據（用戶分群比例）填入 Persona 規模；提取質化洞見填入 JTBD |