to-tickets

name	to-tickets
description	Run when the user says "break this down", "create tickets", "create issues", "milestone plan", "split this into tasks", or hands over a spec / grilled plan that is too big for one session. It converts a spec into TRACER-BULLET tickets: thin end-to-end slices, each independently verifiable, with explicit blocking edges — never horizontal layers ("all the schema first, then all the logic, then all the tests"). Use even if the work "naturally" splits by layer — that split is precisely the failure mode this skill blocks. Slash alias: /to-tickets.
metadata	{"short-description":"Spec -> tracer-bullet tickets: thin end-to-end slices with explicit blocking edges"}

To tickets (tracer-bullet work breakdown)

Tracer bullet, defined

A tracer-bullet ticket cuts one narrow but COMPLETE path through every layer the feature touches: data + logic + surface + test, all in one ticket. When it lands, something end-to-end demonstrably works, however small. Horizontal layers defer all integration risk to the final ticket; tracer bullets pay it down on ticket one. This slicing catches integration surprises early; it does not make them impossible.

Workflow

1. Gather the source. Work from the spec (/to-spec output), the grilled plan, or the conversation. Fetch any referenced issue in full. If no acceptance checks exist yet, stop — tickets without checks are un-closeable; route back to /to-spec.
2. Scout for prefactoring. Read the touched area of the codebase. If a small preparatory refactor would make every later slice easier, make it ticket 01: make the change easy first, then make the easy change.
3. Draft vertical slices. For each slice, write:
   • Title — the behavior it delivers, user-visible phrasing.
   • What it delivers — end-to-end behavior, not layer-by-layer steps.
   • Verify by — the command/check that proves it landed. In this repo that usually means a script-mode CI test (see ci-script-test-bootstrap) or a gate from verification-recipe-runner.
   • Blocked by — the tickets that must land first. No blockers = startable now. The unblocked set is the frontier; work it one ticket per session. Size each slice to fit one fresh context window with room to verify.
4. Handle the wide-refactor exception. One mechanical change with a blast radius across the codebase (rename a shared symbol, retype a column) cannot be a vertical slice. Sequence it expand–contract: an expand ticket adds the new form beside the old; migrate tickets move call sites in batches (per package/directory), each blocked by the expand, CI green after each batch; a contract ticket deletes the old form, blocked by every migrate.
5. Quiz the user. Present the numbered breakdown (Title / Blocked by / What it delivers) and ask specifically: too coarse or too fine anywhere? are the blocking edges right? any merges/splits? Iterate until approved — the breakdown is a proposal, not a decree.
6. Publish in dependency order — blockers first, numbered from 01 — to wherever the user tracks work (GitHub issues with native blocking links, or one markdown file per ticket in a scratch directory; never one combined file). Ticket bodies follow the same no-stale-coordinates rule as /to-spec: no file paths, no snippets, except a snippet that encodes a decision.
7. Per-ticket execution scaffolding is NOT this skill. When a ticket is a recurring repo shape — run a gated eval, land an evidence artifact, resolve a ledger conflict — stamp its execution scaffold from task-blueprint. This skill decides the slicing and the edges; task-blueprint supplies the eval/evidence scaffolds inside a ticket. They compose; neither replaces the other. Likewise each ticket's landing sequence is git-discipline + verification-recipe-runner, not something to restate per ticket.

Composition

• Upstream: /grill-the-plan (decisions), /to-spec (the durable source).
• Sideways: /wayfinder when slices cannot even be named yet — investigation before decomposition.
• Downstream: task-blueprint (in-ticket scaffolds), ci-script-test-bootstrap (test shape), session-handover (state between ticket-sessions).

Do not

• Do not cut horizontal layers ("backend ticket, frontend ticket, tests ticket") — every slice carries its own test or names why it cannot.
• Do not emit a ticket without a "Verify by"; un-checkable tickets accumulate as permanently-open noise.
• Do not leave blocking edges implicit ("obviously B needs A") — write them, they define the frontier.
• Do not size a ticket beyond one session; if it needs a handover mid-ticket, it is two tickets.
• Do not publish before the user approves the breakdown.
• Do not close or rewrite the parent spec/issue when publishing children.

Method adapted from mattpocock/skills skills/productivity/to-tickets/SKILL.md (MIT) — see THIRD_PARTY_NOTICES.md.