to-tickets

Splits plans and specifications into independently verifiable tickets with explicit blocking dependencies.

Updated Jul 3, 2026
One-click install
npx skills add https://github.com/alex-jordan547/agent-setup --skill to-tickets-alex-jordan547
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: to-tickets
Source: https://github.com/alex-jordan547/agent-setup/tree/main/skills/to-tickets
Command: npx skills add https://github.com/alex-jordan547/agent-setup --skill to-tickets-alex-jordan547

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Turning a plan or specification into actionable work items often produces vague, overlapping, or unverifiable tickets. This Skill converts a source plan into bounded tickets with clear acceptance criteria and explicit blocking dependencies, avoiding duplicate or unverifiable work items. ## Core Features & Use Cases - Ticket Decomposition: Breaks a plan into tickets that each deliver a bounded, observable behavior across the necessary layers rather than unverifiable schema/API/UI splits. - Dependency Mapping: Declares only true blocking dependencies and identifies shared integration branches or coordinated deployment requirements for broad contract migrations. - Tracker Integration: Creates blockers first, uses returned identifiers for native dependency links, and verifies the resulting items when publication is authorized. - Use Case: Given an approved migration specification, produce a sequenced set of tickets where each one can be verified independently, with expand-migrate-contract ordering for contract changes. ## Quick Start Split the attached specification into independently verifiable tickets with acceptance criteria and blocking dependencies.

Frequently Asked Questions about to-tickets

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I break a specification into tickets?

Read the source plan and relevant code, then create tickets that each deliver a bounded behavior with observable acceptance criteria. Prefer a complete path across layers over separate schema, API, and UI tickets that cannot be verified alone.

How to handle dependencies between project tickets?

Declare only dependencies that truly block work, and create blocker tickets first so their returned identifiers can be used for native dependency links in the tracker. For broad contract migrations, use an expand, migrate callers, then contract sequence.

What should a good engineering ticket include?

A ticket should include a title and source spec, the behavior delivered with scope limits, acceptance criteria and verification steps, and any blocking tickets or an explicit statement of none. Use the project's own ticket template when one exists.

Can tickets be created directly in my issue tracker?

Yes, when publication is authorized the Skill creates blockers first, links dependencies using returned identifiers, and verifies the resulting items. Without authorization it provides the proposed tickets locally instead.

When should a migration not be split into independent tickets?

When a broad contract migration cannot land in independent slices, avoid promising that incompatible intermediate states work alone. Instead identify shared integration branches or coordinated deployment requirements explicitly.