Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →sociotechnica-org/to-tickets
Decompose a decided plan, spec, issue, or design conversation into dependency-ordered tracer-bullet tickets written as local markdown files.
Passed 16 of 21 test cases with the skill, and 11 of 21 without it.
and 4 more in the full report
7 fixed10 passed either way3 still failing2 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 7 test cases the skill fixed. Same model, same prompt, with and without the skill.
Where should the generated markdown tickets be stored by default when breaking down a feature named 'User Analytics'?
| Checked | Without skill | With skill |
|---|---|---|
| Proposes storing output in tickets/user-analytics/ rather than a hidden dot directory like .tickets/. | Missed | Passed |
The instructions your model reads when the skill loads.
Decompose an already-decided scope into vertical-slice implementation tickets with dependency ordering. Each ticket is a thin, end-to-end tracer bullet through every affected layer. You produce local markdown files — you never talk to a tracker API.
Work from whatever is already in the conversation. If the user passes a reference (spec path, issue URL), fetch and read it.
Stop if input is too vague. If there is no clear what-to-build and no scope boundaries, do not invent tickets. Tell the user what's missing:
I need at least: what to build, why, scope boundaries, and any constraints (tech stack, patterns). Can you provide more detail?
If the user has already sketched a partial breakdown, work with that structure — do not discard it and start from scratch.
If the conversation already contains file paths, function names, or architectural references specific to the project, skip this step.
Otherwise, explore the codebase to:
Ask the user where to write tickets. Default to tickets/<slug>/ relative to the project root. Derive the slug from the scope description. One question, one line:
I'll write tickets to
tickets/<slug>/. OK, or different path?
Never use a hidden dot-directory. Never cache the answer.
Break the work into tickets. Each ticket must follow these rules:
test cases passed, vs 11 / 21 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.