identify-assumptions-existing
作者 phurynidentify-assumptions-existing 可幫你針對既有產品中的功能構想進行壓力測試，從價值、可用性、可行性與商業可行性四個面向找出高風險假設。它結合 PM、設計師與工程師的觀點，並加入反方辯證視角，用於策略規劃與開發前的風險檢視。
此技能評分 78/100，代表它很適合列入想針對既有產品進行結構化假設風險分析的目錄使用者。它的使用情境明確、觸發語言清楚，且有定義好的流程，能讓代理程式比起通用提示更少猜測地執行；但它仍缺少支援素材與更深入的操作範例。
- 針對既有產品中的功能構想壓力測試，觸發條件與範圍都很清楚
- 涵蓋價值、可用性、可行性與商業可行性的具體流程，並附信心程度與測試建議
- 沒有任何占位符標記；正文內容充實且具體，足以供代理程式使用
- 沒有支援檔案、參考資料或範例，因此使用者多半得依賴 SKILL.md 內容
- 沒有安裝指令或輔助資源，會限制上手速度與例外情境的引導
identify-assumptions-existing 概觀
identify-assumptions-existing 是一個產品探索技能，專門用來在你真正投入設計或開發之前，先對既有產品中的功能想法做壓力測試。它會透過內建的唱反調視角，從 Value、Usability、Viability、Feasibility 四個面向，幫你把提案背後那些高風險假設攤開來看。
這個 identify-assumptions-existing skill 最適合產品經理、設計師、工程師和創辦人使用：如果你要的不是一份漂亮的策略簡報，而是一張快速可用的假設地圖，它就很對味。當你在判斷某個功能值不值得做，或想找出一個看起來很有潛力的點子背後的隱性失敗點時，identify-assumptions-existing 會是很強的選擇。
它最大的價值在於提升決策品質：它會把討論從「聽起來不錯」推進到「要成立，前提到底是什麼？」這讓它特別適合用在 Strategic Planning、roadmap 初步篩選，以及研究前的風險檢視。
identify-assumptions-existing 的用途
當你已經有一個功能想法，並且需要把它放到真實世界的限制下驗證時，就用 identify-assumptions-existing skill。它的設計目的，是找出這個想法可能在哪些地方在市場、使用體驗、商業模式或實作層面上出問題。
誰適合安裝它
如果你常常把粗略的產品想法轉成可測試的假設，那就該安裝 identify-assumptions-existing。它最適合那些希望在功能提案變成 ticket、spec 或 experiment 之前，先有一套可重複的方法來挑戰它的團隊。
它的差異在哪裡
和一般的腦力激盪提示不同，identify-assumptions-existing 會要求模型從三種角色思考：PM、designer、engineer。這種跨職能的框架能更快找出盲點，並且針對每個假設產出更可執行的驗證方式。
如何使用 identify-assumptions-existing skill
安裝並觸發 identify-assumptions-existing
請使用來源中顯示的 repo 指令流程來安裝 identify-assumptions-existing：
npx skills add phuryn/pm-skills --skill identify-assumptions-existing
接著輸入一個針對既有產品的功能想法來呼叫這個 skill。你的輸入越具體，產出的假設清單就越有品質。
提供正確的輸入給 skill
identify-assumptions-existing usage 的模式，在你提供以下內容時效果最好：
- product 或 feature 名稱
- 目標使用者區隔
- 想達成的結果
- 功能想法本身
- 任何限制，例如平台、時程、法規要求或相依關係
較弱的 prompt 是：Analyze my feature.
較強的 prompt 是：Stress-test a dashboard export feature for SMB finance admins in our B2B app. Goal: reduce support tickets. Constraints: web only, two engineers, no new data warehouse.
依照正確順序閱讀來源檔案
若要進行 identify-assumptions-existing guide，請先從 SKILL.md 開始。如果未來 repository 擴充了內容，再檢查 README.md、AGENTS.md、metadata.json，以及任何 rules/、resources/、references/ 或 scripts/ 資料夾，補充脈絡。在這個 repo 裡，SKILL.md 是主要的唯一事實來源。
會讓輸出更好的工作流程
實務上比較有效的 identify-assumptions-existing usage 流程是：
- 說明產品情境與功能想法。
- 要求依 Value、Usability、Viability、Feasibility 分類的假設。
- 要求每個假設附上信心程度與驗證方式。
- 用輸出結果決定先驗證哪一項。
如果你是拿來做 Strategic Planning，請一併提供市場區隔、商業目標與上線限制，讓 skill 能把策略風險和 UX 或工程風險區分開來。
identify-assumptions-existing skill 常見問答
identify-assumptions-existing 只適用於既有產品嗎？
是，這正是它的設計定位。這個 skill 是為了在既有產品中對功能想法做壓力測試，不是拿來從零進行開放式概念發想的。
這和一般 prompt 有什麼不同？
一般 prompt 可能只是列出優點和缺點。identify-assumptions-existing skill 會更往前推一步，把風險整理成四個類別，並追問哪裡可能出錯、你有多有把握、以及該怎麼驗證。這讓輸出更容易直接拿去做決策。
identify-assumptions-existing 適合新手嗎？
可以，只要你能用白話描述產品、受眾和功能就行。你不需要先學會正式的假設地圖框架，也能把它用好；但你仍然需要足夠的背景資訊，讓模型能夠更務實地判斷取捨。
什麼時候不該用它？
如果你需要的是詳細的 UX 文案、實作程式碼，或最終上線計畫，就不要用 identify-assumptions-existing。它是一個辨識風險的 skill，因此最適合放在開發決策之前的上游階段使用。
如何改進 identify-assumptions-existing skill
提供更精準的情境
identify-assumptions-existing 的最大品質槓桿，在於你對使用者與商業目標描述得有多具體。如果你只說「加 AI 搜尋」，skill 只能猜很多事情；但如果你說「為客服人員加入 AI 搜尋，縮短重複性工單的回覆時間」，它產出的假設就會實用得多。
要求驗證方式，不只要風險
來源已經要求這個 skill 同時列出可能出錯的地方與驗證方式，所以不要只停在風險描述。請主動要求像是訪談、原型測試、log 檢視，或內部 dogfood 檢查這類輕量驗證想法。這樣輸出才會從評論變成真正可用的規劃素材。
把產品風險和交付風險分開
最有價值的 identify-assumptions-existing skill 輸出，通常會把使用者價值、採用阻力、商業限制和技術可行性分開看。如果你的 prompt 把這些混成一個模糊要求，答案就會比較難直接拿來做決策。請明確寫出限制，讓 skill 能先排序最危險的假設。
在第一次結果後再迭代
先用第一次輸出縮小範圍，接著再用更聚焦的功能切片重新跑一次 skill。舉例來說，如果第一次結果顯示 Usability 與整合風險較高，就改問只看 onboarding flow，或只看 data-sync dependency。這通常是把 Strategic Planning 討論磨得更清楚、也最快的方法。