// week 01 · day 03 · wed

Break a Spec Into Shippable Stories.

$/generate-tasks · ~20 min
// 01 · what it does

Spec to backlog-ready stories.

generate-tasks decomposes a PRD or spec into shippable stories, each scoped to a single deployable unit with Given/When/Then acceptance criteria. It produces an ordered story set, a dependency graph, and an implementation sequence — plus a list of items flagged for PM input: edge cases the spec didn't resolve, data requirements that need explicit instrumentation, and product decisions embedded in acceptance criteria that only the PM can make.

The transition from spec to backlog is where scope and quality erode. Stories get written without acceptance criteria, data requirements get forgotten until after launch, and engineers make product decisions because the spec didn't make them. generate-tasks closes that gap systematically — and is explicit about what remains unresolved. Every flag it raises is a conversation you'd otherwise have mid-sprint.

Day 3 follows Day 2 because the PRD you wrote and reviewed is the natural input. You'll see how a document you authored translates into implementation units — and where the spec's gaps become story-level ambiguities. The stories you generate today are what a sprint plan would draw from on Day 4.

// 02 · sample prompts

Two ways in.

prompt.basic.txt 
/generate-tasks

Break this feature description into shippable stories:

We want to add a difficulty rating system so adventurers can filter search results by skill level. Guides set the difficulty level on their listing (beginner, intermediate, advanced). Adventurers can filter by difficulty on search. The filter should persist across sessions.
prompt.advanced.txt 
/generate-tasks

Use the guide listing setup guidance PRD from Day 1 as input. Decompose it into sprint-ready stories.

Team context:
- 6 engineers: 2 iOS, 1 Android, 2 backend, 1 QA
- 18–22 story points per sprint
- Single Android engineer — Android work must be sequenced serially, it cannot run in parallel with other Android tickets
- Listing object is owned by Jordan Lee's Guide Experience squad; any changes to listing schema require cross-squad coordination and a separate backend ticket owned by that squad
- Definition of ready requires: AC in Given/When/Then, Figma link for user-facing changes, named analytics events, no unresolved dependencies, estimated

Flag:
- Any story that requires a data tracking counterpart that isn't explicit in the PRD
- Any story where the AC requires a PM decision not yet resolved in the spec
- Any story that touches the shared listing object (needs Jordan's squad coordination)
- Any Android-specific story (serialized, plan accordingly)

[paste the Day 1 PRD here, or describe the guide listing setup guidance feature in detail]
// 03 · reflection

Three questions.

  1. 01Which stories were split differently than you would have split them — and do you agree with the dependency ordering the skill produced?
  2. 02What data stories did the skill add that weren't explicit in the PRD — and would you have remembered them before launch?
  3. 03Where did the skill flag PM input needed, and were those the right calls to escalate?
← Day 2 Day 4 →