Skill-Details
user-story
Core PM backlog and requirements-writing capability.
Vor Nutzung prüfen
Die automatische Prüfung bewertet Relevanz, nicht Sicherheit oder Empfehlung. Lies vor der Nutzung die Quellanweisungen.
SKILL.md
Dieser Auszug wurde bei der Prüfung gespeichert. Die externe Quelle enthält die vollständige und aktuelle Version.
--- name: user-story argument-hint: "[feature or user need]" description: Create user stories with Mike Cohn format and Gherkin acceptance criteria. Use when turning user needs into development-ready work with clear outcomes and testable conditions. intent: >- Create clear, concise user stories that combine Mike Cohn's user story format with Gherkin-style acceptance criteria. Use this to translate user needs into actionable development work that focuses on outcomes, ensures shared understanding between product and engineering, and provides testable success criteria. type: component theme: pm-artifacts best_for: - "Writing user stories with proper acceptance criteria" - "Converting requirements into development-ready stories" - "Establishing story quality standards across your team" scenarios: - "I need to write a user story for a new notification system in our B2B SaaS app" - "Convert this PRD requirement into a properly formatted user story with Gherkin acceptance criteria" estimated_time: "5-10 min" --- ## Purpose Create clear, concise user stories that combine Mike Cohn's user story format with Gherkin-style acceptance criteria. Use this to translate user needs into actionable development work that focuses on outcomes, ensures shared understanding between product and engineering, and provides testable success criteria. This is not a feature spec—it's a conversation starter that captures *who* benefits, *what* they're trying to do, *why* it matters, and *how* you'll know it works. ## Input **Works best with:** The feature or user need the story captures. **Also useful:** The user role, the outcome they want, and edge cases the acceptance criteria must cover. Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended `ARGUMENTS:` line — counts as answers already given. Use it and skip whatever it covers; don't re-ask. **Arriving empty-handed? That works too.** The skill asks who the user is and what they're trying to accomplish before drafting story and Gherkin criteria. **Example invocation:** `Write user stories for password reset via SMS for our banking app — include the lockout edge case.` ## Key Concepts ### The Mike Cohn + Gherkin Format A user story combines: **Use Case (Mike Cohn format):** - **As a** [user persona/role] - **I want to** [action to achieve outcome] - **so that** [desired outcome] **Acceptance Criteria (Gherkin format):** - **Scenario:** [Brief description of the scenario] - **Given:** [Initial context or preconditions] - **and Given:** [Additional preconditions] - **When:** [Event that triggers the action] - **Then:** [Expected outcome] ### Why This Structure Works - **User-centric:** Forces focus on who benefits and why - **Outcome-focused:** "So that" emphasizes the value delivered, not just the action - **Testable:** Gherkin acceptance criteria are concrete and verifiable - **Conversational:** Story is the opening for discussion, not the final spec - **Shared language:** Product, engineering, and QA all understand the format ### Anti-Patterns (What This Is NOT) - **Not a task:** "As a developer, I want to refactor the database" (this is a tech task, not user value) - **Not a feature list:** "I want dashboards, reports, and analytics" (this is too big—needs splitting) - **Not vague:** "I want a better experience" (unmeasurable, no clear outcome) - **Not a contract:** Stories are placeholders for conversation, not locked-in specs ### When to Use This - Translating user needs into development work - Backlog grooming and sprint planning - Communicating value to engineering and design - Ensuring testable acceptance criteria exist before development ### When NOT to Use This - For pure technical debt or refactoring (use engineering tasks instead) - When stories are too large (split first—see `skills/user-story-splitting/SKILL.md`) - Before understanding the user problem (write a problem statement first) --- ## Application #Vollständige Quelle auf GitHub lesen (öffnet externe Seite)