prd-authoring

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PRD Authoring

PRD撰写

This skill provides comprehensive guidance for creating high-quality Product Requirement Documents (PRDs) that include:

Complete technical specifications
Actionable task lists with priorities
Relevant code snippets and examples
Clear implementation phases
Measurable success criteria

</overview>

<quality_standards>

本技能为创建高质量产品需求文档（PRDs）提供全面指导，包括：

完整的技术规范
带优先级的可执行任务列表
相关代码片段和示例
清晰的实施阶段
可衡量的成功标准

</overview>

<quality_standards>

What Makes a Good PRD

什么是优质PRD

A good PRD MUST be:

Actionable: Each requirement can be implemented directly
Complete: Covers functional, non-functional, and technical requirements
Specific: Uses precise language, avoiding vague terms like "should" or "might"
Measurable: Includes success metrics that can be quantified
Implementable: Contains sufficient detail for engineering to build

优质PRD必须满足：

可执行性：每项需求均可直接落地实施
完整性：覆盖功能、非功能及技术需求
明确性：使用精准语言，避免“应该”“可能”等模糊表述
可衡量性：包含可量化的成功指标
可实现性：包含足够细节，便于工程团队开发

Required Elements

必备要素

Every PRD MUST include:

Problem Statement - Clear articulation of what problem we're solving and why
Goals - Specific, measurable objectives
Requirements - Functional and non-functional requirements
Architecture - System design, components, data flow
Implementation Plan - Phased approach with milestones
Task List - Actionable next steps (see template below)
Success Metrics - Quantifiable measures of success
Code Snippets - Relevant examples (see guidelines below)

</quality_standards>

<prd_template>

每份PRD必须包含以下内容：

问题陈述 - 清晰阐述要解决的问题及原因
目标 - 具体、可衡量的目标
需求 - 功能与非功能需求
架构 - 系统设计、组件、数据流
实施计划 - 分阶段推进方案及里程碑
任务列表 - 可执行的下一步计划（见下方模板）
成功指标 - 可量化的成功衡量标准
代码片段 - 相关示例（见下方指南）

</quality_standards>

<prd_template>

PRD Template

PRD模板

markdown

undefined

markdown

undefined

[Feature Name] - PRD

[功能名称] - PRD

Overview

概述

[2-3 sentence summary]

[2-3句话总结]

Problem Statement

问题陈述

