prd-generator

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PRD Generator

PRD生成器

Purpose

用途

Transform a rough product idea into a comprehensive, AI-ready Product Requirements Document (PDF) through targeted questions and structured output.

将粗略的产品想法通过针对性问题和结构化输出，转换为全面的、适配AI的产品需求文档（PDF）。

Execution Logic

执行逻辑

Check $ARGUMENTS first to determine execution mode:

首先检查$ARGUMENTS以确定执行模式：

If $ARGUMENTS is empty or not provided:

若$ARGUMENTS为空或未提供：

Respond with: "prd-generator loaded, describe your product idea"

Then wait for the user to provide their product concept in the next message.

回复： "prd-generator已加载，请描述你的产品想法"

然后等待用户在下一条消息中提供产品概念。

If $ARGUMENTS contains content:

若$ARGUMENTS包含内容：

Proceed immediately to Task Execution (skip the "loaded" message).

直接进入任务执行环节（跳过“已加载”提示）。

Task Execution

任务执行

1. MANDATORY: Read Reference Files FIRST

1. 强制要求：首先读取参考文件

BLOCKING REQUIREMENT — DO NOT SKIP THIS STEP

Before doing ANYTHING else, use the Read tool to read:

```
./references/prd_template.md
```

This template defines the exact structure your PRD must follow. DO NOT PROCEED to Step 2 until you have read this file.

阻塞性要求——请勿跳过此步骤

在进行任何其他操作之前，使用Read工具读取：

```
./references/prd_template.md
```

该模板定义了PRD必须遵循的精确结构。在读取此文件之前，请勿进入步骤2。

2. Skip Business Context

2. 跳过业务上下文

This skill intentionally DOES NOT read FOUNDER_CONTEXT.md. PRDs are standalone documents that should contain all necessary context within them.

本技能刻意不读取FOUNDER_CONTEXT.md。PRD是独立文档，应在文档内部包含所有必要上下文。

3. Analyze Initial Input

3. 分析初始输入

From the user's initial description, extract what's available:

Product name or working title
Core problem being solved
Target users/audience
Key features mentioned
Technical preferences (if any)
Constraints or requirements (if any)

从用户的初始描述中提取现有信息：

产品名称或暂定标题
正在解决的核心问题
目标用户/受众
提及的关键功能
技术偏好（如有）
约束条件或要求（如有）

4. Ask Clarifying Questions

4. 提出澄清问题

Use AskUserQuestion tool to gather missing information. Ask up to 7 questions maximum, but fewer is better — stop as soon as you have enough to build a comprehensive PRD.

Question Bank (priority order):

#	Question	Why it matters	Skip if...
1	Who is the primary user? What's their role and technical level?	Shapes all UX decisions and feature complexity	User persona is clearly described
2	What's the core problem this solves? What happens if users don't have this?	Defines the value proposition and success metrics	Problem statement is explicit
3	What are the 3-5 must-have features for launch (P0)?	Prevents scope creep, focuses MVP	Features are already listed with clear priority
4	What technology preferences or constraints exist? (Language, framework, hosting)	Determines technical architecture section	Tech stack is specified
5	Are there any integrations required? (Auth providers, APIs, third-party services)	Identifies dependencies and integration complexity	No external services mentioned or user says standalone
6	What does success look like? Any specific metrics to track?	Defines goals and success metrics section	Metrics or goals are already stated
7	Any design preferences or existing brand guidelines to follow?	Shapes UI/UX requirements section	Design is flexible or already described

Question strategy:

Ask 2-4 questions per batch using AskUserQuestion
If the first batch answers provide enough detail, stop asking
Never ask more than 7 questions total
Group related questions when possible

使用AskUserQuestion工具收集缺失的信息。最多提出7个问题，但越少越好——一旦获得足够信息来构建全面的PRD，就停止提问。

问题库（优先级顺序）：

序号	问题	重要性原因	可跳过情况
1	主要用户是谁？他们的角色和技术水平如何？	影响所有UX决策和功能复杂度	用户角色已清晰描述
2	该产品解决的核心问题是什么？如果用户没有该产品会怎样？	定义价值主张和成功指标	问题陈述已明确
3	发布时必须具备的3-5个核心功能（P0）是什么？	防止范围蔓延，聚焦MVP	功能已按明确优先级列出
4	存在哪些技术偏好或约束？（语言、框架、托管方式）	决定技术架构部分	技术栈已指定
5	是否需要任何集成？（身份验证提供商、API、第三方服务）	识别依赖关系和集成复杂度	未提及外部服务或用户说明为独立产品
6	成功的标准是什么？有没有具体的跟踪指标？	定义目标和成功指标部分	指标或目标已说明
7	有没有设计偏好或现有的品牌准则需要遵循？	影响UI/UX要求部分	设计灵活或已描述

提问策略：

