SKILL.md
readonlyread-only
name
product-lens
description
使用此技能在開始建構前驗證「為什麼」，執行產品診斷，並在需求變成實作合約前對產品方向進行壓力測試。
Product Lens — 先想清楚再動手
這個領域負責產品診斷，而不是撰寫可實作的規格文件。
如果使用者需要一份完整的 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、最近的 commits
2. 推斷：這個專案想成為什麼？
3. 評分：產品市場契合度訊號（0-10）
- 使用成長趨勢
- 留存指標（重複貢獻者、回訪使用者）
- 營收訊號（定價頁面、計費程式碼、Stripe 整合）
- 競爭護城河（什麼是難以複製的？）
4. 找出：能讓這個專案成長 10 倍的那一件事
5. 標記：你正在建構但其實不重要的東西
模式 3：使用者旅程稽核
繪製實際的使用者體驗：
1. 以新使用者的身分 clone/安裝產品
2. 記錄每個摩擦點（令人困惑的步驟、錯誤、缺少的文件）
3. 計時每個步驟
4. 與競爭對手的入門流程比較
5. 評分：達到價值的時間（使用者多久能獲得第一次成功？）
6. 建議：改善入門流程的前 3 個修正
模式 4：功能優先級排序
當你有 10 個點子但只能選 2 個時：
1. 列出所有候選功能
2. 對每個功能評分：影響力（1-5）× 信心度（1-5）÷ 投入（1-5）
3. 按 ICE 分數排序
4. 套用限制：資金、團隊規模、相依性
5. 輸出：附有理由的優先級路線圖
輸出
所有模式都輸出可執行的文件，而不是長篇大論。每個建議都有具體的下一步。
整合
搭配使用：
/browser-qa驗證使用者旅程稽核的發現/design-system audit進行視覺品質評估/canary-watch進行上線後監控product-capability當產品簡報需要變成可實作的能力計畫時
