From product-owner
Write user stories with Gherkin acceptance criteria, edge cases, anti-requirements, and ISC-validated criteria from a feature description or PRD section.
npx claudepluginhub hpsgd/turtlestack --plugin product-ownerThis skill is limited to using the following tools:
Write user stories for $ARGUMENTS.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Analyzes BMad project state from catalog CSV, configs, artifacts, and query to recommend next skills or answer questions. Useful for help requests, 'what next', or starting BMad.
Write user stories for $ARGUMENTS.
Follow every step below. Each story must be complete enough to hand directly to an engineer without additional conversation.
Before writing any stories, list every distinct user type involved. Do not use generic labels.
Anti-patterns (never use these):
Good user types are specific about role AND context:
For each user type, note:
Each story captures exactly one user behaviour. Apply this test: if the story has "and" in the action clause, it is two stories. Split it.
### US-[N]: [Short descriptive title]
**As a** [specific user type with context],
**I want** [concrete action the user takes — not what the system does],
**so that** [the value to the user — why they care, not how it works].
User type clause:
Action clause:
Value clause:
Every story must have acceptance criteria written in Gherkin format. Gherkin makes criteria unambiguous and directly translatable to automated tests.
Scenario: [Descriptive name of the scenario]
Given [precondition — the state of the world before the action]
When [action — what the user does]
Then [outcome — what the user observes]
When steps, split it.Given I am logged in is context. Given I click the login button is an action — put actions in When.Then the database is updated is not observable to the user. Then I see a confirmation message "Item saved" is observable.When I enter "john@example.com" is better than When I enter a valid email.Scenario: Successful password reset request
Given I am on the login page
And I have a registered account with email "user@example.com"
When I click "Forgot password"
And I enter "user@example.com" in the email field
And I click "Send reset link"
Then I see the message "Check your email for a reset link"
And an email is sent to "user@example.com" within 60 seconds
Scenario: Password reset with unregistered email
Given I am on the login page
When I click "Forgot password"
And I enter "unknown@example.com" in the email field
And I click "Send reset link"
Then I see the message "Check your email for a reset link"
And no email is sent
# Security: same message shown to prevent email enumeration
Every acceptance criterion (Gherkin scenario) must pass all three checks:
Can this scenario be verified without first executing another scenario? If Scenario B requires Scenario A to have run first, they are not independent — either merge them or restructure so B sets up its own preconditions in the Given block.
Does this scenario test exactly one behaviour? If the Then block asserts multiple unrelated things, split into separate scenarios. Multiple related assertions (e.g., "Then I see the item in the list And the count updates to 5") are fine if they are consequences of the same action.
Does this scenario cover the boundary? Check:
If any boundary is missing, add a scenario for it.
For every story, enumerate edge cases explicitly. Do not leave them implicit. Common categories:
| Category | Questions to answer |
|---|---|
| Empty state | What does the user see when there is no data yet? First-time experience? |
| Error handling | What happens on network failure? Timeout? Invalid input? Server error? |
| Permissions | What happens if the user lacks permission? Expired session? |
| Concurrency | What if two users act on the same item simultaneously? |
| Scale | What happens with 0 items? 1 item? 1,000 items? 100,000 items? |
| Accessibility | Can the entire flow be completed with keyboard only? With a screen reader? |
| Undo/recovery | Can the user reverse the action? What is the recovery path for mistakes? |
Write a Gherkin scenario for each edge case that could affect user experience. Minor edge cases (purely cosmetic at extreme scale) can be noted without full Gherkin.
List what this story deliberately does NOT cover. Anti-requirements prevent scope creep and make implicit exclusions explicit.
Format:
**Anti-requirements:**
- This story does NOT cover bulk operations — that is a separate story (US-[N])
- This story does NOT handle the admin workflow — admin stories are in US-[N] through US-[N]
- This story does NOT include email notifications — notifications are tracked in [reference]
Every anti-requirement should reference where the excluded behaviour IS tracked (another story, a future initiative, or "out of scope entirely").
Before finalising, validate each story against these size constraints:
Group related stories under a feature heading. Number stories sequentially.
# User Stories: [Feature Name]
## User Types
1. **[Type A]** — [one-line description with context]
2. **[Type B]** — [one-line description with context]
---
## [Feature Area 1]
### US-1: [Title]
**As a** [specific user type],
**I want** [action],
**so that** [value].
**Acceptance Criteria:**
\```gherkin
Scenario: [Happy path]
Given ...
When ...
Then ...
Scenario: [Error case]
Given ...
When ...
Then ...
Scenario: [Edge case]
Given ...
When ...
Then ...
\```
**Edge Cases:**
- [Edge case not covered by Gherkin scenarios, noted for awareness]
**Anti-requirements:**
- Does NOT cover [excluded behaviour] — tracked in [reference]
**Size:** [S/M/L]
---
Write the output to a file if writing more than 3 stories: docs/stories-[feature-name].md.
/product-owner:groom-backlog — groom the backlog to identify which items need user stories written./product-owner:write-prd — user stories implement requirements from the PRD. Reference the PRD for context.