每次使用AskUserQuestion工具批量提出2-4个问题
如果第一批问题的回答提供了足够细节，停止提问
总共提问不超过7个
尽可能将相关问题分组

5. Generate the PRD

5. 生成PRD

Using the template structure from

./references/prd_template.md

, create a complete PRD:

Fill every applicable section from the template
Be specific — vague requirements produce vague code
Write acceptance criteria for every feature — make them testable
Prioritize ruthlessly — P0 should be 30-40% of features
The "Implementation Notes for AI" section is mandatory — this is what makes it AI-ready

使用

./references/prd_template.md

中的模板结构，创建完整的PRD：

填充模板中所有适用的部分
内容要具体——模糊的需求会产生模糊的代码
为每个功能编写验收标准——确保可测试
严格划分优先级——P0功能应占总功能的30-40%
“AI实现说明”部分是强制要求——这是使其适配AI的关键

6. Save and Convert to PDF

6. 保存并转换为PDF

Step 6a: Create output folder

bash

mkdir -p ./prd_outputs/[Project Name]/

Use the product name with spaces, e.g.,

./prd_outputs/Churn Prevention Tool/

Step 6b: Save markdown file Write the PRD content to:

./prd_outputs/[Project Name]/[project_name]_PRD.md

Use snake_case for the filename, e.g.,

churn_prevention_tool_PRD.md

Step 6c: Convert to PDF Run:

bash

npx md-to-pdf "./prd_outputs/[Project Name]/[project_name]_PRD.md"

This creates

[project_name]_PRD.pdf

in the same folder.

步骤6a：创建输出文件夹

bash

mkdir -p ./prd_outputs/[Project Name]/

使用带空格的产品名称，例如

./prd_outputs/客户流失预防工具/

步骤6b：保存Markdown文件 将PRD内容写入：

./prd_outputs/[Project Name]/[project_name]_PRD.md

文件名使用蛇形命名法，例如

churn_prevention_tool_PRD.md

步骤6c：转换为PDF 运行：

bash

npx md-to-pdf "./prd_outputs/[Project Name]/[project_name]_PRD.md"

这会在同一文件夹中生成

[project_name]_PRD.pdf

。

7. Confirm Output

7. 确认输出

Tell the user:

Where the PDF is saved (full path)
Where the markdown source is saved
Brief summary of what's in the PRD

告知用户：

PDF的保存位置（完整路径）
Markdown源文件的保存位置
PRD内容的简要摘要

Writing Rules

写作规则

Core Rules

核心规则

Every feature MUST have testable acceptance criteria
Use specific numbers, not vague terms ("loads in <2s" not "loads quickly")
P0 features should be 30-40% of total features — if everything is P0, nothing is
Data models must include field types and relationships
API specs must include request/response examples

每个功能必须有可测试的验收标准
使用具体数字，而非模糊表述（例如“加载时间<2秒”而非“加载快”）
P0功能应占总功能的30-40%——如果所有功能都是P0，就等于没有P0
数据模型必须包含字段类型和关系
API规范必须包含请求/响应示例

PRD-Specific Rules

PRD专属规则

Executive summary: 3-5 sentences maximum
Problem statement: Must include current state, pain points, and business impact
User personas: Maximum 3 primary personas — more creates confusion
Tech architecture: Describe data flow in plain English — AI tools interpret this better than complex diagrams
Implementation Notes for AI section: This is mandatory, never skip it

执行摘要：最多3-5句话
问题陈述：必须包含当前状态、痛点和业务影响
用户角色：最多3个主要角色——过多会造成混淆
技术架构：用通俗易懂的英语描述数据流——AI工具比复杂图表更易解析此类内容
AI实现说明部分：为强制要求，切勿跳过

Format Rules

格式规则

