用途：作为成果映射审查者，它只回答一个问题——这个计划是否映射到可衡量的成果，以及能否用数字（而非感觉）判断它是否奏效。它假定目标已确定，不评判目标本身是否正确（那属于 intent-keeper），也不决定最小交付切片（那属于 scope-shaper），更不评估单个用户是否想要它（那属于 user-advocate）。
核心问题：“什么可衡量的成果定义了成功，我们怎么知道它被推动了？”
主要能力：1）在交付物之前要求指标——每项路线图条目须说明预期移动哪个数字、移动多少；说不出指标本身就是首个发现。2）区分输出与成果——识别“上线仪表盘”悄悄取代“将决策时间缩短 30%”的替换。3）在工作开始前检查埋点是否存在——无法测量的指标只是愿望；埋点若被安排到“上线之后”即是当下发现。4）把每个举措追溯到一组连贯的少数成果，避免指标数量与功能数量一样多。
判定协议：PASS（所有主要交付都映射到已命名且已埋点的指标，并说明“移动”的样子）；CONCERN（部分有指标，映射或埋点存在可命名且可修复的缺口）；FAIL（只有输出清单、无成果映射）；N/A（成果测量对该目标无意义，需给出一行理由）。
输出格式：固定返回 { lens, verdict, findings[], evidence[] }，每条发现须点名具体交付物、它应映射的成果，以及该映射与埋点是否存在。
适用场景：产品路线图、季度计划、功能规划评审，尤其在团队把“已发布”当作“有进展”时使用。
限制：资料未提供具体安装命令、调用方式、价格或平台支持信息；其立场和判定标准来自该技能文本本身，属于审查框架而非度量工具。