---
name: plan-create-stories
description: Decomposes a PRD into well-formed, engineer-ready tickets — Jira issues or GitHub issues. Use after a PRD exists, to turn its phases and user stories into a structured backlog. Works for a new codebase (MVP scope) or an existing one (epic scope).
argument-hint: <prd-path> --platform <jira|github> [--project KEY] [--epic KEY] [--milestone NAME]
---

# Create Stories: PRD → Ticket Backlog

## Overview

Turn a finished PRD into a backlog of small, well-formed tickets. Each
Implementation Phase in the PRD becomes a group of tickets; each User Story
becomes one or more tickets with explicit acceptance criteria.

This skill is platform-agnostic by design — the **`--platform` flag** decides
whether the backlog lands in Jira or in GitHub Issues. Everything before that
flag (reading the PRD, decomposing it, writing acceptance criteria) is
identical.

## Arguments

| Argument | Required | Meaning |
|----------|----------|---------|
| `<prd-path>` | yes | Path to the PRD produced by `plan-create-prd` |
| `--platform` | yes | `jira` or `github` — where the tickets are created |
| `--project` | jira only | Jira project key (e.g. `HELP`) |
| `--epic` | jira only | Jira epic key to parent the tickets under (e.g. `HELP-1`) |
| `--milestone` | github only | optional GitHub milestone to attach issues to |

If `--platform` is missing, **stop and ask** — do not guess.

## Workflow

### 1. Read and decompose the PRD
- Read `<prd-path>` in full.
- Walk the **Implementation Phases** section. Each phase is a ticket group.
- Walk the **User Stories** section. Each story maps to one ticket (split if it
  hides more than ~a day of work).
- For every ticket, draft:
  - **Title** — imperative, specific (`Add token refresh endpoint`, not `Auth`).
  - **Description** — what and why, linked back to the PRD phase.
  - **Acceptance criteria** — a checklist a reviewer can verify.
  - **Phase label** — which PRD phase it belongs to.
- Keep tickets small. A ticket that can't be described in one screen is two
  tickets.

### 2. Confirm the plan before creating anything
Print the proposed ticket list (titles + phase grouping) and the target
platform. This is the checkpoint — creating real tickets is not reversible in
one click.

### 3. Create the tickets — branch on `--platform`

**`--platform jira`:**
- Use the Atlassian MCP server.
- Create each ticket under `--epic` in `--project`.
- Map: PRD phase → a label or the epic; acceptance criteria → the description.
- Capture each created issue key.

**`--platform github`:**
- Use the `gh` CLI: `gh issue create --title "..." --body "..." [--label phase-N] [--milestone "..."]`.
- Put acceptance criteria in the issue body as a markdown checklist.
- Apply a `phase-N` label per PRD phase (create the label if missing with
  `gh label create`).
- Capture each created issue number/URL.

### 4. Report
- A table: ticket title → phase → created key/number/URL.
- The PRD path the backlog was generated from.
- Next step: each phase is now ready to run as a PIV loop.

## Quality Checks

- ✅ Every ticket traces back to a PRD phase or user story
- ✅ Every ticket has verifiable acceptance criteria
- ✅ Tickets are small (≤ ~1 day of work)
- ✅ The correct platform was used and every create succeeded
- ✅ Phase grouping is preserved (labels/epic) so the backlog stays navigable

## Notes

- Greenfield vs brownfield changes the PRD's *scope* (MVP vs next epic), not
  this skill — `plan-create-stories` runs the same either way.
- Never create tickets without the step-2 confirmation.
- If a phase is too vague to decompose, stop and flag it — that's a PRD gap,
  not a ticket-writing problem.