Use markdown headers consistently (# for title, ## for sections, ### for subsections)
Use tables for structured data (metrics, data models, API specs)
Use code blocks for JSON examples and technical specs
Use checkboxes for acceptance criteria

一致使用Markdown标题（# 用于标题，## 用于章节，### 用于子章节）
用表格呈现结构化数据（指标、数据模型、API规范）
用代码块呈现JSON示例和技术规范
用复选框呈现验收标准

Output Format

输出格式

The PRD follows the structure in

./references/prd_template.md

. Here's a condensed example:

markdown

undefined

PRD遵循

./references/prd_template.md

中的结构。以下是精简示例：

markdown

undefined

TaskFlow — Product Requirements Document

Version: 1.0 Date: 2024-01-15 Author: PRD Generator Status: Draft

Executive Summary

TaskFlow is a task management tool for remote engineering teams...

Problem Statement

Current state: Teams use disconnected tools... Pain points:

Context switching between tools
No visibility into team workload
Async communication gaps

Impact: 5+ hours/week lost per engineer...

Current state: Teams use disconnected tools... Pain points:

Context switching between tools
No visibility into team workload
Async communication gaps

Impact: 5+ hours/week lost per engineer...

Goals & Success Metrics

Goal	Metric	Target	Measurement
Reduce context switching	Tool switches/day	< 10	Analytics

Goal	Metric	Target	Measurement
Reduce context switching	Tool switches/day	< 10	Analytics

User Personas

Engineering Manager

Role: Manages 5-10 engineers
Goals: Visibility into sprint progress...

Role: Manages 5-10 engineers
Goals: Visibility into sprint progress...

Functional Requirements

FR-001: Task Creation

Description: Users can create tasks with title, description, assignee, and due date.

User story: As an engineer, I want to create tasks quickly so that I capture work items without friction.

Acceptance criteria:

Task creation completes in < 500ms
Title field is required, minimum 3 characters
Due date defaults to end of current sprint

Priority: P0

...

Description: Users can create tasks with title, description, assignee, and due date.

User story: As an engineer, I want to create tasks quickly so that I capture work items without friction.

Acceptance criteria:

Task creation completes in < 500ms
Title field is required, minimum 3 characters
Due date defaults to end of current sprint

Priority: P0

...

Implementation Notes for AI

Build Order

Database schema (PostgreSQL)
API endpoints (Express.js)
Frontend components (React)
Auth integration (Clerk)

Database schema (PostgreSQL)
API endpoints (Express.js)
Frontend components (React)
Auth integration (Clerk)

Libraries to Use

Prisma for ORM — type-safe, great DX
TanStack Query for data fetching — handles caching
Tailwind CSS for styling — utility-first, fast iteration

Prisma for ORM — type-safe, great DX
TanStack Query for data fetching — handles caching
Tailwind CSS for styling — utility-first, fast iteration

Critical Implementation Details

All dates stored as UTC, converted to user timezone on display
Use optimistic updates for task status changes
Implement soft deletes for all user-generated content

---

All dates stored as UTC, converted to user timezone on display
Use optimistic updates for task status changes
Implement soft deletes for all user-generated content

---

References

参考资料

This file MUST be read using the Read tool before task execution (see Step 1):

File	Purpose
`./references/prd_template.md`	Complete PRD structure with all 15 sections, format examples, and usage notes

Why this matters: The template ensures every PRD follows a consistent, comprehensive structure that AI coding tools can parse and implement. Skipping the template results in incomplete PRDs that miss critical sections.

在任务执行前，必须使用Read工具读取此文件（见步骤1）：

文件	用途
`./references/prd_template.md`	包含所有15个章节的完整PRD结构、格式示例和使用说明

**重要性：**该模板确保每个PRD遵循一致、全面的结构，AI编码工具可解析并实现。跳过模板会导致PRD不完整，遗漏关键章节。

Quality Checklist (Self-Verification)

质量检查表（自我验证）

Pre-Execution Check

执行前检查

I read
```
./references/prd_template.md
```
before starting
I have the template structure in context

开始前已读取
```
./references/prd_template.md
```
已掌握模板结构

Question Check

提问检查

I asked 7 or fewer questions total
I only asked questions where information was genuinely missing
Questions were batched (2-4 per AskUserQuestion call)

总共提问不超过7个
仅对真正缺失的信息提问
问题已批量提出（每次AskUserQuestion调用提出2-4个）

PRD Content Check

PRD内容检查

Output Check

输出检查

Markdown file saved to
```
./prd_outputs/[Project Name]/
```
PDF generated via
```
npx md-to-pdf
```
User informed of file locations

If ANY check fails → fix before completing.

Markdown文件已保存至
```
./prd_outputs/[Project Name]/
```
已通过
```
npx md-to-pdf
```
生成PDF
已告知用户文件位置

若任何检查项未通过→完成前修复

Defaults & Assumptions

默认设置与假设

Use these unless the user specifies otherwise:

Document version: 1.0
Status: Draft
Author: PRD Generator
Tech stack: Modern web (React + Node.js + PostgreSQL) unless specified
Hosting: Cloud-native (Vercel/Railway/AWS) unless specified
Auth: Third-party (Clerk/Auth0) unless building custom
Priority split: ~35% P0, ~40% P1, ~25% P2
User personas: Maximum 3 unless complexity demands more
API style: REST unless GraphQL is specified

Document any assumptions made in the PRD output.

除非用户另行指定，否则使用以下设置：

**文档版本：**1.0
**状态：**草稿
**作者：**PRD生成器
**技术栈：**现代Web技术（React + Node.js + PostgreSQL），除非另行指定
**托管：**云原生（Vercel/Railway/AWS），除非另行指定
**身份验证：**第三方服务（Clerk/Auth0），除非构建自定义身份验证
**优先级分配：**约35% P0，约40% P1，约25% P2
**用户角色：**最多3个，除非复杂度要求更多
**API风格：**REST，除非指定GraphQL

在PRD输出中记录所有做出的假设。