推荐订阅源

一、项目概述

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: 收集上下文（对话式提问）

按重要性排序，逐步补齐信息缺口：

1. 用户问题 — 解决什么问题？谁遇到了这个问题？有多痛？
2. 目标用户 — 哪些用户群体？数量？当前替代方案是什么？
3. 成功指标 — 如何衡量成功？哪些指标会变化？
4. 约束条件 — 技术限制、时间线、合规要求、跨团队依赖？
5. 已有尝试 — 之前试过吗？市场上有类似方案吗？
6. 范围偏好 — 一次性完整方案，还是分阶段交付？

如果用户提供了文档，则先从中提取已有信息，只问缺失部分。

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 的关键原则

1. 对范围要有态度 — 紧凑的 PRD 好过宽泛模糊的 PRD
2. 主动建议分阶段 — 如果想法太大，主动建议分阶段，只详细定义 Phase 1
3. 非目标和目标同样重要 — 它们是防止范围蔓延的利器
4. 指标必须具体 — 包含当前值、目标值、衡量方式和时间框架
5. 用平实语言 — 用小学生能理解的语言，避免行业术语
6. 数据驱动 — 尽可能用数据支撑
7. 假设要标记清楚 — 让团队知道哪些需要验证
8. 每个段落要能回溯到整体战略

---

五、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

每个命令执行完毕后，会建议下一步可以使用的命令，形成连贯的产品管理流程。

使用技巧

1. 大多数命令支持参数，比如 /brainstorm ideas existing 或 /sprint retro
2. 命令执行中会有检查点，让你确认方向后再继续
3. 结果会保存为 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）

通过对话式提问逐步补齐信息缺口，按重要性排序：

1. 用户问题 — 解决什么问题？谁遇到了？有多痛？
2. 目标用户 — 哪些用户群体？数量？当前替代方案？
3. 成功指标 — 如何衡量成功？哪些指标会变化？
4. 约束条件 — 技术限制、时间线、合规、跨团队依赖？
5. 已有尝试 — 之前试过吗？市场上有类似方案吗？
6. 范围偏好 — 一次性完整方案，还是分阶段？

关键逻辑：如果用户提供了文档，先从中提取已有信息，只问缺失部分，避免重复提问。

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 设计亮点总结

1. 双层架构：Command 管流程编排，Skill 管领域知识，职责分离、可独立复用
2. 渐进式信息收集：不要求一次给全信息，通过对话逐步补齐
3. 智能跳过：有文档输入时自动提取已有信息，只问缺失部分
4. 强制质量标准：通过 Notes 层硬编码写作规则，防止 AI 生成模糊内容
5. 链式工作流：Step 4 的后续选项自然链接到其他命令（/pre-mortem、/write-stories、/stakeholder-map）
6. 文件持久化：输出保存为 PRD-[产品名].md，成为团队可共享的工件