SKILL.md：PRD 转 EARS 需求规范
能力概述
接收用户上传的 PRD 文档（支持 PDF、Word、Markdown、纯文本），输出一份符合 EARS（Easy Approach to Requirements Syntax）规范的结构化需求清单。让AI更容易理解PRD文档，EARS 由 Rolls-Royce 于 2009 年提出，通过固定句式约束自然语言需求，减少歧义、提高可测试性，已被 Bosch、Daimler、NASA、Siemens 等组织采用。
核心规则
EARS 五种句式
每条功能需求必须使用以下五种句式之一：
| 句式 | 关键词 | 结构 | 适用场景 |
|---|---|---|---|
| Ubiquitous | 无 | The <system> shall <response>. | 始终为真的不变量 |
| Event-driven | When | When <trigger>, the <system> shall <response>. | 离散事件触发的响应 |
| State-driven | While | While <state>, the <system> shall <response>. | 持续状态下的行为 |
| Unwanted behavior | If...Then | If <unwanted condition>, then the <system> shall <response>. | 错误、故障、非法输入 |
| Optional feature | Where | Where <feature is included>, the <system> shall <response>. | 可选功能/配置 |
复杂需求可组合关键词，例如 While <state>, when <trigger>, the <system> shall <response>.
句法要素
每条需求必须包含：零个或多个先决条件、零个或一个触发器、一个明确的系统名称、一个且仅一个系统响应。
处理流程
第一步：解析 PRD
读取上传的 PRD 文档，逐段提取候选需求语句。保留原始文本的章节结构和编号，以便建立追溯关系。
第二步：拆分复合需求
将包含多个要求的句子拆分为独立语句。判断依据：如果一句话中包含两个独立的响应（例如"保存文件并发送通知"），则拆分为两条需求。
第三步：判定需求类型
对每条拆分后的需求，按以下优先级判定 EARS 句式：
- 有触发器 → Event-driven（When）
- 有持续状态 → State-driven（While）
- 是错误/异常处理 → Unwanted behavior（If...Then）
- 仅在特定功能启用时存在 → Optional feature（Where）
- 无任何条件 → Ubiquitous
选择最窄的句式：只要有触发条件，就优先使用 When/While/If，而非 Ubiquitous。
第四步：重写为 EARS 格式
使用判定出的句式模板，将原始需求改写为规范语句。改写时遵循以下规则：
- 系统名称具体化：不可使用"系统应该..."这类模糊指代，替换为明确的系统/组件名称（如"订单服务""前端应用"）
- 触发器具体化：将"当需要时""在适当情况下"替换为具体的事件或条件
- 响应可测试：将"处理错误""快速响应"等不可验证的表述替换为可观察、可度量的行为
- 每条需求一个响应：如果原句包含"并且/或者"，拆分为多条
第五步：输出需求清单
按以下格式输出每条需求：
REQ-<AREA>-<NNN>
EARS 句式：<Ubiquitous | Event-driven | State-driven | Unwanted behavior | Optional feature>
需求语句：<EARS 格式的完整语句>
验收标准（Given/When/Then）：
- Given: <前置条件>
- When: <触发动作>
- Then: <预期结果>
MoSCoW 优先级：<Must | Should | Could>
原文追溯：<PRD 原文章节编号或原文引用>
<AREA> 为功能领域缩写（如 AUTH、ORDER、PAY）。<NNN> 从 001 递增。
质量检查清单
在输出每条需求前，自检以下问题：
- 触发器是否具体？（"WHEN appropriate"不通过）
- 响应是否可测试？（"handles errors"不通过）
- 是否隐藏了"and"？（一条需求只含一个响应）
- 系统名称是否明确写出？
- 是否混入了设计/实现细节？（EARS 只描述"做什么"，不描述"怎么做"）
任何一项不通过，重新改写。
输出格式
最终输出为一个 Markdown 文件，结构如下：
# EARS 需求规范
> 来源 PRD：<文件名>
> 生成时间：<时间戳>
> 需求总数：<N>
## 功能需求
### REQ-<AREA>-001
...
### REQ-<AREA>-002
...
## 非功能需求
（非功能需求不强制使用 EARS 句式，以"类别 / 目标"表格形式呈现）
| 类别 | 目标 | 追溯 |
|---|---|---|
| 性能 | 订单查询响应 < 200ms (P95) | PRD 3.2 |
## 待澄清项
以下内容因信息不足无法确定 EARS 句式或系统响应，需人工确认：
- [ ] <原始文本片段> — 缺少：<缺失信息类型>
## 边界约束
- 不生成非功能需求的 EARS 句式（性能、安全、可用性等阈值型需求不适用 EARS 的行为导向结构）
- 不推断 PRD 中未明示的需求
- 不修改原始需求的业务意图，只改变表述形式
- 遇到信息不足时，列入"待澄清项"，不猜测
