to-tickets
To Tickets
Break a plan, spec, or conversation into a set of tickets: tracer-bullet vertical slices, each declaring the tickets that block it.
Not model-discoverable in practice. A human may name it, and /specs-to-tickets calls it — one spec at a time, at its step 3. Do not invoke it because a plan or a spec happens to be in front of you: publishing a set of tickets to a shared tracker is asked for, never volunteered, and a slice made outside a settled spec slices a plan nobody has agreed to yet.
The issue tracker and triage label vocabulary should have been provided to you. If not, tell the user to run /setup-matt-pocock-skills.
Adapted from Matt Pocock's /to-tickets; the slicing method below is his.
Approvals go on the tracker. The granularity chosen at step 3, and every merge or split the human asks for at step 5, are decisions — follow the approval-policy skill for recording them. A ticket body says what to build; if the human's reasoning for a boundary needs keeping, it goes in a comment on the ticket or the parent, never inside the spec being sliced.
Process
1. Gather context
Work from whatever is already in the conversation context. If the user passes a reference (a spec path, an issue number or URL) as an argument, fetch it and read its full body and comments.