To Tickets — Break Plans into Tracer-Bullet Tickets

Skill Overview

To Tickets is a skill that breaks plans, specification documents, or the contents of an ongoing conversation into a set of “tracer-bullet tickets.” Each ticket is a complete vertical slice spanning all layers, explicitly states which tickets it depends on, and is finally published to your configured task tracker in dependency order.

Use Cases

1. Turning a completed plan into actionable tasks: You have already written a technical plan or PRD, or have discussed what needs to be built with AI, but are facing a long document without knowing where to make the first cut. To Tickets breaks it into a set of tickets with clear boundaries and dependencies, ready to enter the development queue.

2. Defining task boundaries for team collaboration: When several people are developing the same feature in parallel, the hardest part is not writing code but making it clear who goes first and who is waiting on whom. Each ticket identifies the prerequisite tickets blocking it. Unblocked tickets can start immediately, while blocked tickets make it obvious at a glance what they are waiting for.

3. Making large refactors safer: For broad refactors—such as renaming a field or changing a shared type—that affect thousands of call sites, forcing everything into one vertical slice will only leave CI red for an extended period. To Tickets arranges the work as “expand first, migrate in batches, then contract,” so that every batch can remain green on its own.

Core Features

1. Vertical slicing instead of layer-by-layer splitting: Each ticket is a narrow but complete path through the system, connecting the data structure, interface, UI, and tests in one pass. Once completed, it can be demonstrated or validated. It will not give you a horizontal split such as “finish all database changes first, then finish all interfaces”—that approach produces nothing verifiable when any individual layer is complete. Each ticket is sized so that it can be completed within a fresh context window.

2. Explicitly declared blocking relationships: Every ticket lists the “tickets blocking it.” Tickets with no prerequisites can start immediately; the remaining tickets are queued in dependency order, forming a clear progression. During development, you only need to focus on the “frontier”—the batch of tickets whose prerequisites have all been completed.

3. Publishing according to the tracker’s format: If a local file is configured, tickets are numbered in dependency order under .scratch/<feature-name>/issues/, with one Markdown file per ticket and blocking relationships written in the files. If a real issue tracker such as GitHub or Linear is configured, issues are created one by one in dependency order, with platform-native blocking/subtask relationships used where possible to express dependencies. They are also automatically tagged with the ready-for-agent label so that an Agent can claim them directly.

Frequently Asked Questions

What is a “tracer-bullet” ticket? How is it different from a regular task?

A tracer bullet originally refers to a visible bullet fired first to confirm the trajectory before unleashing full firepower. In development, a tracer-bullet ticket must be a complete narrow path spanning every layer: it touches the data structure, interface, UI, and tests, but implements only the thinnest layer at each point. Its acceptance criterion is “can be demonstrated or validated when complete,” rather than “this layer is finished.” This is different from a horizontal task such as “implement CRUD for the user table,” which leaves users unable to see anything when completed.

Where are the resulting tickets stored? Which trackers are supported?

That depends on your configuration. In local mode, each feature gets its own directory. Tickets are numbered in dependency order as 01, 02, and so on; each ticket has its own file, with smaller numbers indicating earlier work. The files specify which ticket numbers block them. In real-tracker mode, issues are created one by one in the same dependency order and linked using the platform’s native blocking relationships. The ticket content is the same in both modes; only the way blocking relationships are expressed differs.

Do I need to approve the split granularity? Will it modify my original issue directly?

You will be asked to confirm first. The skill initially presents the proposed breakdown as a numbered list. For each ticket, it identifies the title, what blocks it, and the behavior it ultimately delivers, then asks you three questions: Is the granularity appropriate? Are the blocking relationships correct? Is anything that should be merged or split into smaller pieces? Only after you confirm will the tickets actually be published. It will not close or modify any parent issue—the split creates new issues rather than overwriting existing ones.