用途：把产品意图翻译成需求，发生在选择界面方案之前。需求描述用户与系统需要什么，而不是使用哪个组件。
主要能力与流程：抽取用户目标、业务目标、约束，以及数据/API/认证依赖；用“FR-XX：当[条件]时，系统应[动作]，以便[结果]”的格式编写功能需求；在相关时编写非功能需求，覆盖性能、可访问性、响应式、浏览器支持、安全/隐私、可靠性、国际化；识别 v1 明确的超出范围项；列出假设与待解决问题；建议以验收标准、站点地图或用户流程映射作为下一步。
输出格式：按“需求”分段，含功能需求、非功能需求、依赖（数据/API、认证/权限、设计系统）、v1 超出范围、假设、待解决问题，并给出建议的下一步。资料提供了工作示例，例如仪表盘展示最近 30 天活动、日期范围筛选保留在 URL、4G 移动端 LCP 低于 2.5 秒、控件可键盘访问并满足 WCAG 2.2 AA 对比度等。
使用方式：当输入是产品简报、干系人笔记、功能想法、客户请求或模糊概念时使用。想法仍模糊时应先运行 $product-intent-clarifier；需求已存在而待解决问题是信息架构时应改用 $sitemap-planner。
常见错误与边界：不要把需求写成界面方案（“比较 20 项”是需求，“显示表格”是可能方案）；不要因用户只描述功能就跳过非功能需求；不要用模糊措辞掩盖认证、权限或 API 依赖。
最终校验：每条功能需求可测试；除非明显无关，至少考虑可访问性与响应式作为非功能需求；未知项以假设或待解决问题显式呈现。