Prompt file imported from parolkar/awesome-ai-driven-product-engineering (.windsurf/workflows/generate-story.md). Copyright stays with the author.

Workflow for Generating User Story

Name: generate-story
Author: parolkar

User Story Fundamentals

A user story is a short description of functionality from a user's perspective. It represents valuable, small functionality for agile planning and prioritization.

Core Format:

As a [user/persona],
I want [capability/feature],
so that [benefit/value].

INVEST Model Checklist:

Independent: Stands alone without dependencies
Negotiable: Not rigid; details can be discussed
Valuable: Delivers clear user benefit
Estimable: Team can size the effort
Small: Fits in single iteration
Testable: Can be verified with clear criteria

Acceptance Criteria

Use Gherkin syntax (Given/When/Then) to define testable conditions:

Scenario: [Descriptive title]
  Given [precondition/context]
  When [user action]
  Then [expected outcome]

Example:

As a mobile bank customer,
I want to see balance on my accounts,
So that I can make better informed decisions about my spending.

Scenario: Show balance after login
  Given I have logged into the mobile banking app
  When I navigate to the accounts page
  Then I should see the balance for each of my accounts

Best Practices

Focus on single feature - One incremental improvement per story
User-centered perspective - Address real user needs
Clear titles - Include specific user/persona
Include business rationale - Always have a clear "so that"
Define acceptance criteria - Outcomes, not implementations
Keep stories small - Split if too complex
Avoid technical details - Focus on what, not how
Add supporting materials - Attach mockups or flow diagrams if helpful
Use appropriate story type - Features for user functionality, Bugs for defects, Chores for technical tasks

Quick Checklist

Clear persona identified
Need and value clearly stated
Meets INVEST criteria
Acceptance criteria in Given/When/Then format
No implementation details specified
Appropriately sized
Edge cases considered
Additional context provided if needed
Correct story type used

# Workflow for Generating User Story ## User Story Fundamentals A **user story** is a short description of functionality from a user's perspective. It represents valuable, small functionality for agile planning and prioritization. **Core Format:** ``` As a [user/persona], I want [capability/feature], so that [benefit/value]. ``` **INVEST Model Checklist:** - **I**ndependent: Stands alone without dependencies - **N**egotiable: Not rigid; details can be discussed - **V**aluable: Delivers clear user benefit - **E**stimable: Team can size the effort - **S**mall: Fits in single iteration - **T**estable: Can be verified with clear criteria ## Acceptance Criteria Use Gherkin syntax (Given/When/Then) to define testable conditions: ``` Scenario: [Descriptive title] Given [precondition/context] When [user action] Then [expected outcome] ``` **Example:** ``` As a mobile bank customer, I want to see balance on my accounts, So that I can make better informed decisions about my spending. Scenario: Show balance after login Given I have logged into the mobile banking app When I navigate to the accounts page Then I should see the balance for each of my accounts ``` ## Best Practices 1. **Focus on single feature** - One incremental improvement per story 2. **User-centered perspective** - Address real user needs 3. **Clear titles** - Include specific user/persona 4. **Include business rationale** - Always have a clear "so that" 5. **Define acceptance criteria** - Outcomes, not implementations 6. **Keep stories small** - Split if too complex 7. **Avoid technical details** - Focus on what, not how 8. **Add supporting materials** - Attach mockups or flow diagrams if helpful 9. **Use appropriate story type** - Features for user functionality, Bugs for defects, Chores for technical tasks ## Quick Checklist - [ ] Clear persona identified - [ ] Need and value clearly stated - [ ] Meets INVEST criteria - [ ] Acceptance criteria in Given/When/Then format - [ ] No implementation details specified - [ ] Appropriately sized - [ ] Edge cases considered - [ ] Additional context provided if needed - [ ] Correct story type used

{ "prompt": "# Workflow for Generating User Story \n\n## User Story Fundamentals\nA **user story** is a short description of functionality from a user's perspective. It represents valuable, small functionality for agile planning and prioritization.\n\n**Core Format:**\n```\nAs a [user/persona],\nI want [capability/feature],\nso that [benefit/value].\n```\n\n**INVEST Model Checklist:**\n- **I**ndependent: Stands alone without dependencies\n- **N**egotiable: Not rigid; details can be discussed\n- **V**aluable: Delivers clear user benefit\n- **E**stimable: Team can size the effort\n- **S**mall: Fits in single iteration\n- **T**estable: Can be verified with clear criteria\n\n## Acceptance Criteria\nUse Gherkin syntax (Given/When/Then) to define testable conditions:\n\n```\nScenario: [Descriptive title]\n Given [precondition/context]\n When [user action]\n Then [expected outcome]\n```\n\n**Example:**\n```\nAs a mobile bank customer,\nI want to see balance on my accounts,\nSo that I can make better informed decisions about my spending.\n\nScenario: Show balance after login\n Given I have logged into the mobile banking app\n When I navigate to the accounts page\n Then I should see the balance for each of my accounts\n```\n\n## Best Practices\n1. **Focus on single feature** - One incremental improvement per story\n2. **User-centered perspective** - Address real user needs\n3. **Clear titles** - Include specific user/persona\n4. **Include business rationale** - Always have a clear \"so that\"\n5. **Define acceptance criteria** - Outcomes, not implementations\n6. **Keep stories small** - Split if too complex\n7. **Avoid technical details** - Focus on what, not how\n8. **Add supporting materials** - Attach mockups or flow diagrams if helpful\n9. **Use appropriate story type** - Features for user functionality, Bugs for defects, Chores for technical tasks\n\n## Quick Checklist\n- [ ] Clear persona identified\n- [ ] Need and value clearly stated \n- [ ] Meets INVEST criteria\n- [ ] Acceptance criteria in Given/When/Then format\n- [ ] No implementation details specified\n- [ ] Appropriately sized\n- [ ] Edge cases considered\n- [ ] Additional context provided if needed\n- [ ] Correct story type used", "variables": [], "notes": "This is to generate stories as per https://github.com/parolkar/awesome-ai-driven-product-engineering/blob/main/PROMPTS/parolkar_user_story_prompt.md", "metadata": { "source": { "provider": "github-windsurf-workflows", "repository": "https://github.com/parolkar/awesome-ai-driven-product-engineering", "path": ".windsurf/workflows/generate-story.md", "ref": "8804057a48f0a866e4a27232f1893ba0a450e012", "url": "https://github.com/parolkar/awesome-ai-driven-product-engineering/blob/8804057a48f0a866e4a27232f1893ba0a450e012/.windsurf/workflows/generate-story.md", "key": "parolkar/awesome-ai-driven-product-engineering/.windsurf/workflows/generate-story.md" } } }

generate-story

About

Workflow for Generating User Story

User Story Fundamentals

Acceptance Criteria

Best Practices

Quick Checklist

Use it

Manifest

Reviews