prd

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PRD Generator

PRD生成器

Create detailed Product Requirements Documents that are clear, actionable, and suitable for implementation.

创建清晰、可执行且适合落地的详细产品需求文档。

The Job

工作职责

Receive a feature description from the user
Ask 3-5 essential clarifying questions (with lettered options)
Generate a structured PRD based on answers
Save to
```
tasks/prd-[feature-name].md
```

Important: Do NOT start implementing. Just create the PRD.

接收用户提供的功能描述
提出3-5个关键的澄清问题（带字母选项）
根据回答生成结构化的PRD
保存至
```
tasks/prd-[feature-name].md
```

重要提示： 不要开始功能实现，仅需创建PRD。

Step 1: Clarifying Questions

步骤1：澄清问题

Ask only critical questions where the initial prompt is ambiguous. Focus on:

Problem/Goal: What problem does this solve?
Core Functionality: What are the key actions?
Scope/Boundaries: What should it NOT do?
Success Criteria: How do we know it's done?

仅针对初始提示中模糊的部分提出关键问题，重点关注：

问题/目标： 该功能解决什么问题？
核心功能： 关键操作有哪些？
范围/边界： 该功能不包含什么？
成功标准： 如何判断功能已完成？

Format Questions Like This:

问题格式示例：

1. What is the primary goal of this feature?
   A. Improve user onboarding experience
   B. Increase user retention
   C. Reduce support burden
   D. Other: [please specify]

2. Who is the target user?
   A. New users only
   B. Existing users only
   C. All users
   D. Admin users only

3. What is the scope?
   A. Minimal viable version
   B. Full-featured implementation
   C. Just the backend/API
   D. Just the UI

This lets users respond with "1A, 2C, 3B" for quick iteration. Remember to indent the options.

1. 该功能的主要目标是什么？
   A. 优化用户入门体验
   B. 提升用户留存率
   C. 减轻客服负担
   D. 其他：[请说明]

2. 目标用户是谁？
   A. 仅新用户
   B. 仅现有用户
   C. 所有用户
   D. 仅管理员用户

3. 功能范围是什么？
   A. 最小可行版本
   B. 全功能实现
   C. 仅后端/API
   D. 仅UI界面

这样用户可以通过回复“1A, 2C, 3B”快速完成迭代。记得为选项添加缩进。

Step 2: PRD Structure

步骤2：PRD结构

Generate the PRD with these sections:

生成的PRD需包含以下章节：

1. Introduction/Overview

1. 简介/概述

Brief description of the feature and the problem it solves.

功能的简要描述及其解决的问题。

2. Goals

2. 目标

Specific, measurable objectives (bullet list).

具体、可衡量的目标（项目符号列表）。

3. User Stories

3. 用户故事

Each story needs:

Title: Short descriptive name
Description: "As a [user], I want [feature] so that [benefit]"
Acceptance Criteria: Verifiable checklist of what "done" means

Each story should be small enough to implement in one focused session.

Format:

markdown

undefined

每个用户故事需包含：

标题： 简短的描述性名称
描述： “作为[用户角色]，我希望[功能]，以便[收益]”
验收标准： 可验证的“完成”清单

每个用户故事应足够小，可在一个专注的工作周期内完成。

格式：

markdown

undefined

US-001: [Title]

US-001: [标题]

Description: As a [user], I want [feature] so that [benefit].

Acceptance Criteria:

Specific verifiable criterion
Another criterion
Typecheck/lint passes
[UI stories only] Verify in browser using dev-browser skill


**Important:** 
- Acceptance criteria must be verifiable, not vague. "Works correctly" is bad. "Button shows confirmation dialog before deleting" is good.
- **For any story with UI changes:** Always include "Verify in browser using dev-browser skill" as acceptance criteria. This ensures visual verification of frontend work.

描述： 作为[用户角色]，我希望[功能]，以便[收益]。

验收标准：

具体可验证的标准
另一项标准
类型检查/代码扫描通过
[仅UI相关故事] 使用dev-browser技能在浏览器中验证


**重要提示：**
- 验收标准必须可验证，不能模糊。“正常工作”是不合格的，“删除前按钮显示确认对话框”是合格的。
- **所有包含UI变更的故事：** 必须将“使用dev-browser技能在浏览器中验证”纳入验收标准，以确保前端工作的视觉验证。

4. Functional Requirements

4. 功能需求

Numbered list of specific functionalities:

"FR-1: The system must allow users to..."
"FR-2: When a user clicks X, the system must..."

Be explicit and unambiguous.

编号列表形式的具体功能：

"FR-1：系统必须允许用户..."
"FR-2：当用户点击X时，系统必须..."

表述需明确且无歧义。

5. Non-Goals (Out of Scope)

5. 非目标（范围外内容）

What this feature will NOT include. Critical for managing scope.

该功能不包含的内容，对范围管理至关重要。

6. Design Considerations (Optional)

6. 设计考量（可选）

UI/UX requirements
Link to mockups if available
Relevant existing components to reuse

UI/UX要求
原型链接（如有）
可复用的现有组件

7. Technical Considerations (Optional)

7. 技术考量（可选）

Known constraints or dependencies
Integration points with existing systems
Performance requirements

已知约束或依赖
与现有系统的集成点
性能要求

8. Success Metrics

8. 成功指标

How will success be measured?

"Reduce time to complete X by 50%"
"Increase conversion rate by 10%"

如何衡量成功？

