一、项目概述
PM Skills Marketplace 是一个面向产品经理的 AI 技能市场，包含 8 个插件、65 个技能、36 个链式工作流，覆盖产品发现、策略、执行、上市等全流程。
它的核心理念：不是让 AI 生成一堆文字，而是将成熟的 PM 框架（Teresa Torres、Marty Cagan、Alberto Savoia 等）编码为结构化的引导式工作流，帮助产品经理做出更好的产品决策。
二、核心概念
| 概念 | 说明 |
|---|---|
| Skill（技能） | 最小构建块。每个技能赋予 AI 一个特定 PM 领域的知识或框架，会话相关时自动加载 |
| Command（命令） | 用户触发的工作流，用 /命令名 调用。将多个技能串联成端到端流程 |
| Plugin（插件） | 将相关技能和命令打包为可安装的模块，按 PM 领域分组 |
三、如何写 PRD（核心聚焦）
3.1 触发方式
/write-prd SSO support for enterprise customers
/write-prd Users are dropping off during onboarding — we need to fix step 3
/write-prd [上传 brief、研究文档或策略 deck]
输入可以是任何形式：功能名称、问题陈述、用户诉求、模糊想法、上传文档均可。
3.2 四步工作流
Step 1: 理解需求
接受任何形式的输入：
- 功能名（如 "SSO 支持"）
- 问题描述（如 "企业客户一直要求集中认证"）
- 用户请求（如 "用户想导出 CSV"）
- 模糊想法（如 "注册流失率太高了，得想想办法"）
- 上传文档（brief、调研、Slack 讨论、邮件）
Step 2: 收集上下文（对话式提问）
按重要性排序，逐步补齐信息缺口：
- 用户问题 — 解决什么问题？谁遇到了这个问题？有多痛？
- 目标用户 — 哪些用户群体？数量？当前替代方案是什么？
- 成功指标 — 如何衡量成功？哪些指标会变化？
- 约束条件 — 技术限制、时间线、合规要求、跨团队依赖？
- 已有尝试 — 之前试过吗？市场上有类似方案吗？
- 范围偏好 — 一次性完整方案，还是分阶段交付？
如果用户提供了文档，则先从中提取已有信息，只问缺失部分。
Step 3: 生成 PRD（8 段式结构）
Step 4: 评审与迭代
生成后提供进一步选项：
- 收紧范围（挑战 P1 是否应降为 P2）
- 运行预验尸分析（Pre-mortem）
- 拆解为用户故事
- 创建干系人沟通方案
最终保存为 PRD-[产品名].md。
3.3 PRD 模板结构（8 个段落）
PRD 由两套互补的模板定义，综合如下：
1. Executive Summary / 摘要
- 2-3 句话说清：做什么、给谁做、为什么现在做
2. Contacts / 干系人
- 列出关键人：姓名、角色、备注
3. Background & Context / 背景
- 这个项目是什么？
- 为什么是现在？发生了什么变化？
- 是否有新的技术/市场条件使其变得可行？
- 已有的调研、市场背景、前序工作
4. Objectives & Success Metrics / 目标与指标
- 目标（Goals）：具体、可衡量的成功定义
- 非目标（Non-Goals）：明确不做什么、为什么不做（防止范围蔓延）
- 关键结果（Key Results）：用 SMART OKR 格式，要与公司战略对齐
- 指标表：
| 指标 | 当前值 | 目标值 | 衡量方式 |
|---|
关键原则："提升 NPS" 是差的指标，"90天内将 NPS 从 32 提升到 45" 才是好的指标。
5. Target Users & Market Segments / 目标用户与市场分群
- 为谁构建？
- 存在哪些约束？
- 市场由人的问题/待完成的工作定义，而非人口统计特征
6. Value Proposition / 价值主张
- 解决用户什么工作/需求？
- 用户会得到什么？
- 帮用户避免什么痛苦？
- 相比竞品的优势在哪里？
- 可参考价值曲线（Value Curve）框架
7. Solution / 解决方案
- 7.1 UX/原型：线框图、用户流程
- 7.2 核心功能：详细功能描述
- 7.3 技术方案（可选）：仅在相关时提供
- 7.4 假设：我们相信但尚未验证的事情
8. User Stories & Requirements / 用户故事与需求（按优先级）
P0 — Must Have（必须有）：
| # | 用户故事 | 验收标准 |
|---|
P1 — Should Have（应该有）：
| # | 用户故事 | 验收标准 |
|---|
P2 — Nice to Have / Future（最好有/未来）：
| # | 用户故事 | 验收标准 |
|---|
9. Open Questions / 待解决问题
| 问题 | 负责人 | 截止时间 |
|---|
只列真正未解决的问题，不要列能从上下文中回答的问题。
10. Timeline & Phasing / 时间线与阶段划分
- 里程碑、依赖关系
- 第一版 vs 后续版本各做什么
- 避免精确日期，使用相对时间框架
四、写 PRD 的关键原则
- 对范围要有态度 — 紧凑的 PRD 好过宽泛模糊的 PRD
- 主动建议分阶段 — 如果想法太大，主动建议分阶段，只详细定义 Phase 1
- 非目标和目标同样重要 — 它们是防止范围蔓延的利器
- 指标必须具体 — 包含当前值、目标值、衡量方式和时间框架
- 用平实语言 — 用小学生能理解的语言，避免行业术语
- 数据驱动 — 尽可能用数据支撑
- 假设要标记清楚 — 让团队知道哪些需要验证
- 每个段落要能回溯到整体战略
五、PRD 的上下游衔接
PRD 不是孤立文档，PM Skills 将其嵌入完整的产品工作流中：
/discover（产品发现）
↓ 想法 → 假设 → 优先级 → 实验
/strategy（产品策略）
↓ 愿景 → 商业模式 → 价值主张
/write-prd（撰写 PRD） ← 你在这里
↓
/pre-mortem（预验尸分析，评估 PRD 风险）
↓
/write-stories（拆解为用户故事）
↓
/sprint plan（冲刺规划）
↓
/plan-launch（上市策略）
每个命令完成后会推荐下一步可执行的命令，形成自然的工作流衔接。
六、PM Skills 全部插件使用指南
安装全部 8 个插件后，可直接在对话中输入斜杠命令触发工作流。以下是按场景分类的速查表：
7.1 产品发现（pm-product-discovery）
| 命令 | 用途 |
|---|---|
/discover | 完整发现流程：创意 → 假设 → 优先级 → 实验设计 |
/brainstorm | 多角度创意风暴（PM/设计/工程视角） |
/triage-requests | 分析和分类客户功能请求 |
/interview | 准备客户访谈脚本 或 总结访谈记录 |
/setup-metrics | 设计产品指标看板（北极星指标等） |
7.2 产品战略（pm-product-strategy）
| 命令 | 用途 |
|---|---|
/strategy | 9 部分产品战略画布 |
/business-model | 商业模式画布（精益/完整/创业） |
/value-proposition | 基于 JTBD 的价值主张设计 |
/market-scan | 宏观环境分析（SWOT + PESTLE + 波特五力 + 安索夫矩阵） |
/pricing | 定价策略设计 |
7.3 产品执行（pm-execution）
| 命令 | 用途 |
|---|---|
/write-prd | 撰写完整 PRD 文档 |
/plan-okrs | 制定团队 OKR |
/transform-roadmap | 将功能路线图转为成果导向路线图 |
/sprint | Sprint 计划 / 回顾 / 发版说明 |
/pre-mortem | 预防性风险分析 |
/meeting-notes | 会议纪要整理 |
/stakeholder-map | 利益相关者分析 + 沟通计划 |
/write-stories | 编写用户故事 / 工作故事 |
/test-scenarios | 生成测试场景 |
/generate-data | 生成模拟数据集 |
7.4 市场调研（pm-market-research）
| 命令 | 用途 |
|---|---|
/research-users | 用户画像 + 细分 + 客户旅程地图 |
/competitive-analysis | 竞品分析 |
/analyze-feedback | 用户反馈情感分析 |
7.5 数据分析（pm-data-analytics）
| 命令 | 用途 |
|---|---|
/write-query | 自然语言生成 SQL |
/analyze-cohorts | 同期群留存分析 |
/analyze-test | A/B 测试统计分析 |
7.6 上市策略（pm-go-to-market）
| 命令 | 用途 |
|---|---|
/plan-launch | 完整 GTM 计划 |
/growth-strategy | 增长飞轮 + GTM 渠道评估 |
/battlecard | 销售竞争对战卡 |
7.7 营销增长（pm-marketing-growth）
| 命令 | 用途 |
|---|---|
/market-product | 营销创意 + 定位 + 价值主张文案 + 产品命名 |
/north-star | 定义北极星指标 |
7.8 PM 工具箱（pm-toolkit）
| 命令 | 用途 |
|---|---|
/review-resume | PM 简历评审 |
/tailor-resume | 简历针对 JD 定制 |
/draft-nda | 起草保密协议 |
/privacy-policy | 起草隐私政策 |
/proofread | 语法和逻辑校对 |
推荐的入门路径
- 有新想法？ → 从
/discover开始 - 需要战略清晰度？ →
/strategy - 要写需求文档？ →
/write-prd - 准备上市？ →
/plan-launch - 定义指标？ →
/north-star
工作流串联
命令之间是设计好的链式工作流。例如一个完整的产品从 0 到 1 流程：
/discover → /strategy → /write-prd → /plan-launch → /north-star
每个命令执行完毕后，会建议下一步可以使用的命令，形成连贯的产品管理流程。
使用技巧
- 大多数命令支持参数，比如
/brainstorm ideas existing或/sprint retro - 命令执行中会有检查点，让你确认方向后再继续
- 结果会保存为 Markdown 文件到你的工作目录，方便后续引用
七、参考资源
本项目 PRD 框架融合了以下方法论：
- Teresa Torres — Continuous Discovery Habits
- Marty Cagan — INSPIRED / TRANSFORMED
- Dan Olsen — The Lean Product Playbook
- Christina Wodtke — Radical Focus（OKR）
- Anthony W. Ulwick — Jobs to Be Done
- Strategyzer — Value Proposition Design
进一步阅读：
- How to Write a Product Requirements Document? The Best PRD Template.
- A Proven AI PRD Template by Miqdad Jaffer (Product Lead @ OpenAI)
八、/write-prd 命令运行原理深度解析
/write-prd 是 pm-execution 插件中的核心命令，由命令文件（write-prd.md）和技能文件（create-prd/SKILL.md）两层协作完成。
8.1 架构：Command + Skill 分层设计
用户输入: /write-prd SSO support for enterprise customers
│
▼
┌─────────────────────────────────────────────┐
│ Command 层 (write-prd.md) │
│ 定义：触发方式、工作流步骤、交互逻辑、输出格式 │
│ 职责：编排流程、引导对话、管理迭代 │
└──────────────────┬──────────────────────────┘
│ Step 3 调用
▼
┌─────────────────────────────────────────────┐
│ Skill 层 (create-prd/SKILL.md) │
│ 定义：PRD 模板结构、写作规范、领域知识 │
│ 职责：提供 8 段式模板、写作原则、质量标准 │
└─────────────────────────────────────────────┘
- Command 是动词（做什么），负责流程编排和用户交互
- Skill 是名词（知识），负责提供领域框架和模板
8.2 触发机制
命令文件通过 YAML frontmatter 注册：
---
description: Create a comprehensive Product Requirements Document from a feature idea or problem statement
argument-hint: "<feature or problem statement>"
---
description：让 Claude 知道何时该触发这个命令argument-hint：提示用户可以传入的参数格式
用户可以用以下任何方式触发：
/write-prd SSO support for enterprise customers
/write-prd Users are dropping off during onboarding — we need to fix step 3
/write-prd [上传 brief、研究文档或策略 deck]
8.3 四步工作流详解
Step 1: 理解输入（Understand the Feature）
接受任意形式的输入，不要求结构化：
| 输入类型 | 示例 |
|---|---|
| 功能名称 | "SSO support" |
| 问题陈述 | "Enterprise customers keep asking for centralized auth" |
| 用户请求 | "Users want to export their data as CSV" |
| 模糊想法 | "We should do something about onboarding drop-off" |
| 上传文档 | brief、调研报告、Slack 讨论记录、邮件 |
设计理念：降低使用门槛——PM 不需要先整理好想法才能开始写 PRD。
Step 2: 收集上下文（Gather Context）
通过对话式提问逐步补齐信息缺口，按重要性排序：
- 用户问题 — 解决什么问题？谁遇到了？有多痛？
- 目标用户 — 哪些用户群体？数量？当前替代方案？
- 成功指标 — 如何衡量成功？哪些指标会变化？
- 约束条件 — 技术限制、时间线、合规、跨团队依赖？
- 已有尝试 — 之前试过吗？市场上有类似方案吗？
- 范围偏好 — 一次性完整方案，还是分阶段？
关键逻辑：如果用户提供了文档，先从中提取已有信息，只问缺失部分，避免重复提问。
Step 3: 生成 PRD（Generate the PRD）
调用 create-prd 技能，技能层提供两件事：
a) 角色设定
You are an experienced product manager responsible for creating
a comprehensive Product Requirements Document for $ARGUMENTS.
$ARGUMENTS 会被替换为用户传入的参数，让 AI 进入正确的角色上下文。
b) 思考框架（Think Step by Step）
技能要求 AI 在写之前先分析四个问题：
- 我们要解决什么问题？
- 我们为谁解决？
- 如何衡量成功？
- 约束和假设是什么？
c) 8 段式 PRD 模板
Command 层和 Skill 层各定义了一套模板，两者互补：
| 段落 | Command 层定义 | Skill 层补充 |
|---|---|---|
| 1. 摘要 | 2-3 句话：what, for whom, why now | 同 |
| 2. 干系人/背景 | Background & Context | Contacts（姓名、角色、备注）+ Background（为什么是现在？是否新近可行？） |
| 3. 目标与指标 | Goals + Non-Goals + Success Metrics 表 | Objective + SMART OKR Key Results + 战略对齐 |
| 4. 目标用户 | Who this serves, segment sizing | 市场由问题/JTBD 定义，非人口统计 |
| 5. 用户故事 | P0/P1/P2 三级优先级表 | — |
| 6. 价值主张 | — | 客户 JTBD、收益、痛点、竞争优势、价值曲线 |
| 7. 解决方案 | High-level approach, design decisions | UX/原型 + 核心功能 + 技术方案(可选) + 假设 |
| 8. 时间线 | Milestones, dependencies, phasing | 首版 vs 后续版本，用相对时间框架 |
| 附: 开放问题 | Question + Owner + Deadline 表 | — |
Step 4: 评审与迭代（Review and Iterate）
生成后不是结束，而是提供四个后续选项：
1. "Want me to tighten the scope?" → 挑战 P1 是否应降为 P2
2. "Should I run a pre-mortem?" → 链接到 /pre-mortem 命令
3. "Want me to break this into stories?" → 链接到 /write-stories 命令
4. "Create a stakeholder update?" → 链接到 /stakeholder-map 命令
这就是链式工作流的实现方式：每个命令在完成后推荐下一个命令。
最终保存为 PRD-[产品名].md。
8.4 写作质量控制（Notes 层）
Command 和 Skill 两层都定义了质量规则，合并后形成完整的写作标准：
| 规则 | 来源 |
|---|---|
| 对范围要有态度——紧凑的 PRD 好过宽泛模糊的 PRD | Command |
| 如果想法太大，主动建议分阶段，只详细定义 Phase 1 | Command |
| 非目标和目标同样重要——防止范围蔓延 | Command |
| 指标必须具体："improve NPS" 是差的，"increase NPS from 32 to 45 within 90 days" 才是好的 | Command |
| 开放问题必须是真正未解决的，不要列能从上下文回答的问题 | Command |
| 如果用户提供了调研，将洞察织入 Background 段落并标注来源 | Command |
| 用平实语言，为小学生写作水平即可理解 | Skill |
| 尽可能数据驱动 | Skill |
| 每个段落要能回溯到整体战略 | Skill |
| 假设要标记清楚，让团队知道哪些需要验证 | Skill |
8.5 运行流程时序图
用户 Command 层 Skill 层
│ │ │
│── /write-prd "SSO" ───→│ │
│ │ │
│ [Step 1: 解析输入] │
│ │ │
│←── "SSO 是给谁用的？ │ │
│ 有什么约束？" ──────│ │
│ │ │
│── "企业客户，要支持 │ │
│ SAML 和 OIDC" ─────→│ │
│ [Step 2: 补齐上下文] │
│ │ │
│←── "成功指标是什么？" ──│ │
│ │ │
│── "SSO 采纳率 > 60%" ─→│ │
│ │ │
│ │── 调用 create-prd ───→│
│ │ │
│ │ [应用 8 段模板] │
│ │ [应用写作规范] │
│ │ [Think Step by Step]│
│ │ │
│ │←── 返回 PRD 文档 ─────│
│ [Step 3: 输出 PRD] │
│ │ │
│←── PRD-SSO.md ─────────│ │
│ │ │
│ [Step 4: 提供后续选项] │
│←── "要收紧范围吗？ │ │
│ 要跑预验尸吗？ │ │
│ 要拆用户故事吗？" ──│ │
│ │ │
8.6 设计亮点总结
- 双层架构：Command 管流程编排，Skill 管领域知识，职责分离、可独立复用
- 渐进式信息收集：不要求一次给全信息，通过对话逐步补齐
- 智能跳过：有文档输入时自动提取已有信息，只问缺失部分
- 强制质量标准：通过 Notes 层硬编码写作规则，防止 AI 生成模糊内容
- 链式工作流：Step 4 的后续选项自然链接到其他命令（
/pre-mortem、/write-stories、/stakeholder-map） - 文件持久化：输出保存为
PRD-[产品名].md，成为团队可共享的工件
