requirements-discovery

name	requirements-discovery
description	需求澄清 Skill：帮助 Manager 用四维框架（目标/边界/约束/风险） 对用户的初步需求进行结构化梳理，生成完整的需求文档。 适用场景：接收到用户模糊需求后，在无法实时追问的情况下， 按框架推演并将不确定项标记为「待确认」。 输出结果由调用方（通常是 memory-save skill）写入文件。
type	reference

requirements-discovery：四维需求发现框架

概述

本 Skill 是一个参考型（reference） Skill，直接注入调用方 Agent 的上下文。 Manager 无需启动沙盒，只需按照下面的框架对用户需求进行结构化思考，输出标准格式的需求文档。

---

四维需求框架

对任何初步需求，按以下四个维度逐一拆解：

维度 1：目标（Goal）

这个需求要解决什么问题？交付物是什么？成功的标志是什么？

发问视角：

• 用户的核心诉求是什么？（不是表面要求，而是背后的目的）
• 最终用户是谁？他们的使用场景是什么？
• 如何衡量"做成功了"？（可量化的验收标准）

维度 2：边界（Scope）

本次做什么？明确不做什么？

发问视角：

• 本次包含哪些功能/模块？
• 本次明确排除哪些功能/模块？（防止范围蔓延）
• 与现有系统的集成边界在哪里？

维度 3：约束（Constraints）

有哪些不可突破的限制？

发问视角：

• 时间约束：截止日期、里程碑节点
• 技术约束：必须使用的技术栈、语言、框架；禁止使用的技术
• 资源约束：团队规模、预算上限
• 合规约束：法律法规、数据隐私（如 GDPR）、安全标准

维度 4：风险与待确认项（Risks & TBDs）

哪些不确定因素会影响交付？

发问视角：

• 需求中哪些地方描述模糊，有歧义？→ 标记为「待确认」
• 哪些技术方案尚未验证，存在不确定性？
• 哪些外部依赖可能造成延期？
• 如果关键假设失败，备选方案是什么？

---

执行步骤

1. 阅读用户的初步需求描述
2. 逐维度推演：按目标 → 边界 → 约束 → 风险四个维度逐一分析
3. 补全缺失项：能推断的直接填写；无法推断的标记为「待确认：[问题描述]」
4. 输出需求文档：使用下方标准格式

---

输出格式（标准模板）

# 需求文档 - {项目/功能名称}

生成时间：{YYYY-MM-DD}
需求来源：{用户的原始描述摘要}

## 目标
- 核心诉求：...
- 目标用户：...
- 验收标准：
  - [ ] ...
  - [ ] ...

## 边界
### 本次包含
- ...

### 本次不包含（明确排除）
- ...

## 约束
| 类型 | 约束内容 |
|------|---------|
| 时间 | ... |
| 技术 | ... |
| 资源 | ... |
| 合规 | ... |

## 风险与待确认项
| 编号 | 类型 | 描述 | 影响 | 处理方式 |
|------|------|------|------|---------|
| R-01 | 待确认 | ... | 高/中/低 | 需甲方确认 |
| R-02 | 技术风险 | ... | 高/中/低 | 预留缓冲时间 |

## 验收标准（DoD）
- [ ] ...
- [ ] ...

---

使用注意

• 本 Skill 是纯思考框架，不执行任何代码
• 输出的需求文档内容交由 memory-save skill 写入文件
• 无法实时追问用户时，不得假设关键信息，必须标注为「待确认」
• 待确认项越少越好，但宁可多标也不要漏标