---
name: spec-to-tickets
description: "Slices a spec into thin end-to-end tickets with blocking links, each one demoable on its own rather than a layer-by-layer task list. Use when an agreed spec must become a set of thin vertical tickets with dependencies that can be built and demoed one by one. Do not use for writing the spec itself or planning day-level coding tasks inside one ticket. Related topics: product, productivity."
---

# Spec to Tickets

Slices a spec into thin end-to-end tickets with blocking links, each one demoable on its own rather than a layer-by-layer task list.

## When to use

Use this skill when an agreed spec must become a set of thin vertical tickets with dependencies that can be built and demoed one by one. Do not use it for writing the spec itself or planning day-level coding tasks inside one ticket.

## Workflow

1. Ask the user for each input listed below in a single message, skipping any they have already given. Where options are listed, offer them, but accept other answers too.
2. Find the thinnest end-to-end path through every layer and make it the first ticket.
3. Add later tickets that each widen the path by one behavior, never splitting by layer.
4. Give each ticket an outcome, a demo line, acceptance criteria from the spec, a size and a blocked-by list.
5. Check the blocking edges for cycles and mark which tickets can run in parallel.
6. Propose an order and list the gaps the spec leaves unspecified.

## Inputs

- **The spec** (longer free text)
- **Team and stack** (free text, e.g. "Who builds it and with what")
- **Ticket tracker format** (choose one: Plain markdown, GitHub issues, Linear style)
- **Target ticket size** (choose one: Under a day, One to two days, Up to a week)
- **Existing work to build on** (longer free text)

## Output

A list of tickets in the chosen format with outcome, demo, acceptance criteria, size and blockers, then a suggested order and spec gaps.

## Prompt template

Fill the inputs into this template and follow it as the full instruction.

### Spec to Tickets

Break this spec into tickets.

- The spec: {{The spec}}
- Team and stack: {{Team and stack}}
- Ticket tracker format: {{Ticket tracker format}}
- Target ticket size: {{Target ticket size}}
- Existing work to build on: {{Existing work to build on}}

Slice vertically as tracer bullets: the first ticket is the thinnest path that runs end to end through every layer, even if crude, so the riskiest integration is proven early. Each later ticket widens that path with one behavior. Never split by layer such as database, then API, then interface, since none of those can be demoed alone. Every ticket needs a title, the user-visible outcome, a demo line saying how to show it working, acceptance criteria drawn from the spec, size, and a blocked-by list. Draw the blocking edges so independent tickets can run in parallel, and name any ticket that blocks the most others. Finish with a suggested order and a note on what the spec leaves unspecified.

## Pitfalls

- Tickets sliced by layer, so nothing works until the last one lands.
- A first ticket so large it is the whole feature, which defeats the early proof.
- Dependencies that form a loop, leaving the team with nothing startable.