prd-generation

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PRD Generation

PRD生成

Overview

概述

Transform high-level ideas into structured Product Requirements Documents through guided discovery. This skill walks through problem/solution/constraint discovery, generates a professional PRD with measurable goals and user stories, and ensures stakeholder approval before saving.

Announce at start: "I'm using the prd-generation skill to create a Product Requirements Document."

通过引导式调研将高层创意转化为结构化的产品需求文档。本Skill会引导完成问题/解决方案/约束条件调研，生成包含可衡量目标和用户故事的专业PRD，并在保存前确保获得利益相关方批准。

启动时声明： "我正在使用prd-generation Skill创建产品需求文档。"

Phase 1: Discovery

阶段1：调研

Ask these questions ONE AT A TIME (prefer multiple choice where possible).

Do NOT skip discovery. Even if the user provides a detailed brief, confirm understanding by asking at least 3 clarifying questions.

STOP after discovery — present a summary of collected answers and get confirmation before drafting.

逐个提出以下问题（尽可能提供多选选项）。

不得跳过调研环节。 即使用户提供了详细的需求说明，也至少要提出3个澄清问题来确认理解无误。

调研结束后停止流程——先展示收集到的答案摘要，获得用户确认后再进入起草环节。

Problem Space Questions

问题域相关问题

#	Question	Why It Matters
1	What problem does this solve?	Anchors the entire PRD
2	Who are the target users? (personas, roles)	Shapes user stories
3	How are users currently solving this?	Identifies competitive landscape
4	What is the impact of NOT solving this?	Justifies priority

#	问题	重要性
1	该需求解决了什么问题？	为整个PRD锚定核心方向
2	目标用户是谁？（用户画像、角色）	支撑用户故事的设计
3	用户目前是如何解决这个问题的？	明确竞争格局
4	不解决这个问题会带来什么影响？	为优先级判定提供依据

Solution Space Questions

方案域相关问题

#	Question	Why It Matters
5	What does success look like? (specific metrics)	Defines success metrics
6	What are must-have vs nice-to-have features?	Sets priority tiers
7	What are the explicit non-goals?	Prevents scope creep
8	Are there existing solutions to learn from?	Informs design decisions

#	问题	重要性
5	成功的标准是什么？（具体指标）	定义可量化的成功指标
6	哪些是必备功能，哪些是锦上添花的功能？	设定优先级层级
7	明确不做的事项有哪些？	避免范围蔓延
8	有没有可参考的现有解决方案？	为设计决策提供参考

Constraint Questions

约束条件相关问题

#	Question	Why It Matters
9	What is the timeline? Any hard deadlines?	Scopes release plan
10	What technical constraints exist?	Narrows solution space
11	What resources are available?	Sets realistic expectations
12	Are there compliance or regulatory requirements?	Identifies non-functional reqs

#	问题	重要性
9	时间周期是怎样的？有没有硬性截止日期？	划定发布计划的范围
10	存在哪些技术约束？	缩小可行方案的范围
11	可用资源有哪些？	设定合理的预期
12	是否有合规或监管要求？	明确非功能性需求

Phase 2: Draft PRD

阶段2：PRD起草

Generate the PRD using the template below. Dispatch the

prd-writer

agent with collected answers for heavy generation.

STOP after drafting — do NOT present as final until Phase 3 review is complete.

使用下方模板生成PRD。调用

prd-writer

agent基于收集到的答案完成生成工作。

起草完成后停止流程——在完成阶段3的评审前，不要将草稿作为最终版本呈现。

PRD Template

PRD模板

markdown

undefined

markdown

undefined

[Product/Feature Name] — Product Requirements Document

1. Overview

One paragraph summarizing what this is and why it matters.

2. Problem Statement

Current situation
Pain points
Impact of not solving

Current situation
Pain points
Impact of not solving

3. Goals & Non-Goals

Goals

Goal 1 (measurable)
Goal 2 (measurable)

Goal 1 (measurable)
Goal 2 (measurable)

Non-Goals

Explicitly NOT doing X
Explicitly NOT doing Y

Explicitly NOT doing X
Explicitly NOT doing Y

4. User Stories

As a [persona], I want to [action], so that [benefit].

5. Functional Requirements

FR-1: [Requirement Name]

Description
Acceptance criteria
Priority (P0/P1/P2)

Description
Acceptance criteria
Priority (P0/P1/P2)

