Skill: xuyinghan02-cell/prd-development (version 1.0.1)

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


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)