req-analysis

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一一对应，减少模板填充时的二次整理