Back to Details

prd

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Product Requirements Document (PRD)

PRD生成器

Overview

—
Design comprehensive, production-grade Product Requirements Documents (PRDs) that bridge the gap between business vision and technical execution. This skill works for modern software systems, ensuring that requirements are clearly defined.
创建清晰、可执行且适合落地的详细产品需求文档。

When to Use

工作流程

Use this skill when:
  • Starting a new product or feature development cycle
  • Translating a vague idea into a concrete technical specification
  • Defining requirements for AI-powered features
  • Stakeholders need a unified "source of truth" for project scope
  • User asks to "write a PRD", "document requirements", or "plan a feature"
  1. 接收用户提供的功能描述
  2. 提出3-5个关键的澄清问题（带字母选项）
  3. 根据用户的回答生成结构化的PRD
  4. 保存至
    tasks/prd-[feature-name].md
重要提示： 不要开始落地实现，仅创建PRD即可。

Operational Workflow

步骤1：澄清问题

Phase 1: Discovery (The Interview)

—
Before writing a single line of the PRD, you MUST interrogate the user to fill knowledge gaps. Do not assume context.
Ask about:
  • The Core Problem: Why are we building this now?
  • Success Metrics: How do we know it worked?
  • Constraints: Budget, tech stack, or deadline?
仅在初始提示模糊时提出关键问题，重点关注：
  • 问题/目标： 该功能解决什么问题？
  • 核心功能： 关键操作有哪些？
  • 范围/边界： 该功能不应该做什么？
  • 成功标准： 如何判断功能已完成？

Phase 2: Analysis & Scoping

问题格式示例：

Synthesize the user's input. Identify dependencies and hidden complexities.
  • Map out the User Flow.
  • Define Non-Goals to protect the timeline.
1. 该功能的主要目标是什么？
   A. 优化用户入门体验
   B. 提升用户留存率
   C. 降低支持负担
   D. 其他：[请说明]

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

3. 功能范围是什么？
   A. 最小可行版本
   B. 全功能实现
   C. 仅后端/API
   D. 仅UI
这样用户可以通过回复"1A, 2C, 3B"快速迭代。记得为选项添加缩进。

Phase 3: Technical Drafting

步骤2：PRD结构

Generate the document using the Strict PRD Schema below.
生成包含以下章节的PRD：

PRD Quality Standards

1. 简介/概述

Requirements Quality

—
Use concrete, measurable criteria. Avoid "fast", "easy", or "intuitive".
diff
undefined
功能的简要描述及其解决的问题。

Vague (BAD)

2. 目标

  • The search should be fast and return relevant results.
  • The UI must look modern and be easy to use.
具体、可衡量的目标（项目符号列表）。

Concrete (GOOD)

3. 用户故事

  • The search must return results within 200ms for a 10k record dataset.
  • The search algorithm must achieve >= 85% Precision@10 in benchmark evals.
  • The UI must follow the 'Vercel/Next.js' design system and achieve 100% Lighthouse Accessibility score.

---
每个故事需包含：
  • 标题： 简短的描述性名称
  • 描述： "As a [user], I want [feature] so that [benefit]"
  • 验收标准： 可验证的完成标准清单
每个故事应足够小，以便在一个专注的工作周期内完成。
格式：
markdown
undefined

Strict PRD Schema

US-001: [标题]

You MUST follow this exact structure for the output:
描述： As a [user], I want [feature] so that [benefit].
验收标准：
  • 具体的可验证标准
  • 另一项标准
  • 类型检查/代码扫描通过
  • [仅UI故事] 使用dev-browser skill在浏览器中验证

**重要提示：**
- 验收标准必须可验证，不能模糊。“正常工作”是不合格的，“点击删除按钮前显示确认对话框”是合格的。
- **对于任何包含UI变更的故事：** 务必将“使用dev-browser skill在浏览器中验证”作为验收标准之一。这确保前端工作的视觉验证。

1. Executive Summary

4. 功能需求

  • Problem Statement: 1-2 sentences on the pain point.
  • Proposed Solution: 1-2 sentences on the fix.
  • Success Criteria: 3-5 measurable KPIs.
