- name
- prd-development
- description
- 将产品需求转化为Coding Agent可执行的需求文档。当用户提到"写PRD"、"产品需求文档"、"用户故事"、"功能说明"，或提供会议记录/功能描述需要整理成开发文档时触发。
PRD开发工作流
执行原则
AI 的角色： 产品经理的思考伙伴 + 需求文档撰写者。
工作流程
阶段一：项目背景
在开始撰写之前，先确认以下关键信息。如果用户输入已经包含答案，直接提取；缺失的才询问。
必须明确的两个要素：
- 问题 — 项目产生的的原因和背景，必须指出用户/业务遇到了什么具体问题。。
- 目标 —打算做一个什么东西来解决这个问题？这个东西做完之后怎么衡量"做对了"？。
背景分析与补全
在用户提供初始信息后，执行以下分析：
- 信息完整性检查 — 问题和目标是否都已明确？目标中是否同时包含"做什么"和"成功标准"？
- 矛盾检测 — 检查问题描述与目标之间是否有不一致的地方
- 补全建议 — 对缺失项提供具体的补全建议而非开放式追问。
阶段二：专业领域识别
需求收集完成后，根据阶段一项目背景中提取的信息，判断当前需求所属的专业领域，并自动加载对应的领域 skill：
| 关键词 | 加载Skill |
|---|---|
| DNS、域名异常分析 | DNS-analysis |
| 蜜罐、样本、IP | botnet-analysis |
识别流程：
- 扫描阶段一的项目背景（问题和目标），匹配上表中的关键词
- 如果匹配成功，告知用户将加载对应领域 skill，并说明该 skill 的作用
- 如果无法从用户输入中判断领域，询问一次："这个需求属于哪个专业领域？"并提供已有领域列表供选择
- 如果需求不属于任何已有领域，告知用户当前无对应领域 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 细节。
业务说明
功能背后的业务规则和约束条件。包括以下五项内容：
前置条件
说明功能使用前需要满足的条件，例如用户权限要求、必须依赖的系统模块等。
功能实现逻辑
描述系统处理业务的主要逻辑，包括数据来源、处理流程、能力边界等。
以评论功能为例
- 内容输入
支持用户以下三种形式的输入：
- 纯文本 - 图片（限制JPG/PNG/格式和大小） - 文件上传（限制格式和大小）
- 富文本编辑
支持文字样式（字号、字重、字体颜色）和段落样式（段落间距、对齐方式）编辑。
- 回复功能
支持对一级评论进行回复，形成二级评论，但不支持三级及以上评论嵌套。
- 权限控制
| 操作 | 普通用户 | 管理员 |
|---|---|---|
| 删除评论 | 仅限自己的评论 | 任意评论 |
| 修改评论 | 仅限自己的评论 | 仅限自己的评论 |
核心字段说明
列出页面呈现的字段，并说明其含义，如果存在多种状态，请明确描述生命周期中会经历哪些状态（Status），以及在什么条件下从一个状态变为另 一个状态。
例如：
- 告警ID：告警唯一标识
- 告警名称：恶意软件家族
- 影响资产：触发告警的资产IP
- 告警状态：包括未处置、处置中、已完成，由管理员用户手动切换告警状态。
数据校验规则
说明系统需要对于输入数据进行的合法性和唯一性校验，例如：
- 域名、IP、样本哈希格式校验
- 新增用户名唯一性校验
- 上传文件格式、大小限制
阶段六：界面和交互说明
描述页面组成元素以及每个操作的完整执行流程，视觉样式以design-system.md中定义的内容为准，此处只描述行为逻辑。
页面结构
描述页面由哪些区块构成、各区块的布局关系。组件样式以 design-system.md 为准，此处只说明结构和布局。
需要描述的内容：
- 整体布局：页面的主要结构，如顶部操作区 + 内容区、左侧导航 + 右侧内容、多 Tab 切换等
- 区块划分：页面拆分为哪几个区块，每个区块展示的内容是什么
- 区块关系：哪些区块之间存在联动（如过滤区的条件影响下方数据区）
- 默认状态：页面首次加载时各区块的初始展示状态
交互流程
每个操作按以下结构描述：
操作名称
触发：[用户做什么触发这个操作]
执行中：[进行中的 UI 状态，如按钮 disabled、显示 loading]
成功：[成功后的结果和页面变化]
失败：[失败后的提示方式和可恢复操作]
边界条件：[特殊输入或状态下的处理，如空值、超长、无权限]阶段七：文档撰写
PRD 内容全部完成后，调用 docx_handlerskill，将完整 PRD 转换为 Word 文档输出。
写作原则：
\- 具体可执行：避免模糊表述。❌ "支持搜索" → ✅ "支持精准/模糊搜索某某字段" \- 开发视角：写完每一条，想象一下开发人员问："这个我能直接开始做吗？" \- 无歧义：避免"可能"、"应该"、"等"这类模糊词。 \- 边界清晰：不确定的内容用 [待确认] 标注，而不是含糊带过