job-stories

job-stories 技能概覽

job-stories 技能可幫你把零散的產品想法整理成 JTBD 風格的 job story，格式為：「當 [情境] 發生時，我想要 [動機]，以便我可以 [結果]。」當你需要更清楚的 backlog 項目、更好的需求規劃，或是在解決方案設計前先用一致的方式描述使用者情境時，它特別有用。

這個 job-stories 技能最適合用在什麼情況

當你已經知道功能範圍，但需要把背後的使用者問題釐清得更準時，就適合用 job-stories 技能。它很適合產品經理、設計師、分析師，以及從設計連結、功能提示或利害關係人筆記起草需求的 AI 代理。

它和一般提示詞有什麼不同

它的主要價值在於結構：會引導模型先從情境與動機出發，再補上和可觀察結果掛勾的驗收條件。當團隊重視上下文、意圖與可測試結果時，job-stories 會比單純的「寫使用者故事」提示更實用。

什麼情況下特別適合

這個技能很適合 job-stories for Requirements Planning、前期探索前的 backlog 形塑，以及把功能概念轉成以使用者為中心的故事。如果你只需要幾句沒有驗收條件的快速點子，或你的團隊完全採用另一種需求格式，它就沒那麼適合。

如何使用 job-stories 技能

正確安裝並觸發 job-stories

在 job-stories install 的情境下，請使用目錄預設的技能載入器：npx skills add phuryn/pm-skills --skill job-stories。接著再輸入足夠資訊，讓模型能推斷使用者情境、產品範圍與預期結果。只給一個功能名稱通常太薄弱。

提供正確的輸入格式

這個技能在提示詞包含產品、功能、使用者情境與任何設計參考時表現最好。較好的起手式像是：「根據這些使用者情境：[context]，為 [product] 的 [feature] 功能產出 job stories。請使用設計連結 [design]，並聚焦在結果，不要聚焦角色。」這會比「幫我寫 checkout 的 job stories」更有效。

先讀這些檔案

先從 SKILL.md 開始，因為裡面包含工作流程、故事模板與必填參數。如果你的本機副本還有相鄰文件，接著讀 README.md、AGENTS.md、metadata.json，以及任何 rules/、resources/、references/ 或 scripts/ 資料夾。在這個 repo 裡，SKILL.md 是主要依據，所以要掃讀的額外內容不多。

能明顯提升輸出的工作流程建議

建議分兩輪使用這個技能：第一輪先產出原始 job stories，第二輪再依你的真實限制做修訂。如果第一次的輸出太空泛，就補上更具體的情境、決策點與設計連結。如果故事過度偏向角色，請要求改寫成以觸發條件與想達成的進展為核心，而不是 persona。

job-stories 技能 FAQ

job-stories 適合 Requirements Planning 嗎？

適合。job-stories 原本就是為 requirements planning 設計的，當你想要的是以使用者為中心的 backlog 項目，而不是功能先行的 ticket 時，它特別好用。它能把範疇轉成情境、動機與結果，讓你更容易和設計、工程團隊討論。

使用時一定要提供設計檔嗎？

不用，但如果有提供，job-stories 技能會更強。Figma 或 Miro 連結可以幫模型把驗收條件錨定到可見行為，而不是自行腦補假設。

這和一般 user stories 有什麼不同？

一般提示詞常會產生以角色為中心的模板，或只是很表面的驗收條件。job-stories 技能更適合在意的是使用者為什麼要採取行動、他們需要什麼結果，而不只是系統應該做什麼的情境。

這個技能對新手友善嗎？

是，只要你能用白話描述功能就可以。主要限制在於輸入品質：新手如果能提供一兩個真實的使用者情境，而不是一個很寬泛的功能主題，通常會得到更好的結果。

如何改進 job-stories 技能

提供更豐富的情境，不要只給功能名稱

品質提升最大的一步，就是補上具體上下文。與其只寫「notifications」，不如給像「當使用者在旅行中錯過付款提醒時」這種情境，讓 job-stories 技能能產出更有意義的情境、動機與結果串連。

補上限制與成功訊號

如果你在意無障礙、時效、裝置限制或核准流程，請一開始就寫進去。當提示詞清楚說明成功長什麼樣子、哪些行為必須可觀察、什麼情況會讓故事失敗時，驗收條件通常會更扎實。

針對失敗模式要求修訂

如果第一版太籠統，請要求減少角色參照、增加情境細節。如果太偏解法，請要求改成避免實作語言的 job stories。如果範圍太大，就把功能縮到一次只處理一個使用者目標。

把第一版輸出當成規劃草稿

第一輪輸出應該視為探索工具，而不是最終需求。job-stories 最好的用法，是反覆調整到故事和你的 roadmap、設計與工程限制一致，然後刪掉任何對 Requirements Planning 或交付沒有幫助的內容。