SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsprd-writing

prd-writing

Writing & research

View repository

Updated 10-16 09:31

About this skill

PRD Writing

Applicable Scenarios

  • Requirement definition for complete feature modules
  • Requirement review preparation
  • Requirement packages delivered to project managers/UI/API/development
  • Completion and standardization of existing requirements

Inapplicable Scenarios

  • Highly uncertain requirements (should first use opportunity-tree for exploration)
  • Small fixes and patches for a single feature point (should directly use user-story）
  • Strategic-level vision alignment (should first use pr-faq）

Core Principles

  1. Define the problem first, then define the features
  2. Testable > Exhaustive: Every feature must have verifiable acceptance criteria
  3. Clearly define out-of-scope: Prevent requirement creep
  4. Do not prescribe technical solutions: Leave technical choices to the technical workflow

PRD 14-Section Standard Structure

1. 背景和目标
   - 为什么做这个？业务目标是什么？
   - 不做会怎样？

2. 用户和场景
   - 目标用户画像
   - 使用场景（什么时候、在哪里、用什么设备）
   - 用户当前的工作流和痛点

3. 问题定义
   - 用户遇到什么问题？
   - 问题造成什么损失？
   - 现有解决方案为什么不够？

4. 目标和非目标
   - 这次要解决什么（Goals）
   - 这次不解决什么（Non-Goals）
   - 后续版本可能做什么

5. MVP 范围
   - 必须有（Must）：没有不能成立
   - 应该有（Should）：影响体验但可后置
   - 可以有（Could）：锦上添花
   - 暂不做（Won't）：明确排除

6. 功能需求
   - 功能清单（按优先级）
   - 每个功能的具体描述

7. 用户故事
   - 作为 [角色]，我希望 [动作]，以便 [价值]
   - 每条故事用 INVEST 检查（见 [user-story](../user-story/SKILL.md)）

8. 业务规则
   - 状态流转
   - 计算逻辑
   - 业务约束

9. 权限和角色
   - 谁能做什么
   - 字段级权限（如有）
   - 租户/组织隔离（如有）

10. 异常场景
    - 输入校验失败
    - 权限不足
    - 资源不存在
    - 并发冲突
    - 网络异常
    - 空状态

11. 验收标准
    - Given [前置条件] When [用户行为] Then [系统结果]
    - 每个核心功能至少 1 条
    - 主路径 + 异常路径

12. 指标和埋点建议
    - 成功指标（参考 [heart-metrics](../heart-metrics/SKILL.md)）
    - 埋点事件名 + 属性
    - 复盘时间点

13. 风险和依赖
    - 技术风险 / 业务风险 / 合规风险
    - 外部依赖（第三方 API、审批、合作方）
    - 内部依赖（其他工作流的产出）

14. 未决问题
    - 需要进一步确认的点
    - 不同方案的取舍
    - 等待外部输入的事项

Workflow

1. 检查输入是否充足（用户/问题/价值/期望产物）
   ↓
2. 不充足则补问（不要硬写 PRD）
   ↓
3. 按 14 节结构逐节填充
   ↓
4. 每个功能点写用户故事 + 验收标准
   ↓
5. 检查异常场景是否覆盖
   ↓
6. 检查指标是否定义
   ↓
7. 检查未决问题是否标注
   ↓
8. 输出完整 PRD
   ↓
9. 转交下游工作流（按工作流主控的交接协议）

Quality Self-Check

□ 14 节是否都填了（不必每节很长，但不能空）
□ 目标用户和场景是否具体（不能只写"用户"）
□ 每个核心功能是否有 Given/When/Then 验收标准
□ 异常场景是否覆盖（权限/空/错/冲突）
□ 非目标范围是否写清楚
□ 是否定义了成功指标
□ 是否标注了未决问题
□ 是否避免规定技术方案

Common Pitfalls

  1. The sections are all there, but the content is empty— writing one sentence per section just to fill it in is the same as not writing it
  2. Goals and non-goals are mixed together— they must be clearly separated
  3. Business rules describe state transitions in prose— when there are many states, use a Mermaid stateDiagram
  4. Acceptance criteria only cover the success path— exception paths also need acceptance criteria
  5. Metric definitions are vague: "improve user experience" → change to "7-day retention from X% to Y%"
  6. The open questions list is empty— a real project cannot possibly have no open questions

Supporting Templates

  • templates/prd-template.md — Complete 14-section template
  • templates/requirement-brief-template.md — Simplified version (suitable for M-level tasks)
  • templates/requirement-review-template.md — Requirement review record template

Collaboration with Other Skills

上游：
  opportunity-tree → 提供机会和方案候选
  positioning → 提供产品定位
  pr-faq → 提供愿景

平行：
  user-story → 拆解功能为用户故事（PRD 第 7 节）
  mvp-scoping → 划分 MVP 范围（PRD 第 5 节）
  heart-metrics → 定义指标（PRD 第 12 节）

下游：
  整个 PRD 转交项目经理 / UI/UX / API / 开发工作流