2skill

Generate product requirement documents (PRD) with a complete structure for product design and requirement writing. Use when the user asks for PRD, 产品需求文档, 产品...

Product PRD Writer

Instructions

When activated, help the user design and write a PRD in Chinese.

1) Intake & Clarify

First, read the user’s prompt and extract any given information:

• 产品/业务背景与问题
• 目标与成功标准
• 用户角色与使用场景
• 范围（做/不做）、约束、时间线
• 现有系统/数据、依赖、风险

If key information is missing, ask up to 6 clarifying questions. Prefer questions that unlock multiple PRD sections at once, such as:

• 产品阶段：新建还是改版？当前处于哪个阶段（0->1 / MVP / 增长迭代）？
• 目标用户是谁？核心场景是什么？（至少给出 1-3 个典型场景）
• 成功标准/KPI是什么？如何量化？
• 本次要做的范围与不做的范围分别是什么？
• 关键约束是什么？（技术/合规/平台/成本/进度）
• 交付节奏：期望里程碑与上线时间？

If the user cannot answer, proceed with “明确假设”并在 PRD 中标注 “待确认”字段。

2) PRD Structure (generate a full doc)

Always output a complete PRD with the following sections (use Markdown and Chinese headings):

1. 摘要（1 段话 + 目标）
2. 背景与问题定义（现状、痛点、为什么现在做）
3. 目标与成功标准（KPI、指标口径、达成方式）
4. 非目标（不做什么）
5. 目标用户与使用场景（角色、旅程/场景）
6. 需求概览（按优先级/模块做总览）
7. 功能需求（逐条列出，可表格化）
8. 非功能需求（性能、安全、可用性、合规、可维护性等）
9. 交互/原型要点（用文字描述关键流程与交互状态）
10. 数据埋点与分析（事件、字段、用于衡量 KPI 的逻辑）
11. 权限与流程（如适用）
12. 验收标准（可测试、可核查）
13. 里程碑与发布计划
14. 依赖、风险与对策
15. 开放问题与待确认清单（与“假设”对应）

3) Requirement Detailing Rules

For every functional requirement, use this minimum schema:

• 编号：FR-xxx
• 标题：一句话描述“用户能做什么”
• 优先级：P0 / P1 / P2（默认 P1）
• 用户价值：为哪个用户解决什么问题
• 前置条件：触发需要满足的条件（如登录/权限/状态）
• 业务规则：关键规则、边界与例外
• 交互要点：关键页面/组件/状态（成功/失败/加载/空状态）
• 数据与埋点：相关事件与关键字段（若适用）
• 验收标准：至少 3 条，优先使用 Given / When / Then

For non-functional requirements, use:

• 编号：NFR-xxx
• 指标目标：如响应时间、可用性、并发、安全等（可量化则量化）
• 验证方式：如何测试/如何验收
• 风险与替代：无法达到时的处理方案

4) Prototype & Interaction (text-only)

Since the agent cannot assume access to design tools, describe:

• 核心页面/流程图（用步骤化文字）
• 关键交互状态（加载/空/错误/重试/权限不足）
• 关键字段与表单校验规则（如适用）

If the user provides wireframe or screenshots text, integrate them; otherwise propose a sensible baseline flow and mark “待确认”.

5) Reverse Review (quality gate)

Before finalizing, do a quick consistency check:

• 每个目标/成功标准都能追溯到具体需求或埋点事件
• “非目标”不会与“功能需求”冲突
• 需求条目足够可测试（有验收标准/边界条件）
• 优先级合理（P0 必须覆盖 MVP 必需）
• 风险/依赖覆盖至少：数据、权限、合规、性能、上线回滚

6) Output Format Preferences

Default to:

• 直接给出 PRD 终稿（不只给大纲）
• 保持可读性：使用表格用于“需求概览”和“依赖清单”
• 不要输出与 PRD 无关的冗长背景

What to Ask the User Next

If the PRD 已足够推进，给出下一步建议（最多 3 条），例如：

• 需要补齐的输入
• 立即可做的原型/评审活动
• 需求拆分与排期建议

Example

用户输入（示例）： “帮我做一个 PRD：一键补贴申请，面向新用户，减少申请流程。”

Skill 输出（示例摘要）：

1. 摘要：...
2. 背景与问题定义：...
3. 目标与成功标准：...
4. 功能需求：FR-001（P0）...