"将完成X的时间缩短50%"
"将转化率提升10%"

9. Open Questions

9. 待解决问题

Remaining questions or areas needing clarification.

仍需澄清的问题或领域。

Writing for Junior Developers

面向初级开发者的写作要点

The PRD reader may be a junior developer or AI agent. Therefore:

Be explicit and unambiguous
Avoid jargon or explain it
Provide enough detail to understand purpose and core logic
Number requirements for easy reference
Use concrete examples where helpful

PRD的阅读者可能是初级开发者或AI Agent，因此：

表述需明确且无歧义
避免使用行话，若使用需解释
提供足够细节以理解功能目的和核心逻辑
对需求进行编号以便引用
必要时提供具体示例

Output

输出要求

Format: Markdown (
```
.md
```
)
Location:
```
tasks/
```
Filename:
```
prd-[feature-name].md
```
(kebab-case)

格式： Markdown（
```
.md
```
）
位置：
```
tasks/
```
文件名：
```
prd-[feature-name].md
```
（短横线分隔的小写格式）

Example PRD

PRD示例

markdown

undefined

markdown

undefined

PRD: Task Priority System

PRD: 任务优先级系统

Introduction

简介

Add priority levels to tasks so users can focus on what matters most. Tasks can be marked as high, medium, or low priority, with visual indicators and filtering to help users manage their workload effectively.

为任务添加优先级级别，帮助用户聚焦重要事项。任务可标记为高、中、低优先级，通过视觉标识和筛选功能帮助用户高效管理工作量。

Goals

目标

Allow assigning priority (high/medium/low) to any task
Provide clear visual differentiation between priority levels
Enable filtering and sorting by priority
Default new tasks to medium priority

允许为任意任务分配优先级（高/中/低）
为不同优先级提供清晰的视觉区分
支持按优先级筛选和排序
新任务默认优先级为中

User Stories

用户故事

US-001: Add priority field to database

US-001: 为数据库添加优先级字段

Description: As a developer, I need to store task priority so it persists across sessions.

Acceptance Criteria:

Add priority column to tasks table: 'high' | 'medium' | 'low' (default 'medium')
Generate and run migration successfully
Typecheck passes

描述： 作为开发者，我需要存储任务优先级以确保跨会话持久化。

验收标准：

为tasks表添加priority列：可选值为'high' | 'medium' | 'low'（默认'medium'）
成功生成并执行迁移脚本
类型检查通过

US-002: Display priority indicator on task cards

US-002: 在任务卡片上显示优先级标识

Description: As a user, I want to see task priority at a glance so I know what needs attention first.

Acceptance Criteria:

Each task card shows colored priority badge (red=high, yellow=medium, gray=low)
Priority visible without hovering or clicking
Typecheck passes
Verify in browser using dev-browser skill

描述： 作为用户，我希望一眼看到任务优先级，以便知道哪些任务需要优先处理。

验收标准：

每个任务卡片显示彩色优先级徽章（红色=高，黄色=中，灰色=低）
无需悬停或点击即可看到优先级
类型检查通过
使用dev-browser技能在浏览器中验证

US-003: Add priority selector to task edit

US-003: 在任务编辑界面添加优先级选择器

US-004: Filter tasks by priority

US-004: 按优先级筛选任务

Functional Requirements

功能需求

FR-1: Add
```
priority
```
field to tasks table ('high' | 'medium' | 'low', default 'medium')
FR-2: Display colored priority badge on each task card
FR-3: Include priority selector in task edit modal
FR-4: Add priority filter dropdown to task list header
FR-5: Sort by priority within each status column (high to medium to low)

FR-1: 为tasks表添加
```
priority
```
字段（可选值'high' | 'medium' | 'low'，默认'medium'）
FR-2: 在每个任务卡片上显示彩色优先级徽章
FR-3: 在任务编辑模态框中包含优先级选择器
FR-4: 在任务列表头部添加优先级筛选下拉菜单
FR-5: 在每个状态列内按优先级排序（高→中→低）

Non-Goals

非目标

No priority-based notifications or reminders
No automatic priority assignment based on due date
No priority inheritance for subtasks

不包含基于优先级的通知或提醒
不包含根据截止日期自动分配优先级的功能
不包含子任务的优先级继承

Technical Considerations

技术考量

Reuse existing badge component with color variants
Filter state managed via URL search params
Priority stored in database, not computed

复用现有徽章组件并添加颜色变体
筛选状态通过URL查询参数管理
优先级存储在数据库中，而非计算得出

Success Metrics

成功指标

Users can change priority in under 2 clicks
High-priority tasks immediately visible at top of lists
No regression in task list performance

用户可在2次点击内修改优先级
高优先级任务在列表顶部立即可见
任务列表性能无退化

Open Questions

待解决问题

Should priority affect task ordering within a column?
Should we add keyboard shortcuts for priority changes?

---

优先级是否应影响列内任务的排序？
是否应添加优先级变更的键盘快捷键？

---

Checklist

检查清单

Before saving the PRD:

Asked clarifying questions with lettered options
Incorporated user's answers
User stories are small and specific
Functional requirements are numbered and unambiguous
Non-goals section defines clear boundaries
Saved to
```
tasks/prd-[feature-name].md
```

保存PRD前需确认：

已提出带字母选项的澄清问题
已纳入用户的回答
用户故事小而具体
功能需求已编号且无歧义
非目标部分定义了清晰的边界
已保存至
```
tasks/prd-[feature-name].md
```