yumih1129 Skill: 需求简报整理器
将用户输入的自然语言需求转成结构清晰、边界明确、可继续推进的结构化需求简报。
本地资源与权威顺序
SKILL.mdfrontmatter：只定义技能名称与触发描述。SKILL.md正文：只定义流程、选择规则、输出规则、质量门禁和失败处理；正文与其他本地文件冲突时，以正文为准。references/requirement-template.md：只提供固定章节骨架、局部改写映射和示例，不补充、不覆盖、不改写执行规则。_meta.json：只提供注册与展示元数据，不补充、不覆盖、不改写执行规则。
核心原则
- 先理解目标，再重写表达，不要先假设方案。
- 不补不存在的业务要求；推断内容必须显式标注为“推断”或“待确认”。
- 保留用户原意，同时消除口语、重复、跳跃和歧义。
- 只追问阻塞性的缺口；一次最多问 3 个问题。
- 需求描述要面向执行与验收，不要写成实现说明。
- 如果输入已经足够，直接输出专业版需求简报，不要额外展开流程解释。
- 输出完整结构化需求简报时，必须读取
references/requirement-template.md；只输出简短正式描述时，不读取该模板也可执行。
何时使用
当用户提供以下任一种输入时使用本技能：
- 一句或一段不够正式的需求描述。
- 一段混杂了想法、限制、目标和实现偏好的对话记录。
- 一份需要整理成正式需求简报的草稿、笔记或要点列表。
- 需要把“想做什么”转成“应该交付什么”的场景。
不要把本技能直接用来产出技术方案、代码实现或排期计划，除非用户明确要求把需求继续展开成这些内容。
执行流程
1. 识别需求类型
按以下顺序判断用户输入属于哪一类；命中后停止：
- 对话整理成正式简报：输入是聊天记录、会议记录、零散问答或多轮表达。
- 需求补充：用户在已有需求基础上追加内容、限制、范围或验收条件。
- 需求重写：用户明确要求改写、正式化、润色或整理已有需求文本。
- 需求澄清：用户重点是确认方向、边界、歧义或待确认项。
- 新需求：其余首次提出的需求表达。
同时按以下顺序提取四个基础要素：
- 目标
- 受众或使用对象
- 作用范围
- 约束或验收信号
2. 找出缺口
按以下顺序检查以下信息是否缺失：
- 用户为什么要做这件事
- 要给谁用
- 需要覆盖到什么范围
- 哪些内容明确不做
- 结果怎样算完成
只有缺失的信息会影响方向、范围或验收时，才追问；追问顺序与本节检查顺序一致，一次最多问 3 个问题。
3. 生成专业表述
将输入改写为正式、简洁、可交付的需求简报：
- 用明确、客观、可执行的语气。
- 用“应、需、支持、允许、不应”替代“可以、尽量、最好”。
- 把模糊词转成可判断的表达。
- 把实现偏好与真实需求分开。
- 未经用户明确给出的内容，只允许写入“推断”或“待确认项”，不得直接写入确定性需求。
4. 组织输出
按以下规则选择输出结构：
- 用户只想要一段正式描述时，只输出“需求名称 + 一句话概述 + 核心范围 + 关键要求”。
- 其余情况一律输出完整结构化需求简报，并按
references/requirement-template.md的固定章节顺序组织。
完整结构固定顺序：
- 需求名称
- 一句话概述
- 背景与目标
- 适用对象
- 需求范围
- 非目标
- 关键要求
- 约束与依赖
- 验收标准
- 待确认项
输出规则
- 保持中文正式表达，避免口语化。
- 不写实现细节，除非用户明确要求“实现建议”。
- 不把不确定信息伪装成事实。
- 同一概念只用一套术语，不要混用多个叫法。
- 如果存在多个理解方向且会影响范围、边界或验收，不选择其一直接落稿；将推荐理解写入“待确认项”，其余理解方向与差异一并列出。推荐理解按以下顺序确定：目标更明确者 > 范围更明确者 > 约束或验收信号更明确者 > 与用户原话更一致者。
- 如果存在多个理解方向但不影响范围、边界或验收，按最贴近用户原话的方向统一表述，不额外展开分支。
质量门禁
输出前检查以下几点：
- 目标是否清楚。
- 范围是否明确。
- 非目标是否能区分。
- 验收是否可判断。
- 待确认项是否显式列出。
- 是否有任何未经说明的推断。
失败处理
- 输入过短且无法判断目标：只追问目标、对象、范围中最阻塞的缺口。
- 输入混杂实现方案与真实需求：保留实现偏好，但与需求正文分开；无法确认其是否为硬约束时，写入“待确认项”。
- 输入存在多个互斥方向：不合并成单一需求；输出推荐理解和其他方向，并标记为“待确认项”。
- 用户要求继续展开为技术方案、代码实现或排期：先完成需求简报整理，再按用户要求继续展开。
输出模板引用
完整结构化需求简报必须使用 references/requirement-template.md 中的固定章节骨架。该模板只负责章节标题、局部改写映射和示例，不负责流程判断。
完整输出骨架
## 需求名称
## 一句话概述
## 背景与目标
## 适用对象
## 需求范围
## 非目标
## 关键要求
## 约束与依赖
## 验收标准
## 待确认项
如果用户提供的是很碎的原始描述，仍按上述骨架输出；无法确认的内容统一写入“待确认项”。