How to use the To Tickets agent skill: install and run it

What is an agent skill, and what does to-tickets do?

An agent skill is a packaged set of instructions that an AI agent can load when a task matches it. The to-tickets skill, from mattpocock/skills under skills/engineering/to-tickets (MIT licence), teaches the agent a specific process: take a plan, spec, or the current conversation, and turn it into tracer-bullet tickets.

A tracer-bullet ticket is a narrow but complete slice of work that cuts through every layer it touches, such as schema, API, UI and tests, so it can be demoed or verified on its own. Each ticket declares its blocking edges, meaning the other tickets that must complete before it can start. A ticket with no blockers can start immediately.

• Reads context from the conversation, or from a spec path or issue number/URL you pass in
• Optionally explores the codebase to match domain vocabulary and existing decisions
• Proposes a numbered breakdown with blocked-by relationships and asks you to approve or adjust it
• Publishes approved tickets as local markdown files or as real issues on your configured tracker

Install the to-tickets skill

You can install the skill in one of two ways. Download the ZIP from this page and unzip it into your personal skills folder at ~/.claude/skills/, or into a project's .claude/skills/ folder if you want it available only in that repository.

In the Claude apps, you can instead upload the skill under Settings → Capabilities → Skills.

• Personal install: unzip into ~/.claude/skills/
• Project install: unzip into the project's .claude/skills/ folder
• Claude apps: Settings → Capabilities → Skills, then upload the skill

Set up your tracker before the first run

The skill expects an issue tracker or local file setup to already exist. It reads the tracker and triage label vocabulary that should have been provided to it. If that configuration is missing, the skill tells you to run /setup-matt-pocock-skills first, so run that before you ask for tickets.

Publishing to a real tracker such as GitHub or Linear also needs tracker access and credentials. The source does not specify exactly how these are supplied, so check your setup for the tracker you use.

How do you trigger the skill with a natural request?

The skill is set to disable automatic model invocation, so ask for it explicitly and name the work you want broken down. Give it the plan or spec in the conversation, or pass a reference such as a spec path or an issue number or URL. The skill will fetch that reference and read its full body and comments.

Good requests state the goal and the source. Describe what you want built, point to where the plan lives, and say whether you want local files or a tracker.

• Use the plan we just wrote for the CSV export feature and turn it into tickets using the to-tickets skill.
• Using the to-tickets skill, break spec docs/billing-v2.md into tickets and show me the breakdown before publishing.
• Use the to-tickets skill on issue 412 and make each ticket a sub-issue of it.

What happens during a run?

The agent first gathers context, then may explore the codebase and look for small prefactoring steps that make the main change easier. It drafts vertical slices and presents them as a numbered list with each ticket's title, blocked-by list, and what it delivers.

You are asked whether the granularity is right, whether each blocking edge is genuine, and whether any tickets should be merged or split. The agent iterates until you approve. Only after approval does it publish. Work proceeds along the frontier, meaning any ticket whose blockers are all done.

• Local files: one file per ticket at .scratch/<feature-slug>/issues/<NN>-<slug>.md, numbered from 01 in dependency order
• Real tracker: one issue per ticket, blockers first, using native blocking links where the platform has them, otherwise a Blocked by list
• New tickets get the ready-for-agent triage label unless you instruct otherwise
• The skill does not close or modify any parent issue

Handle large refactors with expand, migrate and contract

For a mechanical change that touches a huge number of call sites, such as renaming a column or retyping a shared symbol, the skill does not force vertical slices. It sequences the work as expand, migrate and contract. First the new form is added beside the old, then call sites are migrated in batches (per package or per directory), and finally the old form is deleted once no caller remains.

If the batches cannot stay green on their own, the skill lets them share an integration branch that all block a final integrate-and-verify ticket.