version: "1.0.3" name: req-analysis description: "需求分析 — 需求拆解、用户故事编写、验收标准定义。当用户提出新需求、需要编写 PRD、拆解功能点或定义优先级与验收标准时使用。" argument-hint: "<用户需求描述或已有PRD路径>" suggested-tools: file_read, file_write, file_edit depends: [context, research] 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
• 非功能需求(性能/安全/兼容性)

执行流程

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 finalize交付PRD

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