Product Lens — Think Before You Build
此技能負責產品診斷，而非實作規格的撰寫。
如果使用者需要持久的 PRD 到 SRS 或能力合約文件，請移交給 product-capability。
何時使用
- 開始任何功能之前 — 驗證「為什麼」
- 每週產品回顧 — 我們是否在建構正確的東西？
- 在功能之間猶豫不決時
- 上線前 — 對使用者旅程進行健康檢查
- 在工程規劃開始前，將模糊想法轉換成產品簡報時
運作方式
模式 1：產品診斷
就像 YC 辦公時間但自動化。提出困難的問題：
1. 這是為誰設計的？（具體人物，不是「開發者」）
2. 痛點是什麼？（量化：發生頻率、嚴重程度、他們目前如何解決？）
3. 為什麼是現在？（什麼改變了使這變得可能/必要？）
4. 10 星版本是什麼？（如果資金/時間無上限）
5. MVP 是什麼？（能夠證明假設的最小事物）
6. 反目標是什麼？（你明確不建構什麼？）
7. 你如何知道它有效？（指標，不是感覺）
輸出：一個包含答案、風險以及執行/不執行建議的 PRODUCT-BRIEF.md。
如果結果是「是的，建構這個」，下一階段是 product-capability，而不是更多的創辦人表演。
模式 2：創辦人審查
以創辦人的視角審查你目前的專案：
1. 閱讀 README、CLAUDE.md、package.json、最近的提交
2. 推斷：這試圖成為什麼？
3. 評分：產品市場契合度訊號（0-10）
- 使用成長軌跡
- 留存指標（重複貢獻者、回訪使用者）
- 收入訊號（定價頁面、計費程式碼、Stripe 整合）
- 競爭護城河（什麼難以複製？）
4. 識別：能夠讓這個專案提升 10 倍的一件事
5. 標記：你正在建構但不重要的事情
模式 3：使用者旅程審計
繪製實際的使用者體驗：
1. 以新使用者身分複製/安裝產品
2. 記錄每一個摩擦點（令人困惑的步驟、錯誤、缺少的文件）
3. 為每個步驟計時
4. 與競爭對手的入門體驗比較
5. 評分：達到價值的時間（使用者多快獲得第一個成功體驗？）
6. 建議：入門流程的前三大修正
模式 4：功能優先級排序
當你有 10 個點子但需要選出 2 個：
1. 列出所有候選功能
2. 為每個功能評分：影響（1-5） × 信心（1-5） ÷ 努力（1-5）
3. 按 ICE 分數排序
4. 套用限制：資金跑道、團隊規模、依賴關係
5. 輸出：附有理由的優先級路線圖
輸出
所有模式輸出可立即行動的文件，而不是論文。每個建議都包含具體的下一步行動。
整合
搭配使用：
/browser-qa以驗證使用者旅程審計的發現/design-system audit進行視覺打磨評估/canary-watch進行上線後監控product-capability當產品簡報需要變成可實作的能力計畫時