| name | to-tickets |
| description | Break an approved plan, specification, or settled conversation into independently verifiable vertical-slice tasks with acceptance criteria and blocking dependencies. Use when the user asks for tickets, issues, a backlog, or work units for multiple sessions or agents. Do not use before requirements are settled, for simple single-session work, or to publish externally without authorization. |
Create Tickets
Turn settled intent into the smallest set of independently executable tasks that can remain green as work progresses.
Read references/evidence.md when selecting task shape, dependencies, or tracker fields. If delegation is explicitly authorized, apply delegate-work only after the dependency graph is settled; use the initial unblocked frontier for assignments and preserve exclusive write ownership.
Respect the Ticket Contract
- Draft tickets in the response by default.
- Create local files only when the user requests them or provides an established location.
- Publish or modify GitHub, Linear, Jira, or another tracker only with explicit authorization and an exact repository or project target.
- Never close, relabel, or modify a parent issue unless the user explicitly asks.
- Do not decompose unresolved product decisions into implementation guesses.
Gather the Source of Truth
Read the complete approved plan, specification, issue, or conversation and its accepted decisions. Inspect the repository enough to understand:
- current architecture and domain vocabulary;
- existing seams and test surfaces;
- data, API, migration, and compatibility boundaries;
- relevant implementation and verification commands;
- expected blast radius.
Use stable component names and verified paths where they help execution. Avoid brittle line numbers and speculative file lists.
Identify Required Preparation
Look for a small prerequisite change that makes later work safer or independently verifiable. Add it only when evidence shows the current structure blocks the requested implementation.