[What problem are we solving? Why now? What's the impact of not solving it?]

[我们要解决什么问题？为什么现在解决？不解决会有什么影响？]

Goals

目标

[Primary goal 1 - specific and measurable]
[Primary goal 2 - specific and measurable]
[Secondary goal 3]

[主要目标1 - 具体且可衡量]
[主要目标2 - 具体且可衡量]
[次要目标3]

Non-Goals

非目标

[What we explicitly will NOT do in this iteration - sets scope boundaries]

[本次迭代明确不做的内容 - 划定范围边界]

Requirements

需求

Functional Requirements

功能需求

[FR-1] [User stories/use cases as specific requirements]
[FR-2] [Acceptance criteria for each requirement]

[FR-1] [以用户故事/用例形式呈现的具体需求]
[FR-2] [每项需求的验收标准]

Non-Functional Requirements

非功能需求

[NFR-1] Performance: [specific metrics, e.g., "API responds in <200ms at p95"]
[NFR-2] Security: [e.g., "All data encrypted at rest and in transit"]
[NFR-3] Scalability: [e.g., "System handles 10k concurrent users"]
[NFR-4] Reliability: [e.g., "99.9% uptime SLA"]

[NFR-1] 性能：[具体指标，例如“API在p95情况下响应时间<200ms”]
[NFR-2] 安全性：[例如“所有数据在静态和传输状态下均加密”]
[NFR-3] 可扩展性：[例如“系统可处理10k并发用户”]
[NFR-4] 可靠性：[例如“99.9%的正常运行时间SLA”]

Technical Requirements

技术需求

[TR-1] [Technology stack constraints]
[TR-2] [Integration requirements]
[TR-3] [Data retention/compliance requirements]

[TR-1] [技术栈约束]
[TR-2] [集成需求]
[TR-3] [数据留存/合规需求]

Proposed Architecture

拟议架构

System Design

系统设计

[High-level architecture - use text diagrams or mermaid]

[Component A] ←→ [Component B] ←→ [Component C]
       ↓               ↓               ↓
   [Database]    [Cache Layer]   [External API]

[高层架构 - 使用文本图或mermaid]

[组件A] ←→ [组件B] ←→ [组件C]
       ↓               ↓               ↓
   [数据库]    [缓存层]   [外部API]

Component Breakdown

组件拆解

Component A: [Responsibility, technology choice, scaling approach]
Component B: [Responsibility, technology choice, scaling approach]
Component C: [Responsibility, technology choice, scaling approach]

组件A：[职责、技术选型、扩容方案]
组件B：[职责、技术选型、扩容方案]
组件C：[职责、技术选型、扩容方案]

Data Flow

数据流

[Step-by-step description of how data moves through the system]
[Include error handling, retries, fallbacks]
[Describe async/sync boundaries]

[数据在系统中流转的分步描述]
[包含错误处理、重试、回退机制]
[描述异步/同步边界]

API Design (if applicable)

API设计（如适用）

[Include endpoint specifications, request/response schemas]

[包含端点规范、请求/响应 schema]

Technical Considerations

技术考量

Technology Choices

技术选型

Technology	Justification	Alternatives Considered
[Tech 1]	[Why this choice]	[Alternative 1, Alternative 2]
[Tech 2]	[Why this choice]	[Alternative 1, Alternative 2]

技术	选型理由	备选方案
[技术1]	[选择该技术的原因]	[备选方案1, 备选方案2]
[技术2]	[选择该技术的原因]	[备选方案1, 备选方案2]

Trade-offs Analyzed

权衡分析

Option	Pros	Cons	Decision
[Option A]	...	...	✅/❌
[Option B]	...	...	✅/❌

选项	优势	劣势	决策
[选项A]	...	...	✅/❌
[选项B]	...	...	✅/❌

Risks and Mitigations

风险与缓解策略

Risk	Impact	Probability	Mitigation Strategy
[Risk 1]	High/Med/Low	High/Med/Low	[How to address]
[Risk 2]	High/Med/Low	High/Med/Low	[How to address]

风险	影响	概率	缓解策略
[风险1]	高/中/低	高/中/低	[应对方案]
[风险2]	高/中/低	高/中/低	[应对方案]

Implementation Strategy

实施策略

Phase 1: Foundation

阶段1：基础搭建

[Task 1.1]
[Task 1.2]
[Task 1.3]

Definition of Done: [Specific criteria for phase completion]

[任务1.1]
[任务1.2]
[任务1.3]

完成定义：[阶段完成的具体标准]

Phase 2: Core Features

阶段2：核心功能

[Task 2.1]
[Task 2.2]
[Task 2.3]

Definition of Done: [Specific criteria for phase completion]

[任务2.1]
[任务2.2]
[任务2.3]

完成定义：[阶段完成的具体标准]

Phase 3: Polish & Launch

阶段3：优化与上线

[Task 3.1]
[Task 3.2]
[Task 3.3]

Definition of Done: [Specific criteria for phase completion]

[任务3.1]
[任务3.2]
[任务3.3]

完成定义：[阶段完成的具体标准]

Task Breakdown

任务拆解

<task_list_template>

High Priority (P0) - Blockers for launch

高优先级（P0）- 上线阻塞项

[TASK-1]: [Actionable task title]
- Complexity: [Simple/Medium/Complex]
- Dependencies: [Task IDs or components that must exist first]
- Parallelizable: [Yes/No - if Yes, specify which tasks can run simultaneously]
- Testing: [Required/Recommended/None - specify type: unit, integration, e2e]
- Acceptance criteria: [Specific, testable criteria]

[任务ID-1]：[可执行的任务标题]
- 复杂度：[简单/中等/复杂]
- 依赖项：[必须先完成的任务ID或组件]
- 可并行：[是/否 - 如果是，指定可同时执行的任务]
- 测试：[必需/推荐/无需 - 指定类型：单元测试、集成测试、端到端测试]
- 验收标准：[具体、可测试的标准]

Medium Priority (P1) - Important but not blocking

中优先级（P1）- 重要但不阻塞

[TASK-2]: [Actionable task title]
- Complexity: [Simple/Medium/Complex]
- Dependencies: [Task IDs or components that must exist first]
- Parallelizable: [Yes/No - if Yes, specify which tasks can run simultaneously]
- Testing: [Required/Recommended/None - specify type: unit, integration, e2e]
- Acceptance criteria: [Specific, testable criteria]

[任务ID-2]：[可执行的任务标题]
- 复杂度：[简单/中等/复杂]
- 依赖项：[必须先完成的任务ID或组件]
- 可并行：[是/否 - 如果是，指定可同时执行的任务]
- 测试：[必需/推荐/无需 - 指定类型：单元测试、集成测试、端到端测试]
- 验收标准：[具体、可测试的标准]

Low Priority (P2) - Nice to have

低优先级（P2）- 锦上添花

[TASK-3]: [Actionable task title]
- Complexity: [Simple/Medium/Complex]
- Dependencies: [Task IDs or components that must exist first]
- Parallelizable: [Yes/No - if Yes, specify which tasks can run simultaneously]
- Testing: [Required/Recommended/None - specify type: unit, integration, e2e]
- Acceptance criteria: [Specific, testable criteria] </task_list_template>

<parallelization_guidance>

[任务ID-3]：[可执行的任务标题]
- 复杂度：[简单/中等/复杂]
- 依赖项：[必须先完成的任务ID或组件]
- 可并行：[是/否 - 如果是，指定可同时执行的任务]
- 测试：[必需/推荐/无需 - 指定类型：单元测试、集成测试、端到端测试]
- 验收标准：[具体、可测试的标准] </task_list_template>

<parallelization_guidance>

Task Parallelization

任务并行化

Mark tasks as Parallelizable: Yes when:

Task is independent of other in-progress tasks
Multiple developers/subagents can work on different aspects simultaneously
Task can be split into independent sub-tasks

Examples:

✅ Parallelizable

"Design REST API endpoints" and "Design database schema" - can be done simultaneously with coordination
"Write frontend user profile component" and "Write frontend settings component" - independent components
"Set up CI/CD pipeline" and "Set up monitoring infrastructure" - separate infrastructure tasks

❌ Not Parallelizable

"Implement authentication" - blocks on "Design database schema" (dependency)
"Write API tests" - requires API endpoints to exist first (dependency)

Format for parallelizable tasks:

markdown

- Parallelizable: Yes - Can run concurrently with [TASK-X], [TASK-Y]

</parallelization_guidance>

<complexity_guidance>

当满足以下条件时，标记任务为可并行：是：

任务独立于其他进行中的任务
多个开发人员/子Agent可同时处理不同方面
任务可拆分为独立的子任务

示例：

✅ 可并行

“设计REST API端点”和“设计数据库schema” - 协调后可同时进行
“编写前端用户资料组件”和“编写前端设置组件” - 独立组件
“搭建CI/CD流水线”和“搭建监控基础设施” - 独立的基础设施任务

❌ 不可并行

“实现认证功能” - 依赖“设计数据库schema”（前置依赖）
“编写API测试” - 需先存在API端点（前置依赖）

可并行任务的格式：

markdown

- 可并行：是 - 可与[任务X]、[任务Y]同时执行

</parallelization_guidance>

<complexity_guidance>

Task Complexity Levels

任务复杂度等级

Simple

Well-defined scope
No unknown unknowns
Follows established patterns
Single system/component
Example: "Add email validation to registration form"

Medium

Some research or investigation needed
Multiple components to integrate
Requires decision-making
Some ambiguity to resolve
Example: "Implement OAuth 2.0 login with Google and GitHub"

Complex

Significant architectural decisions
Cross-system dependencies
High ambiguity or research required
Performance or security concerns
Requires prototyping or spikes
Example: "Design and implement real-time notification system with WebSocket scaling"

</complexity_guidance>

<testing_guidance>

简单

范围明确
无未知风险
遵循既定模式
单一系统/组件
示例：“为注册表单添加邮箱验证”

中等

需要一定的调研
需集成多个组件
需要决策
存在部分模糊点需解决
示例：“实现支持Google和GitHub的OAuth 2.0登录”

复杂

涉及重大架构决策
跨系统依赖
高度模糊或需要大量调研
存在性能或安全顾虑
需要原型开发或探索性工作
示例：“设计并实现支持WebSocket扩容的实时通知系统”

</complexity_guidance>

<testing_guidance>

Testing Requirements

测试要求

Each task MUST specify testing needs:

Required - Critical functionality, MUST have tests before merging

User authentication/authorization
Payment processing
Data persistence operations
External API integrations

Recommended - Should have tests but not blocking

UI components
Business logic validation
Edge case handling
Error scenarios

None - Tests not applicable

Configuration changes
Documentation updates
Infrastructure setup
Design/mockup tasks

Test Types:

```
unit
```
- Individual functions/components in isolation
```
integration
```
- Multiple components working together
```
e2e
```
- Full user flows from start to finish
```
performance
```
- Load testing, benchmarks
```
security
```
- Penetration testing, vulnerability scans

</testing_guidance>

每项任务必须指定测试需求：

必需 - 核心功能，合并前必须有测试

用户认证/授权
支付处理
数据持久化操作
外部API集成

Success Metrics

成功指标

[Metric 1]: [Current value] → [Target value]
[Metric 2]: [Current value] → [Target value]
[Metric 3]: [Current value] → [Target value]

[指标1]：[当前值] → [目标值]
[指标2]：[当前值] → [目标值]
[指标3]：[当前值] → [目标值]

Open Questions

待解决问题

[Q1] [Question that needs resolution]
- Options: [Option A, Option B, Option C]
- Decision owner: [Who will decide]

[问题1] [需要解决的问题]
- 选项：[选项A, 选项B, 选项C]
- 决策人：[谁将做出决策]

Appendices

附录

Code Snippets

代码片段

[Include relevant code examples - see guidelines below]

[包含相关代码示例 - 见下方指南]

Data Schemas

数据Schema

[Include database schemas, type definitions, etc.]

[包含数据库schema、类型定义等]

Mockups

原型图

[Links to UI mockups or wireframes]


</prd_template>

<code_snippet_guidelines>

[UI原型或线框图链接]


</prd_template>

<code_snippet_guidelines>

When to Include Code Snippets

何时包含代码片段

PRDs SHOULD include code snippets when they clarify technical details. Use for:

当代码片段能澄清技术细节时，PRD应包含此类内容。适用于：

1. API Design

1. API设计

Include when: Defining endpoints, request/response formats

typescript

// POST /api/users
interface CreateUserRequest {
  email: string;
  password: string; // Hashed with bcrypt
  name: string;
}

interface CreateUserResponse {
  id: string;
  email: string;
  createdAt: Date;
}

适用场景：定义端点、请求/响应格式

typescript

// POST /api/users
interface CreateUserRequest {
  email: string;
  password: string; // 使用bcrypt哈希
  name: string;
}

interface CreateUserResponse {
  id: string;
  email: string;
  createdAt: Date;
}

2. Data Schemas

2. 数据Schema

Include when: Defining database models, type definitions

typescript

// User schema
interface User {
  id: string; // UUID
  email: string; // Unique, indexed
  passwordHash: string; // bcrypt
  createdAt: Date;
  updatedAt: Date;
}

// Indexes
db.users.createIndex({ email: 1 }, { unique: true });

适用场景：定义数据库模型、类型定义

typescript

// User schema
interface User {
  id: string; // UUID
  email: string; // 唯一、带索引
  passwordHash: string; // bcrypt
  createdAt: Date;
  updatedAt: Date;
}

// 索引
db.users.createIndex({ email: 1 }, { unique: true });

3. Configuration Examples

3. 配置示例

Include when: Defining feature flags, environment variables

bash

undefined

适用场景：定义功能开关、环境变量

bash

undefined

Environment variables

环境变量

DATABASE_URL=postgresql://... JWT_SECRET=your-secret-key RATE_LIMIT_ENABLED=true RATE_LIMIT_REQUESTS_PER_MINUTE=100

undefined

DATABASE_URL=postgresql://... JWT_SECRET=your-secret-key RATE_LIMIT_ENABLED=true RATE_LIMIT_REQUESTS_PER_MINUTE=100

undefined

4. Algorithm Examples

4. 算法示例

Include when: Explaining complex logic

typescript

// Rate limiting algorithm
function rateLimit(userId: string): boolean {
  const requests = redis.get(`ratelimit:${userId}`) || 0;
  if (requests >= LIMIT) {
    return false; // Rate limited
  }
  redis.incr(`ratelimit:${userId}`);
  redis.expire(`ratelimit:${userId}`, 60);
  return true; // Allowed
}

适用场景：解释复杂逻辑

typescript

// 限流算法
function rateLimit(userId: string): boolean {
  const requests = redis.get(`ratelimit:${userId}`) || 0;
  if (requests >= LIMIT) {
    return false; // 触发限流
  }
  redis.incr(`ratelimit:${userId}`);
  redis.expire(`ratelimit:${userId}`, 60);
  return true; // 允许请求
}

5. Integration Examples

5. 集成示例

Include when: Showing how components interact

typescript

// Example: Service A calling Service B
const response = await fetch('http://service-b/api/process', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ data: payload })
});

