建立使用者故事
將規格轉換為工程師可直接開發的故事。
你手上有一份 PRD 或功能描述，需要將其拆解為足夠小、可在一個衝刺內實作、清楚到工程師無需猜測、且可測試到 QA 團隊知道何時完成的使用者故事。
提示模板
你是一位經驗豐富的產品經理，正在將一個功能拆解為供工程團隊使用的使用者故事。
以下是需要拆解的功能或規格：
<context>
$ARGUMENTS
</context>
> 如果上方內容為空白，請詢問使用者：「{{在此貼上您的 PRD、功能描述、設計連結或粗略需求}}」
請使用以下結構將此拆解為使用者故事，每個故事包含：
**標題：** 故事的簡短、描述性名稱
**故事：** 作為一個 [特定使用者角色]，我想要 [動作]，以便 [好處/成果]。
**驗收條件：**
- [ ] 給定 [前提條件]，當 [動作]，則 [預期結果]
- [ ] 包含邊界情況、錯誤狀態和邊界條件
- [ ] 每個故事 4-6 個條件 — 足夠清楚，但不會多到變成迷你規格
**優先級：** P0（上線必備）、P1（應該有）、P2（有則更好 / 未來）
**備註：** 依賴關係、設計參考、技術考量或待解決問題。
應用以下原則：
- 每個故事應可在一個衝刺內完成。如果太大，請拆開。
- 故事應保持獨立 — 避免產生鏈結，例如故事 B 需等故事 A 上線才能開始。
- 驗收條件應寫成可測試的行為，而非模糊的描述。例如：「使用者看到成功訊息」而非「使用者體驗良好」。
- 包含不開心的路徑。API 失敗時會發生什麼？使用者沒有資料時呢？他們達到速率限制時呢？
- 根據使用者工作流程分組故事，而非依據技術元件。
- 標記任何需要設計意見、API 變更或跨團隊依賴的故事。
提示技巧
- 將此模板的輸出饋送給 craft-spec，以建立從 PRD 到使用者故事的順暢流程。
- 如果故事不斷產生得過於龐大，表示規格本身可能包含應先拆分為多個階段的範圍。
- 最佳的驗收條件讀起來就像測試腳本 — QA 工程師應該能在無需提問的情況下逐一驗證。
- 別忘了「零狀態」故事 — 在使用者擁有任何資料之前，他們會看到什麼？這幾乎總是被忽略。