| name | req-analysis |
| description | 需求分析 — 需求拆解、用户故事编写、验收标准定义。当用户提出新需求、需要编写 PRD、拆解功能点或定义优先级与验收标准时使用。 |
| argument-hint | <用户需求描述或已有PRD路径> |
| suggested-tools | file_read, file_write, file_edit, shell_exec |
| depends | ["context","research","design-grill"] |
| disable-model-invocation | false |
| user-invocable | true |
需求分析 (req-analysis)
能力边界
- 能做: 解析用户原始需求、拆解功能点、编写用户故事、定义验收标准、标注优先级
- 不做: 架构设计、技术选型、UI设计、任务卡(T-{NNN})拆分与 Sprint 划分(ARCH 完成后由 task-decomp 负责,本 skill 止于 F-{NNN} 功能点层)
输入规范
- 用户原始需求描述(自然语言)
- 可选: 已有PRD(用于需求变更场景)
输出规范
- 功能列表(F-{NNN}),每个包含:
- 用户故事: 作为{角色},我希望{动作},以便{价值}
- 验收标准: AC-{NNN} 可验证条件
- 优先级: P0/P1/P2
- 非功能需求(性能/安全/兼容性)
执行流程
可选前置: Grill 深度澄清
触发与启用协议见 design-grill §启用门(项目偏好或阶段入口一次询问;询问不等于启用,用户明确接受后调用 design-grill prd [范围])。未启用即以 research user-interview 做普通澄清。Grill 总结返回后再进入 Step 1,不由 Grill 代写 PRD。
Step 1: 需求收集与澄清
- 解析用户输入,识别功能域和核心诉求
- 执行至少一轮 user-interview 确认核心需求方向,模糊/冲突需求通过追加提问澄清(提问通道见 research 指令2/2b)
- 产出: 原始需求清单(非正式,工作文档)
Step 2: 概述编写 (对应PRD §1)
- §1.1 背景与动机: 提炼项目背景(2-3句,回答"为什么做这个项目")
- §1.2 目标用户: 用户画像(角色 + 特征 + 核心诉求)
- §1.3 成功指标: 定义可量化指标,填写(指标 | 目标值 | 衡量方式)表
- 信息不足时通过research skill的user-interview指令确认
Step 3: 功能需求拆解 (对应PRD §2)
- 每个功能点编号 F-{NNN},包含:
- 用户故事: "作为{角色},我希望{动作},以便{价值}"
- 验收标准: AC-{NNN},每条必须可独立验证(给出具体条件而非模糊描述)
- 优先级: P0(必须有,缺失则产品不可用) / P1(重要,影响核心体验) / P2(锦上添花)
- 优先级决策记录: P0标注须说明"为什么是P0而非P1"——标准是"没有此功能产品是否完全不可用"
- 备注: 约束/边界条件/[ASSUMPTION]标注
- P0功能优先完成,P2可标注[ASSUMPTION]待确认
- 功能间有依赖时在备注中标注(供后续task-dep-analysis使用)
Step 4: 非功能需求 (对应PRD §3)
- §3.1 性能: 填写(场景 | 指标 | 目标值)表,如"列表加载 | 响应时间 | <200ms"
- §3.2 安全: 认证/授权/数据保护要求
- §3.3 兼容性: 平台/浏览器/设备要求
- 无明确要求时标注[ASSUMPTION]并给出合理默认值
Step 5: 约束/假设/术语 (对应PRD §4-§5)
- §4 约束与假设:
- 约束: 技术/业务/时间约束
- 假设: 前提假设,标注[ASSUMPTION]
- 调研记录: 引用research-note编号(如有)
- §5 术语表: 领域特定术语(术语 | 定义)表
- 经 context generate 分支 authoring 落图后 finalize 交付 PRD(操作细节见 context skill)
Anti-Patterns
- 禁止: 把 P0/P1/P2 优先级直接抄用户原话 —— 必须基于 MoSCoW 框架重新评估;否则出现"用户说全部 P0"的瀑布化退化
- 禁止: 漏写非功能性需求章节 —— 仅功能列表的 PRD 在 ARCH 阶段无法做技术选型,architect 阻塞
- 禁止: 在 PRD 写实现细节("使用 React")—— PRD 是 What/Why,实现细节属 ARCH 范畴;越界会让 architect 失去决策面
- 禁止: 把验收标准写成主观描述("体验流畅")—— AC 必须可测(Given-When-Then 或明确通过条件),否则下游 QA / TDD 无从验证
效率策略
- 先识别核心功能(P0),再扩展次要功能
- 模糊需求及时澄清,不累积假设
- 执行流程各Step与PRD模板§1-§5一一对应,减少模板填充时的二次整理