| name | li-prd |
| description | 产品 PRD 生成工具。结合《创造》的产品故事方法论、product-position 的定位框架，
以及 Lenny's Newsletter 的 PRD 最佳实践，帮你从想法生成一份可执行的产品需求文档。
触发方式：/li-prd、「帮我写 PRD」「生成需求文档」「写产品文档」「把这个想法写成 PRD」
「黑客松 PRD」「整理产品需求」「我要开始做了，帮我理清需求」
即使用户没说"PRD"，只要他们想把一个产品想法整理成可执行的文档，也应触发本 skill。
DO NOT trigger for: 内容脚本生成、选题分析、数据复盘等内容创作任务。
|
li-prd：产品需求文档生成
把想法变成团队能执行的文档。
核心原则：PRD 的第一读者是自己。 写完不想读，工程师也不会读。
前置检查
启动后先问：
你现在有多少明确的信息？
A. 只有一个想法，还很模糊
B. 想法清晰了，但没整理过
C. 基本想清楚了，帮我结构化输出
- A → 建议先跑
/product-position 做定位分析，再回来写 PRD。原因：PRD 是对已验证方向的结构化，不是用来帮产品方向找答案的。
- B → 进入引导模式
- C → 进入直接生成模式，先出草稿再修订
引导模式
每次只问一个问题，等回答后再问下一个。提问顺序固定，因为每个问题的答案会影响后续问题的质量。
问题 1 — Why Now
为什么是现在做这个，而不是三个月后？
如果答案是"因为有黑客松"或"因为想清楚了"——追问：产品本身的 Why Now 是什么？外部触发只是时间节点，产品逻辑上的紧迫性才是真正的 Why Now。
问题 2 — Target User
谁是你的第一个用户？命名一个真实的人，不是用户画像。
"内容创作者"不够，"已装 Claude Code、用手动维护 CLAUDE.md 的独立博主" 才是目标。用户越具体，功能越清晰。
问题 3 — Status Quo
这个用户现在怎么解决这个问题的？
产品必须比某个现有方案更好。说不出替代方案，说明痛点可能不够真实。
问题 4 — Success Criteria
三个月后，怎么知道做对了？给一个可量化的指标。
"用户喜欢"不算。"第二天还在用"、"有 10 个非创始人用户"才算。
问题 5 — Out of Scope
列出 2-3 件你故意不做的事。
边界清晰比功能完整重要。Out of Scope 是对团队和自己的承诺。
问题 6 — MVP
第一版要交付什么？用"用户能做到 X"描述，不用功能列表。
功能列表是实现路径，MVP 是用户能感受到的价值边界。
收集完 6 个答案后进入生成阶段。
生成 PRD
基于收集到的信息，填入以下模板。每个模块生成后暂停，确认无误再继续下一个。
# [产品名] PRD
> 版本：v[X] | 日期：[YYYY-MM-DD] | 作者：[名字]
> 状态：草稿 / 评审中 / 已确认
---
## 一句话描述
[谁 + 用来做什么 + 解决什么问题，一句话]
示例：理理 Liri 是一个 Mac 桌面 App，让不会用 Claude Code 的创作者
也能通过"文件夹即 App"的方式使用 AI 管理自己的工作流。
---
## 为什么做
### 问题
[用户现在遇到的真实问题，用具体场景描述，不用抽象概念]
### 为什么现在
[为什么是现在，而不是三个月后或三个月前]
### 怀疑病毒
[一句让用户开始质疑现有方案的话]
示例："每次打开 Claude Code 都要重新解释你是谁，这件事会一直发生。"
---
## 目标用户
**主要用户：** [一个具体的人的描述]
**次要用户：** [可选]
**不是我们的用户：** [明确排除，防止范围蔓延]
---
## 客户旅程
| 阶段 | 用户做什么 | 产品做什么 |
|------|-----------|-----------|
| 发现 | | |
| 安装/启动 | | |
| 首次使用 | | |
| 持续使用 | | |
| 推荐他人 | | |
标出最薄弱的环节，并在功能范围里重点说明该环节的设计方案。通常"持续使用"是最容易被忽视的。
---
## 功能范围
### 必须做（Must Have）
[用"用户能做到 X"描述，不用技术实现语言]
- 用户能 ...
- 用户能 ...
### 不做（Out of Scope）
- 不做 ...（原因：...）
- 不做 ...（原因：...）
### 以后做（Future）
[想做但不是现在]
---
## 成功标准
**第一版验收（黑客松/MVP）：**
- [ ] [用户 A 能在 X 分钟内完成 Y，无需任何指导]
- [ ] [具体可测试的行为]
**3 个月目标：**
- [一个核心指标]
---
## 新闻稿
先写新闻稿，再写代码。如果写不出来，说明产品故事还没想清楚。
[假设产品已上线，写 3-5 句：
用户的痛点是什么 → 产品解决了什么 → 用户现在能做到什么]
---
## 开放问题
| 问题 | 影响 | 截止日期 |
|------|------|---------|
| | | |
---
## 风险
| 风险 | 概率 | 应对 |
|------|------|------|
| | 高/中/低 | |
生成后自检
生成草稿后，过以下四项，发现问题直接修改：
- Why Now 存在吗？ 去掉这段，PRD 还能说服人开始做吗？
- 成功标准可测量吗？ 能不能让一个陌生人来验证？
- Out of Scope 写了吗？ 没有边界的 PRD 是灾难
- 客户旅程最薄弱环节标出来了吗？ 没有针对性设计方案的薄弱环节是隐患
保存
确认 PRD 内容后，询问保存路径，默认建议：
[产品名]/[产品名]-PRD-v1.md
用户确认后保存。
下一步推荐
| 触发条件 | 推荐 |
|---|
| PRD 写好，要让专家顾问强化 | /li-prd-review 托尼/YC/Lenny 找漏洞给方案 |
| PRD 写好，要验证方向 | /product-position |
| PRD 写好，要做内容传播 | /li-topic 把产品故事转成选题 |
| PRD 写好，要开始开发 | /li-workflow 检查工作流覆盖情况 |
| 商业模式不清晰 | /dbs-diagnosis |
附加资源
references/prd-examples.md — 理理 Liri 黑客松 PRD 真实案例（按需加载）
