to-tickets
To Tickets
Break one spec into tickets — tracer-bullet vertical slices, each declaring the tickets that block it. A ticket is one session of build work, and it is the smallest unit the pipeline tracks.
Pipeline position: wayfinder (decide) → to-spec (write the spec) → to-tickets (break it into tickets) → implement (build one ticket per session).
Process
1. Gather context
Work from whatever is already in the conversation. If the user passes a reference — a spec path, or a wayfinder map when the effort skips the spec — fetch it and read its full body and comments. On a map, the source is the map plus every closed decision ticket's ## Resolution.
2. Explore the codebase when applicable
When the work targets an existing codebase and you haven't already explored it, inspect the current state. Ticket titles and descriptions use the project's domain vocabulary (CONTEXT.md/glossary if present) and respect ADRs in the area. For greenfield or non-code work, continue from the gathered context.
Look for opportunities to prefactor — restructure first so the feature lands cleanly. "Make the change easy, then make the easy change." Prefactors become the first tickets.