---

name: story-to-tickets description: Break a user story into documentation and GitHub issues. Use when the user wants to turn a story (a docs/stories/ file or pasted text) into tickets or issues.

Story to Tickets

Break a user story into independent, well-scoped GitHub issues plus a short design doc.

Flow

1. Input: A user story — a docs/stories/<slug>.md file (preferred; ask which one if ambiguous) or pasted text.
2. Break down: Launch the product-manager agent with the story and the relevant parts of the codebase structure. Ask it to return:
   • A short technical design note (what parts of the codebase are touched, in what order)
   • A list of tickets, each independently implementable and testable, as vertical slices, with title, description, and acceptance criteria
3. Document: Write the design note to docs/<slug>-design.md.
4. Create tickets as a parent/subticket hierarchy — one feature (parent) issue plus one subticket per vertical slice:
   • If a GitHub remote exists (git remote get-url origin succeeds):
     1. Create the parent feature issue first (title = the story/feature name, body = feature summary + link to the story/design doc + a task-list placeholder that will be filled in step 3): gh issue create --title "<Feature>" --body "...". Note its number.
     2. Create each vertical-slice subticket with gh issue create --title "..." --body "...", where the body includes a Part of #<parent-number> line and cross-links dependent subtickets.
     3. Update the parent issue's body to add a task list checking off each subticket by number (- [ ] #<n>) via gh issue edit <parent-number> --body "...".
   • If no remote: write the parent ticket to docs/tickets/<slug>-0-<title>.md and each subticket to docs/tickets/<slug>-<n>-<title>.md in the same format, with subtickets noting Part of <slug>-0 and the parent listing them, and tell the user they can be pushed to GitHub later.
5. Report: List the created issues (numbers/URLs or file paths), which are the parent and which are subtickets, and the suggested implementation order.

Ticket format

Title: imperative, scoped (Add health-check polling to dashboard). Body: context (1-2 sentences), acceptance criteria checklist, link to the story/design doc, dependencies on other tickets if any. Subtickets additionally state Part of #<parent-number> (or Part of <slug>-0 when no GitHub remote).