# Requirements Brief > 将用户口语化、零散或模糊的需求整理为结构化、可交付的需求简报。适用于需求梳理、需求改写、需求补全、范围界定、验收标准整理、待确认项提炼，以及把对话记录转成正式需求简报时使用。 - Skill: `yumih1129/requirements-brief` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add yumih1129/requirements-brief` - Raw SKILL.md: https://api.skillmd.com/api/skills/yumih1129/requirements-brief/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: yumih1129 (https://skillmd.com/u/yumih1129) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/yumih1129/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` 中的固定章节骨架。该模板只负责章节标题、局部改写映射和示例，不负责流程判断。 ## 完整输出骨架 ```markdown ## 需求名称 ## 一句话概述 ## 背景与目标 ## 适用对象 ## 需求范围 ## 非目标 ## 关键要求 ## 约束与依赖 ## 验收标准 ## 待确认项 ``` 如果用户提供的是很碎的原始描述，仍按上述骨架输出；无法确认的内容统一写入“待确认项”。