prd-to-issues

name	prd-to-issues
description	Splits a PRD into vertical-slice GitHub issues with HITL/AFK tagging and dependencies. Triggers: PRD to issues, create tickets, break down PRD, work items.
effort	medium
disable-model-invocation	true
argument-hint	[PRD issue number]
allowed-tools	Read, Grep, Glob, Bash

PRD to Issues

$ARGUMENTS

Break a PRD into independently-grabbable GitHub issues using vertical slices (tracer bullets).

Usage

/prd-to-issues [PRD issue number]

What This Command Does

1. Fetches PRD from GitHub issue
2. Explores codebase for context
3. Drafts vertical slices with HITL/AFK classification
4. Quizzes user on breakdown
5. Creates GitHub issues in dependency order via gh issue create

Process

1. Locate the PRD

Fetch with gh issue view <number> (with comments). If no number provided, ask.

2. Draft Vertical Slices

Each issue is a thin vertical slice cutting through ALL layers end-to-end.

Classification	Description
AFK	Can be implemented and merged without human interaction (prefer)
HITL	Requires human decision — architectural choice, design review, etc.

3. Quiz the User

Present as numbered list. For each slice show:

• Title: short descriptive name
• Type: HITL / AFK
• Blocked by: which other slices must complete first
• User stories covered: which stories from the PRD

Ask:

• Granularity right? (too coarse / too fine)
• Dependency relationships correct?
• HITL vs AFK classification correct?
• Any slices to merge or split?

Iterate until approved.

4. Create GitHub Issues

Create in dependency order (blockers first) so real issue numbers can be referenced.

Use gh issue create with the template below for each slice.

Issue Template

Parent PRD

#{prd-issue-number}

What to build

Concise description of this vertical slice. End-to-end behavior, not layer-by-layer. Reference parent PRD sections, don't duplicate.

Acceptance criteria

• Criterion 1
• Criterion 2
• Criterion 3

Blocked by

• Blocked by #{issue-number} (if any)

Or "None — can start immediately" if no blockers.

User stories addressed

Reference by number from the parent PRD:

• User story 3
• User story 7

Rules

• MUST slice vertically — every issue cuts through schema, API, UI, tests end-to-end. Horizontal slices (all-schema, then all-API) defer integration risk.
• MUST create issues in dependency order so blockers have real issue numbers to reference
• NEVER close or modify the parent PRD issue — it is the reference anchor for every child issue
• NEVER include file paths, line numbers, or function names in issue bodies — they go stale before the issue is picked up
• CRITICAL: maximize parallelism. Independent issues have zero Blocked by entries; if every issue has blockers, the slicing is wrong.
• MANDATORY: every issue lists the user stories it addresses by number from the parent PRD — traceability matters more than brevity

Gotchas

• gh issue create opens $EDITOR without --body or --body-file. In automation, this hangs silently. Always pass the body explicitly.
• Dependency chains longer than 3 hops (A blocks B blocks C blocks D) almost always mean the slicing is too thin. Collapse the chain into fewer, wider slices.
• GitHub issue numbers increment globally in the repo. Creating 5 issues with forward references (#124 blocks #125) requires the blocker to land before the blocked — order matters, and a mid-batch failure leaves dangling references.
• AFK issues (no human interaction) appear attractive but the label is aspirational. Real AFK requires green CI, clear acceptance criteria, and no design ambiguity — misclassifying HITL as AFK creates reopens.
• User stories referenced by "number from the PRD" drift if the PRD gets edited. Quote the story text inline if it is short, or pin to a PRD anchor (#issue-42 > User Story 7) to resist drift.

When NOT to Use

• For breaking a PRD into a plan (phases, no issues yet) — use /prd-to-plan
• For writing the PRD itself — use /write-a-prd
• For filing a single bug — use /qa-session or /triage-issue
• For a plan that exists but has no PRD — use /plan then revisit this skill
• For triaging existing issues (not creating new ones) — this skill is create-only