编号列表形式的具体功能：
  • "FR-1: 系统必须允许用户..."
  • "FR-2: 当用户点击X时，系统必须..."
表述要明确、无歧义。

2. User Experience & Functionality

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

  • User Personas: Who is this for?
  • User Stories: 
    As a [user], I want to [action] so that [benefit].
  • Acceptance Criteria: Bulleted list of "Done" definitions for each story.
  • Non-Goals: What are we NOT building?
该功能不包含的内容。这对管理范围至关重要。

3. AI System Requirements (If Applicable)

6. 设计考量（可选）

  • Tool Requirements: What tools and APIs are needed?
  • Evaluation Strategy: How to measure output quality and accuracy.
  • UI/UX需求
  • 原型图链接（如有）
  • 可复用的现有组件

4. Technical Specifications

7. 技术考量（可选）

  • Architecture Overview: Data flow and component interaction.
  • Integration Points: APIs, DBs, and Auth.
  • Security & Privacy: Data handling and compliance.
  • 已知的约束或依赖
  • 与现有系统的集成点
  • 性能要求

5. Risks & Roadmap

8. 成功指标

  • Phased Rollout: MVP -> v1.1 -> v2.0.
  • Technical Risks: Latency, cost, or dependency failures.
如何衡量成功？
  • "将完成X的时间减少50%"
  • "将转化率提升10%"

Implementation Guidelines

9. 待解决问题

DO (Always)

—
  • Define Testing: For AI systems, specify how to test and validate output quality.
  • Iterate: Present a draft and ask for feedback on specific sections.
剩余的疑问或需要澄清的领域。

DON'T (Avoid)

面向初级开发者的编写建议

  • Skip Discovery: Never write a PRD without asking at least 2 clarifying questions first.
  • Hallucinate Constraints: If the user didn't specify a tech stack, ask or label it as 
    TBD
    .
PRD的读者可能是初级开发者或AI Agent。因此：
  • 表述要明确、无歧义
  • 避免使用行话，若使用需解释
  • 提供足够的细节以理解功能目的和核心逻辑
  • 为需求编号以便引用
  • 必要时提供具体示例

Example: Intelligent Search System

输出要求

1. Executive Summary

—
Problem: Users struggle to find specific documentation snippets in massive repositories. Solution: An intelligent search system that provides direct answers with source citations. Success:
  • Reduce search time by 50%.
  • Citation accuracy >= 95%.
  • 格式： Markdown（
    .md
    ）
  • 位置： 
    tasks/
  • 文件名： 
    prd-[feature-name].md
    （短横线分隔命名）

2. User Stories

PRD示例

  • Story: As a developer, I want to ask natural language questions so I don't have to guess keywords.
  • AC:
    • Supports multi-turn clarification.
    • Returns code blocks with "Copy" button.
markdown
undefined

3. AI System Architecture

PRD: Task Priority System

—

Introduction

  • Tools Required: 
    codesearch
    , 
    grep
    , 
    webfetch
    .
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.

4. Evaluation

Goals

  • Benchmark: Test with 50 common developer questions.
  • Pass Rate: 90% must match expected citations.
  • 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

—
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
—

US-002: Display priority indicator on task cards

—
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
—

US-003: Add priority selector to task edit

—
Description: As a user, I want to change a task's priority when editing it.
Acceptance Criteria:
  • Priority dropdown in task edit modal
  • Shows current priority as selected
  • Saves immediately on selection change
  • Typecheck passes
  • Verify in browser using dev-browser skill
—

US-004: Filter tasks by priority

—
Description: As a user, I want to filter the task list to see only high-priority items when I'm focused.
Acceptance Criteria:
  • Filter dropdown with options: All | High | Medium | Low
  • Filter persists in URL params
  • Empty state message when no tasks match filter
  • Typecheck passes
  • Verify in browser using dev-browser skill
—

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)
—

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
—

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
—

Open Questions

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

---
—

检查清单

—
保存PRD前：
  • 提出了带字母选项的澄清问题
  • 整合了用户的回答
  • 用户故事小而具体
  • 功能需求已编号且无歧义
  • 非目标章节定义了清晰的边界
  • 已保存至
    tasks/prd-[feature-name].md