| name | requirement-qa |
| description | 通过"方向定调 → 增量产出 → 用户 Review → 确认修正"的循环，帮助用户从模糊想法走向完整需求。不同于纯问答模式，本 skill 每轮都产出可 Review 的文档片段到 docs/01-requirement/，用户只需判断"对不对"而非从零表达需求。 务必在以下场景使用本 skill：用户的需求描述模糊或不完整（如"我想做一个 XX 系统"）、用户不确定技术方案该怎么选、用户要求进行需求分析、需求调研、需求访谈、需求梳理、需求沟通、技术方案讨论、架构讨论，或者用户说"帮我想想还缺什么"、"帮我理一下需求"、"我们聊聊这个项目"。当输入信息不足以直接输出完整文档时，应先进入本 skill 的 QA 流程，而不是凭猜测交付半成品。 |
需求引导对话（Requirement QA）
本 Skill 通过增量产出 + 用户 Review 的循环，帮助用户从模糊想法走向明确、完整、可落地的需求描述。
核心理念：用户不需要"说清楚需求"，只需要判断"Agent 产出的内容对不对"。把信息质量的压力从用户转移到 Agent，用户的角色从"回答者"变成"审核者"。
产出目标
每轮 QA 循环直接产出或更新 docs/01-requirement/ 下的模块化文件：
docs/01-requirement/
├── project-profile.md ← 项目画像（定位、用户、目标）
├── feature-scope.md ← 功能范围（功能列表 + MoSCoW 优先级）
├── business-rules.md ← 业务规则（核心规则 + 边界条件）
├── non-functional.md ← 非功能要求（性能、安全、合规）
└── tech-constraints.md ← 技术约束（技术栈、部署、集成）
这些文件是 spec-writing 等后续 skill 的输入。requirement-qa 解决 What（做什么），spec-writing 解决 How（怎么做到）。
核心循环：产出 → Review → 修正
每个模块的处理都遵循同一个三步循环：
Step 1：用户定方向
用户给出高层级方向或已有信息，可以很简短：
- "我想做一个在线教育平台"
- "给内部团队用的项目管理工具"
- 甚至只是"帮我想想这个系统还缺什么"
Agent 基于已有信息（用户输入 + 仓库工程事实），推断尽可能多的细节。
Step 2：Agent 产出 + 推荐选项
Agent 做两件事：
- 直接产出文档片段：把能推断的内容写成结构化文档，创建或更新到
docs/01-requirement/ 对应文件
- 对不确定的点给出推荐选项：遵循选项规则（2-5 个选项，标记一个推荐项，最后一个为自由输入）
关键：先产出再提问。不要空手来问"你想做什么"——先基于已知信息写一版草稿，再针对草稿中不确定的点提问。
Step 3：用户 Review + 确认
用户看到的是一个可 Review 的文档，不是一堆问题。用户可以：
- 确认："对，就是这样"→ Agent 进入下一个模块
- 标注修正："角色描述不对，应该是 XX"→ Agent 更新文件
- 补充信息："还有一个场景你漏了"→ Agent 补充到文件
Agent 确认用户 Review 结果后，原地更新文件（不删除重建），然后进入下一个模块或更深层的追问。
交互方式：优先使用结构化选项
优先使用当前 Agent 宿主编辑器提供的结构化提问能力，而不是系统级弹窗。如果宿主完全不支持结构化提问，才退回普通聊天消息。澄清逻辑只有一套，不同宿主之间只有 UI 表达方式不同，不允许逻辑分叉。
核心规则：
- 每个问题 2-5 个选项，必须且只能标记一个推荐项（附理由），最后一个选项始终为自由输入
- 推荐依据：工程事实 > 上下文推断 > 行业惯例 > 安全侧偏好
详细的选项设计规则、推荐项标记规则、宿主适配方式见 references/option-rules.md。
提问节奏控制
先产出再提问
每轮的核心产出是文档片段，问题只是文档中不确定点的澄清。比起"问 5 个问题等回答"，更好的做法是：
- 写一版草稿（80% 推断 + 20% 待确认）
- 在草稿中用
<!-- 待确认 --> 或 加粗标注 标记不确定点
- 针对最关键的 1-3 个不确定点提问
按需产生问题
每轮问多少个问题取决于当前实际需要澄清的未知项：
- 只有一个关键未知点，就只问一个问题
- 多个相互独立的未知点可以在同一轮一起问，减少往返次数
- 多个有依赖关系的未知点必须分轮——后续问题取决于前面的回答
错误示例：把有依赖的问题硬塞一轮——"你做 Web 还是桌面？支持哪些浏览器？"（浏览器依赖于"Web"这个前提）
正确思路：先问"最终产物形态"，根据回答再问具体约束。
高价值问题优先
优先问能改变执行路径的问题：
- 先问：做什么、给谁、到什么程度、范围边界
- 后问：用什么技术、什么风格、什么 UI 偏好
从工程事实出发
如果当前仓库已经是 Vue 3 项目，不要问"你想用 React 还是 Vue？"——先读事实，直接写入 tech-constraints.md，再问真正未知的东西。
模块推进流程
模块 1：项目画像（project-profile.md）
产出内容：项目定位、目标用户角色及核心诉求、核心痛点、成功标准、时间约束。
Agent 的做法：
- 读取用户输入 + 扫描仓库（README、package.json、已有文档等）
- 基于已知信息，直接写出
project-profile.md 草稿
- 对不确定的点提问（如目标用户角色、成功标准）
- 用户 Review → 更新文件 → 确认后进入下一模块
产出模板：
# 项目画像：{项目名称}
## 项目定位
{一两句话描述这个产品解决什么问题}
## 目标用户
| 角色 | 核心诉求 | 使用频率 |
|------|----------|----------|
| ... | ... | ... |
## 核心痛点
- 用户目前怎么解决这个问题
- 现有方案的主要不满
## 成功标准
- {可量化的业务目标}
## 时间约束
- MVP 期限：
- 关键里程碑：
模块 2：功能范围（feature-scope.md）
产出内容：功能列表（按 MoSCoW 分类），每个功能附简要验收标准。
Agent 的做法：
- 基于项目画像，主动推断可能的功能列表
- 写出
feature-scope.md 草稿，按 MoSCoW 分类
- 提问："以下功能列表是否完整？优先级是否正确？"
- 用户 Review → 增删改 → 更新文件
产出模板：
# 功能范围：{项目名称}
## Must（MVP 必做）
- [ ] {功能点} — 验收标准：{简述}
- [ ] ...
## Should（重要但可延后）
- [ ] ...
## Could（锦上添花）
- [ ] ...
## Won't（明确不做）
- [ ] ...
## 功能依赖关系
- {功能 A} 依赖 {功能 B}
模块 3：业务规则（business-rules.md）
产出内容：核心业务规则、边界条件、异常处理策略。
Agent 的做法：
- 从功能范围中提取隐含的业务规则
- 主动推断常见的边界条件和异常场景
- 写出
business-rules.md，标注哪些是推断的
- 用户 Review → 修正/补充 → 更新文件
模块 4：非功能要求（non-functional.md）
产出内容：性能、安全、可用性、合规等要求。
Agent 的做法：
- 根据项目类型和用户规模，主动推断合理的非功能指标
- 写出
non-functional.md，给出推荐值
- 提问：重点确认性能指标和安全合规要求
- 用户 Review → 更新文件
模块 5：技术约束（tech-constraints.md）（如涉及技术选型）
产出内容：技术栈、部署环境、集成点、团队约束。
Agent 的做法：
- 扫描仓库获取已有技术栈信息
- 直接写入已确定的事实（不问已经能从代码里看到的东西）
- 对需要决策的点给出对比表 + 推荐
- 用户 Review → 更新文件
对话技巧
应对不同类型的用户
- 话多的用户：适时做文档更新，让用户看到信息被结构化了；避免信息在聊天中散落
- 话少的用户：多产出、少提问；写出更完整的草稿，让用户只需确认"对/不对"
- 犹豫不决的用户：给出推荐方案 + 理由，"根据你描述的场景，我建议先做 X，原因是……"
- 过于发散的用户：先记录到文档的 Could/Won't 区域，温和拉回核心流程
Review 确认模板
每完成一个模块的文档更新后：
已更新 docs/01-requirement/project-profile.md
待确认点：
1. 目标用户是否只有"学生"和"教师"两个角色？
2. 成功标准中"日活 1000"是否合理？
请 Review 文件内容，告诉我哪里需要修正。确认后我进入下一模块（功能范围）。
执行方式
- 判断进入条件：用户的输入信息不足以直接输出完整文档时，进入 QA 流程
- 从项目画像开始：无论信息多少，先产出 project-profile.md 草稿
- 按模块推进：每个模块走"产出 → Review → 修正"循环；信息够了就跳过某些模块
- 原地更新：每次修正都更新同一个文件，不创建新文件
- 适时退出：当所有 Must 模块完成 Review，用户表示满意时，输出完成总结
- 衔接后续：提示用户可以用
docs/01-requirement/ 的产出进入 spec-writing 生成详细需求文档
完成信号
默认只有以下情况可以结束 QA：
- 用户明确说"开始产出""可以写文档了""按这个做"等
- project-profile.md 和 feature-scope.md 至少已完成 Review
如果用户说"继续问""先别开始"，优先视为继续澄清。即使用户要求立即结束但信息不完整，在文档中显式列出假设，标注为"未经用户确认，基于推断"。
完整的信号列表和最低结束标准见 references/completion-signals.md。
