prd-development

by xuyinghan02-cell

Install this Skill

curl -fsSL -o prd-development.zip https://skill.seembox.com/api/v1/skills/prd-development/download && unzip prd-development.zip

Download prd-development.zip

SKILL.md About

---
name: prd-development
description: 将产品需求转化为Coding Agent可执行的需求文档。当用户提到"写PRD"、"产品需求文档"、"用户故事"、"功能说明"，或提供会议记录/功能描述需要整理成开发文档时触发。
---
---

# PRD开发工作流

## 执行原则

**AI 的角色：** 产品经理的思考伙伴 + 需求文档撰写者。

## 工作流程

### 阶段一：项目背景

在开始撰写之前，先确认以下关键信息。如果用户输入已经包含答案，直接提取；缺失的才询问。

**必须明确的两个要素：**

1. **问题** — 项目产生的的原因和背景，必须指出用户/业务遇到了什么具体问题。。
2. **目标** —打算做一个什么东西来解决这个问题？这个东西做完之后怎么衡量"做对了"？。

**背景分析与补全**

在用户提供初始信息后，执行以下分析：

1. **信息完整性检查** — 问题和目标是否都已明确？目标中是否同时包含"做什么"和"成功标准"？
2. **矛盾检测** — 检查问题描述与目标之间是否有不一致的地方
3. **补全建议** — 对缺失项提供具体的补全建议而非开放式追问。

### 阶段二：专业领域识别

需求收集完成后，根据阶段一项目背景中提取的信息，判断当前需求所属的专业领域，并自动加载对应的领域 skill：

| 关键词            | 加载Skill         |
| ----------------- | ----------------- |
| DNS、域名异常分析 | `DNS-analysis`    |
| 蜜罐、样本、IP    | `botnet-analysis` |

**识别流程：**

1. 扫描阶段一的项目背景（问题和目标），匹配上表中的关键词
2. 如果匹配成功，告知用户将加载对应领域 skill，并说明该 skill 的作用
3. 如果无法从用户输入中判断领域，询问一次："这个需求属于哪个专业领域？"并提供已有领域列表供选择
4. 如果需求不属于任何已有领域，告知用户当前无对应领域 skill，后续阶段将基于通用方法推进

领域 skill 加载后，贯穿阶段二之后的所有阶段。

### 阶段三：用户故事

基于阶段一的项目背景，将需求拆解为用户故事。用户故事是后续功能设计和测试核心指引。

每条用户故事使用统一编号 `US-XX`，包含以下字段：

```
US-01：[故事标题]
- 角色：作为 [具体角色]
- 场景：当 [触发条件/情境]
- 意图：希望 [达成的结果，动词开头]
- 动机：以便 [背后的目标]
```

### 阶段四：大纲确认（必须等待用户确认后再继续）

用户故事完成后，**不得直接进入功能说明的详细撰写**。必须先输出一份结构化大纲供用户确认，确认后才能继续推进。

**大纲格式：**

针对每条用户故事，列出其下属的功能要点。每个功能只用一句话概括核心能力，不展开细节。

```
US-01：[故事标题]
  ├─ F-01-1：[一句话功能概述]
  ├─ F-01-2：[一句话功能概述]
  └─ F-01-3：[一句话功能概述]

US-02：[故事标题]
  ├─ F-02-1：[一句话功能概述]
  └─ F-02-2：[一句话功能概述]
```

**确认要求：**

输出大纲后，明确询问用户：

- 用户故事的拆分是否合理？是否有遗漏或需要合并的？
- 每条故事下挂的功能要点是否覆盖了核心场景？是否有多余或缺失的？

**执行规则：用户明确确认（或给出调整意见并完成修改）后，才进入阶段五。未经确认直接展开功能说明是违反工作流的行为。**

**拆解原则：**

- 每个故事对应一个可独立交付和验证的用户价值
- 如果一个故事包含"并且"，通常应该拆成两个
- 故事只描述"要什么"，不描述"怎么做"
- 角色要具体——"安全分析师"而非"用户"，"系统管理员"而非"管理人员"

