PRD-13 · SEC. 04 Product & Planning

Turn an Approved Spec into Engineering-Ready Tickets

Split a locked spec into sized tickets with acceptance criteria instead of one vague epic.

FORMAT: workflow
DIFFICULTY: beginner
TIME: 15 min
TOOLS: universal
MODELS: any
COPIES: 0 so far

When to use this

The spec is approved and you're about to hand it to an agent or a teammate to build, but "implement the spec" is still one giant task with no clear stopping points.

The pattern

Pastes as plain text

Break the approved spec into tickets. Find the spec first: use the spec or PRD file in this repo if one exists (docs/, anything named spec or prd) and confirm the file with me. If there isn't one, ask me to paste the spec and wait. For each ticket:
1. Title, one line, verb-first (e.g., "Add rate limit to login endpoint")
2. Acceptance criteria: a checklist of testable conditions
3. Size: S (under 2 hrs), M (half day), L (full day+). If anything is L, say why it can't be split further
4. Depends on: which other tickets, if any (by title)

Flag any P0 requirement in the spec that doesn't map cleanly to a ticket, that's a gap in the spec, not something to silently interpret.

Stop after the ticket list and wait for my review. Once I approve, order the tickets into a build sequence respecting the dependencies you listed, and group them into a first milestone (P0 only) and a second milestone (P1+).

Real example output

"TICKET 1: Add saved-card pre-selection at checkout. AC: returning customer sees last-used card pre-selected, single tap completes payment, falls back to card picker if no saved card. Size: M. Depends on: none.
TICKET 2: Add inline card switcher. AC: user can swap cards without leaving checkout page, selection persists for session. Size: S. Depends on: Ticket 1.
GAP FLAGGED: the spec's P0 'reduce support tickets by half' has no corresponding ticket; it's an outcome metric, not a buildable requirement. Confirm what change actually drives it (likely clearer error messaging on card failure) before this milestone is called complete.

MILESTONE 1 (P0): Tickets 1-2.
MILESTONE 2 (P1): card nicknames, expiry warnings."

Why it works

Sizing and acceptance criteria per ticket give whoever picks it up a concrete stopping point instead of one open-ended epic. The gap-flagging step catches the common case where a spec's goal (a metric) gets treated as a requirement (a feature) and silently dropped.

Related patterns

PRD-02Turn a Rough Idea into a Structured PRDFeed a one-line idea in, get a real PRD out: problem, goals, non-goals, stories, P0/P1/P2.PRD-08Order Features by Dependency Before Sequencing the RoadmapTurn a flat feature list into a dependency-ordered build sequence before assigning sprints.PRD-03Turn a One-Line Task into a Self-Verifying BriefExpand a one-liner into success criteria and a verify step so the agent can loop without you babysitting it.