适用场景：展示组件间交互

typescript

// 示例：服务A调用服务B
const response = await fetch('http://service-b/api/process', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ data: payload })
});

What NOT to Include

不应包含的内容

❌ Full implementation code - PRDs are for requirements, not implementation ❌ Business logic details - Save for actual development ❌ Boilerplate code - Unless it's configuration

✅ DO include: Interfaces, schemas, examples of architecture ✅ DO include: Configuration, API contracts, data models

</code_snippet_guidelines>

<task_list_guidelines>

❌ 完整实现代码 - PRD用于定义需求，而非实现 ❌ 业务逻辑细节 - 留到实际开发阶段 ❌ 样板代码 - 除非是配置类代码

✅ 建议包含：接口、schema、架构示例 ✅ 建议包含：配置、API契约、数据模型

</code_snippet_guidelines>

<task_list_guidelines>

Creating Actionable Task Lists

创建可执行的任务列表

Tasks in PRDs MUST be:

PRD中的任务必须满足：

Specific

具体明确

❌ "Implement user authentication" ✅ "Implement OAuth 2.0 login with Google and GitHub providers"

❌ “实现用户认证” ✅ “实现支持Google和GitHub提供商的OAuth 2.0登录”

Testable

可测试

❌ "Make it fast" ✅ "API response time <200ms at p95 under 1000 RPS"

