SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsli-prd

li-prd

General & other

View repository

Updated 10-15 23:32

About this skill

li-prd: Product Requirements Document Generation

Turn ideas into documents the team can execute.

Core principle: The first reader of a PRD is yourself. If you don't want to read it after writing it, engineers won't read it either.

Pre-check

After starting, first ask:

How much clear information do you have right now? A. Just an idea, still very vague B. The idea is clear, but hasn't been organized C. Basically thought through, help me output it in a structured way

  • A → Suggest running /product-position for positioning analysis first, then come back to write the PRD. Reason: A PRD is a structured output for a validated direction, not something used to help find answers for the product direction.
  • B → Enter guided mode
  • C → Enter direct generation mode, produce a draft first and then revise

Guided Mode

Ask only one question at a time, and wait for the answer before asking the next. The question order is fixed, because the answer to each question affects the quality of subsequent questions.

Question 1 — Why Now

Why do this now, rather than three months later?

If the answer is "because there's a hackathon" or "because I've thought it through"—follow up: What is the product's own Why Now? An external trigger is only a timing point; the urgency in the product logic is the real Why Now.

Question 2 — Target User

Who is your first user? Name a real person, not a user persona.

"Content creator" is not enough; "an independent blogger who has installed Claude Code and manually maintains CLAUDE.md" is the target. The more specific the user, the clearer the features.

Question 3 — Status Quo

How does this user currently solve this problem?

The product must be better than some existing solution. If you can't name an alternative, it means the pain point may not be real enough.

Question 4 — Success Criteria

Three months later, how do you know you got it right? Give a quantifiable metric.

"Users like it" doesn't count. "Still using it the next day" and "10 non-founder users" do count.

Question 5 — Out of Scope

List 2-3 things you deliberately will not do.

Clear boundaries are more important than complete features. Out of Scope is a commitment to the team and to yourself.

Question 6 — MVP

What should the first version deliver? Describe it as "users can do X", not as a feature list.

A feature list is the implementation path; the MVP is the boundary of value users can feel.

After collecting all 6 answers, enter the generation stage.

Generate PRD

Based on the collected information, fill in the following template. After generating each module, pause and continue to the next one only after confirming it is correct.

# [产品名] 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 句：
用户的痛点是什么 → 产品解决了什么 → 用户现在能做到什么]

---

## 开放问题

| 问题 | 影响 | 截止日期 |
|------|------|---------|
| | | |

---

## 风险

| 风险 | 概率 | 应对 |
|------|------|------|
| | 高/中/低 | |

Post-generation self-check

After generating the draft, go through the following four items and directly revise any problems found:

  1. Does Why Now exist? If you remove this section, can the PRD still persuade people to start building?
  2. Are the success criteria measurable? Can a stranger verify them?
  3. Is Out of Scope written? A PRD without boundaries is a disaster
  4. Have the weakest links in the customer journey been identified? Weak links without targeted design solutions are hidden risks

Save

After confirming the PRD content, ask for the save path. Default suggestion:

[产品名]/[产品名]-PRD-v1.md

Save after user confirmation.

Next Step Recommendations

Trigger Condition Recommendation
PRD is ready; need expert consultants to strengthen it /li-prd-review Tony/YC/Lenny find loopholes and provide solutions
PRD is ready; need to validate direction /product-position
PRD is ready; need to do content distribution /li-topic Turn the product story into topic ideas
PRD is ready; need to start development /li-workflow Check workflow coverage
Business model is unclear /dbs-diagnosis

Additional Resources

  • references/prd-examples.md — Liri Hackathon PRD real case (load on demand)