Product Lens 的定位是产品诊断，而不是直接产出可实现规格。若用户需要可长期使用的 PRD 到 SRS 或能力契约类文档，应交给 product-capability 处理。
适用时机：开始任何功能前验证「为什么」；每周产品复盘判断是否在做对的事；在功能之间难以取舍时；上线前检查用户旅程；以及把模糊想法转化为产品简报、进入工程规划之前。
工作方式
模式一：产品诊断。类似自动化的 YC office hours，追问硬问题：这是给谁用的（具体的人，而不是「开发者」）？痛点是什么（量化频率、严重程度、现在怎么解决）？为什么是现在（什么变化使其可能或必要）？10 分版本是什么？MVP 是什么（证明论点成立的最小事物）？反目标是什么（明确不做什么）？怎么知道它有效（指标，而非感觉）？输出 PRODUCT-BRIEF.md，包含答案、风险与 go/no-go 建议。若结论是「可以开始做」，下一步应进入 product-capability，而不是继续做创业者式表演。
模式二：创始人视角复盘。读取 README、CLAUDE.md、package.json 和近期提交，推断「这东西想成为什么」，评估产品市场契合信号（0-10 分），涵盖使用增长轨迹、留存指标（重复贡献者、回访用户）、收入信号（定价页、计费代码、Stripe 集成）、竞争壁垒（什么难以复制）；指出能让它提升 10 倍的那一件事；并标记出正在做但不重要的东西。
模式三：用户旅程审计。以新用户身份克隆或安装产品，记录每个摩擦点（令人困惑的步骤、错误、缺失文档），为步骤计时，与竞品引导流程对比，评估 time-to-value（用户多久获得第一次成功），并给出引导流程最值得做的三项修复。
模式四：功能优先级。当有 10 个想法但只能选 2 个时，列出候选功能，按影响力（1-5）× 信心（1-5）÷ 投入（1-5）打分，按 ICE 分数排序，结合跑道、团队规模、依赖等约束，输出带有理由的优先级路线图。
输出与集成：所有模式都输出可执行的文档，而不是长文；每条建议都带有具体下一步。可与 /browser-qa 验证用户旅程审计发现、/design-system audit 评估视觉打磨、/canary-watch 做上线后监控配合；当产品简报需要转化为可实现的能力计划时交给 product-capability。
限制：资料未提供该技能的具体安装方式、收费模式、支持平台或实现细节；上述集成命令与文件名保持资料原文。