Back to Details

prd-writer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

PRD Writer

PRD 撰写工具

Generate structured Product Requirements Documents through guided discovery.
通过引导式调研生成结构化的产品需求文档（PRD）。

Workflow

工作流程

discovery --> analysis --> drafting
3 sequential phases. Never skip discovery -- always interview the user first.
discovery --> analysis --> drafting
分为三个连续阶段。切勿跳过调研阶段——始终先与用户进行访谈。

Process

流程

Phase 1: Discovery (Interview)

阶段1：调研（访谈）

Never assume context. Ask questions in stages, not all at once.
Stage 1 -- Problem & Audience:
  • What problem are you solving?
  • Who is the target audience?
  • What pain points do they have?
Stage 2 -- Solution & Features:
  • What is your proposed solution?
  • What are the key features?
  • What makes it different from alternatives?
Stage 3 -- Structure & Scope:
  • What is the product structure? (pages, screens, sections)
  • What are the success criteria?
  • Any known technical constraints?
Minimum 2 question stages before moving to analysis. Ask follow-ups as needed.
切勿预设背景信息。分阶段提问，不要一次性抛出所有问题。
第一子阶段——问题与受众：
  • 你要解决什么问题？
  • 目标受众是谁？
  • 他们存在哪些痛点？
第二子阶段——解决方案与功能：
  • 你提出的解决方案是什么？
  • 核心功能有哪些？
  • 与其他方案相比有何差异化优势？
第三子阶段——结构与范围：
  • 产品结构是怎样的？（页面、屏幕、板块）
  • 成功标准是什么？
  • 有哪些已知的技术限制？
进入分析阶段前至少完成2个子阶段的提问。根据需要进行跟进提问。

Phase 2: Analysis & Scoping

阶段2：分析与范围界定

Synthesize user inputs into structured findings:
  1. Identify dependencies and risks
  2. Define non-goals (what is out of scope)
  3. Surface unknowns (mark as TBD)
  4. Present synthesis to user for feedback before drafting
将用户输入整合为结构化结论：
  1. 识别依赖关系与风险
  2. 定义非目标内容（即超出范围的事项）
  3. 明确未知事项（标记为TBD）
  4. 在撰写前将整合结果提交给用户以获取反馈

Phase 3: Drafting

阶段3：撰写

USE TEMPLATE: 
templates/prd.md
Generate the PRD using the schema below. Present draft to user for review.
使用模板： 
templates/prd.md
使用以下架构生成PRD。将草稿提交给用户审核。

PRD Schema

PRD 架构

1. Executive Summary

1. 执行摘要

  • Problem Statement: What problem exists and for whom
  • Proposed Solution: High-level description of what will be built
  • Success Criteria: Measurable KPIs (concrete numbers, not vague goals)
  • 问题陈述：存在什么问题，针对哪些用户
  • 拟议解决方案：将要构建的内容的高层级描述
  • 成功标准：可衡量的KPI（具体数值，而非模糊目标）

2. Product Definition

2. 产品定义

  • Value Proposition:
    • Headline: main benefit
    • Subheadline: supporting text
    • Key Benefits: 3-5 benefits
  • Target Audience:
    • Personas: who uses this
    • Pain Points: what problems they face
    • Goals: what they want to achieve
  • 价值主张：
    • 标题：核心收益
    • 副标题：辅助说明
    • 核心收益：3-5项
  • 目标受众：
    • 用户画像：谁会使用该产品
    • 痛点：他们面临的问题
    • 目标：他们想要达成的结果

3. User Experience & Functionality

3. 用户体验与功能

  • User Stories: "As a [user], I want [action], so that [benefit]"
  • Acceptance Criteria: When/Then/Shall format
  • Features List: with descriptions
  • Non-Goals: what is explicitly out of scope
  • 用户故事："作为[用户角色]，我想要[执行操作]，以便[获得收益]"
  • 验收标准：采用When/Then/Shall格式
  • 功能列表：附带描述
  • 非目标内容：明确超出范围的事项

4. Technical Specifications

4. 技术规格

  • Architecture Overview: high-level system design
  • Integration Points: APIs, databases, auth
  • Security & Privacy: requirements and constraints
  • 架构概述：高层级系统设计
  • 集成点：API、数据库、认证
  • 安全与隐私：要求与限制

5. Risks & Roadmap

5. 风险与路线图

  • Phased Rollout: v1.0, v1.1, v2.0 (never frame as MVP)
  • Technical Risks: known challenges
  • Unknowns: marked as TBD
  • 分阶段发布：v1.0、v1.1、v2.0（切勿使用MVP表述）
  • 技术风险：已知挑战
  • 未知事项：标记为TBD

Quality Standards

质量标准

Requirements must be concrete and measurable.
BadGood
"Search should be fast""Search returns results within 200ms"
"Easy to use""New users complete onboarding in under 2 minutes"
"Intuitive interface""Task completion rate above 90% without help text"
需求必须具体且可衡量。
反面示例正面示例
"搜索速度要快""搜索结果返回时间不超过200ms"
"易于使用""新用户可在2分钟内完成入门引导"
"界面直观""无需帮助文本的情况下，任务完成率超过90%"

Guidelines

指南

DO:
  • Always complete discovery before drafting
  • Present draft for user feedback
  • Mark unknowns as TBD rather than inventing constraints
  • Use concrete, measurable requirements
  • Keep phased rollout realistic (v1.0/v1.1/v2.0, not MVP framing)
DON'T:
  • Skip discovery with fewer than 2 question stages
  • Assume project type -- discover it
  • Include visual/design direction (that belongs in design-builder)
  • Use vague adjectives as requirements ("fast", "easy", "intuitive")
需要做：
  • 始终在撰写前完成调研阶段
  • 提交草稿以获取用户反馈
  • 将未知事项标记为TBD，而非凭空设定限制
  • 使用具体、可衡量的需求
  • 分阶段发布要切合实际（采用v1.0/v1.1/v2.0表述，而非MVP）
不要做：
  • 不要在完成少于2个子阶段的提问时跳过调研
  • 不要预设项目类型——要通过调研确定
  • 不要包含视觉/设计方向（这属于设计构建工具的范畴）
  • 不要使用模糊形容词作为需求（如“快”、“易”、“直观”）

Output

输出

Save to: 
.specs/docs/prd-{project-name}.md
Create 
.specs/docs/
if it doesn't exist.
保存至：
.specs/docs/prd-{project-name}.md
如果
.specs/docs/
目录不存在则创建它。

Integration with Other Skills

与其他技能的集成

  • design-builder: PRD informs copy extraction and design extraction (sections 1, 2, 3)
  • spec-driven: PRD informs feature initialization (sections 1, 3, 4, 5)
  • design-builder：PRD为文案提取和设计提取提供依据（第1、2、3部分）
  • spec-driven：PRD为功能初始化提供依据（第1、3、4、5部分）