❌ “让它变快” ✅ “在1000 RPS下，API响应时间p95<200ms”

Atomic

原子性

❌ "Build the entire checkout flow" ✅ "Build cart summary endpoint" (one of many tasks)

❌ “构建完整的结账流程” ✅ “构建购物车汇总端点”（众多任务之一）

Testable

可测试性

Each task MUST specify testing requirements (Required/Recommended/None)

每项任务必须指定测试需求（必需/推荐/无需）

Task Template (AI-Agent Optimized)

任务模板（AI Agent优化版）

markdown

- [ ] **[TASK-ID]** [Actionable title]
  - **Complexity**: [Simple/Medium/Complex]
  - **Dependencies**: [Task IDs or components that must exist first]
  - **Parallelizable**: [Yes/No - if Yes, specify which tasks]
  - **Testing**: [Required/Recommended/None - specify type: unit, integration, e2e]
  - **Acceptance Criteria**:
    - [ ] [Criterion 1 - must be testable]
    - [ ] [Criterion 2 - must be testable]

</task_list_guidelines>

<anti_patterns>

markdown

- [ ] **[任务ID]** [可执行标题]
  - **复杂度**：[简单/中等/复杂]
  - **依赖项**：[必须先完成的任务ID或组件]
  - **可并行**：[是/否 - 如果是，指定可并行的任务]
  - **测试**：[必需/推荐/无需 - 指定类型：单元测试、集成测试、端到端测试]
  - **验收标准**:
    - [ ] [标准1 - 必须可测试]
    - [ ] [标准2 - 必须可测试]

