to-tickets

Split into Tickets

Split the plan, spec, or conversation into a set of ticket—tracer-bullet vertical slices, each declaring the other tickets that block it.

The issue tracker and triage label vocabulary should already be given to you—if not, tell the user to run /setup-matt-pocock-skills。

Process

1. Gather context

Start with what's already in the conversation context. If the user passed a reference (a spec path, an issue number, or a URL) as an argument, fetch it and read its full body and comments.

2. Explore the codebase (optional)

If you haven't already explored the codebase, get to know the current state of the code. Ticket titles and descriptions should use the project's domain glossary vocabulary and respect the ADRs of the area you're touching.

Look for opportunities for pre-refactoring the code to make the implementation simpler. "Make the change easy, then make the easy change."

3. Draft vertical slices

Split the work into tracer bullet ticket。

• Each slice takes a narrow butcompletepath through every layer (schema, API, UI, tests)—vertical, not a horizontal slice of one layer
• A finished slice is demonstrable or verifiable on its own
• Each slice is sized to fit in a single fresh context window
• Any pre-refactoring should be done first

For each ticket, specify itsblocking edges—the other tickets that must be completed before it can start. A ticket with no blockers can start immediately.

Large-scope refactoring is the exception to vertical slices. Large-scope refactoring is a mechanical change (renaming a column, changing the type of a shared symbol) whoseblast radiusspans the whole codebase, where a single edit breaks thousands of call sites at once, so that no vertical slice can stay green. Don't force it into a tracer bullet; serialize it as an expand-contract sequence. First expand: add the new form alongside the old form, making sure nothing is broken. Then migrate the call sites in batches sized by blast radius (by package, by directory), one ticket per batch blocked by the expansion, and since the old form still exists, CI stays green between batches. Finally contract: once all callers are migrated, delete the old form, as a ticket blocked by every migration batch. When the batches themselves also cannot stay green individually, keep the sequence but have them share an integration branch, with all batches blocking a final "integrate and verify" ticket—green is only promised there.

4. Ask the user for feedback

Present the proposed breakdown as a numbered list. For each ticket, show:

• Title: a short descriptive name
• Blocked by: which other tickets (if any) must be completed first
• What it delivers: which end-to-end behavior this ticket makes work

Ask the user:

• Is the granularity right? (too coarse / too fine)
• Are the blocking edges correct: does each ticket depend only on the tickets that truly constrain it?
• Should any tickets be merged or split further?

Iterate until the user approves the breakdown.

5. Publish the tickets to the configured tracker

Publish the approved tickets.How to publishDepends on the tracker configured in /setup-matt-pocock-skills —the tickets themselves are the same, only the form of the blocking edges differs:

• Local files → write one file per ticket under .scratch/<feature-slug>/issues/<NN>-<slug>.md , numbered in dependency order starting from 01 (blockers first). Each file's "Blocked by" lists the number/title it depends on. Use the per-ticket file template below: one ticket per file, never merge into a single file.
• Real issue tracker (GitHub, Linear, ...) → publish one issue per ticket in dependency order (blockers first), so each ticket's blocking edge can reference a real identifier. Use native blocking relations when the platform supports them; otherwise set each ticket's "Blocked by" to the issue blocking it. If the source is an existing issue, make each ticket its sub-issue (using the operations in the tracker documentation). Unless otherwise instructed, apply the ready-for-agent triage label—these tickets are themselves agent-claimable.

Proceed byfrontier: any ticket whose blockers are all complete. For a purely linear chain, that is top to bottom.

Do not close or modify any parent issue.

: <Ticket title>

What to build: Which end-to-end behavior this ticket makes take effect—from the user's perspective, not a layer-by-layer implementation checklist.

Blocked by: The number/title of other tickets that constrain this ticket, or "None (can start immediately)".

Status: ready-for-agent

• Acceptance criterion 1
• Acceptance criterion 2

Parent

Reference to the parent issue on the tracker (if the source is an existing issue, otherwise omit this section).

What to build

Which end-to-end behavior this ticket makes take effect—from the user's perspective, not layer-by-layer implementation.

Acceptance criteria

• Criterion 1
• Criterion 2

Blocked by

• A reference to each blocking ticket, or "None (can start immediately)". If the blocking relations are already set via native edges, omit this section.

Either way, avoid concrete file paths or code snippets—they go stale quickly. Exception: if a snippet produced by the prototype encodes a decision more precisely than prose (state machine, reducer, schema, type structure), inline it and briefly note that it comes from the prototype. Keep it to the decision-dense parts—not a working demo, just the parts that matter.