菜单
产品 PRD 生成工具。结合《创造》的产品故事方法论、product-position 的定位框架， 以及 Lenny's Newsletter 的 PRD 最佳实践，帮你从想法生成一份可执行的产品需求文档。 触发方式：/li-prd、「帮我写 PRD」「生成需求文档」「写产品文档」「把这个想法写成 PRD」 「黑客松 PRD」「整理产品需求」「我要开始做了，帮我理清需求」 即使用户没说"PRD"，只要他们想把一个产品想法整理成可执行的文档，也应触发本 skill。 DO NOT trigger for: 内容脚本生成、选题分析、数据复盘等内容创作任务。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
当用户说「数据复盘」「爆款分析」「分析我的内容」「拆解博主爆款」「分析哪期视频最火」时，应使用本 skill。 当用户说「全对标分析」「跨博主分析」「哪类选题最容易爆」「总结爆款规律」时，以全对标模式运行，读取所有爆款话题分析报告进行横向比较。 自动读取已发布视频脚本，按爆款等级（✈️🚗🛵🚲🚶）分类，提取标题公式、内容结构、话题类型等可复用创作规律，生成分类整理报告。 不应触发：选题推荐（用 li-recorder）、写脚本（用 li-writer）。 Use when the user asks to "analyze my content", "data review", "viral analysis", or wants to break down a creator's top-performing videos.
当用户说「生成封面」「封面配文」「小红书标题」「优化标题」「帮我写封面」时，应使用本 skill。 基于认知心理学 + 行为经济学，识别内容类型和权威元素，自动选择驱动策略，输出激进/平衡/保守三版方案，每版含封面配文 + 3 个标题，并附四维评分和 A/B 测试建议。 不应触发：写视频脚本（用 li-writer）、优化开头（用 li-opening）。 Use when the user asks to "generate cover", "cover copy", "XHS title", "optimize title", or needs Xiaohongshu cover text and title variants.
当用户说「一鱼多吃」「生成长文」「生成短文」「转成公众号文章」「帮我出朋友圈/推特/即刻版本」「基于这个脚本生成其他格式」时，应使用本 skill。 基于已确认的短视频脚本，调用 li-writer 生成长文（公众号）或短文（朋友圈/推特/即刻）。 即使用户只说「出长文」「出短文」没有明确说来源，也应主动找脚本让用户选择。 不应触发：生成原始脚本（用 li-writer）、优化开头（用 li-opening）、生成封面（用 li-cover）。 Use when the user wants to repurpose a finalized video script into a long-form article or short posts.
This skill should be used when the user wants to "create a skill", "build a new skill", "write a skill", "improve a skill", "update a skill", "optimize skill description", or needs guidance on skill structure, progressive disclosure, or skill development best practices. 触发方式：/li-factory、「创建skill」、「改进skill」、「帮我写一个skill」、「优化skill」、「把这个流程变成skill」、「这个工作流能做成skill吗」。即使用户没有明确说"skill"，只要他们想把某个重复流程自动化或封装成可复用工具，也应该触发本 skill。
当用户说「更新索引」「把这个加进索引」「添加了新文件」「新加了一本书/一篇笔记/一个文档」「素材库索引要更新」时，应使用本 skill 的【增量维护模式】。 当用户说「索引体检」「index 体检」「检查索引」「索引同步」「补齐索引」时，应使用本 skill 的【体检模式】，扫描所有库 ↔ INDEX 找出漏录/失效条目并批量补齐。 适用于所有带 INDEX.md 的库：读书笔记库、核心概念库、爆款脚本库、04-方法论沉淀，以及未来新建的任何库。 索引的价值取决于内容准确性——必须先完整读取原文再写入，凭文件名或印象推断会导致索引失去参考价值。 即使用户只说「我加了一个文件」「这个放进去」，只要涉及索引，也应触发本 skill。 不应触发：仅查阅索引（直接 Read）、深化选题（用 li-topic）、生成脚本（用 li-writer）。 Use when the user adds new content to any indexed library, OR runs a global index health-check to find missing/stale entries.
当用户说「优化开头」「开头怎么写」「帮我写钩子」「开头不好」或提供了视频脚本需要改进开头时，应使用本 skill。 先做内容质量守门（素材是否充足）和视界诊断（是否从观众视界出发），再三路并发生成 10-15 条开头方案，附 Top 3 推荐和爆款模板说明。 不应触发：生成完整脚本（用 li-writer）、生成封面标题（用 li-cover）。 Use when the user wants to "optimize opening", "write hook", "improve intro", or provides a script needing a better opening.
| name | li-prd |
| description | 产品 PRD 生成工具。结合《创造》的产品故事方法论、product-position 的定位框架， 以及 Lenny's Newsletter 的 PRD 最佳实践，帮你从想法生成一份可执行的产品需求文档。 触发方式：/li-prd、「帮我写 PRD」「生成需求文档」「写产品文档」「把这个想法写成 PRD」 「黑客松 PRD」「整理产品需求」「我要开始做了，帮我理清需求」 即使用户没说"PRD"，只要他们想把一个产品想法整理成可执行的文档，也应触发本 skill。 DO NOT trigger for: 内容脚本生成、选题分析、数据复盘等内容创作任务。 |
把想法变成团队能执行的文档。
核心原则：PRD 的第一读者是自己。 写完不想读，工程师也不会读。
启动后先问：
你现在有多少明确的信息？ A. 只有一个想法，还很模糊 B. 想法清晰了，但没整理过 C. 基本想清楚了，帮我结构化输出
/product-position 做定位分析，再回来写 PRD。原因：PRD 是对已验证方向的结构化，不是用来帮产品方向找答案的。每次只问一个问题，等回答后再问下一个。提问顺序固定，因为每个问题的答案会影响后续问题的质量。
问题 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
> 版本：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 句：
用户的痛点是什么 → 产品解决了什么 → 用户现在能做到什么]
---
## 开放问题
| 问题 | 影响 | 截止日期 |
|------|------|---------|
| | | |
---
## 风险
| 风险 | 概率 | 应对 |
|------|------|------|
| | 高/中/低 | |
生成草稿后，过以下四项，发现问题直接修改：
确认 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 真实案例（按需加载）