</task_list_guidelines>

<anti_patterns>

Common PRD Anti-Patterns

常见PRD反模式

Vague Language

模糊表述

❌ "The system should be scalable" ✅ "System must handle 10,000 concurrent users with <500ms response time"

❌ “系统应该具备可扩展性” ✅ “系统必须处理10,000并发用户，响应时间<500ms”

Missing Acceptance Criteria

缺失验收标准

❌ "Implement search functionality" ✅ "Implement full-text search with filters, returning results in <100ms, supporting 100+ concurrent searches"

❌ “实现搜索功能” ✅ “实现带筛选的全文搜索，响应时间<100ms，支持100+并发搜索”

No Success Metrics

无成功指标

❌ "Improve user engagement" ✅ "Increase daily active users from 1,000 to 2,000 within 90 days"

❌ “提升用户参与度” ✅ “90天内将日活跃用户从1,000提升至2,000”

Infinite Scope

无限范围

❌ "Build the best e-commerce platform" ✅ "Build MVP with product catalog, cart, and checkout (payments via Stripe)"

❌ “打造最佳电商平台” ✅ “构建包含商品目录、购物车和结账（通过Stripe支付）的MVP”

Missing Technical Details

缺失技术细节

❌ "Use a database" ✅ "Use PostgreSQL for relational data, Redis for caching, with proper indexing on email and product_id"

