product-playbook 1.0.0

package/i18n/zh-CN/SKILL.md

@@ -0,0 +1,245 @@
+---
+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/zh-TW/SKILL.md`
+- 若用户使用 **日本語** 书写 → 静默读取并遵循 `i18n/ja/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-CN/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-CN/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-CN/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-CN/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-CN/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-CN/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-CN/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-CN/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-CN/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-CN/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 |