用途：在功能想法成为正式需求之前进行 YC 风格的产品验证，确认真实需求、清晰切入点和假设背后的证据，并以 constructively skeptical 的方式找出弱点。
主要能力：按六个 forcing questions 依次追问，每个问题建立在上一答案之上：1）Demand Reality，谁在主动要求、有何证据，区分“客户要求”与“我们认为客户想要”，无证据即标记；2）Status Quo，用户如今如何解决、为何不够好，梳理现有工作流并量化痛点；3）Desperate Specificity，谁是唯一最迫切的用户、其一天如何度过，定位最大挫败点；4）Narrowest Wedge，能解决该用户问题的最小版本，参考已有能力，抵制扩大范围；5）Observation / Surprise，观察到什么出乎意料的事，若没有惊喜说明理解不够深；6）Future-Fit，若成功解锁什么、若失败学到什么，是否可复利、强化竞争地位。
使用方式：先让 PM 用 2-3 句话描述功能想法，不用术语和实现细节；再依次走完六个问题，每答完一步总结所听内容、给出评级（Strong / Needs Work / Red Flag），回答含糊时追问；最后把评估保存到功能文件夹的 validation.md，文件含 title、type、verdict（GO | REFINE | PAUSE）、date、pm、feature 等元数据，以及 Demand Reality、Status Quo、Desperate User、Narrowest Wedge、Surprise、Future-Fit 各节和 Verdict 与 Next Steps。文件命名会被下游技能读取：context builder 读取客户驱动与竞争背景，requirements writer 读取需求证据、范围与人物画像，executive summary 读取 Problem、Why Now 与 FAQ 部分。
适用场景：功能立项前的需求评审、优先级判断、MVP 范围收敛，以及跨角色对齐产品假设。
限制：资料未说明该技能的具体平台、安装方式与收费信息；其效果依赖团队是否能提供具体客户、会议或支持工单等证据，无证据时应按 Red Flag 处理。