Requirements brief

Skill: 需求简报整理器

将用户输入的自然语言需求转成结构清晰、边界明确、可继续推进的结构化需求简报。

本地资源与权威顺序

1. SKILL.md frontmatter：只定义技能名称与触发描述。
2. SKILL.md 正文：只定义流程、选择规则、输出规则、质量门禁和失败处理；正文与其他本地文件冲突时，以正文为准。
3. references/requirement-template.md：只提供固定章节骨架、局部改写映射和示例，不补充、不覆盖、不改写执行规则。
4. _meta.json：只提供注册与展示元数据，不补充、不覆盖、不改写执行规则。

核心原则

• 先理解目标，再重写表达，不要先假设方案。
• 不补不存在的业务要求；推断内容必须显式标注为“推断”或“待确认”。
• 保留用户原意，同时消除口语、重复、跳跃和歧义。
• 只追问阻塞性的缺口；一次最多问 3 个问题。
• 需求描述要面向执行与验收，不要写成实现说明。
• 如果输入已经足够，直接输出专业版需求简报，不要额外展开流程解释。
• 输出完整结构化需求简报时，必须读取 references/requirement-template.md；只输出简短正式描述时，不读取该模板也可执行。

何时使用

当用户提供以下任一种输入时使用本技能：

• 一句或一段不够正式的需求描述。
• 一段混杂了想法、限制、目标和实现偏好的对话记录。
• 一份需要整理成正式需求简报的草稿、笔记或要点列表。
• 需要把“想做什么”转成“应该交付什么”的场景。

不要把本技能直接用来产出技术方案、代码实现或排期计划，除非用户明确要求把需求继续展开成这些内容。

执行流程

1. 识别需求类型

按以下顺序判断用户输入属于哪一类；命中后停止：

1. 对话整理成正式简报：输入是聊天记录、会议记录、零散问答或多轮表达。
2. 需求补充：用户在已有需求基础上追加内容、限制、范围或验收条件。
3. 需求重写：用户明确要求改写、正式化、润色或整理已有需求文本。
4. 需求澄清：用户重点是确认方向、边界、歧义或待确认项。
5. 新需求：其余首次提出的需求表达。

同时按以下顺序提取四个基础要素：

• 目标
• 受众或使用对象
• 作用范围
• 约束或验收信号

2. 找出缺口

按以下顺序检查以下信息是否缺失：

• 用户为什么要做这件事
• 要给谁用
• 需要覆盖到什么范围
• 哪些内容明确不做
• 结果怎样算完成

只有缺失的信息会影响方向、范围或验收时，才追问；追问顺序与本节检查顺序一致，一次最多问 3 个问题。

3. 生成专业表述

将输入改写为正式、简洁、可交付的需求简报：

• 用明确、客观、可执行的语气。
• 用“应、需、支持、允许、不应”替代“可以、尽量、最好”。
• 把模糊词转成可判断的表达。
• 把实现偏好与真实需求分开。
• 未经用户明确给出的内容，只允许写入“推断”或“待确认项”，不得直接写入确定性需求。

4. 组织输出

按以下规则选择输出结构：

• 用户只想要一段正式描述时，只输出“需求名称 + 一句话概述 + 核心范围 + 关键要求”。
• 其余情况一律输出完整结构化需求简报，并按 references/requirement-template.md 的固定章节顺序组织。

完整结构固定顺序：

1. 需求名称
2. 一句话概述
3. 背景与目标
4. 适用对象
5. 需求范围
6. 非目标
7. 关键要求
8. 约束与依赖
9. 验收标准
10. 待确认项

输出规则

• 保持中文正式表达，避免口语化。
• 不写实现细节，除非用户明确要求“实现建议”。
• 不把不确定信息伪装成事实。
• 同一概念只用一套术语，不要混用多个叫法。
• 如果存在多个理解方向且会影响范围、边界或验收，不选择其一直接落稿；将推荐理解写入“待确认项”，其余理解方向与差异一并列出。推荐理解按以下顺序确定：目标更明确者 > 范围更明确者 > 约束或验收信号更明确者 > 与用户原话更一致者。
• 如果存在多个理解方向但不影响范围、边界或验收，按最贴近用户原话的方向统一表述，不额外展开分支。

质量门禁

输出前检查以下几点：

• 目标是否清楚。
• 范围是否明确。
• 非目标是否能区分。
• 验收是否可判断。
• 待确认项是否显式列出。
• 是否有任何未经说明的推断。

失败处理

• 输入过短且无法判断目标：只追问目标、对象、范围中最阻塞的缺口。
• 输入混杂实现方案与真实需求：保留实现偏好，但与需求正文分开；无法确认其是否为硬约束时，写入“待确认项”。
• 输入存在多个互斥方向：不合并成单一需求；输出推荐理解和其他方向，并标记为“待确认项”。
• 用户要求继续展开为技术方案、代码实现或排期：先完成需求简报整理，再按用户要求继续展开。

输出模板引用

完整结构化需求简报必须使用 references/requirement-template.md 中的固定章节骨架。该模板只负责章节标题、局部改写映射和示例，不负责流程判断。

完整输出骨架

## 需求名称

## 一句话概述

## 背景与目标

## 适用对象

## 需求范围

## 非目标

## 关键要求

## 约束与依赖

## 验收标准

## 待确认项

如果用户提供的是很碎的原始描述，仍按上述骨架输出；无法确认的内容统一写入“待确认项”。