{{PREAMBLE}}

Story Generation Mode

Philosophy

User stories are not tasks. They are not implementation instructions. They are promises to the user about what they'll be able to do.

A good story answers one question: "What can the user do after this is done that they couldn't do before?" If the answer is "nothing user-visible," it's either a tech debt story (valid, but label it) or a task masquerading as a story (rewrite it).

The INVEST test — every story must be:

• Independent — can be built without completing other stories first (minimize dependencies)
• Negotiable — describes the outcome, not the implementation
• Valuable — delivers value to the user or the business (not "set up database table")
• Estimable — team can estimate the effort (if they can't, the story is too vague)
• Small — completable in one sprint (if not, break it down)
• Testable — clear criteria for "done"

Input Modes

Ask the user (via AskUserQuestion):

What are we generating stories from?

RECOMMENDATION: Choose A if you have a PRD. Stories derived from a structured PRD are higher quality.

A) A PRD or spec document — I'll share it B) A feature description — let me explain what we're building C) A conversation we just had — generate from context above D) An existing backlog — I need to break down / refine stories

Step 1: Epic Definition

Before individual stories, define the epic(s):

EPIC: [Title]
═════════════
Goal:        [One sentence — what user outcome does this epic deliver?]
Success:     [How do we know this epic is "done"? Link to PRD metrics if available]
User:        [Primary user for this epic]
Scope:       [What's in / what's out for this epic specifically]
Dependencies:[Other epics or external dependencies]
Est. size:   [T-shirt: S/M/L/XL — relative to team's velocity]

Epics should be completable in 1-3 sprints. If an epic is bigger than 3 sprints, break it into multiple epics. If it's smaller than 1 sprint, it's probably just a story.

Step 2: Story Generation

For each story within the epic:

STORY [EPIC-N]: [Title]
───────────────────────
As a [specific user role],
I want to [specific action],
so that [specific outcome/value].

ACCEPTANCE CRITERIA:
Given [precondition],
When [action],
Then [expected result].

Given [precondition],
When [action],
Then [expected result].

EDGE CASES:
- What if [empty state]? → [Expected behavior]
- What if [error condition]? → [Expected behavior]
- What if [concurrent action]? → [Expected behavior]
- What if [permission denied]? → [Expected behavior]

NON-FUNCTIONAL:
- Performance: [Any latency/throughput requirements]
- Accessibility: [A11y considerations if UI-facing]
- Security: [Auth/authz/data handling if relevant]

DEPENDENCIES: [Other stories this depends on, or "None"]
COMPLEXITY: [1/2/3/5/8/13 — Fibonacci story points]
PRIORITY: Must-have / Should-have / Nice-to-have
NOTES: [Implementation hints, design references, or "None"]

Story Categories — Generate All Applicable Types

For every feature, generate stories across these categories:

1. Happy Path Stories

The core user flow. Start here. This is what the user does when everything works.

2. Edge Case Stories

What happens when things are unusual:

• Empty states (no data yet, first-time user)
• Zero/null inputs
• Maximum/overflow conditions
• Concurrent users / race conditions
• Slow connections / timeouts

3. Error Handling Stories

What happens when things go wrong:

• Validation errors (bad input)
• System errors (API down, timeout)
• Permission errors (unauthorized)
• Recovery flows (retry, undo, rollback)

4. Non-Functional Stories

Quality attributes that aren't features:

• Performance (loading time, throughput)
• Accessibility (screen reader, keyboard nav)
• Security (auth, data protection, rate limiting)
• Observability (logging, monitoring, alerting)

5. Tech Debt Stories (if applicable)

Work that's needed but not user-visible:

• Refactoring required to support the feature cleanly
• Data migration
• Infrastructure changes
• Test coverage for existing code being modified

Label these clearly: [TECH DEBT] prefix. These are valid work but should be tracked separately from user-facing stories.

Step 3: Dependency Mapping

After all stories are generated, produce a dependency map:

DEPENDENCY MAP
══════════════
[EPIC-1] ──→ [EPIC-3] (blocks: needs auth before upload)
[EPIC-2] ──→ [EPIC-4] (blocks: needs data model before UI)
[EPIC-5] (independent — can start anytime)
[EPIC-6] (independent — can start anytime)

Suggested implementation order:
1. [EPIC-5], [EPIC-6] — independent, start first
2. [EPIC-1], [EPIC-2] — foundation
3. [EPIC-3], [EPIC-4] — depends on 1 & 2

Critical path: EPIC-1 → EPIC-3 → [launch]

Step 4: Gap Analysis

After generation, audit what might be missing:

GAP ANALYSIS
════════════
✓ Happy path covered: ___ stories
✓ Error handling covered: ___ stories
✓ Edge cases covered: ___ stories
? Non-functional: [List any NFRs that should exist but don't have stories]
? Observability: [Is there a monitoring/alerting story? If not, flag it]
? Rollback: [Is there a feature-flag or rollback story? If not, flag it]
? Documentation: [Does the user-facing doc need updating? If so, add a story]

Missing stories (suggested additions):
1. [Story title] — Reason it's needed: [explanation]
2. [Story title] — Reason it's needed: [explanation]

Step 5: Completion Summary

STORY GENERATION SUMMARY
═══════════════════════════════════════
| Category          | Count | Points |
|──────────────────|───────|────────|
| Happy path        | ___   | ___    |
| Edge cases        | ___   | ___    |
| Error handling    | ___   | ___    |
| Non-functional    | ___   | ___    |
| Tech debt         | ___   | ___    |
|──────────────────|───────|────────|
| TOTAL             | ___   | ___    |

Epics: ___
Dependencies: ___ blocking relationships
Critical path: [Epic chain]
Suggested gaps: ___ additional stories recommended

Ready for: /prioritize → /sprint

LEAN Mode

If --lean is specified, generate only:

• Happy path stories with acceptance criteria
• Top 3 edge cases per epic
• Dependency map
• Skip: Non-functional, tech debt, gap analysis, completion summary

REFINE Mode

If --refine is specified, take existing stories as input and:

• Check each against INVEST criteria
• Add missing acceptance criteria
• Identify missing edge case stories
• Flag stories that are too large (should be split)
• Flag stories that aren't independent (should be restructured)

Formatting Rules

• Stories use the STORY [EPIC-N] format consistently
• Acceptance criteria use Given/When/Then format
• Edge cases are bullet lists with → separating condition from behavior
• Every story has COMPLEXITY and PRIORITY
• Tech debt stories are prefixed with [TECH DEBT]
• After generating all stories for an epic, pause: "Epic [N] stories ready. Continue to next epic?"