PRD-14 · 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. Use the spec file in this repo if I name one in my next message, otherwise use what I paste below the line. 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.

Paste the spec below this line (or name the file instead):

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.