pm-skills/pm-execution/commands/write-stories.md

description, argument-hint

description	argument-hint
Break a feature into backlog items — user stories, job stories, or WWA format with acceptance criteria	[user|job|wwa] <feature description or PRD>

/write-stories -- Backlog Item Generator

Break a feature into well-structured backlog items. Choose from three formats based on your team's preference, each with full acceptance criteria.

Invocation

/write-stories user Allow users to export reports as PDF and CSV
/write-stories job Notification system for task deadlines
/write-stories wwa Dark mode for the mobile app
/write-stories [upload a PRD or feature spec]      # asks format preference
/write-stories                                      # asks for feature and format

Formats

User Stories

Format: "As a [user type], I want [capability], so that [benefit]" Apply the user-stories skill:

• Follow the 3 C's: Card (brief), Conversation (context), Confirmation (acceptance criteria)
• Validate against INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable
• Include design links or mockup references where relevant

Job Stories

Format: "When [situation], I want to [motivation], so I can [outcome]" Apply the job-stories skill:

• Focus on the situation and context, not the user role
• Ground in real user scenarios observed in research
• Ideal for JTBD-oriented teams

WWA (Why-What-Acceptance)

Format: Why [strategic context] → What [deliverable] → Acceptance [criteria] Apply the wwas skill:

• Includes strategic reasoning (why we're building this)
• Produces independent, valuable, testable items
• Good for cross-functional teams that need business context

Workflow

Step 1: Accept the Feature

Accept in any form: PRD, feature description, user research finding, or verbal idea. If a PRD is provided, extract the requirements to decompose.

Step 2: Determine Format

If not specified in the invocation, ask:

• "Which format does your team use? User stories, Job stories, or WWA?"
• If unsure, recommend user stories as the default

Step 3: Decompose the Feature

• Break the feature into 5-15 independent stories (small enough to complete in one sprint)
• Ensure each story is independently valuable (delivers user value on its own)
• Order by dependency and priority
• Write 3-5 acceptance criteria per story
• Flag stories that need design input or technical spikes

Step 4: Generate Stories

## Backlog: [Feature Name]

**Format**: [User Stories / Job Stories / WWA]
**Total stories**: [count]
**Estimated total effort**: [if possible]

### Stories

#### Story 1: [Short title]
**[The story in chosen format]**

Acceptance Criteria:
- [ ] [Criterion 1]
- [ ] [Criterion 2]
- [ ] [Criterion 3]

Priority: [P0/P1/P2] | Effort: [S/M/L] | Dependencies: [none or list]

---
[Repeat for each story]

### Story Map
[Visual ordering: must-have → should-have → nice-to-have]

### Technical Notes
[Cross-cutting concerns: API changes, data migration, infrastructure]

### Open Questions
[Things that need answers before implementation can start]

Save as markdown.

Step 5: Offer Next Steps

• "Want me to generate test scenarios for these stories?"
• "Should I create dummy data for development and testing?"
• "Want me to estimate sprint capacity for these stories?"
• "Should I convert to a different format (user stories ↔ job stories ↔ WWA)?"

Notes

• One story = one deployable unit of value — if it needs another story to be useful, they should be combined
• Acceptance criteria should be testable by QA without additional interpretation
• Error handling and edge cases deserve their own stories, not bullet points within a happy-path story
• If the feature is large (15+ stories), suggest grouping into epics or phases
• Flag any story that requires a spike (technical investigation before estimation is possible)