user-story
作者 deanpetersuser-story 技能可協助你把產品需求轉成一則可直接交付開發的故事，並使用 Mike Cohn 寫法與 Gherkin 驗收條件。適合用在更清楚的交接、更好的估算，以及為技術寫作與產品團隊建立更精準的 user-story 指南。
這個技能獲得 84/100，代表它很適合放進目錄，供想要聚焦型 user-story 建立器的使用者選用。此 repository 提供了足夠的觸發語句、格式指引與範例輸出，能讓 agent 在使用時少掉很多猜測，比起一般通用提示詞更好上手；不過它還不是一套完全打磨好、端到端的工作流程套件。
- 觸發與意圖清楚：像是「使用 Mike Cohn 格式與 Gherkin 驗收條件建立 user stories」以及「Use when」說明，讓呼叫方式很直接。
- 結構上很實用：範本、範例，以及針對單一 When/Then 配對的規則，讓 agent 有明確的輸出形狀可依循。
- 額外執行支援：內含的 Python script 與可重複使用的 'Given' 輸入，有助於提升重現性並降低格式歧義。
- 沒有安裝指令或套件中繼資料，因此使用者可能需要自行把它接到既有工作流程中。
- 文件在格式方面寫得不錯，但對邊界情況、驗證規則，以及如何在超出簡短說明時拆分 stories 的指引相對較少。
user-story 概觀
user-story skill 能幫你把模糊的產品需求，整理成一則可直接交付開發的 user story，並使用 Mike Cohn 的寫法與 Gherkin 驗收條件。它最適合產品經理、技術寫作者、分析師，以及需要把 AI 融入工作流程的人，用來產出乾淨的交付物，而不是一段鬆散想法或完整規格書。
這個 skill 真正要解決的是清晰度：把使用者、動作、價值，以及可測試的結果定義出來，整理成工程與 QA 都能直接使用的格式。相較於一般 prompt，user-story skill 提供可重複套用的結構與更明確的範圍；當你想減少含糊不清的故事、也想減少審查輪次時，這點尤其重要。
適合產品到工程交接的情境
當你已經知道需求方向，但需要把它表達得精簡、可測試、也方便估工時時，就適合用這個 user-story skill。它特別適合把 PRD 筆記、利害關係人需求、以及 roadmap 條目，轉成能支援實作的 story。
user-story 有什麼不同
它的關鍵差異，在於把標準 user story 格式和明確的 acceptance criteria 結合在一起。這代表輸出不只是好讀，還更容易驗證、拆分與討論。當你需要在多個項目之間維持一致的 story 品質時，user-story skill 會比自由發揮式 prompt 更實用。
什麼情況最適合用 user-story
適合用 user-story 處理功能開發、流程調整、導入步驟，以及其他範圍明確、且一個使用者動作對應一個可衡量結果的需求。對支援產品文件的 Technical Writing 團隊來說，它也很合適，因為它能讓產品意圖與成功條件保持一致。
如何使用 user-story skill
安裝 user-story skill
安裝指令：
npx skills add deanpeters/Product-Manager-Skills --skill user-story
安裝完成後，先讀 skills/user-story/SKILL.md，再看 template.md 與 examples/sample.md，了解預期的結構與品質標準。如果你打算自動化產生 story，也建議檢查 scripts/user-story-template.py，確認這個 skill 期待哪些欄位。
提供正確的輸入
user-story skill 最適合的輸入，是具體的使用者、單一想完成的動作，以及背後的商業或使用者價值。好的輸入會像這樣：
- Persona:
trial user,support agent,account owner - Action:
reset my password,export invoices,approve a request - Outcome:
so that I can regain access quickly
像「改善 onboarding」這類模糊輸入，通常會產生空泛的結果，因為它沒有交代是誰、做什麼、以及為什麼要做。
使用符合 template 的 prompt
若要把 user-story 用得最好，請一次只要求一則 story，並把 skill 原本設計要填寫的欄位一併提供。好的 prompt 可以是：
“Write a user-story for a trial user who wants to connect their Google account so that they can sign in faster. Include one summary, the use case, and one scenario with one Given/When/Then set.”
這樣會比直接說「寫一則關於登入的 user story」更有效，因為前者提供了範圍與結果，能提升 acceptance criteria 的品質。
按這個順序閱讀 repo 檔案
如果你要實際做 user-story guide 相關工作，建議依序看：
SKILL.md：寫作規則與概念框架template.md：確切的 Markdown 結構examples/sample.md：好與壞的 story 品質對照scripts/user-story-template.py：若要重複產生內容
這個順序能讓你在自己動筆前，先掌握格式與防呆規則。
user-story skill 常見問答
user-story 只適合產品經理嗎？
不是。user-story skill 也很適合技術寫作者、分析師、設計師與工程師，只要他們需要一個可共用的規劃或實作交付物。任何需要把意圖轉成可測試 story 的人，都能使用它。
user-story 和一般 prompt 有什麼不同？
一般 prompt 可能會產生一段看起來像 story 的文字，但 user-story skill 會推著你維持一致的結構：summary、persona、action、outcome、scenario、以及 acceptance criteria。當 story 需要審查、估算或拆分時，這種一致性就很重要。
user-story 對新手友善嗎？
是，只要你能描述使用者、目標與想要的結果，就能上手。新手最常犯的錯誤，是先講解法，而不是使用者問題。如果你能回答「誰需要這個、為什麼需要」，這個 skill 就很適合你。
什麼時候不該用 user-story？
不要把 user-story 用在大型策略文件、多步驟 epic、架構決策，或是有很多相依結果的功能規格上。如果需要多種行為，通常代表這則 story 太大，應該先拆開再進入實作。
如何優化 user-story skill
提供更好的原始材料
品質提升最大的一步，就是把輸入寫得更精準。請加入確切的 persona、觸發情境、想要的結果，以及會影響 story 的任何限制，例如平台、角色或權限層級。像「billing admin on desktop exports invoice history」就遠比「user downloads data」有用得多。
注意範圍膨脹
user-story 輸出常見的失敗模式，是想把多個結果硬塞進同一則 story。如果你的草稿需要多條 When/Then 路徑、不同的使用者動作，或混合不同使用者類型，就應該先拆分。repo 裡的 template 與 examples 強調一則 story 對應一個主要行為，是有原因的。
強化 acceptance criteria
如果第一版看起來太鬆，請為 Given 狀態補進更具體的情境，並把 Then 的成功條件寫得更精準。好的 acceptance criteria 描述的是審查者看得到的結果，而不只是系統「應該支援」什麼。這在使用 user-story for Technical Writing 時尤其重要，因為一旦有模糊地帶，後續文件會更難寫。
從審查意見再迭代
先把第一版當草稿，再根據 review 意見修正 persona、收緊 outcome，並刪掉任何屬於實作猜測的 acceptance criteria。如果審查者會問「這是給誰用的？」或「要怎麼測？」，就把這些問題回灌到下一輪 prompt，讓 user-story skill 產出更可用的修正版。