6. Non-Functional Requirements

Performance: [specific targets]
Security: [requirements]
Accessibility: [standards]
Scalability: [expectations]

Performance: [specific targets]
Security: [requirements]
Accessibility: [standards]
Scalability: [expectations]

7. Technical Constraints

Platform/stack requirements
Integration dependencies
Data requirements

Platform/stack requirements
Integration dependencies
Data requirements

8. Success Metrics

Metric	Current	Target	How to Measure

Metric	Current	Target	How to Measure

9. Timeline & Milestones

Phase	Description	Target Date

Phase	Description	Target Date

10. Open Questions

Question 1
Question 2

Question 1
Question 2

11. Appendix

References, mockups, related documents

undefined

References, mockups, related documents

undefined

Priority Classification

优先级定义

Priority	Meaning	Rule
P0	Must-have for launch	Without this, the product does not ship
P1	Important, ship soon after launch	Significant value but not blocking
P2	Nice-to-have	Enhances experience, can wait

优先级	含义	规则
P0	上线必备	缺少该功能产品就不能发布
P1	重要功能，上线后尽快发布	价值显著但不阻塞上线
P2	锦上添花的功能	可提升体验，后续迭代再做

Phase 3: Review

阶段3：评审

Present the PRD section by section:

After each section, ask: "Does this capture your intent? Any changes?"
Revise based on feedback before moving to next section
Pay special attention to these high-signal sections:
- Goals & Non-Goals (scope alignment)
- User Stories (persona accuracy)
- Success Metrics (measurability)
- Functional Requirements (acceptance criteria completeness)

STOP after review — get explicit "approved" confirmation before saving.

逐节展示PRD内容：

每展示完一节后询问："这部分是否符合你的预期？有没有需要修改的地方？"
根据反馈修改完成后再进入下一节的评审
重点关注这些高优先级章节：
- 目标与非目标（范围对齐）
- 用户故事（用户画像准确性）
- 成功指标（可衡量性）
- 功能性需求（验收标准完整性）

评审结束后停止流程——获得明确的「批准」确认后再进行保存操作。

Phase 4: Save and Transition

阶段4：保存与流程过渡

After explicit approval:

Save to
```
docs/prds/YYYY-MM-DD-<feature>.md
```
Commit the PRD with message:
```
docs(prd): add PRD for <feature>
```
If implementation follows, invoke the
```
brainstorming
```
skill
If specs are needed, invoke the
```
spec-writing
```
skill

获得明确批准后：

保存到路径
```
docs/prds/YYYY-MM-DD-<feature>.md
```
提交PRD，提交信息为：
```
docs(prd): add PRD for <feature>
```
如果需要后续实施，调用
```
brainstorming
```
skill
如果需要产出详细规格，调用
```
spec-writing
```
skill

Transition Decision Table

过渡决策表

User Intent	Next Skill	Rationale
"Let's build this"	`brainstorming` → `planning`	Explore approaches then plan
"Write the specs"	`spec-writing`	Break PRD into JTBD specs
"Just save it"	None	PRD is the deliverable
"Get estimates"	`task-decomposition`	Break into estimable tasks

用户意图	下一个调用的Skill	逻辑说明
"我们来开发这个功能吧"	`brainstorming` → `planning`	先探索实现方案再做规划
"写一下详细规格"	`spec-writing`	将PRD拆解为JTBD规格
"直接保存就行"	无	PRD本身就是交付物
"评估一下工作量"	`task-decomposition`	拆解为可估算的任务

Anti-Patterns / Common Mistakes

反模式/常见错误

Mistake	Why It Is Wrong	What To Do Instead
Skipping discovery and jumping to draft	Produces assumptions-based PRD	Always complete Phase 1 first
Goals without metrics	Cannot measure success	Every goal needs a number
Missing non-goals	Scope creep guaranteed	Explicitly list what is out of scope
User stories without acceptance criteria	Untestable requirements	Add Given/When/Then to each story
Generic success metrics ("improve UX")	Unmeasurable	Use specific numbers: "reduce load time to <2s"
Presenting entire PRD at once for review	User overwhelmed, gives superficial approval	Present section by section
Copying competitor features verbatim	Misses actual user needs	Focus on user problems, not solutions