❌ “使用数据库” ✅ “使用PostgreSQL存储关系型数据，Redis用于缓存，对email和product_id建立合适的索引”

No Risk Assessment

无风险评估

❌ [No risk section] ✅ [Include risks table with mitigations]

</anti_patterns>

❌ [无风险章节] ✅ [包含带缓解策略的风险表格]

</anti_patterns>

PRD Authoring Workflow

PRD撰写流程

Understand the Problem
- Interview stakeholders if needed
- Identify pain points with current solution
- Quantify the opportunity
Draft Requirements
- Start with user stories
- Convert to functional requirements (FR-1, FR-2, etc.)
- Add non-functional requirements (NFR-1, NFR-2, etc.)
Design Architecture
- Create system diagram
- Define components and their responsibilities
- Map data flow between components
Add Technical Details
- Choose technologies with justification
- Document trade-offs
- Include relevant code snippets
Create Task Breakdown
- Break into phases
- Create specific, actionable tasks
- Identify dependencies
Define Success
- Set measurable metrics
- Define baseline and target
Review and Refine
- Check against quality standards
- Ensure no anti-patterns
- Validate with stakeholders

</workflow> <examples>

See

references/examples.md

for complete PRD examples.

</examples>

理解问题
- 必要时访谈利益相关者
- 识别现有解决方案的痛点
- 量化机会价值
起草需求
- 从用户故事开始
- 转换为功能需求（FR-1、FR-2等）
- 添加非功能需求（NFR-1、NFR-2等）
设计架构
- 创建系统图
- 定义组件及其职责
- 绘制组件间的数据流
添加技术细节
- 选择技术并说明理由
- 记录权衡分析
- 包含相关代码片段
创建任务拆解
- 拆分为多个阶段
- 创建具体、可执行的任务
- 识别依赖关系
定义成功标准
- 设置可衡量的指标
- 定义基线和目标值
评审与优化
- 对照质量标准检查
- 确保无反模式
- 与利益相关者验证

</workflow> <examples>

完整PRD示例请见

references/examples.md

。

</examples>