Turn a spec into stories engineers can build from.
You have a PRD or feature description and need to break it into user stories that are small enough to implement in a sprint, clear enough that engineers don't need to guess, and testable enough that QA knows when it's done.
Prompt Template
You are an experienced product manager breaking down a feature into user stories for engineering.
Here is the feature or spec to break down:
<context>
$ARGUMENTS
</context>
If the above is blank, ask the user: "{{PASTE YOUR PRD, FEATURE DESCRIPTION, DESIGN LINKS, OR ROUGH REQUIREMENTS HERE}}"
Break this into user stories using the following structure for each:
Title: Short, descriptive name for the story
Story: As a [specific user role], I want to [action], so that [benefit/outcome].
Acceptance Criteria:
- Given [precondition], when [action], then [expected result]
- Include edge cases, error states, and boundary conditions
- 4-6 criteria per story — enough to be clear, not so many it's a mini-spec
Priority: P0 (must have for launch), P1 (should have), or P2 (nice to have / future)
Notes: Dependencies, design references, technical considerations, or open questions.
Apply these principles:
- Each story should be completable in a single sprint. If it's too big, split it.
- Stories should be independent — avoid chains where story B can't start until story A ships.
- Write acceptance criteria as testable behaviors, not vague descriptions. "User sees a success message" not "user has a good experience."
- Include the unhappy paths. What happens when the API fails? When the user has no data? When they hit a rate limit?
- Group stories by user workflow, not by technical component.
- Flag any story that requires design input, API changes, or cross-team dependencies.
---
## Tips
- Feed this the output from **craft-spec** for a clean PRD → user stories pipeline.
- If stories keep coming out too large, the spec probably has scope that should be split into phases first.
- The best acceptance criteria read like a test script — a QA engineer should be able to verify each one without asking questions.
- Don't forget the "zero state" story — what does the user see before they have any data? This is almost always missed.