Back to Details

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

问题域相关问题

#QuestionWhy It Matters
1What problem does this solve?Anchors the entire PRD
2Who are the target users? (personas, roles)Shapes user stories
3How are users currently solving this?Identifies competitive landscape
4What is the impact of NOT solving this?Justifies priority
#问题重要性
1该需求解决了什么问题？为整个PRD锚定核心方向
2目标用户是谁？（用户画像、角色）支撑用户故事的设计
3用户目前是如何解决这个问题的？明确竞争格局
4不解决这个问题会带来什么影响？为优先级判定提供依据

Solution Space Questions

方案域相关问题

#QuestionWhy It Matters
5What does success look like? (specific metrics)Defines success metrics
6What are must-have vs nice-to-have features?Sets priority tiers
7What are the explicit non-goals?Prevents scope creep
8Are there existing solutions to learn from?Informs design decisions
#问题重要性
5成功的标准是什么？（具体指标）定义可量化的成功指标
6哪些是必备功能，哪些是锦上添花的功能？设定优先级层级
7明确不做的事项有哪些？避免范围蔓延
8有没有可参考的现有解决方案？为设计决策提供参考

Constraint Questions

约束条件相关问题

#QuestionWhy It Matters
9What is the timeline? Any hard deadlines?Scopes release plan
10What technical constraints exist?Narrows solution space
11What resources are available?Sets realistic expectations
12Are 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

[Product/Feature Name] — Product Requirements Document

1. Overview

1. Overview

One paragraph summarizing what this is and why it matters.
One paragraph summarizing what this is and why it matters.

2. Problem Statement

2. Problem Statement

  • Current situation
  • Pain points
  • Impact of not solving
  • Current situation
  • Pain points
  • Impact of not solving

3. Goals & Non-Goals

3. Goals & Non-Goals

Goals

Goals

  • Goal 1 (measurable)
  • Goal 2 (measurable)
  • Goal 1 (measurable)
  • Goal 2 (measurable)

Non-Goals

Non-Goals

  • Explicitly NOT doing X
  • Explicitly NOT doing Y
  • Explicitly NOT doing X
  • Explicitly NOT doing Y

4. User Stories

4. User Stories

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

5. Functional Requirements

5. Functional Requirements

FR-1: [Requirement Name]

FR-1: [Requirement Name]

  • Description
  • Acceptance criteria
  • Priority (P0/P1/P2)
  • Description
  • Acceptance criteria
  • Priority (P0/P1/P2)

6. Non-Functional Requirements

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

7. Technical Constraints

  • Platform/stack requirements
  • Integration dependencies
  • Data requirements
  • Platform/stack requirements
  • Integration dependencies
  • Data requirements

8. Success Metrics

8. Success Metrics

MetricCurrentTargetHow to Measure
MetricCurrentTargetHow to Measure

9. Timeline & Milestones

9. Timeline & Milestones

PhaseDescriptionTarget Date
PhaseDescriptionTarget Date

10. Open Questions

10. Open Questions

  • Question 1
  • Question 2
  • Question 1
  • Question 2

11. Appendix

11. Appendix

References, mockups, related documents
undefined
References, mockups, related documents
undefined

Priority Classification

优先级定义

PriorityMeaningRule
P0Must-have for launchWithout this, the product does not ship
P1Important, ship soon after launchSignificant value but not blocking
P2Nice-to-haveEnhances experience, can wait
优先级含义规则
P0上线必备缺少该功能产品就不能发布
P1重要功能，上线后尽快发布价值显著但不阻塞上线
P2锦上添花的功能可提升体验，后续迭代再做

Phase 3: Review

阶段3：评审

Present the PRD section by section:
  1. After each section, ask: "Does this capture your intent? Any changes?"
  2. Revise based on feedback before moving to next section
  3. 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内容：
  1. 每展示完一节后询问："这部分是否符合你的预期？有没有需要修改的地方？"
  2. 根据反馈修改完成后再进入下一节的评审
  3. 重点关注这些高优先级章节：
    • 目标与非目标（范围对齐）
    • 用户故事（用户画像准确性）
    • 成功指标（可衡量性）
    • 功能性需求（验收标准完整性）
评审结束后停止流程——获得明确的「批准」确认后再进行保存操作。

Phase 4: Save and Transition

阶段4：保存与流程过渡

After explicit approval:
  1. Save to 
    docs/prds/YYYY-MM-DD-<feature>.md
  2. Commit the PRD with message: 
    docs(prd): add PRD for <feature>
  3. If implementation follows, invoke the 
    brainstorming
    skill
  4. If specs are needed, invoke the 
    spec-writing
    skill
获得明确批准后：
  1. 保存到路径
    docs/prds/YYYY-MM-DD-<feature>.md
  2. 提交PRD，提交信息为：
    docs(prd): add PRD for <feature>
  3. 如果需要后续实施，调用
    brainstorming
    skill
  4. 如果需要产出详细规格，调用
    spec-writing
    skill

Transition Decision Table

过渡决策表

User IntentNext SkillRationale
"Let's build this"
brainstorming
→ 
planning
Explore approaches then plan
"Write the specs"
spec-writing
Break PRD into JTBD specs
"Just save it"NonePRD 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

反模式/常见错误

MistakeWhy It Is WrongWhat To Do Instead
Skipping discovery and jumping to draftProduces assumptions-based PRDAlways complete Phase 1 first
Goals without metricsCannot measure successEvery goal needs a number
Missing non-goalsScope creep guaranteedExplicitly list what is out of scope
User stories without acceptance criteriaUntestable requirementsAdd Given/When/Then to each story
Generic success metrics ("improve UX")UnmeasurableUse specific numbers: "reduce load time to <2s"
Presenting entire PRD at once for reviewUser overwhelmed, gives superficial approvalPresent section by section
Copying competitor features verbatimMisses actual user needsFocus 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

集成关联

SkillRelationship
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:
  1. VERIFY all 11 sections are filled (not placeholder text)
  2. VERIFY every goal has a measurable metric
  3. VERIFY non-goals are explicit and meaningful
  4. VERIFY user stories have acceptance criteria
  5. VERIFY user has approved each section individually
  6. VERIFY the file is saved and committed
在宣告PRD完成前需确认：
  1. 所有11个章节都已填写完成（无占位符文本）
  2. 每个目标都有可衡量的指标
  3. 非目标定义明确且有实际意义
  4. 用户故事都包含验收标准
  5. 用户已经逐个批准了所有章节
  6. 文件已保存并提交到版本库

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结构，但始终遵循「先调研后起草」的原则和逐节评审的流程。