### 阶段五：功能说明

将每条用户故事拆解为具体功能，用编号体现归属关系（F-01-1 表示 US-01 的第 1 个功能）。

#### **功能描述**

这个功能要实现什么，核心逻辑是什么。用一段话说清楚核心逻辑，不涉及 UI 细节。

#### **业务说明**

功能背后的业务规则和约束条件。包括以下五项内容：

##### 前置条件

说明功能使用前需要满足的条件，例如用户权限要求、必须依赖的系统模块等。

##### 功能实现逻辑

描述系统处理业务的主要逻辑，包括数据来源、处理流程、能力边界等。

以评论功能为例

1. 内容输入

支持用户以下三种形式的输入：

- 纯文本
   - 图片（限制JPG/PNG/格式和大小）
   - 文件上传（限制格式和大小）

2. 富文本编辑

支持文字样式（字号、字重、字体颜色）和段落样式（段落间距、对齐方式）编辑。

3. 回复功能

支持对一级评论进行回复，形成二级评论，但不支持三级及以上评论嵌套。

4. 权限控制

| 操作     | 普通用户       | 管理员         |
   | -------- | -------------- | -------------- |
   | 删除评论 | 仅限自己的评论 | 任意评论       |
   | 修改评论 | 仅限自己的评论 | 仅限自己的评论 |

##### 核心字段说明

列出页面呈现的字段，并说明其含义，如果存在多种状态，请明确描述生命周期中会经历哪些**状态（Status）**，以及**在什么条件下从一个状态变为另	一个状态**。

例如：

- 告警ID：告警唯一标识
- 告警名称：恶意软件家族
- 影响资产：触发告警的资产IP
- 告警状态：包括未处置、处置中、已完成，由管理员用户手动切换告警状态。

##### 数据校验规则

说明系统需要对于输入数据进行的合法性和唯一性校验，例如：

- 域名、IP、样本哈希格式校验
- 新增用户名唯一性校验
- 上传文件格式、大小限制

### 阶段六：界面和**交互说明**

描述页面组成元素以及每个操作的完整执行流程，视觉样式以`design-system.md`中定义的内容为准，此处只描述行为逻辑。

#### 页面结构

描述页面由哪些区块构成、各区块的布局关系。组件样式以 `design-system.md` 为准，此处只说明结构和布局。

需要描述的内容：

- **整体布局**：页面的主要结构，如顶部操作区 + 内容区、左侧导航 + 右侧内容、多 Tab 切换等
- **区块划分**：页面拆分为哪几个区块，每个区块展示的内容是什么
- **区块关系**：哪些区块之间存在联动（如过滤区的条件影响下方数据区）
- **默认状态**：页面首次加载时各区块的初始展示状态

#### 交互流程

每个操作按以下结构描述：

```
操作名称
  触发：[用户做什么触发这个操作]
  执行中：[进行中的 UI 状态，如按钮 disabled、显示 loading]
  成功：[成功后的结果和页面变化]
  失败：[失败后的提示方式和可恢复操作]
  边界条件：[特殊输入或状态下的处理，如空值、超长、无权限]
```

### 阶段七：文档撰写

PRD 内容全部完成后，调用 `docx_handler`skill，将完整 PRD 转换为 Word 文档输出。

**写作原则：**

\- **具体可执行**：避免模糊表述。❌ "支持搜索" → ✅ "支持精准/模糊搜索某某字段"
 \- **开发视角**：写完每一条，想象一下开发人员问："这个我能直接开始做吗？"
 \- **无歧义**：避免"可能"、"应该"、"等"这类模糊词。
 \- **边界清晰**：不确定的内容用 `[待确认]` 标注，而不是含糊带过

------

_meta.json Metadata

{
  "ownerId": "kn7f684m8bxqbd1cs26x2hb9k982t3xj",
  "publishedAt": 1774942221760,
  "slug": "prd-development",
  "version": "1.0.1"
}