错误	问题所在	正确做法
跳过调研直接开始起草	产出的PRD基于假设而非实际需求	始终先完成阶段1的调研
目标没有对应衡量指标	无法判断是否达成目标	每个目标都要有可量化的数值
缺少非目标定义	必然会出现范围蔓延	明确列出不在本次范围内的事项
用户故事没有验收标准	需求无法测试	为每个故事添加Given/When/Then格式的验收标准
使用通用的成功指标（比如「提升UX」）	无法衡量	使用具体数值：比如「将加载时间缩短到2秒以内」
一次性展示完整PRD供评审	用户负担过重，只会给出表面的同意	逐节展示评审
原样照搬竞品功能	忽略了自身用户的真实需求	聚焦用户问题而非现成解决方案

Anti-Rationalization Guards

防不合理操作规则

Do NOT skip discovery because "the user already described it well enough"
Do NOT leave placeholder text in any section — fill every section or mark as "TBD: [reason]"
Do NOT proceed to save without explicit user approval of each section
Do NOT invent success metrics — they must come from the user

不得因为「用户已经描述得足够清楚」就跳过调研环节
不得在任何章节保留占位符文本——要么填完所有内容，要么标记为「待确认：[原因]」
不得在没有获得用户对每个章节的明确批准前就进入保存环节
不得自行编造成功指标——必须由用户提供

Integration Points

集成关联

Skill	Relationship
`brainstorming`	Upstream: explores ideas before PRD; downstream: explores implementation after PRD
`spec-writing`	Downstream: PRD provides high-level requirements; specs detail them with JTBD
`planning`	Downstream: plan references PRD requirements for task breakdown
`task-decomposition`	Downstream: breaks PRD into estimable work items
`tech-docs-generator`	Parallel: PRD informs what documentation is needed
`acceptance-testing`	Downstream: acceptance criteria from PRD feed test definitions

Skill	关联关系
`brainstorming`	上游：PRD生成前用于探索创意；下游：PRD确认后用于探索实现方案
`spec-writing`	下游：PRD提供高层需求，规格文档基于PRD细化为JTBD
`planning`	下游：项目规划会参考PRD需求来做任务拆解
`task-decomposition`	下游：将PRD拆解为可估算的工作项
`tech-docs-generator`	并行：PRD会明确需要产出哪些技术文档
`acceptance-testing`	下游：PRD中的验收标准会作为测试用例的输入

Verification Gate

验证关口

Before claiming the PRD is complete:

VERIFY all 11 sections are filled (not placeholder text)
VERIFY every goal has a measurable metric
VERIFY non-goals are explicit and meaningful
VERIFY user stories have acceptance criteria
VERIFY user has approved each section individually
VERIFY the file is saved and committed

在宣告PRD完成前需确认：

所有11个章节都已填写完成（无占位符文本）
每个目标都有可衡量的指标
非目标定义明确且有实际意义
用户故事都包含验收标准
用户已经逐个批准了所有章节
文件已保存并提交到版本库

Concrete Example: Discovery Summary

具体示例：调研摘要

Problem: Users cannot find relevant search results in the dashboard.
Users: Data analysts (primary), team leads (secondary).
Current workaround: Export to Excel and use Ctrl+F.
Impact of not solving: 30min/day wasted per analyst (team of 12).
Success metric: Reduce average search time from 5min to <30s.
Must-have: Full-text search across all dashboard widgets.
Non-goal: Advanced boolean query syntax (P2, not launch).
Timeline: 6 weeks to MVP.
Constraint: Must work with existing Elasticsearch cluster.

This summary is presented to the user for confirmation before Phase 2 begins.

Problem: Users cannot find relevant search results in the dashboard.
Users: Data analysts (primary), team leads (secondary).
Current workaround: Export to Excel and use Ctrl+F.
Impact of not solving: 30min/day wasted per analyst (team of 12).
Success metric: Reduce average search time from 5min to <30s.
Must-have: Full-text search across all dashboard widgets.
Non-goal: Advanced boolean query syntax (P2, not launch).
Timeline: 6 weeks to MVP.
Constraint: Must work with existing Elasticsearch cluster.

该摘要会在进入阶段2前展示给用户确认。

Skill Type

Skill类型

Flexible — Adapt discovery depth and PRD structure to project context while preserving the discovery-before-drafting principle and section-by-section review process.

灵活适配型 —— 可根据项目上下文调整调研深度和PRD结构，但始终遵循「先调研后起草」的原则和逐节评审的流程。