/aor-req — 需求撰写
根据EARS-12模式、INCOSE C1-C9质量属性以及规范交叉引用语法，起草UN、PR和SR。输出为Markdown格式。
关于技能与代理的说明。 AOR工具包中包含
.claude/skills/aor-*/SKILL.md下的技能（可直接调用，例如本技能）和.claude/agents/aor-sme-*.md下的专家代理（仅由aor-review/aor-review-adhoc调用的子代理系统提示词）。切勿将代理作为技能调用——否则将失败并显示“未找到技能”。
操作纪律
全程应用。在启动时向用户声明每一项。
- 模式（启动时声明）： 询问本次是探索性会话（单个需求，对话式，无文件）还是文档会话（完整规范编写，写入文件）。如果作用域以内联文本形式提供且不包含文件路径，则默认为探索性模式；否则默认为文档模式。该模式控制步骤5–7是否写入磁盘。
- 调用确认： 技能的首次回复应声明“以
aor-req身份在<模式>模式下运行。除非您另行指定，否则文件将写入<输出路径>”。消除“技能是否实际运行？”的歧义。 - 问答纪律： 一次只问一个澄清性问题。等待用户回答后再问下一个。不要堆叠问题。一个
AskUserQuestion调用中呈现一个包含多个选项的决策（例如多选菜单）算作一个问题；但在一次调用中呈现两个不相关的决策则属于堆叠。 - 失败披露： 如果任何规定步骤无法完成（文件写入受阻、子代理调用失败、参考文件不可用、部分完成、超时、权限被拒绝），请在聊天中说明。在披露之后，暂停并询问是重试、回退到披露的手动模拟，还是中止——不要静默继续。对于明显可恢复的临时故障（例如网络超时），在强制披露前允许重试一次。
工作流
步骤1：确定范围
如果用户传递了作用域文本或文件路径，则使用它。否则，通过AskUserQuestion询问：“应指定哪些功能或变更？”
区分作用域文本与文件路径（REQ-B）：如果输入满足以下任一条件，则视为路径：（a）包含/或\，（b）以.md / .txt / .xlsx / .csv / .docx结尾，或（c）通过Read()解析为磁盘上存在的文件。否则视为作用域文本——包括多词描述，如“患者预约挂号系统”。
决胜规则： 如果只有规则（c）匹配（没有/或\，没有识别的扩展名，但Read()解析成功）且输入是单个单词，请在视为路径之前向用户确认：“我找到了一个名为<输入>的文件。您是指那个文件，还是这是一个范围描述？”
对于来自Excel的输入，期望主机LLM在此技能运行之前已将行转录到Markdown工作缓冲区中（工具包不直接解析Excel）。
步骤1a：分类级别
如果是探索性模式，请询问：
“这是用户需求（UN）、产品需求（PR）还是软件需求（SR）？”
一旦知道级别，跳过未使用的步骤：UN审查需要步骤2；PR审查需要步骤3 + 回显门控；SR审查需要步骤4–6。
探索性模式下的多级输入： 如果用户提供的是UN+PR+SR集合（或任意多个级别的组合），而不是选择一个，则作为多级审查处理——按顺序对所提供的级别执行步骤2–4，但保持探索性文件写入纪律（不自动写入磁盘；以内联方式呈现发现）。
如果是文档模式，除非用户另有指定，否则默认对所有三个级别（UN → PR → SR）执行步骤2–4。
步骤2：编写用户需求（UN-NNN）
为每个不同的利益相关者需求编写一个UN。规则：
- 技术无关，以利益相关者视角表述
- 纯叙述性语言（非EARS语法）
- 包含问题陈述（2-3句）+ 需求陈述
- 通过
traces_to::UN->Persona [<persona-id>]标记人物角色 - 优先级：Critical | High | Medium | Low
格式见templates.md。
步骤3：编写产品需求（PR-NNN）
为每个UN推导PR：
- 技术无关，可测量，客观
- EARS语法（参见
ears-guide.md了解12种模式） - 每个PR向后追溯：
derived_from::PR->UN [UN-NNN] - 每个PR向前追溯：
traces_to::PR->SR [SR-NNN] - 每个主路径PR必须至少有一个If/Then（非期望行为）PR作为伴侣
- 相同If/Then伴侣规则适用于步骤4中的SR级别——每个主路径SR必须有一个指定实现级恢复机制的If/Then SR伴侣
- 每个EARS-N（否定/“不得”）PR必须至少有一个正向伴侣PR（普遍型、事件驱动型或状态驱动型），用于指定预期的正确行为；相同规则适用于SR级别
“主路径”定义（REQ-E）：如果PR使用以下正向EARS模式之一，则视为主路径——Ubiquitous、Event-Driven、State-Driven、Optional、Complex、EARS-E、EARS-T、EARS-P。排除项：Unwanted Behaviour、EARS-N（否定/“不得”）、EARS-F（故障模式声明式）。
为每个UN执行对抗性错误分解：
- 它如何静默失败？
- 它如何噪音失败？
- 它如何在高负载下失败？
- 它如何在恶意攻击下失败？
- 它如何随时间推移失败？
每种故障模式要么成为EARS If/Then PR（在标题中标记[ADV]；标识符保持规范，例如PR-007 [ADV]），要么作为单独风险登记册的备注。
工作示例。 UN：“保留所有上传的文件”。故障模式：“磁盘空间耗尽时静默失败”。生成的PR：
### PR-007 [ADV]: 磁盘压力高时拒绝上传
如果磁盘剩余空间低于5%，则系统应拒绝新上传，返回HTTP 507 Insufficient Storage并包含Retry-After标头。
derived_from::PR->UN [UN-001]
traces_to::PR->SR [SR-014]
注意故障模式是具体且量化的（5%、HTTP 507、Retry-After）——这正是使PR可验证的原因（C7）。
步骤4：编写软件需求（SR-NNN）
为每个PR推导SR：
- 实现特定：命名服务、API、数据库、错误代码
- 使用具体组件名称的EARS语法
- 每个SR向后追溯：
derived_from::SR->PR [PR-NNN] - 每个SR向前追溯：
traces_to::SR->TC [TC-NNN] - 使用子句级粒度（
SR-NNN.c1、.c2）将相关行为整合到单个SR ID下 - 每个主路径SR必须至少有一个If/Then（非期望行为）SR伴侣（参见步骤3中的“主路径”定义）
- 每个EARS-N SR必须至少有一个正向伴侣SR
步骤5：字段规格表
对于具有数据输入/显示的功能，在SR部分添加字段规格表：
| Field ID | Name | Label | Type | Min | Max | Unit | Default | Required | UI Exposure | Validation Rule | Error Msg | Parent SR |
|---|
UI Exposure值：editable | display-only | hidden。
步骤6：回显门控
为每个SR子句编写一行可测试的断言：
VERIFY: [SR-NNN.cl] — [将需求重述为可测试的断言]
如果无法编写断言，则需求不可测试——请重写它。
步骤7：完整性检查
在宣布撰写完成之前，运行completeness.md中的检查清单。
大型输入处理
当输入超过大约200个源项时（例如大型Excel粘贴）：
- 将输入拆分为每批50行。
- 对于每个批次： a. 读取该批次。 b. 按照上述步骤转录为Markdown UN/PR/SR。 c. 追加到工作文件（不要覆盖）。 d. 报告进度：“批次 / 完成；已起草个需求。”
- 所有批次完成后，对完整文件运行完整性检查。
如果某个批次包含模糊输入，请在继续之前暂停并请求澄清——不要静默跳过行。
输出路径
默认：合并的UN/PR/SR输出到./requirements/SPECIFICATION.md。用户可以覆盖。
更新现有文件时，保留现有ID——使用下一个顺序编号追加新ID。
交叉引用语法（速查表）
relation_type::SOURCE->TARGET [ID-list]
| 类型 | 方向 | 用途 |
|---|---|---|
traces_to | 向前 | UN→PR, PR→SR, SR→TC, UN→Persona |
derived_from | 向后 | PR→UN, SR→PR, TC→SR |
validates | 验证 | TC→SR |
mitigates | 风险控制 | SR→RISK |
conflicts_with | 矛盾 | 任意→任意 |
标识符格式
正则表达式：^(UN|PR|SR|TC)-\d{3}(\.[A-Z])?$
- 基本ID：
UN-001,PR-001,SR-001 - 子ID（EARS-P表格）：
PR-010.A,PR-010.B - 子句表示法：
SR-001.c1,SR-001.c2
参考文件
ears-guide.md— 12种EARS模式templates.md— UN/PR/SR部分的Markdown模板completeness.md— 退出检查清单（UN→PR→SR覆盖）